create an MP map, put only this line in init.sqf:

enableEnvironment false;

doesn't take effect.

this function should turn off ambiant life : like wind sounds, insect, bugs, rabbits, flies, etc

Why this design choice ? I don't understand. Why we have to work with an invisible object the weaponholder instead the visible object ? what is the benefit ?

IT should be the inverse:
getweaponholderentity()

this behavior has been implemented as a part of further design document(section: interaction with a content placed on a ground and/or crate).

is it a private or public document ? Where we can fount it ?

For the other hand, the only thing I know about you is you are not so polite to others ;-) Just my two cents

Let me be quite profesionnal (..) it s perphaps because you don't read enough the BIS FORUM, and you don't see the coders who use the arma's functions (..)

It's not important but you can't talk to me about community when you are a worker from BIS and you receive a salaries for your work while i do this for FREE since 2007 (7/7)

I recieve so much requests from this community to enhance/fix the vanilla work, support coder through chat, forums or other, and organize events, that i know what i m talking about.

I don't want to be rude with you, but i think the minimun of BIS should be to/

• give premium access to the tracker to well known community developers which have good pratice to permit to fix, priorize, give some orientation on design choice
• give acces to design decision when it s happen through documented paper
• update its wiki

Do you think i m happy to complain ? I just used a script that was developped by other developper, worked for several months, and don't work anymore after release.

For my think, the thing you are talking about broke the global design cause script only created before standalone object.

I lost half day on this stupid bug to find why the object cant move anymore, came here to open a tracker, and explain the case.

So yes i m a bit lazy of what happens here (..)

and what ? You just proove what i said before. The reference to the old object is lost, and you retrieve the new bacpack reference with nearestobject command.

Try this code instead:

_pack = unitBackpack player;
player addBackpack "B_Parachute";
_weaponholder = nearestObject [_pack, "GroundWeaponHolder"];
_position = position player;
_weaponholder setpos [((_position select 0) + 10), ((_position select 1) + 10)];
_distance = (_pack modelToWorld [0,0,0]) distance player;
hint format["bacpack is at %1 meter of player", _distance];

The backpack will be move at 15 meters, and your _pack is at 0 meters (..)

Note: your nearestobject command is not a good way to fix this problem, it's just a workaround.

i want to go out of this maze doom. I spend more time to talk to explain things to unskilled guys than coding. (i open this poor ticket 2 months ago)

If BIS doesn't want to fix this kind of problem, at least they should share the source, i will fix it myself.

well i m sorry, i had a bad spirit yesterday. You are not unskilled, we are just not agree about how the things should go.

your analysis is Wrong.

It's not a position problem, it s an object reference problem. This bug happens 2 releases ago.

_pack = unitBackpack player; get reference to players backpack
player addBackpack "B_Parachute"; drops old pack at player's feet

_position = position player;
_pack setpos [((_position select 0) + 10), ((_position select 1) + 10)];
_distance = (_pack modelToWorld [0,0,0]) distance player;

hint format["bacpack is at %1 meter of player", _distance]; // 15 meters

But the new object suppose to be the old backpack still at foot of player (..)

Killzone i saw your trolls on any other tickets with wrong/stupid analysis.

As you don't have the skill to report or understand thoses kind of problems,you shouldn't ask to close them.

The question is not why deleting 2 lines in editable file, the question is why the sync between fog runing in game and AI parameters is not working. Is it a default parameter problem, or other thing, i dont know.

If there is an issue here, it can happens at another place and affect AI skills. There is no way to detect this kind of bug.

nope, all weather settings should not be dependant of mission.sqm as they can be overide by script.

0 setfog 0; 0 setovercast 0; don't solve the problem.

mission.sqm is a text editable file, not a binary file like pbo or dll (..) All parameters that are not explicity setted in this file, should have a defaut setting. This one seems to be max fog or 0 fog or other that have a bad effect on AI.

report bug on this doom tracker is useless. You will never go out.

not working as expected (not working anymore like in A2) first parameter is totaly useless.

i confirm, nearestObjects function used with a big radius value crash the game on Altis

you can have access to code at this uri:
https://github.com/code34/war-in-takistan/blob/master/warcontext/ressources/WC_fnc_enumvillages.sqf

yes it s a problem, cause with this kind of classification, we will have everytime some kind of objects that are not houses. It didn't happen on arma2 maps

thank you. Do you know where can i found a really tree of differents objects class ? I know there was a tree on wiki but it was not up to date for arma2

well, 3 months later (..)

yes, sea bed objects are not house (..) With this you can not do global treatment on houses, you have to do a special condition to control if the objects is a sea bed, or other thing that is not be an house. It's not logic.

one more times :(

up !

it seems, there are also others submarine objects in "house" class.

any news about this problem ?