ekroemer
-
Posts
426 -
Joined
-
Last visited
Content Type
Profiles
Forums
Articles
Posts posted by ekroemer
-
-
Imo those missing addons say that the Epoch expansion is not activated (on client).
-
Hmm, I'm not sure if this is complicating matters: I've noticed that my Steam has installed itself under username 'User' while I'm logging into Win7 (and have installed Steam) under another username.
From this follows that the Arma2 profile (and %appdata%) used is a different one between starting the game from Steam/bat or DZC.
You say, you've started Steam as administrator, maybe yet another profile used?
@V414: what does your client rpt say? It's located in the %appdata% of the user starting arma.
-
DZC wouldn't concern me too much, but the rest sounds as if the connection had been attempted with incorrect expansions, resulting in a kick, reverting to the Arma menu.
No Epoch-Screen at all?
Try a (modify IP and STEAMPATH if necessary and copy into your Arma2OA directory) bat-File
@echo off rem path to Steam, change this! set STEAMPATH=C:\Program Files (x86)\Steam rem server connection information set IP=5.9.138.103 set PORT=2302 set MODS=@DayZ_Epoch; rem don't change below set ARMA2OAPATH=%STEAMPATH%\SteamApps\common\Arma 2 Operation Arrowhead set ARMA2PATH=%STEAMPATH%\SteamApps\common\Arma 2 start "" "%ARMA2OAPATH%\ArmA2OA_BE.exe" 0 0 -skipintro -mod=%MODS% -noSplash -noFilePatching -world=empty -connect=%IP% -port=%PORT% "-mod=%ARMA2PATH%;expansion;" @exit
-
Yes, I find it quite irritating that I need to have a functional internet connection to play a singleplayer game on my own PC.
I had preferred to keep Steam in Offline mode, for fear of unwanted game updates (despite deactivated 'keep up to date') and because I can then isolate my PC from the internet while playing.
But no, the player without identity message only stops when I change Steam into Online mode :-(
-
I say the client needs Steam in Online mode (not Offline mode which is sufficient to start the game but not to connect anywhere).
How are you starting arma through Steam? A working connection to a 1.62 server will use another executable ($ARMA2OADIR/expansion/beta/arma2oe.exe) then a connection to an current 1.63 server ($ARMA2OADIR/arma2oa_be.exe).
I myself am mainly using bats, thus having full control of the startup process, so I'm not familiar with the Steam process.
Afair your Steam library offers
- the current game version in form of 'Arma2 Operation Arrowhead', perhaps with '[beta]' in brackets if you've opted into beta versions.
- the 1.62 version as deprecated 'Arma2 Operation Arrowhead Beta' (actual name may differ, but without brackets around beta)
Using 1 you cannot connect to 1.62 servers, using 2 you cannot connect to 1.63 servers. Your (the OP's?) server is 1.63.125548 , so I cannot imagine that you can use the very same connection method for both, 1.62 and 1.63.
-
Some lines 'Player without identity' are normal.
What had me stumped for a while was that you need to have Steam in Online Mode, even when connecting to a LAN server, otherwise you won't be able to acquire an identity at all.
-
I was under the impression that using 'v' is disabled in the vicinity of basebuilding objects to prevent glitching into bases?
I also got the impression that this mechanism does not work as well and reproducible as one would wish.
Be that as it may, intermittent deactivation on 'v' happens to me at places all over the map, independent from snapping.
-
Why should not writing them to DB make them un-sellable per se?
They only need to have ObjectID and ObjectUID and those could be set independently from the DB write.
-
So, if I have read this correctly, I just go through each of those blocks in DZMSBox and change:_crate addWeaponCargoGlobal [_item,DEFSMGRate];
to:
_crate addWeaponCargoGlobal [_item,(round(random 1))];
Is that right?
Also what do I need to do for the ammo as this was doubling up too?:
_crate addMagazineCargoGlobal [(_ammo select 0),(round(random DEFSMGAmmoRate))];
Regarding the weapons, yes that would be the change to make (as far as my sqf-knowledge goes).
Regarding the ammo: whether the weapon was added or not (chance of 50%), ammo will always be added. But that's no problem because you can always fiddle with your ammo count DEFSMGAmmoRate.
If your goal is, that on average every weapon spawned will come with AVERAGEAMMO mags, then set DEFSMGAmmoRate to
AVERAGEAMMO, because:
- ammo count will always be between 0 and DEFSMGAmmoRate
- with a mean value 0.5*DEFSMGAmmoRate
- the probability of a weapon spawning is also 0.5.
Of cource that assumes that 2 different weapons share the same ammo....
If you want to spawn exactly DEFSMGAmmoRate mags per weapon spawned, then you'll have to put the result of (round(random 1)) into a local variable and refer to it, later, something like
private ["_dummy"]; _dummy =(round(random 1)); _crate addWeaponCargoGlobal [_item,_dummy]; if ( _dummy > 0 ) { _crate addMagazineCargoGlobal [(_ammo select 0), DEFSMGAmmoRate]; };Note that I did not test this code.
-
Hmmm, OK. I think we're stepping beyond my knowledge barrier a bit.... :)
In your example above, I haven't even bothered to set them with +x or -x coords to the previous squad, I literally just pasted the line and they seem to be fine..
So, what can I add to make them clear up properly? Although I have it set to 75% of AI must be cleared to complete the mission, I'm still worried about a few roamers left floating about eating CPU resources....
Also, on your final comment, did you mean where Minor SM2 used to have DZMSUnitsMinor missing? Because that actually stopped minor from spawning altogether until it was added to the spawn line in the mission....
That's usually the only way to create new knowledge ;-)
Not offsetting the position should be fine...otherwise the whole squad would stand on each other's heads :-) Jus me being ocd...
Proper cleanup: Quick&Dirty would be to create a copy DZMSUnitsMajor2, use this in the creation of the second group and duplicate the cleanup in DZMSMajTimer.sqf, basically copying everything handling DZMSUnitsMajor.
Naturally one would have to expand this to DZMSUnitsMajor3 and so on if spawning more than 2 groups, that is where it gets less quick and more dirty ;-)
Really proper cleanup...I don't speak sqf, either. One would have to modify DZMSAISpawn.sqf where it creates the array _unitArrayName (lines 141).
Hmmm, looking at the cryptic
call compile format[" %1 = %1 + (units _unitGroup); _unitMissionCount = count %1; ",_unitArrayName];
I could imagine that the new group is already appended to the existing one. In this case my point would be moot :-)
But I'd like the opinion of Vampire or some other sqf-expert, here.
So, lets put this question on hold until someone make a well-founded comment.Edit: Scratch my concerns! Vampire's original DZMS missions do exactly that: spawning several groups of 4-6 AI, so indeed, cleanup is handled via appending. Sorry! I got mislead by assuming that DZMSUnitsMajor was an output variable to DZMSAISpawn, but sqf handles those thingies to the left of the function names as in/out...
-
No, please don't take that as read. I haven't tested them gradually. I just noticed when I first did one line with 12 in it they seemed by top of the idiot class and when I changed it to 3 lines of 4 or even 4 lines of 3 they improved massively. I worked this out with DZMS which I was using before..
[...]
What do you mean about clear up then? I'm not aware of any problems. Should I be worried?
OK, that's a relief :-) So 6 should work nearly as well as 4.
Worried? Depends: When you are spawning more than one group you'll overwrite the argument DZMSUnitsMajor. In this example
[[(_coords select 0), (_coords select 1),0],4,1,"DZMSUnitsMajor"] call DZMSAISpawn; [[(_coords select 0)+10,(_coords select 1),0],4,1,"DZMSUnitsMajor"] call DZMSAISpawn;
after the mission is cleared the surviving members of the first group won't be removed from the game but will continue to roam the vicinity, endanger innocent players ;-) and eat CPU resources.
Obviously there's no problem when all AI have been killed, but may be when players use stealthy tactics.
BTW: in some of the EMS missions the DZMSUnitsMajor|Minor argument to DZMSAISpawn is missing. That means that these missions are not cleaned up, properly.
-
Answering separately:
The problem I'm having is that although I don't mind the fact that they use the same weapon loot rate in DZMSConfig which I could probably mess around with using the other rate types that are unused like DEFRifleRate, for some types like DEFSMGRate when set to 2, might actually put 4 in there and then also double up on the ammo as well.
For an easy mission, with anywhere from 4-8 AI, I think having a payout of 4 guns of one type and then some 2's and 1's as well for other types is too much. I would prefer to see 0-2 all the way down the list.
nice setup you're describing :-)
As I wrote, I do not see an easy way to enforce a limit of 2 to a _specified_ weapon. But you can, e.g.
- put all roughly equivalent weapons into a separate array (equivalent meaning that you don't care if the crate holds 1 of memberA and one of memberB or 2 of memberA)
- define the maximum count by the upper limit of the for_loop, just as the XXXRate does now
- give 0 or 1 weapon per iteration using _crate addWeaponCargoGlobal [_item,(round(random 1))];
This way while some passes through the loop may result in a weapon picked before, the overall count will be less than XXXRate.
-
Is 4 really the magic number, here? (I need to have a look into WAI at the numbers, there).
Does the degradation come with the step from 4 to 5 or gradually?
Is the issue a matter of Arma2 coding or a matter of resources (meaning: is Arma programmed to only handle a limited number of group members or does the communication between too many members bog down the CPU)?
Why I'm asking: if 6 or 8 would still be ok, one could keep a significant number of AI without sacrificing the cleanup:
A typical call to create a group would be
[[(_coords select 0),(_coords select 1),0],6,1,"DZMSUnitsMajor"] call DZMSAISpawn;
defining an array DZMSUnitsMajor that is used in DZMSMajTimer.sqf to get rid of the AI remaining at mission end:
{if (alive _x) then {_x call DZMSPurgeObject;};} forEach DZMSUnitsMajor;When creating more than 1 group we'd need more arrays DZMSMajor or we have to change DZMSAISpawn to append to it (and DZMS*Timer to clear the array after purging).
Edit: looked into WAI and while mostly the squads consist of 4 members the Ikea convoy one has 5 and I remember it as pretty deadly, so I guess performance will degrade rather than break down at 4.
-
@Defent:
Yes, I thought as much about your reasoning; I guess you took your clue from the gshellList where both values (loop and count) are set to 2.
Looking at all the others, though, shows that the argument to addWeaponCargoGlobal is always 1, in line with my first suggestion.
Would be the least hassle to do so (for weapons) and still meet your configuration goals.
@ReDBaron:
What do you want to achieve?
Afaik, using
_crate addWeaponCargoGlobal [_item,(round(random 2))];
would give you 0-2 pieces of _item.
Ensuring that a crate holds at max 2 pieces of a specified pistol is tricky, because nothing prevents the for _x loop from choosing the same type of pistol in every iteration, so with a very low probability you'll end up with 2*DEFMPistolRate pistols of the same kind.
But I think, that's an academic argument, it would be much effort to prevent something only slightly annoying ;-)
The easiest thing to lower the probability of too many pistols of a kind would be to place more classnames in DZMSpistolList.
@all: in my original post I erroneously took the round for a floor, so instead of
_crate addWeaponCargoGlobal [_item,1+(round(random 2))];
one should use
_crate addWeaponCargoGlobal [_item,1+(round(random 1))];
to get results within [1, 2].
-
Hi Defent,
I'm a bit concerned about the logic you use for spawning crate content, as example the use of DEFMPistolrate:
// load pistols _scount = count DZMSpistolList; for "_x" from 0 to DEFMPistolRate do { _sSelect = floor(random _sCount); _item = DZMSpistolList select _sSelect; _crate addWeaponCargoGlobal [_item,DEFMPistolRate]; _ammo = [] + getArray (configFile >> "cfgWeapons" >> _item >> "magazines"); if (count _ammo > 0) then { _crate addMagazineCargoGlobal [(_ammo select 0),(round(random DEFMPistolAmmoRate))]; }; };You are using this (misnamed ;-) Rate
- as loop limit, thus choosing DEFMPistolrate+1 times from the array DZMSpistolList
- and as multiplier: in each iteration DEFMPistolrate pistols of the chosen kind are added.
I can see no reason why one should use the same variable at both places and many against it:
- the way it is, the amount of weapons in the crate will be (DEFMPistolrate+1)*DEFMPistolrate, roughly the square of the number one would expect
- changing Rate from e.g. 3 to 4 will increase weapon count from 12 to 20.
I would change the addWeaponCargoGlobal argument from Rate to 1, thus having exactly Rate+1 pistols in the crate or, more dynamic, do something like
_crate addWeaponCargoGlobal [_item,1+(round(random 1))];
resulting in 1 or 2 pistols per iteration, equivalent to an overall number between Rate+1 and 2*(Rate+1).
-
and the appropriate thread tells you, how: http://epochmod.com/forum/index.php?/topic/4427-wicked-aimission-system/?view=findpost&p=103227
-
Yes, that is the definition, but you used it, before it was defined, you have to switch definition and reference to it. That would make your code look like
tfv_ALL_ITEMS = [ "glock17_EP1", "M9", "M9SD", "Makarov", "MakarovSD", "revolver_EP1", "revolver_gold_EP1"]; tfv_TRADERS_ITEMS = [ ["RU_Profiteer3", tfv_ALL_ITEMS, ["weapons","magazines"],0], ["Soldier_GL_PMC", tfv_ALL_ITEMS, ["weapons","magazines"],0] ]; if (tfv_DEBUGGING) then { diag_log "tfv - Traders and their weapons loaded in!"; }; tfv_TRADERS_PRICES = [ ["glock17_EP1",50], ["M9",20], ["M9SD",100], ["Makarov",10], ["MakarovSD",100], ["revolver_EP1",10], ["revolver_gold_EP1",200] ]; if (tfv_DEBUGGING) then { { diag_log format ["tfv - Price loaded - %1",_x]; } forEach tfv_TRADERS_PRICES; }; -
Is that above a snippet from your config file?
You should define tfv_ALL_ITEMS before using it in tfv_TRADERS_ITEMS, otherwise it looks fine at first glance.
-
I suspect that when the height is 0 the game may default to spawn objects/AI at whatever the ground level is for that spot on the map.
The 3rd coordinate is height over ground, meaning that z=0 will always (barring some oddities) place the item at ground level, that is: level of bare earth regardless of any buildings placed there.
The problem is that objects placed on an upper floor (or on the ground floor if its height differs from 0) will occur at z=0, ingame.
I don't know why that is the case. Maybe during placement the z coordinate is ignored or the object falls 'through the floor', even though the map buildings are spawned before the object is.
Even stranger: when you place a DZMS crate in a church or near sheds you sometimes find the guarding AIs on top of the sheds (that is at z coordinates greater (!) than the box) or dead, apparently from spawning on the church's roof and falling down, but never in the church.
So there seems to be a more complicated postprocessing to change an object's placement to heights other than defined in it's position argument.
-
Probably the HiveExt.dll will be updated to support steam ID's, because now you can change the DB's CharacterID field to BigInt but the dll will truncate that to integer (https://github.com/vbawol/DayZ-Epoch/issues/1371).
Perhaps you should file an issue and ask vbawol to adapt the UID calls, as well?
-
Certainly, but the procedure seems to be complicated. Again looking at my google results it seems that Arma2 getpos for building slots only returns a standard position and that the actual positioning is done with standard coordinates.
Nevertheless I myself did not manage to position DZMS boxes or bots at well defined positions with height over ground > 0. Mostly the z coordinate seems to be ignored, but sometimes boxes placed at ground level float 1m in the air... ;-)
If you are more successful I'd be interested!
-
It's the same with crates and AI may spawn on a building roof even if given a z coordinate of 0.
Google results for something like "ARMA2 place AI in buildings" suggest that in Arma2 you can only place AI in certain positions of certain buildings and that those positions are given by index per building type and not by coordinate.
I didn't find anything DayZ related, it may well be that the added/modified buildings don't meet the necessary prerequisites.
-
Hi, I've been using it for a while and I can't say anything but Thanks for this great job.
I have just one question:
What if I want the AI to have RPGs?
I tried to modify the Floot file to add the rpg classname (M136) to their inventory, and although some of them spawn with RPG, they dont use it. They just carry it on their backs and that's it... they dont even attack at all..
Did you give them ammo, too? RPG7V / PG7V should work, for M136 I don't know the ammo classname.
-
Get an editor with syntax highlighting. Either install e.g. an sqf addon to Notepad++ or paste your code into whatever.c and use C/C++-Mode.
I'd make a backup copy of the original file and delete all comments in the one I'm working with - the less code the less chance to overlook something.
New server install won't startup, hangs on Merlin
in Server Install
Posted
It would be more interesting to see the bat you use to connect your client to the server....
I don't want to offend anyone, but given the experience we've had with our players: there's a plethora of reasons why they could not connect to the server after the change to Steam and the DZC desaster -- all of them rested between their ears, while the server was perfectly fine ;-)