In T75575#1558584, @ynpmoose wrote:

In T75575#1553107, @BIS_fnc_KK wrote:

Perhaps this is due to no AI pathing existing on the roof, so they wander?

MP or SP?
if MP

does it work in SP?
do you execute command where unit is local?

This is on MP. Did not try in SP. Execution is done by server-side scripts that spawn in units via DMS Mission system for Exile (https://github.com/Defent/DMS_Exile) and immediately then try to execute my examples from above. So I assume they should still be local to the server.

Perhaps this is due to no AI pathing existing on the roof, so they wander?

Should be fixed since 1.67.139727

Thanks, reproduced

It works ok for me in the latest dev. Have you got a repro?

In T80863#1076550, @gidsacha wrote:

ctrlParent returns the parent display, regardless if the control is in a group or not.

"InventoryOpened" now returns second connected container

"InventoryOpened" now returns second connected container

"InventoryOpened" now returns second connected container

The problem is with this:

This is not going to work and will change functionality of setHitXXXX commands which will result in backwards incompatibility. For example you want head damage to update when you hit face lets say with 0.5. Ok

I would imagine this is because setHit, setHitIndex and setHitpointDamage provide direct access to hitpoint/part damage manipulation. It would be quite strange if you want to modify exact hitpoint damage but unable to do this because this affects another hitpoint,

There is no bug in here. Your initial respawnDelay is 0 means instant respawn. setPlayerRespawnTime is executed with delay, since onPlayerKilled is execVMed so it doesnt work for the first time. Set default respawn delay in description.ext - problem solved

fixed in today's dev https://forums.bistudio.com/topic/140837-development-branch-changelog/page-45#entry3106246

The correct param names are "EveryoneLost", "EveryoneWon"

Anyway why dont you look at the link provided by Torndeco, the issue there was caused by double use of str command, you might have the same issue.

return of the callextension is string already if it contains "2" then it will be compiled into a string. You should know what the database output for sure, you can do that by running database query on the database server and not rely on diag_log

I dont know specifics of your database setup but going from 2 to ""2"" is unlikely caused by single use of str. 2 to "2" or "2" to ""2"" maybe, but str doesnt double quotes like that not before not now.

Fixed str functionality only escapes " which are inside "". Nothing else has changed.

Torndeco is correct, the str command was always producing illegal strings under certain circumstances, but because it was an old bug it doesnt make it ok.

Well, I obviously cannot check what you are saying, as script you provided does nothing as it is.

I am not sure how to use your repro, it seems out of context. However I have found this in the thread you linked:

I doubt video alone without any repro helps in this case.

have you tried modelToWorldVisual and worldToModelVisual instead?

FYI autoReport (former autoSpot) enables disables automatic reporting of spotted enemies by players only. AI is not affected by this setting. Works as designed as of 1.63.137638

unit setSpeaker "NoVoice";

Use WFSideText instead

I predict if this ticket left open for 21 years, the problem will go away by itself.

Why are you running this on dedicated server? The task commands are designed to work with local player and I would expect on dedicated these commands simply do not exist.

Could you try this on DEV? It might be already fixed, you would be just wasting your time with stable.

Just tested this on dedicated. Everything is kept in the inventory of the dead body. Are you testing this on dev or stable? Could you provide repro mission?

This should be fixed.

This should be fixed. Please confirm.

This should be fixed now. Could anyone confirm please?

Cannot reproduce. Could you please give specific instructions as to what vehicle for example.

What kind of mission, saved from 2d or 3d editor?

Please read the description of the command

"Returns value of given scenario attribute from the 1st tier"

1st tier means it cannot access subclasses

https://community.bistudio.com/wiki/getMissionConfigValue supports string or array. You are not passing string, but some hybrid of string and config. Make sure it is either string or array.

Добавьте хотя бы один юнит на карту, после чего появятся дополнительные опции

Place a unit down first, then Empty category will appear.

Do you use createGroup command anywhere?

Which version are you testing this on? I have tried it on latest dev and when multiselect is enabled, tvSetCurSel can only select 1 row at a time, and if you select multiple rows manually, they all get deselected when [-1] option is supplied

The deselect all option [-1] was added recently and on BIKI is says since what version number it should be available. Are you testing this on version that is newer than the one it was added in?

One way to be sure is to remove it from config and see if you still experience the same. Please report back if you find out more.

Perhaps instead of using the original tank object for position, you can use array position which is offset from the tank and so that when you have another tank closer to that position it would return correct object. In the mean time you can also add a check that the object returned is not the same object as your original tank.

I just tried to preload object and did the trick

{1 preloadObject _x} foreach allunits

Unfortunately I'm not in a position to tell you if this is a bug or as designed.

Yes I was just going to suggest to check availability of groups. Tested on dedicated and used all 144 available groups for blufor, and when tried to join as blufor - got seagull. Going to raise this issue internally.

Have you tried this on DEV or RC already and it is still happening?

Is this on Stable? There were at least 2 tweaks regarding seagull spawn on DEV, so once you get to test it please report back with feedback.

This doesn't show much. Could you make a vid with bullet trace included so it is possible to see actually how many bullets hit the target and where?

In debug console (Esc brings console) type

hint str isFilePatchingEnabled;

Exec. Should show you hint with "true". If it is false, then it is not enabled.

Probably because of filePatching

run isFilePatchingEnabled to see if it is enabled
enable it with -filePatching exe startup param

did this fix your problem?

Reported as fixed in internal, please wait for an update.

It is being fixed, probably in the next RC

You can give description to the unit and read it with roleDescription command if that helps https://community.bistudio.com/wiki/roleDescription

Should be fixed from 1.57.134270

Ah, nice, let's find out why this happens then ;)

Your code works just fine for me, tried it in the editor, all items get removed.

You can actually already control weapon with WeaponOnBack and WeaponInHand actions:
https://community.bistudio.com/wiki/Arma_3_Actions#WeaponInHand_.2F_WeaponOnBack

Reported as fixed in internal, please wait for an update.

This is a design decision, the z will always be z of the ground for convenience. From BIKI page:

"Return Value:
Array - format [x,y,z], where z is land surface in format PositionAGL"

Same with getRelPos. When over water it will return negative z. Makes it easier to calculate an offset if needed.

One other reason is that BIS_fnc_relPos z is treated as AGL even if you supply different format, and as a result the new position may not be exactly horizontally away from origin anyway.

This is because array is passed by reference. You need to make a copy using +.

player setVariable ["Test1", +thisList, true];

^^^^ should do the trick.

Seems like this is more of a scripting issue for the forum discussion. Going to resolve then.

I have maybe slightly disappointing news, this is not a bug but feature. When more than 1 sound is supplied in sounds[] array, a random sound is picked up and played. In multiplayer every PC would pick its own random sound and this is unlikely to change for the near future.

However the good news is that you as modder or mission designed have a choice how you want to configure your SFX sounds. You can put different sounds under different classnames, 1 for each instead of putting them all in 1 array, then select which sound class you would like to play at random. This will guarantee that the same sound it played everywhere.

For example: createSoundSource [selectRandom ["Sound_Alarm1","Sound_Alarm2","Sound_Alarm3"], position player, [], 0];

Ok, this certainly clears it up, lets see if this is a bug or a feature ;)

What do you mean by track selected? createSoundSource is like createVehicle command only for sounds. When you indicate what sound to create it is created from config globally, therefore it will be the same globally. Unless you have different sounds under the same name on different PCs (which is possible if everyone is running a different mod) this could not happen.

I tested the command just to be sure, executing this on 1 client:

createSoundSource ["Sound_Alarm", position player, [], 0];

plays alarm at the same place on all clients. Could you please provide more information with repro?

life_radio_west = radioChannelCreate [[0, 0, 0.8, 0.8], "Police Channel", "%UNIT_NAME", [], false]; // ID 6

There you go, as per my previous post.

2. you use wrong id, you should use life_radio_west which will be 1 not 6

so

player customChat [6, 'test']; should not work

but

player customChat [1, 'test']; should

It starts from 1. Anyway, I'm going to resolve this as it works just fine when I tested. I'm sure you will figure out what you are doing wrong eventually ;)

there are 2 conditions that must be fulfilled for custom channel to work correctly:

1. It has to have correct units assigned to it. If unit is not assigned to the custom channel it cannot broadcast or listen on it

2. The correct channel index should be used. Channel id (currentChannel) is not the index. The index is the id returned by radioChannelCreate. It starts from 1. when 1st time radioChannelCreate is executed it will be 1 not 6 or 7 or 8.

So

<unit assigned to this channel> customChat [<number from radioChannelCreate>, "whatever"]

works. If it doesn't work for you, you must be doing something wrong.

So what you are saying that essentially what you are doing is:

player customChat [currentChannel, 'test'];

or did I misunderstand you?

It works here. Have you added player to the list when you created the channel on the server? Also number 6, the channel number, is this the number you got from radioChannelCreate command or some other number?

I wouldn't bet on what was the reason behind this being local, maybe because it was meant for the leader's eyes only. It doesn't seem to be a bug, so I suggest maybe making a feature request so it can be reviewed as such and assigned priority.

BTW even when using in game UI the team information is not broadcast to another player, but you can rectify this by doing it yourself:

{

_x assignTeam "RED";

if (isPlayer _x) then
{

		[_x, "RED"] remoteExecCall ["assignTeam", _x];

};
}
forEach units group player;

Please have a look at updated description for assignTeam, this should clear things up a bit https://community.bistudio.com/wiki/assignTeam

-2 means execute everywhere but the server. If you type in editor

hint str isServer;

the result would be "true", therefore it will not be executed. Does this resolve the issue for you?

Should be fixed in 1.55.134048, please test and report back

Apparently the fact that clientOwner gets ++ed is "as designed". There was a reason for it no one remembers now. So you are probably better off finding a workaround. Works fine on dedicated though.

You can use "Loaded" EH to detect mission loading from save https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#Loaded

Is it supposed to save or was this possible before? UI elements cannot be serialized, this is why there is even disableSerialization command. The display you are attaching EH to cannot be saved therefore EH will not save.

A good repro is always good.

Apparently yes, the dragging works and overrides the limit. I have raised internal ticket about it.

You mean you can still drag items into your uniform even when the load bar at the bottom shows that it is full?

What do you mean by player is still able to hold at least half a dozen Navid boxes? What criteria you use to judge this?

Is it visual space? Because the bar at the bottom is representation of inventory capacity only not geometrical or visual but weight related. It is not a stamina bar but it will affect your stamina greatly when it is full. I hope this makes it more clear.

Each container has weight limit, i.e. how many items you can put in it depends on the summary weight of items. If container is limited to let's say 40 kg, this means when you want to put in it item that together with items already in the container will exceed 40kg, canAdd will return false.

This has nothing to do with stamina, which is a different system. In fact it is stamina that depends on the weight of your items in the container and not weight of items depends on stamina. So switching stamina off should not affect how many items you can put in the container.

However, as I mentioned already, you don't need canAdd command at all. You only need it if you want to make sure when you're adding items by script it is compatible with how inventory does it.

I'm sorry, but what is this ticket about? canAdd indeed depends on the overall weight of all added items, it works exactly in the way in game inventory does. If you can add item manually with inventory then canAdd will return true. If this doesn't suit your scenario you can simply avoid using canAdd. Does this solve your issue?

The id handling has changed as you can see from the ids themselves, they are all over 1000000 and it is quite possible that UseMagazine is still relying on old ids. Since new ids are WIP I could not tell you when this will be addressed.

Perhaps you could try fire command https://community.bistudio.com/wiki/fire

Fixed in internal, so wait until it is updated in the DEV

Some features that are currently WIP will make this more reliable and consistent when released.

Should be fixed in 1.55.133867