ekroemer
-
Posts
426 -
Joined
-
Last visited
Content Type
Profiles
Forums
Articles
Posts posted by ekroemer
-
-
according to what I've seen in my server's chat, some people are saying they are finding loot when they shoot down an AI heli but when I test it on my test server, I find none
That may be due to the randomly chosen location of the loot which may or may not be covered by the heli wrack or earth mounds.
You could try to get a better location by expanding
private [ "_lootrepeat",
to
private [ "_angle", "_radius", "_minradius", "_lootrepeat",changing
_lootlift = 0.1;
to
_lootlift = 0.1; _minradius = 10.0;
and replacing
_pos0 = _centrum0 + ceil(random _spawnradious)* cos ceil(random 360); _pos1 = _centrum1 + ceil(random _spawnradious)* cos ceil(random 360);
with
_radius = _minradius + (random _spawnradious) _angle = (random 360) _pos0 = _centrum0 + _ radius * cos _angle; _pos1 = _centrum1 + _ radius * sin _angle;I just tried it again and here's the log:
That's odd. _x is a magic variable https://community.bistudio.com/wiki/forEach that does not need to be defined explicitely.
As this is the only place in the script where a foreach loop is used and your log indicates that the spawning of weapons has been performed (the error occurs in the _magspawn function, while the 'spawned 11 items' message comes from the _weaponspawn function), I guess the variable _item in
{ _spawnlootpoint addMagazineCargoGlobal [_x,(floor(random _itemsamount))]; } foreach _items; // diag_log format["Zmienna items %1",_items];does not contain an array. Try to uncomment the diag_log after the loop (Zmienna...) so we can see how _items looks like and can repair it.
To find the spawned weapons try to expand
_spawneditems = _spawneditems + 1; if ( _spawneditems > _lootamount ) exitWith {diag_log format["[MBNQ] ERROR: Out of limit %1 items at NPC %2 crash site",_spawneditems,(typeOf _crashedHeli)]};to
_spawneditems = _spawneditems + 1; diag_log format ["[MBNQ] _weaponspawn at pos %1", _itemSpawnPos]; if ( _spawneditems > _lootamount ) exitWith {diag_log format["[MBNQ] ERROR: Out of limit %1 items at NPC %2 crash site",_spawneditems,(typeOf _crashedHeli)]};This should give you the position(s) where the items spawned and you can use InfiStar to navigate to the exact point.
As I didn't test the code I proposed, I hope there are no systax errors in it....
-
for "_x" from 0 to 2 do {initiates a loop with 3 iterations (0,1,2)
_sSelect = floor(random _sCount);
picks a number between 0 and _sCount-1, _sCount being the length of the list _gshellList containing classnames to choose from
_item = _gshellList select _sSelect;
determines the classname to add to the crate (_gshellList[_sSelect] in C)
_crate addMagazineCargoGlobal [_item,(round(random 2))];
(round(random 2)) will return a number between 0 and 2 and determines how many of _item will be put into the crate.
Altogether you could end up with
- zero items from this list because round(random 2) always returned 0
- 6 identical items, because in each of the 3 iterations the same _sSelect was picked and round(random 2) always returned 2
- or anything between: 1-3 different classes of items with a quantity 0-2 each
-
I've downloaded the mbnqcrash.sqf from somewhere and had a look.
Your cited rpt suggests to take the unknown ItemBookBible out of line 242
_items = ["ItemBookBible", "ItemSandbag", "PipeBomb"];
Looking at
_pos0 = _centrum0 + ceil(random _spawnradious)* cos ceil(random 360); _pos1 = _centrum1 + ceil(random _spawnradious)* cos ceil(random 360); _pos2 = _lootlift;
I shudder :-) (using cos in both coordinates and both, radius and angle are randomly determined twice, thus being totally independent). I'd prefer something more well defined, like
_radius = _minradius + (random _spawnradious) _angle = (random 360) _pos0 = _centrum0 + _radius * cos _angle; _pos1 = _centrum1 + _radius * sin _angle;using new private variable _radius, _angle for a standard polar formula and _minradius, set to something like 10m, to avoid the loot spawning under the heliwrack.
Perhaps play with _lootlift, too. At crash positions you get a cratered landscape that may well exceed the default 0.1m in height.
Then I'd (re-)activate some of the diag_log lines (e.g. line 189). They can tell you how many of which loot has spawned where. Perhaps something like
{ _spawnlootpoint addMagazineCargoGlobal [_x,(floor(random _itemsamount))]; diag_log format["spawned %1 at %2", _x, _spawnlootpoint] } foreach _items;Note that _x is an internal variable automatically generated in loops.
For test purposes you could set all _spawnchance to 1.0. temporarily.
-
You tried all the stuff in ?
-
While I don't see what's causing the option to not appear, your syntax of sequential && does not look for 3 poles and 2 canvas but will return true even if you only have 1 pole and 1 canvas.
I believe the question of multiples of the same classname has been raised and answered in this thread, before.
I don't see the definition of _mags. And the definition of _weapons has (magazines player) in it which strikes me as odd.
-
That does a bit more....but the hint is good, seems you'd only need some ini vars for configuration and could hook into epoch_returnChange if all you wanted to do was to subtract in proportion to item price. That's a start.
-
Hi all,
let's assume that you don't play Epoch for the single reason of killing others.
Then typically what keeps you hooked is to do something new, e.g. buy a new piece of hardware.
On standard Epoch you've the bandit and hero traders - for buying there you've to accumulate humanity. But once you've your 5K, you have access to every item - and are bored.
There are workarounds, such as
- having a sparse economy where it's difficult to assemble the money needed - but on the one hand this tends to frustrate players, on the other hand it favors clans
- creating a bunch of layered traders with increasing humanity requirements - but this merely delays the problem.
What I'd like to propose would be an additional cost in humanity when buying something.
Not necessarily for all items but for the highly priced - e.g. armed vehicles, top-of-the-line weapons.
This way you'd have to kill Zeds/Bandits to assemble humanity, go to an advanced trader, buy the desired vehicle and not only pay in briefcases but in humanity as well, so afterwards you have to kill Zeds again, to re-gain access to the trader.
This would spread out achievements automatically and thus increase long-term playability.
Design decisions like
- signed humanity loss towards the starting value of +2500
- fixed (configurable) amounts of hum-cost or proportional to item price
are mere details.
My main question is: where to hook in a standalone mod that is triggered by the action of selling something and depending on trader ore item price reducing player humanity?
Anyone interested in implementing such a thing?
-
In the statement in itself I don't see an error.
You could try to post the complete sqf and/or your server rpt (in spoiler and code tags).
I'd also use a diff-tool (I like meld) to compare the files before and after your changes, otherwise overlooking something is fairly easy.
I'm sure that changing coordinates only won't trigger a different AI behaviour. More likely the mission shooting has weapons capable of hurting the heli, the others don't.
-
Copying worldspace coordinates from PHT should work (only use [x,y,z] from [dir,[x,y,z]]) at least once you strip it of all unneeded brackets.
Each coordinate comes as [x,y,z], any opening [ as in your example [[x,y,z] comes only as part of a longer
statement [ [x,y,z] , whatever ].
-
In the editor you can find an item section containing the built versions of the Epoch buildables (CinderWall, ...). Sadly I've forgotten where exactly and the interface is simply hideous....
I wouldn't try to set locked items and I never tried to upgrade items, but those you don't need to interact with (those that don't need to be changed in the DB) work fine.
-
The same old:
"Random", or ["Random","at"], // Primary gun set number and rocket launcher. "Random" for random weapon set, "at" for anti-tank, "aa" for anti-air launcher
This line is malformed, it tells you to use
"Random",
or
["Random","at"],
and the part after and including // is the comment that should have started before the 'or'.
While this should be obvious to anyone having even a rudimentary understanding of code, it's clearly bad practise on part of the developers to put an instruction to the user somewhere where it'll be parsed instead of into the comment.
I suggest the developers finally clear this up in the download.
-
-
I've uploaded a new version.
- Smitty Jagerman from KillinZedz contributed coordinates for Takistan
- NigeyS contributed coordinates for Miroslavl
Many thanks to both of them!
-
:-( That's a pity.
I had only looked for syntax and programming errors, when it comes to trader skins, I'm out of my depth, so, are you really sure your traders are correct?
I myself only use the wholesalers RU_Citizen1 and RU_Citizen4 on Chernarus (which you're using, too, I see from your init.sqf)
My traders_data lists those as instance 11 whereas your Soldier_MG_PKM_PMC is instance 17 as is Tanny_PMC. GUE_Soldier_1 is 15 or 16, TK_GUE_Warlord_EP1 I don't find at all.
So you have customized your traders?
If you run InfiStar then you can just look at the trader you want to use and get the classname by pressing 'i'.
Furthermore I have the
[] execVM "TradeFromVehicle\init.sqf";
after the elevator, near the end of the if (!isDedicated) then clause. I don't know if that changes anything.
-
OK, I'm guessing here, but:
Looking at Napf\spawn\halo.hpp it seems as if this indeed only chooses between Halo and Ground, returning "haloSelect = 0" if the ground button is pressed.
The logic in Napf\spawn\spawn.sqf seems to be
- start with statusSelect = -2;
- call E_Class_Dialog
- set statusSelect = 0;
- call E_Spawn_Dialog
- statusSelect = 1;
- if spawn select isn't random call E_Halo_Dialog
So I'd simply try to modify spawn.sqf by
- setting haloSelect = 0 in line 7
- and commenting out line 67
if (statusSelect == 1) then {_i="createDialog";createDialog "E_Halo_Dialog";};
-
I'd love to see that, too.
Did you test the claim here http://opendayz.net/threads/support-ess-enhanced-spawn-selection.19999/page-15#post-109806?
I'll have a look at how to remove the halo option completely like you asked on opendayz.net.
-
Ah, that's done explicitely, then and you would simply use the same
AND `Classname` NOT LIKE 'LightPole_DZ'
in both, the damage event and the deletion event.
Only for reference, the official cleanup method, picked from (Zupa was right) HiveExt.dll's SqlObjDataSource.cpp
if (_cleanupPlacedDays >= 0) { string commonSql = "FROM `"+_objTableName+"` WHERE `Instance` = " + lexical_cast<string>(serverId) + " AND `ObjectUID` <> 0 AND `CharacterID` <> 0" + " AND `Datestamp` < DATE_SUB(CURRENT_TIMESTAMP, INTERVAL "+lexical_cast<string>(_cleanupPlacedDays)+" DAY)" + " AND ( (`Inventory` IS NULL) OR (`Inventory` = '[]') )"; int numCleaned = 0; { auto numObjsToClean = getDB()->query(("SELECT COUNT(*) "+commonSql).c_str()); if (numObjsToClean && numObjsToClean->fetchRow()) numCleaned = numObjsToClean->at(0).getInt32(); } if (numCleaned > 0) { _logger.information("Removing " + lexical_cast<string>(numCleaned) + " empty placed objects older than " + lexical_cast<string>(_cleanupPlacedDays) + " days"); auto stmt = getDB()->makeStatement(_stmtDeleteOldObject, "DELETE "+commonSql); if (!stmt->directExecute()) _logger.error("Error executing placed objects cleanup statement"); } } -
I don't really know, I don't even remember if I once knew ;-)
Now, that you say it, I rember the dreaded DB event removeObjectOld that removes anything older than 24/42 days, unconditionally. But that one is not triggered by the CleanupPlacedAfterDays interval in HiveExt.ini, so you may be right about hiveext.dll.
But my impression was that not everything built was removed after that time.....
-
Perhaps I'm misunderstand you, Zed, but I was under the impression (as Zupa also implies) that the poles will vanish as part of the normal cleanup process when remaining unmaintained (as long as you don't take additional measures as Zupa has suggested one).
If I understand you correctly you're looking for a way to
- not damage the items (-> they cannot be maintained)
- while not having them automatically removed during cleanup.
I assume, somewhere (variables.sqf?) there is a list of items removed during cleanup. If that's the case one could simply delete them, there...
Edit...ninjaed
-
Zed, are lightpoles among those buildables that will vanish when not maintained?
Excluding them from the DB event will prevent them from being maintained.
-
If you're using my canbuild hack (that's aimed to not being forced to edit in mission.sqm or other internals), then you have to replace every canbuild by _canBuildLocal. You only declared and defined the private, you didn't use it in the if clauses.
-
To point out the glaringly obvious ;-):
Right between system chat 4 (printed, so above is ok) and 5 (not printed) in tfv_TRADERS_ITEMS
- your last entry ends with a comma,
- the 2 occurrences of M4A1_AIM_SD_camo have 2 opening " (that is ""M4A1_AIM_SD_camo").
Looking below that, tfv_TRADERS_PRICES also ends with a comma (and an ugly empty line) after the Winchester1866 entry
-
That seems to be really complicated (for my level of understanding), see something like
which uses 'building positions'. I don't even know if the DayZ and Epoch buildings have these....
Perhaps http://www.ofpec.com/forum/index.php?topic=34622.0
Choose an enterable building, put the AI near it and than use the
_building = nearestBuilding _obj; _obj setPos (_building buildingPos _index);
mit _index a fixed buildingpos making the AI accessible or random like in the code cited in the second link.
I'd be really interested in the result if this works out as I would have liked to place the AI in DZMSHotSpots in the building....
-
Hi Zed,
Your _position seems fine to me. I assume there really is a { missing in your file.
As for the static guns, I'm afraid I've never seen a M240 nest used in this role in any mission system, they all use "M2StaticMG". But perhaps you only have to use an array of arrays like
[[[(_position select 0) - 10, (_position select 1) + 10, 0]],"M2StaticMG","Easy","Hero","Hero",0,2,"Random","Random",_mission] call spawn_static;
The spawn_static call seems to support an array of position vectors [[x1,y1,z1],[x2,y2,z2]] but you only provided a single vector [x,y,z] -> use a single-member-array of vectors [[x,y,z]].
In your case, I guess you could create your 2 nests simultanously
[[[13424.713, 5373.127,0],[13589.972, 5244.6523,0]],"Fort_Nest_M240","random","bandit","bandit",0,2,"random","random",_mission] call spawn_static;
In the new WAI they seldom use setDir (I've seen it within loops) but afaik they didn't change that much regarding mission internals, so for the direction you could try going with the old method
_baserunover = createVehicle ["land_fortified_nest_big",[(_position select 0) - 40, (_position select 1),-0.2],[], 0, "CAN_COLLIDE"]; _baserunover setDir 90; _baserunover setVectorUp surfaceNormal position _baserunover;
Zafir so fucking broken !
in Bug Reports
Posted
Given the difference between 7.62 and 5.56 ammo that's not astonishing.
5.56 has mainly been introduced because the "soft kill per ammo weight" ratio is better. 7.62 is overkill on unarmored targets at less then let's guess 300m, so you can save on ammo weight your GI has to pack for one engagement.
On the other hand 5.56 lacks penetration even against body armor at medium ranges.