General Discussion (dev branch)

[lexx 1294]

I just noticed that the Kamysh damage texture is broken. It's on dev-branch and on stable, so it might be broken for a while already. Can't see why that is happening, tho. The rvmat defined in damage class seems to be the same as in the actual model file. Yet, when damaging the vehicle ingame for more than 50%, the texture doesn't swap to the damaged variant.

 

/Edit: Kamysh is missing zbytek selection for the hull. Once that is added, damage should work again. I wonder when this got broken.. maybe with tanks dlc? 😄

[boris_fps 1]

Hi, i reported a issue with the M2 Turret a little bit ago T164716 and it bugs me every time i see it. Should be a fast weighting fix of the rail selection to push into the 2.10 update. (i think it got broke when the issue was fixed where some bullets are left in the feeder when empty), if you guys aren't to overloaded allready obviously.

 

Thanks in advance

[pierremgi 4693]

Hello,

Is it possible to add an event handler for changes about variable(s) set on objects?

something like:

_object/_unit addEventHandler ["variableChanged", {
  params ["_target","_var","_status","_previousValue","_newValue"];  // where status can be "added", "modified" or "deleted"

}];

A kind of event handler for allVariables _object returning info.

 

Short example of use (player is F/A 181 pilot) :

vehicle player addEventHandler ["variableChanged", {
  params ["_target","_var","_status","_previousValue","_newValue"];
  if (_var isEqualTo "bis_wingCheckScript" && {_newValue isEqualTo bis_fnc_aircraftFoldingWings_automatedUnfolding}) then {
    hint "Fold wings is now possible from menu"

  };

}];

This EH could be efficient as well on every variables set on objects during scenario.

 

Thanks

[ZABIR 0]

On 4/30/2022 at 4:42 PM, pierremgi said:

 

1. The "rest of the group" depends on what you order. SEE VIDEO. For example, with a vanilla weapon squad, if the marksman (nbr4) is stuck (as shown in video)

    - on normal trip (no order), the units 2, 3, 5 & 7  follow the played leader, the units 6 & 8 stand by 4.

    - almost same on global regroup order: 6 & 8 are crossing the map for reaching stuck 4 !

    - on general move (whole group selected), ALL AI units are reaching stuck 4 !

 

2. I can't guess what "predecessor" (I called it deputy leader) is. Believe me in some cases there are 2 or more deputy leaders. Difficult to understand how things are working. Perhaps by native (declared in config) ranks for units forming a group.... Changing ranks by scripted code isn't successful. Creating own group with all private ranked units isn't successful. There is probably at least one FSM for this behavior.

 

The fact is, in game, you can't guess when a player will JIP onto a deputy leader, or when a deputy leader AI will be stuck in a house. Or when AI/played deputy will fall unconscious.

That will finally break all your grouped move order... or make AI crossing map for reaching this f..g deputy, for nuts.

This is utterly frustrating, almost as far as the fact these AI deputies don't stop to order ridiculous moves/get in/out/target, even for unconscious units (listen to yelling orders when player leader is unconscious) !!

 

To conclude: there is a need for AIs stopping their weird personal orders (deputy) and moves (subordinates) with a "simple" rule: CONTINUE WHAT LEADER PLAYED HAS ORDERED.

That way, the engine could be simpler, the AIs will obey (at least as ordered independently). It's far better than the present mess and probably Rube Goldberg machine, trying to maintain a fake formation, with a disastrous result, breaking immersion.

 

 

This bug is complete nonsense, compared to what the developers have done with NIGHT VISION! Verify NORMAL NIGHT VISION. I completely lost interest in the game, as I play constantly as a sniper. See how night vision is implemented in DCS World!

😬👿

[Larrow 2753]

Quote

5-4-2023
EXE rev. 150442 (game)

 

Fixed: Changes of slider Control positions caused by the engine or scripting did not trigger the "SliderPosChanged" Event Handler

@DnA@killzone_kid

Sorry but, this will break lots of existing stuff with continuous cycling. People have already accounted for this behaviour, I know it will break a few of my projects.

Slider changes, EH does some update to slider, so slider changes, EH fires again repeat forever.

 

Much like when onLBSelectionChanged and LBSetSelected were changed in 2.12, this also needs a change to sliderSetPosition, so by default the EH does not fire (as is currently) and then add a variant of the command with force EH (again see LBSetSelected)

Syntax

Syntax:
    sliderSetPosition [idc, pos, forceEH]
Parameters:
    idc: Number - Idc of the control
    pos: Number
    forceEH: forceEH (Optional, default false): Boolean - will force sliderPosChanged EH to fire
Return Value:
    Nothing


Alternative Syntax

Syntax:
    control sliderSetPosition [ pos, forceEH ]
Parameters:
    control: Control
    pos: Number
    forceEH: forceEH (Optional, default false): Boolean - will force sliderPosChanged EH to fire
Return Value:
    Nothing 

 

[Dedmen 2532]

13 hours ago, Larrow said:

Slider changes, EH does some update to slider, so slider changes, EH fires again repeat forever.

I'm not sure what you mean.. Have you actually tried it?

Eh doesn't fire if you change slider pos inside EH due to recursion protection.

 

Quote

Much like when onLBSelectionChanged and LBSetSelected were changed in 2.12

That may not have recursion protection and we should probably add it then.

[Larrow 2753]

31 minutes ago, Dedmen said:

Have you actually tried it?

No, don't currently have dev branch installed, I was just going off of the description (or scripting did not trigger the "SliderPosChanged") and the previous experience when testing the changes to onLBSelection changed back in 2.12.

31 minutes ago, Dedmen said:

Eh doesn't fire if you change slider pos inside EH.

So if any code fired by the EH uses sliderSetPosition this will not cause the event to fire again? If not, what is meant by "scripting did not fire the event"? As this is the only logical conclusion I could come to from this description, that the scripting command sliderSetPosition will now cause the event to fire.

 

 

Damn you Dedmen stop changing your post while im trying to reply lol 😛 😄

 

31 minutes ago, Dedmen said:

due to recursion protection

Is this recursion protection something new? Why was it not a solution previously as mentioned for the LBSetSelected and instead changes had to be made to add forceEH to the scripting command to compensate.

31 minutes ago, Dedmen said:

That may not have recursion protection and we should probably add it then. 

Would likely be a better solution.

[Dedmen 2532]

Quote

So if any code fired by the EH uses sliderSetPosition this will not cause the event to fire again?

Correct, changes triggered INSIDE the EH, won't trigger the EH again, which could cause recursion and crash the game.

 

Quote

As this is the only logical conclusion I could come to from this description, that the scripting command sliderSetPosition will now cause the event to fire.

That is correct. It does.

 

Quote

Is this recursion protection something new?

It was added in the last two years, to only some eventhandlers. I think originally for the HandleChatMessage handler, because you could print chat messages from the handler which would loop infinitely and crash the game.

We don't add it to all eventhandlers, only to ones where it might be needed. LBSelectionChanged didn't come up yet, I'll add it there.
Also some EH's have different recursion depth, I think chat message for example will trigger a second time, but not a third.

For SliderPos its just one deep.

 

 

But also, more problems came up with SliderPosChanged (Audio options now fires all sounds on opening). We don't need this change anymore internally, so we will revert it back.

If we were to do this again, we would probably have to introduce a new eventhandler for it.

[Larrow 2753]

Can someone elaborate on these changes, please...

 

Quote

Tweaked: Changed networking behavior of addGoggles/addHeadgear/addVest/addUniform/forceAddUniform

In what sense? LA/GA or LE/GE? Or just something that will not be noticeable to the end user?

 

Quote

Tweaked: Renamed script "Short-Circuiting" to "Simple VM"

Added: Simple VM support for if/then/else support enabled

What is meant by 'Simple VM support'? I get no hits in the wiki.

How does if/then/else support it? (maybe answered if I knew what it was :D) I see no changes to the wiki pages.

[Dedmen 2532]

1 hour ago, Larrow said:

Can someone elaborate on these changes, please...

 

In what sense? LA/GA or LE/GE? Or just something that will not be noticeable to the end user?

 

What is meant by 'Simple VM support'? I get no hits in the wiki.

How does if/then/else support it? (maybe answered if I knew what it was :D) I see no changes to the wiki pages.

 

The commands previously were LA-ish, but some where documented as GA. And they "worked" with GA but bugged out and created leaking entities that started spamming errors on server and created synchronization errors.

Its now properly GA, but I would strongly recommend to handle it like a LA command, Inventory code can get quite buggy when you have to trust on its network syncing.

 

"Simple VM" was mostly talked about in Discord, its a performance improvement where some SQF things (inside loops like forEach/apply/select) under some conditions (not yet documented as its highly WIP, mostly no local variable setting allowed) will be executed differently and about 10x faster (most tests result in about 12% of previous runtime, but that depends on lots of factors).

The scripts get converted into a new "Simpler" VM that is more efficient with executing scripts.

[Larrow 2753]

23 hours ago, Dedmen said:

mostly no local variable setting allowed

So this is the deciding factor on whether these code blocks (forEach/apply/select) get improved execution through Simple VM?

What constitutes setting a local variable? ie do local vars within the immediate scope of commands code block count or are we talking about anything currently in scope ( What is this, something related to accessing the stack )? Sorry if this is a stupid question, just trying to understand what constitutes improved execution.

[zukov 476]

there is a chance to add/fix the insignia for vehicles? 

[Rhyder_Morra 74]

idk worth it asking but can we get argo stuff(since its dead) be ported to arma 3? i found these gamemodes and assets pretty fun.
or at least unbinarize all that stuff from non pbo\ebo format so we ll be able to do it ourself?

[pierremgi 4693]

It could be nice if player couldn't make an evasive right or left, when prone with a backpack! The weirdest is a roll on back with a UGV like Pelter, diving into the ground.

Thanks for your attention.

[zukov 476]

"Added: T-100X Futura Railgun Tank" 

WE NEED A VIDEO!

[krzychuzokecia 691]

I see that we're getting some of the headwear from Argo in upcoming update - any chance the Argo olive version of AAF helmet could also be included?

[zukov 476]

the grey camo T100 futura is can applied even to a normal t100 varsuk?
edit why not the psd sample for some skin like the mrap? this camo is pretty cool

[lexx 1294]

With at least the latest dev-branch update it seems UAV's are broken for me. The moment I switch from pilot to the turret seat, the camera breaks and my character is frozen in place. Can anyone confirm this? Tried without any mods, and still the same result with every drone.

[Anile78 0]

On 8/28/2013 at 5:14 PM, Simas said:

I believe under 64bit Windows if you have installed Steam (and thus Arma) under the Program Files (x86) - which is used for 32bit apps - the Windows will apply the 2GB virtual address space limit automatically, even on 64bit OS. This is mostly done for backwards compatibility. Someone please correct me if I am wrong.

Your understanding is accurate. When Steam (and Arma) is installed under Program Files (x86) on a 64-bit Windows system, the OS may enforce a 2GB virtual address space limit for compatibility with 32-bit applications.