ekroemer
-
Posts
426 -
Joined
-
Last visited
Content Type
Profiles
Forums
Articles
Posts posted by ekroemer
-
-
After looking for veh_monitor in DZMS but finding it in WAI (old version, not 2.x)
veh_monitor = compile preprocessFileLineNumbers "\z\addons\dayz_server\WAI_v1\compile\vehicle_monitor.sqf";
I'm afraid there's a dependency to WAI left.
But looking into vehicle_monitor
if (!isServer) exitWith {}; private ["_mission","_veh"]; _veh = _this select 0; if (count _this == 2) then { _mission = _this select 1; } else { _mission = false; }; waitUntil { count crew _veh > 0}; while {(alive _veh) and ({alive _x} count crew _veh > 0)} do { _veh setVehicleAmmo 1; _veh setFuel 1; if ({alive _x} count crew _veh == 0) then { _veh setDamage 1; _veh setVariable ["killedat", time]; }; if ((_mission) AND (clean_running_mission)) then { _veh setDamage 1; _veh setVariable ["killedat", time]; }; sleep 30; }; _veh setDamage 1; _veh setVariable ["killedat", time];only clean_running_mission seems to be a WAI variable. That one seems to be set to true when a mission is running and false before/between missions.
-
It will work on any map once the static coordinates needed are defined.
Currently the config file provides coordinates for Chernarus, Napf, Taviana (optionally with the landmasses added for Origins).
These are all maps I have access to, but I might get coordinates for Takistan and Miroslavl, soon.
Instructions on how to make your own set of coos are in post #26
-
The one at the end ? i've seen it just after posting, but still not working ...
The key to solving these problems is to use an editor with decent syntax highlighting. I myself find the sqf addon to Notepad++ quite buggy but you can use any editor, that has c/c++ modes.
This way you find quickly that you've forgotten an opening " before VSS_Vintorez in tfv_TRADERS_PRICES.
BTW: You've posted your server rpt (and should fix the error in your dynamic_vehicle.sqf, that is quite obvious from the log), but TradeFromVehicle writes to the client rpt.
-
Start with removing the trailing comma in
["RU_Functionary1",["G36_C_SD_camo","M4A1_AIM_SD_camo","FN_FAL_ANPVS4","SCAR_H_LNG_Sniper_SD","BAF_LRR_scoped","FN_FAL","Mk_48_DZ","M240_DZ"],["weapons"]],
-
What about changing the line
[] execVM "TradeFromVehicle\init.sqf
to
[] execVM "TradeFromVehicle\init.sqf";
Closing " and end-of-statement ; do wonders for correct code parsing.....
-
@Darth_Rogue: I'm no expert in sqf variable scopes but I'd set the _crate1, _crate2 as private (instead of the now unused _crate).
Also line 121 references to the undefined variable _crate instead of _crate1, _crate2.
-
The key thingy makes perfect sense: "ItemKeyGreen950" maps to characterID 950, so I suppose all green keys are problematic.
The DB function FindVehicleKeysCount shows offsets of 2500 between key colors and PHive's key generator is of the opinion that ItemKeyGreen100 maps to CharID100, but 99 does not map.
Iirc there is an Epoch array variable holding all buildables, so perhaps check the returned classname (I guess you'll get more than 1 return) against that?
-
Face gave me permission to use the sophisticated DZAI damage handler for the bots spawned by DZMSHotspots!
All credit for this nice piece of work goes to Face and all blame for incorrectly calling his functions to me! Please don't bugger Face with errors stemming from using his work together with this mod!
Now, what's this about?
- Standard Arma AI is weak - afaik corresponding to 8000 blood and they simply take damage till they die, unlike a player who may go unconscious, before. To keep using standard behaviour keep DZMSHotSpotsAIBlood = 0; in DZMSHotSpotsConfig.sqf.
- Now we could simply make the AI slightly tougher: You can now set DZMSHotSpotsAIBlood to a number > 0, for example 12000 and use a copy-from-the-web damage handler that simply scales down the damage to a fraction 8000/DZMSHotSpotsAIBlood.
- Or: you can set DZMSHotSpotsAIBlood to a number < 0, standard would be player level DZMSHotSpotsAIBlood = -12000; and thus use DZAI's fabulous damage handler (called with abs(DZMSHotSpotsAIBlood)) that does nice things: AI goes unconscious when taking heavy damage, just like a player does, headshots still do 1-shot-kills, ... For this to work, you'll need DZAI running on your server (even if you have disabled all AI patrols, I guess) and have its variable DZAI_useHealthSystem set to true.
Changed files: DZMSHotSpotsConfig.sqf, Scripts/DZMSHotSpotsAISpawn.sqf
-
You can't without rewriting the whole internals.
But: you can simply create a clone (I'll describe it for DZMS, there are more strings to change for EMS):
- make a copy of your DZMS directory
- in any filename/foldername change the substring 'DZMS' to 'DZMSClone'
- open Notepad++, drag the complete folder DZMSClone/ into it, this will load all files simultanously
- search&replace DZMS->DZMSClone with the option 'in all opened files'
Other strings to change for EMS would be (at first glance) 'EMS' and 'DEF' (I'd keep the capitalization when replacing, DEF could be tricky, the substring might be used in system variables/functions).
Finally duplicate the init.sqf line
[] ExecVM "\z\addons\dayz_server\EMS\DZMSInit.sqf";
and change the copy to
[] ExecVM "\z\addons\dayz_server\EMSClone\DZMSCloneInit.sqf";
This method works flawlessly for my
Then you'd have the clone only run minor missions by setting the major mission array to [] (that may trigger a one time rpt-message about a missing variable, see circumventing this.
-
Can anyone tell me how one would need to change the snippets
... && "ItemToolbox" in _weapons ... ... player addWeapon "ItemToolbox";
so instead of a toolbox a backpack, e.g. DZ_CompactPack_EP1 is used to build the bike?
That would make using it come with a price as you'd be restricted to carry an empty (re-spawning would give you an empty one, I guess) small backpack in lieu of a folding bike.
I'd certainly love a folding bike that you'd drop&pick up like a backpack :-)
-
Ah, I see, it gives you a worldspace coordinate to copy, ok.
Really not wanting to nag, but while using an offline map surely works perfectly fine for open areas, I still suspect that you may end up not in the middle of a road but in an adjacent building. Jumping in-game you'll record exact player position and can personally check its validity.
-
Nice script.
On the other hand: a wet dream for the PvPlers that have stolen/looted other people's keys and now want to find the vehicles....
-
Ah, on our KiezFreunde servers we run this, too.
But I have never paid much attention to the format - if it comes as GPS coordinates you'd still have to convert it to worldspace format and either way (being a batch and automatization fan) I'd hate to have to write down the coordinates ;-)
With my method the coordinates are already formatted in the way I need them to and I can just go onto the running server, jump around, perhaps make certain that the house I want to place something in has no player base in it. Now, with a bit of practice and most of the manual steps eliminated, it takes less than 10s per coordinate and less than 5min for postprocessing (search&replace in editor) the whole array.
-
For anyone having to define their own set of coordinates I'll share my admin_start.sqf:
private["_xpos", "_ypos", "_zpos"]; _xpos = 0.1*round(10*((getPos player) select 0)); _ypos = 0.1*round(10*((getPos player) select 1)); _zpos = 0.1*round(10*((getPos player) select 2)); diag_log text format ["admin_start: pos = [%1, %2, %3],", _xpos, _ypos, _zpos];
If (and only if) your server is running InfiStar (and you have admin privileges, I suppose),
- you create a script named admin_start.sqf in your client's (the computer you're playing on ;-) Arma2OA main directory (where the Arma2OA_be.exe resides),
- put the code above into it,
- jump/run to a position you like,
- press ALT-F11,
- repeat for other positions.
- Then you open your client arma2oa.rpt (located in something like %userprofile%\AppData\Local\ArmA 2 OA)
- search for lines containing "admin_start" (using NotePad++ and 'find all in current document' you'll have the whole list in one window)
- copy them into another file and postprocess.
One line will look like
admin_start: pos = [11021.00, 12468.30, 0.00],
and you'll have to get rid of the string before the '[', and copy the result into DZMSHotSpotsConfig.sqf to form an array e.g. DZMSHotSpots<YOURMAP> and DZMSRoadBlocks<YOURMAP>.
Don't forget to get rid of the trailing ',' in the last line of the array and to assign the correct coordinates ala
DZMSHotSpotsStatLocs = DZMSHotSpots<YOURMAP>; DZMSRoadBlocksStatLocs = DZMSRoadBlocks<YOURMAP>;
If you're doing this for a map not yet covered, please share your result here!
-
I'm afraid, a whole bunch of them. I had to touch all mission files because the actual loot coordinate is determined there and I needed to forward it as a global variable to the marker loop.
The touched files should be:
DZMSHotSpots/DZMSHotSpotsConfig.sqf
DZMSHotSpots/DZMSHotSpotsInit.sqf
DZMSHotSpots/Scripts/DZMSHotSpotsMarkerLoop.sqf
DZMSHotSpots/Missions/Major/HSLauncher.sqf
DZMSHotSpots/Missions/Major/HSMoney.sqf
DZMSHotSpots/Missions/Major/HSRareAmmo.sqf
DZMSHotSpots/Missions/Major/HSSupply.sqf
DZMSHotSpots/Missions/Major/HSVehicleAmmo.sqf
DZMSHotSpots/Missions/Minor/RBTankTraps.sqf
DZMSHotSpots/Missions/Minor/RBVehicleArmed.sqf
DZMSHotSpots/Missions/Minor/RBSandBags.sqf
DZMSHotSpots/Missions/Minor/RBFort.sqfAt least nothing defining crate contend or AI in the list ;-)
-
Expanded debug mode as requested.
May I go play, now? ;-)
-
You are in the wrong place :-)
-
I know you're running a PvE server, there clearing the markers would make sense, representing a combined effort to find the treasure and inform the others about where not to look.
However, one of the goals of the mod is to create PvP-hotspots, so it would be a perfectly valid tactic to lay an ambush at a marker, waiting for other players to come, look for treasure. Here a disappearing marker would be counter-productive.
But sure, I could make the feature optional.
The main problem is: DZMS has a mechanism to look for the 'end of a mission', namely, a player being in the vicinity of the objective coordinate. DZMSWaitMissionComp is called in each mission file and is blocking, meaning the call doesn't return before the condition is met.
To implement your suggestion one would have to run this detection on each of the possible crate locations, simultanously.
This is equivalent to having a whole bunch of major missions running in parallel and I'm not prepared to delve this deep into a central part of the mission system.
I will, however, keep an eye open for more easy ways to achieve the goal.
-
Hmmm, perhaps next weekend, I have to work for a living ;-)
But it shouldn't be hard.
For debug I'm using Infistar's map icons, shows you the AI as red circles.
To clarify: do you mean the one active roadblock or all possible ones?
-
Hmmm, and this was supposed to be my day off ;-)
Between a "}" more and a "then" less than needed this has taken longer than expected, but now it should allow you to define your major mission interval without constraints -> re-download.
-
AI being deleted:
DZMS holds all units tied to a mission in either DZMSUnitsMajor or DZMSUnitsMinor. When a mission is started, all surviving AI from the last mission of the same type (major|minor) are deleted.
So I guess you could increase the mission interval DZMSHotSpots(Major|Minor)(Min|Max) from their value of 10s to something greater. Perhaps one should set this value equal to DZMSHotSpotsSceneryDespawnTimer which cares for crate despawn and is set to 300s.
But I'm not that comfortable with this solution because of the map markers: at the end of each mission file a new set of map markers is chosen and will be displayed immediately, even if at that moment new crates are not yet spawned. And I'd rather not make the marker display mechanics more complicated than it already is....
You could try to set the time between missions to 60s: time enough to get shot while looting and not enough time for players to search the new locations in vain.
Markers:
OK, now I got a working solution. First of all: using only circles of a given radius as map marker is not that easy because you only see the marker when zoomed in (no sense in the marker covering the whole village).
I therefore mixed both methods: crate is somewhere within the circle and the circle center is marked with the question mark so you can quickly identify it on the map.
You set the radius of the circle using DZMSHotSpotsConfig:DZMSHotSpotsRandR
I've tested with 50, that makes it astonishingly difficult to locate the crate, with all the fences being in the way ;-)
Be aware that the circle area increases with r^2, so doubling the radius makes it 4 times as hard to find the crate.
Note that the crate position itself does not change! Only the circle center is randomly chosen within the defined distance to the crate. I cannot randomly choose the crate position because it then would most probably end up inaccessibly somewhere within buildings.
Standard DZMS missions do not have this problem because they are spawned in free terrain.
Only way around this is to massively increase the array of possible locations - a dozen spots per village would be great ;-)
I think the uncertainty of the crate's whereabouts makes the AI despawn problem less severe, so I'll keep the default for major mission intervals at 10s. It's highly unlikely that you can sneak to the crate without being seen by the AI.
Minor mission intervals are now 300s, the same as DZMSHotSpotsSceneryDespawnTimer.
BTW:
I also fixed the Vybor position - the loot had been spawned on the building floor (0.36m) but that apparently was too high :-(
-
It won't repeat as in 'do the same mission twice in succession' but you'll double the chance of the mission being randomly picked.
-
OK, I've uploaded an update and added information to the first post.
Now there are minor missions, too: roadblock ambushes without map markers. At any time somewhere on the map (on a road, hence roadblock ;-) a group of 4 AI waits for the unprepared traveller,
- either blocking the road with some static obstacles (sandbag fort, circle of tanktraps or circle of H-barriers), rewarding you with a medic box full of money,
- or with an armed vehicle (including twitchy gunner) that you can sell/drive/shoot with (vanishing with the next server restart in you keep DZMSHotSpotsSaveVehicles in the default position false).
-
In principle you can set an empty array: DZMSMinorArray = [];
With the currect DZMS version, though, you'll get some rpt errors from this. To prevent them, follow
DZMS and WAI, AI not cleaning up after mission timeout.
in DZMS - DayZ Mission System
Posted
DZMS has no mission timeout, only mission completion and DZMS AI is cleared when and only when a new mission of the same type (minor, major) starts, not before (differing in this regard from scenery).