spunfin
-
Content Count
89 -
Joined
-
Last visited
-
Medals
-
Medals
-
Everything posted by spunfin
-
AVIBIRD 1, You were actually right, there was tiny typo in current fillHouse.sqf! Sorry for this issue! :) Here's fixed version: http://kaartomedia.com/ARMA/fillHouse.sqf OR If you have made changes, fix it yourself manually: In default version line 152 is: call compile format["LVgroup%1spawned = true;", _grpId]; And it should be: call compile format["LVgroup%1spawned = 'true';", _grpId];
-
@AVIBIRD 1, Sent pm about the changes for delay tweak. For empty vehicles, have you tried this fix; http://forums.bistudio.com/showthread.php?165089-AI-Spawn-Script-Pack&p=2588051&viewfull=1#post2588051
-
Hey darkymdq007, Nice song lol! :) execVM "LV\LV_functions\LV_fnc_simpleCache.sqf" if you're using it like that, as simpleCachev2 is ment to be used a bit differently; here's Na_Palms' thread for it.
-
Thanks Mariodu62, I included that also now to the file above.
-
Great work Champy! I'm sure this has been causing issues for other people too, so here's a version of reinforcementChopper.sqf which is adjusted to work better (by -=XTRA=-); http://kaartomedia.com/ARMA/reinforcementChopper.sqf The magic lines are 162, 168 and 169.
-
gobi42, I'll ask around if my buddies have seen that issue. You're right that it's probably just something small since people are using it in dedicated servers. SilentSpike, Semicolons will actually break that, as compiles stuff after finding one. So to fix if, you should just use custom init to execVM a file which would have that switch block in it.
-
Hey redarmy o/ Unfortunately I havent found your issue yet, but I'll take a look tomorrow when it's finally free day for me. :) And yes I'll try to keep things updated if BIS makes some script breaking changes, but let's hope they dont. Yes you can run multiple instances from single init line, or, use multiple game logics. Just avoid using identical ID -parameters if you need to use them, otherwise there will be some issues. Also, if you use fillHouse & militarize in large scale, you should consider checking out simpleCacheV2 by Na_Palm to avoid performance issues.
-
Yes that's the case, if you feel like it. :) Usually mission makers gives credit, but I've never required it. It's possible, but you would have to edit the scripts a bit to add new classnames. For example for ambientCombat; in "LV\LV_functions\LV_fnc_menGroup.sqf" you can find arrays "_OPFmen" and "_OPFmen2". These 2 arrays holds classnames for east side units ambientCombat uses, so replace those classnames or add other classnames among those to get new units appear.
-
I'm not sure what ghost mode does - but if it uses setCaptive and you have MP parameter set to true, it will cause issues as AC looks for non-captive alive units from playableUnits and orients patrolling to them. Too many avoid markers could also surely cause this, but not permanently I think, as eventually the loop should find a new position unless surrounding area is 100% suppressed with them. You could try teleporting to another location and see if this issue persists. If issue is still there, try changin patrol type parameter from waypoint behaviour array to 1 and they should use doMove. You could also open LV_functions\LV_fnc_ACpatrol.sqf and uncomment lines 15-31 and 113 and 114, then you should see blue markers on group positions and green markers on waypoint positions always when ACpatrol does something.
-
Hey, You could do this by editing classname arrays at fillHouse.sqf lines 61-62 (or making your custom copy of this file and editing it if you want to use also the original at the same mission). Currently it has 2 classname arrays for OPFOR and it randomly picks one of them where it picks randomly classnames. So populating those two arrays (_redMenArray and _redMenArray2) only with CSAT classnames would do. For naming the unit you could use custom init, eg. "this setVehicleVarName 'CSAT_guy'; CSAT_guy = this;" Example of full calling line: nul = [spot,2,true,1,0,2,"default",nil,"this setVehicleVarName 'CSAT_guy'; CSAT_guy = this;",nil] execVM "LV\fillHouse.sqf"; OR, you could use ID Number parameter of fillHouse: if you set it for example to 1, then you CSAT guy's group can be identified with LVgroup1 and you can refer to the unit itself with (leader LVgroup1), and if he's alive, this will return 1: ({alive _x} count units LVgroup1) .
-
Odd, "ACavoid" should be valid as avoid marker, gotta see why it has stopped working. Indeed, CARELESS could then also be reason for issues. You could maybe try SAFE (to lines 161, 164 and 168). Point of using careless was just to make sure they would really fly directly the path you want, triggering line 191, but let's see how it goes with other behaviours. :)
-
Hey guys, great work again on fixing things and finding reasons for issues! :) About reinforcementChopper - I haven't seen all the changelogs yet on new arma patches, but this could refer to misbehaviour (or misuse?) of isFlatEmpty, as it's being used when exact == false. (line 167) Paradrop - If whole chopper dissapears before paradrop, it must be spawn block at line 174. If jumpers just doesnt appear but heli flies thru path, then it's somekind of distance issue (line 191). Militarize & fillHouse - Nice fixes, but I think if("_milGroup" == "nil0") can cause some issues in scenario where group is respawning from cache with group parameter set to nil, as we're now comparing here only two strings. But this would mess up only the original simpleCache I think, so no worries. :) We should just take some time and clean up the whole script and get rid of simpleCache(1) related stuff etc. I'll get back to these issues on better time, especially that reinforcementHeli issue is now bothering me.
-
Hey redarmy, I actually didn't think about that feature, so currently you would probably get that outcome (kinda) by using a trigger to mark the area where you need units to spawn -> when player(s) triggers it, AC would be called and 'centerUnit' -parameter would be array of players who are inside that trigger area. When player(s) leave the area, trigger would execute LV_fnc_removeAC.sqf. If you decide to try this, you need also to make sure this trigger will be repeating, but not if it hasn't been deactivated first, so you would use global variable in both act -fields. This is messy method, and outcome might be ugly with multiple players, as you can't update 'centerUnit' array on the fly (without some modifications). But I'll keep this feature on mind when I get to rewrite AC. :)
-
Heys Baddazs, For AmbientCombat that would be the file, but all other scripts has classname arrays inside them, usually somewhere top parts of them. About avoiding some areas - only AmbientCombat has this functionality, but you could surely duplicate it. It basicly has: if(isNil("LV_IsInMarker"))then{LV_IsInMarker = compile preprocessFile "LV\LV_functions\LV_fnc_isInMarker.sqf";}; _spotValid = false; while{!_spotValid}do{ ....look for good spawning position...and when found, assign it to _spawnPos... _avoidArray = []; for "_i" from 0 to 30 do { if(_i == 0)then{_m = "ACavoid";}else{_m = ("ACavoid_" + str _i);}; if(_m in allMapMarkers)then{_avoidArray set[(count _avoidArray),_m];}; }; { if([_spawnPos,_x] call LV_IsInMarker)exitWith{_spotValid = false;}; }forEach _avoidArray; }; And it checks if there's markers named "ACavoid", "ACavoid1"...to..."ACavoid30", and inside those possible markers nothing should spawn.
-
How to make the AI ​​use the flashlights
spunfin replied to exevankeko's topic in ARMA 3 - MISSION EDITING & SCRIPTING
Ah yes, ambientCombat has a bit different syntax, so correct one for militarize would be: nul = [this,2,15,[true,false,false],[false,false,false],false,[5,0],[0,0],"default",nil,"nul = [this] execVM 'flashlight.sqf';",3] execVM "LV\militarize.sqf"; -
How to make the AI ​​use the flashlights
spunfin replied to exevankeko's topic in ARMA 3 - MISSION EDITING & SCRIPTING
Hey exevankeko, You could probably use 'custom init' -parameter in AISSP to achieve this, like: "this unassignItem 'NVGoggles_OPFOR'; this removeItem 'NVGoggles_OPFOR'; this removeItemFromPrimaryWeapon 'acc_pointer_IR'; this addPrimaryWeaponItem 'acc_flashlight'; this enableGunLights 'forceon';" So no need to loop it all the time. If you spawn other than OPFOR units with them, you would want to include side check condition on this. Or, maybe simplier, call your custom script via 'custom init', check side there etc. Example with external script on ambient combat: - Create flashlight.sqf: //flashlight.sqf _unit = _this select 0; _goggles = switch(side _unit)do{ case east: {"NVGoggles_OPFOR"}; case west: {"NVGoggles"}; case resistance: {"NVGoggles_INDEP"}; }; _unit unassignItem _goggles; _unit removeItem _goggles; _unit removePrimaryWeaponItem "acc_pointer_IR"; _unit addPrimaryWeaponItem "acc_flashlight"; _unit enableGunLights "forceon"; - Then start ambientCombat and make it use flashlight.sqf: nul = [450,900,2,12,8,[1,1,1],player,"default",0,1500,[color="#008000"]"nul = [this] execVM 'flashlights.sqf';"[/color],["SAFE","SAD"],false] execVM "LV\ambientCombat.sqf"; Happy hunting! :) -
Meatball, you're right, it would need some redesigning for this one. You could surely modify it so that it checks if player is in vehicle or not and adjusts group amount and distance parameters related to that information, but I guess it would be the hard way. Or maybe tracking down what direction player moves or looks to, or even his movement speed, and use those informations slightly for the "spawn pos" formula & patrol stuff. Or... wouldn't it be more exciting to make vehicles move slower! :) I know this has been heard many times already, but soon I'll start rewriting these! :)
-
Heys o/ I've been away for a while so I'm not sure what implementations your version has, but: as default militarize.sqf has variable called _smokesAndChems which you can set to false. It's somewhere top parts of the file. And if they still throw smokes, you can find the actual smokes & chems block at very bottom of militarize.sqf. Huge thanks to Na_Palm for helping people here! :)
-
Haven't tried for a while, but this error refers to that you have some files from the fix, but not all. Militarize.sqf had also little changes in it, so you need to take all files from the fix.
-
Ah indeed! Can't see how, but somehow I've uploaded old version of simpleCache to that FIX folder .. .. .. So the reason for delay is sleep commands in the waitUntil blocks at top of simpleCache. Here's the 'real' fixed version for simpleCache.sqf: http://lostvar.com/arma3/simpleCacheFix/LV_fnc_simpleCache.sqf
-
How slow does it get for you? How many militarize's you have there and what distance are you using in simpleCache? The main loop of it runs in 2s cycle (in that fixed version). If you can share the .pbo or mission folder somewhere, I can check out if I'm able to spot some obvious reason for the slow-downs.
-
Most common reason for issues with it is the last parameter of calling line, and player names etc. But in any case, they should spawn at mission start. If you test in normal editor, try first with most simple combination: -Use only one militarize and set its ID to 1. Call simpleCache with: (no need to name unit in editor since you're trying it locally, so your player unit == player) nul = [[1],[player],500,false,false] execVM "LV\LV_functions\LV_fnc_simpleCache.sqf"; There also was couple post earlier few fixes for simpleCache (didnt find time & will to build 'official' update): http://forums.bistudio.com/showthread.php?165089-AI-Spawn-Script-Pack&p=2588051&viewfull=1#post2588051
-
Sounds a bit odd. What do you have at your mission folder? I guess it should whine if you have files in wrong place. Did you try any of the example missions? They are so simple that you get to experience AI spawnings straight away. Currenty it works like this: scripts like militarize spawns units normally, and when simpleCache starts running -> it loops thru those ID's you defined and checks militarize -center-distances to players. If 'out of range' -> it deletes all AI units from that ID-identified militarize zone which is too far away. While deleting units, it saves the parameters you defined in militarize call, and when player comes near the zone -> it just simply recalls militarize with correct parameters. And it loops again and again checking the distances. Couple different methods already planned for it, but haven't got any time to implement them yet.
-
@Flens, I really don't know how to explain everything better, you are the very first person with this that lost. Calm down for a couple of secs and look closer. Documentation has very clear explanations, and I even included more than simple example missions where you can see how and where. 1. What are zone, zone_1 etc? If those are markers, use quotes with them, as the documentation states multiple times. E.g. "zone","zone_1"... 2. ID parameter should be unique (integer) for each instance of militarize, you have set it as 1 for each call of it. 3. First array in simpleCache call should be all those unique ID's you defined for militarize instances. 4. Second array in simpleCache is player units you want this to work with. So if you have player1 there, you must name your player unit in editor as player1 also. If you set last parameter as true, it doesnt matter which player names you define here as the script automatically finds all non-captive playable units and uses them. +If it's set to true, this wont probably work in SP/Editor. If you are unsure what everything means in my Flash app, check it out closer from Documentation. If you can read, you really can't be that lost. Best luck with it.
-
Outlawz7, Ahh yes, in your case it seemed to handle everything too fast and that might be the issue for multiple spawnings. As in Meatballs case everything happens too slow, it's sometimes hard to think it all logically. :P Here's new fix: http://lostvar.com/arma3/simpleCacheFix/fix2/ -Now it should not spawn extra units due to too fast loop -Included Meatballs fix for empty vehicles -Caching starts without extra delay and should work lot better now with multiple zones -It also loops quicker now, so with 20+ zones you should not get ~3min delays on spawn/despawn anymore