ekroemer
-
Posts
426 -
Joined
-
Last visited
Content Type
Profiles
Forums
Articles
Posts posted by ekroemer
-
-
Chalk it up to the bad social skills of physicists ;-) We guys tend to assume that information/data always has a neutral emo-charge :-)
-
@ekroemer:
waitUntil { not(isNil"VEMF_biggerIssuesFixed") };...I was only offering an analysis, not suggesting you jump to it...
-
I had mine set at 3 groups of 3 and it spawned 11.
DynamicTownInvasion.sqf says
// We Found a Town with No Players. Let's Invade. _housePos = [(_town select 1), VEMF_groupCount] call VEMF_fnc_findHouses; _sqdPos = []; { // 4 Units to a Squad. One Squad Leader. if (!(count _x <= 4)) then { _x resize 4; _sqdPos = _sqdPos + _x; } else { _sqdPos = _sqdPos + _x; }; uiSleep 0.05; } forEach _housePos;so while _housePos is derived from VEMF_groupCount the script uses a fixed squad size of 4 instead of honoring VEMF_groupSize.
I'm not sure what happens when the nested array _housePos has fewer than 4 valid positions, so in Zed's case, one could indeed get (3 groups = 3 houses) * 4 group members = 12 AI - 1 invalid pos?
-
-
I've noticed that with Arma 3 there is a new command addItem(ToXXXX) in addition to the old addMagazine.
You're using addMagazine for all <things-that-are-not-weapons>, I'm not sure, that works, anymore.
Also, https://community.bistudio.com/wiki/addMagazine states that you should add a weapon only after you've added the ammo for it or it won't be loaded.
-
I had another look into the script and came up with a different interpretation, sorry:
_cars = [ //[vehicle, cargo places, [gunner 1 ammo, gunner 2 ammo, ...], loot] ["Lada2",1,[],_loot1 call BIS_fnc_selectRandom], ["UAZ_CDF",2,[],_loot1 call BIS_fnc_selectRandom], ["HMMWV_M1035_DES_EP1",3,[],_loot2 call BIS_fnc_selectRandom] ];
is the culprit. Here only one entry from _loot1 or _loot2 is picked, regardless from how randomized _loot<n> is.
You could try to put something like (please check syntax)
// additional loot for last vehicle if ( _x == _qtd ) then { _motor addMagazineCargoGlobal [(_moneyrand call BIS_fnc_selectRandom), (round(random 2) + 2)]; _motor addMagazineCargoGlobal [(_drinkrand call BIS_fnc_selectRandom), (round(random 2) + 2)]; };between the sections //Put Loot in the Car and //Put vehicle Ammo and expand it to include your other _*rand.
-
Every one of the _*rand variables (whether defined by BIS_fnc_selectRandom or by your loadout_fnc_selectRandom) contains exactly one item. _rndnumber* are defined once and hold a constant number, so the randomization in the script,
call compile format [ "_motor %1 ['%2',%3];", _car select 3 select 0, _car select 3 select 1, _car select 3 select 2 select (_qtd - 1) ];
will be for naught because every entry in [_rndnumber2, _rndnumber2, _rndnumber2] is equal.
I assume you could do something like
_medicalrand = ["ItemPainkiller", "ItemMorphine", "ItemBandage", "ItemBloodbag", "ItemAntibiotic","ItemEpinephrine"]; [...] ["addMagazineCargoGlobal", (_medicalrand call BIS_fnc_selectRandom), [(round(random 2) + 2), (round(random 2) + 2), (round(random 2) + 2)]], [...]
and repeat the last line a few times. Same for the other loot types. Note that the definition of _medicalrand now has no BIS_fnc_selectrandom, keeping the array intact for multiple choosing.
This way
- there would be more lines generating medical loot in _loot1, each one picking randomly from _medicalrand and
- each one generating a different set of numbers to be picked from.
When duplicating the lines in _loot you of course have to adjust the random number, that's lower (round(random 2)+2).
-
Yes, that would be necessary for the
_gearmagazines = _aigear select 0; _geartools = _aigear select 1;
calls in DZMSAISpawn.
I'm not completely sure that an emtpy return for _gearmagazines will work, though, may be, may be not.
DZMSHotSpotsGear00 = [ ["ItemBandage"], ["ItemFlashlight"] ];
would be on the safe side without giving too much loot.
-
Sorry, I meant DZMSHotSpots\ExtConfig\DZMSHotSpotsAIConfig.sqf (pasted too short a line from Explorer).
The error seems to occur when a unit is spawned that has a flashlight in the gear (defined by DZMSHotSpotsGear<nn>).
Is the file you sent me complete? It seems to be the very DZMSHotSpotsAIConfig.sqf I wanted to see, but with only the DZMSHotSpotsWeps<m> entries, missing the following DZMSHotSpotsGear<nn> and DZMSHotSpotsPacklist.
-
Curious, the 'latest' version has been up for a long time.
Did you adapt DZMSHotSpots\ExtConfig.sqf for Overpoch weapons? Can you send me the file?
Or the CfgMagazines is garbled. Mostly, when the standard missions start, I get a 'no entry .' error popup, that's pointing in that direction, too.
-
My understanding has been that that is already the case.
Every mission file has the call to DZMSSaveVeh after the one to DZMSWaitMissionComp and DZMSWaitMissionComp only returns to the <mission>.sqf if the mission has been completed successfully:
//Wait until the player is within 30 meters and also meets the kill req [_coords,"DZMSUnitsMajor"] call DZMSWaitMissionComp; //Call DZMSSaveVeh to attempt to save the vehicles to the database //If saving is off, the script will exit. [_vehicle] ExecVM DZMSSaveVeh; [_vehicle1] ExecVM DZMSSaveVeh; //Let everyone know the mission is over [nil,nil,rTitleText,"The Crash Site has been Secured by Survivors!", "PLAIN",6] call RE; diag_log text format["[DZMS]: Major EM1 C130 Mission has Ended."]; deleteMarker "DZMSMajMarker"; deleteMarker "DZMSMajDot"; //Let the timer know the mission is over DZMSMajDone = true;
-
DZAI weapon arrays DZAI_Pistols<n> and DZAI_Rifles<n> ( for different weapon grades >n>) are built within DZAI/scripts/buildWeaponArrays.sqf.
While it would be possible to write a corresponding, if simplified, version of this for DZMS, I assume that if you've DZAI running, you can simply use these (global) DZAI variables to define DZMS loadout.
DZMS/ExtConfig/DZMSAIConfig.sqf defines variables DZMSWeps<n> and refers to these in DZMS/DZMSFunctions.sqf:DZMSGetWeapon which is in turn used by DZMAAiSpawn.sqf which is called from every mission.
Changing DZMSAIConfig.sqf might not do the trick because at DZMS setup time DZAI might not yet be ready, but perhaps it is sufficient to change DZMSFunctions.sqf from
switch (_skill) do { case 0: {_aiweapon = DZMSWeps0;}; case 1: {_aiweapon = DZMSWeps1;}; case 2: {_aiweapon = DZMSWeps2;}; case 3: {_aiweapon = DZMSWeps3;}; };to
switch (_skill) do { case 0: {_aiweapon = DZAI_Rifles0;}; case 1: {_aiweapon = DZAI_Rifles1;}; case 2: {_aiweapon = DZAI_Rifles2;}; case 3: {_aiweapon = DZAI_Rifles3;}; }; -
I saw this in A2, where you only could populate some fixed positions in a building.
Looking at some of Face's explanations about A3EAI where he talks about (not) placing AI in buildings, I assume that the answer to your question is: not without a deeper understanding of the internal coding of buildings.
It must be possible, though, because the dynamic traders in the industrial halls made from corrugated sheeting (near Zelno e.g.) are placed on the upper walkway.
-
Yes, you have to manually uncomment the locations that fit your map, assigning them to the variables DZMSHotSpotsStatLocs and DZMSRoadBlocksStatLocs.
The cleanest approach is to have only one set of assignments uncommented.
In case of Tavi note that there are additional locations for the map additions coming with Origins.
The mission arrays should be near line 613:
DZMSHotSpotsMajorArray = ["HSMoney","HSSupply","HSRareAmmo","HSVehicleAmmo","HSLauncher"]; DZMSHotSpotsMinorArray = ["RBFort","RBSandBags","RBTankTraps","RBVehicleArmed"];
-
I'm not sure about that: even the current EMS version uses most of the global DZMS* variables, e.g. DZMSMajCoords,
DZMSMajDone, DZMSUnitsMajor.
So I assume that changes to these variables done by EMS will be seen by DZMS and vice versa, resulting in all kinds of unpleasant behaviour.
What's with
-
I, too, heard MG fire (A3EAI vehicle patrol I suppose) at several occasions, when I was the only player on, originating from distances estimated > 1km and from directions pointing to locations I had not been, before.
The estimated locations were definitely half a map away from the VEMF and SEM missions active at that time.
I didn't dare investigate ;-)
You would need to find an animal in game and interrogate it
Nah, you can't trust the bastards - I interrogated a hare and it claimed to be a tuna ;-)
-
So far I haven't seen any radio messages from the AI. Perhaps I just haven't gotten into a situation where they'd use the radio, but is there anything written in the log when the AI send a radio message? I have debug level set to 2.
Radio messaging is ok, I got it engaging a 3 AI group on your Cherno server.
-
-
Jammer may fall sideways when building them, that doesn't impede their functionality.
Anyone can maintain at any jammer, so you'd maintain the owner's base with your money :-)
-
It has its advantages, e.g. you can place your jammer and still hide&build your valuables some distance off, so they are more difficult to find, build a decoy base and a real one nearby, all helpful with destructible base items....
-
As no 'official' answer is forthcoming, I'll update with links touching the subject:
-
I'd find that plausible, but our players told me that they had used it (changed content) daily but not packed/built it.
-
Hi there,
could you please summarize the Epoch rules for object cleanup, especially for storage devices?
The only thing I know positively is that- the jammer maintain option charges one Krypto for every object in its (300m?) circle that has been built after the jammer
- not counting tipis, shelves and lockboxes.
Rumor is that
- lockboxes will disappear some days (regular cleanup interval or other variable?) after they have been built
- lockboxes don't disappear when maintenance is performed at a jammer in range (although no Krypto is deducted?)
- when a jammer is replaced by another one the building parts erected while the first jammer stood are not maintained with the second jammer but will disappear (I don't know why that should be, it may have to do with the group system and a jammer only maintaining building parts associated with current group members, so deleting and re-creating a group may be the problem).
So, what are the rules really?
Especially: what will happen with storage devices (tipi, shelf, lockbox)?
Those differ from other building parts in that they cannot be moved after placing, so I would have thought there'd be a 'last time accessed' timestamp starting the decay interval, but I've heard from people that had lockboxes missing that they accessed daily (but not packed and re-placed).
Could we assemble&sticky the mechanisms somewhere? -
Hi there,
could the range from which shelves can be accessed, be lowered?
As it is now, even when leaving a 0.5m gap to the outer wall of a building (map or Epoch building system) they can be accessed from the outside.
I didn't test with tipis but assume they have the same problem.
[Release] Overpochins Taviana Server with LOTS and LOTS of mods
in A2: Epoch Mods (1.0.5.1)
Posted
Hi Zed,
I see 2 problems with your code:
I re-introduced the if clauses where the code checks whether the object looped over (all origins buildables _x) is a house/garage or stronghold. That will get rid of the object listed 3 times
The other problem may be not so simple to solve.
That depends on for what the s_player_origins_build_* are needed. If they are not needed at all, the code below will work (allowing any player to build any number of any building).
If they are needed, one will have to declare s_player_origins_build_* for all variants of buildings (_H1, _H2, _H3, _B1, ..., SGH, ..., SHH, ...)) and introduce them into any script that now uses the 3 variants _garage, _house, _sh.
I fear that will be the case, they'll be needed at least for providing a callback for the menu.
Please check for syntax and close the outer loops (at and after [...???...]).