General Discussion (dev branch)

[lexx 1363]

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 4853]

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 2820]

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 2700]

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 2820]

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 2700]

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 2820]

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 2700]

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 2820]

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 490]

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 4853]

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 490]

"Added: T-100X Futura Railgun Tank" 

WE NEED A VIDEO!

[krzychuzokecia 717]

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 490]

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 1363]

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.

[froggyluv 2136]

Havent played these games in forever but pretty cool your still developing - 👊

[gatordev 219]

After today's Dev Update (8/14/24), every mission I load in the editor and then try to play gives me a warning that the init.sqf can't be found.  Obviously it's still there in every mission folder.  Is anyone else having this issue?

[EO 11275]

47 minutes ago, gatordev said:

 Is anyone else having this issue?

 

Missions (my own) are loading and playing just fine on latest Dev Branch.

[gatordev 219]

4 minutes ago, EO said:

 

Missions (my own) are loading and playing just fine on latest Dev Branch.

 

Ugh, this is frustrating.  Every single SP mission (that's not a .pbo file, still a mission folder) that I've tried that I've made is giving me the error after hitting "Play Scenario" in the editor.  I even tried loading a different User and same thing.  I also tried loading them as MP missions (just to see) and no go. 

 

It worked last night when I was in the game.  Today the game updated to the new branch and now I have the issue.

 

I've verified game files and otherwise haven't changed anything.  I guess I'll have to go back to the Release branch and see if I have the same issue.  If I do, I have no idea what to do.

[gatordev 219]

Confirmed that when I go back to Stable, the problem goes away.  I'll continue to mess with it, but for now, it looks like the Dev Branch is causing the issue (for me, anyway).

[gatordev 219]

I'm looking for any further guidance based on what I'm finding, but here's what I've narrowed down:

 

1) Mods loaded doesn't seem to matter, it's only the mission files that seem to have the issue.  That said, I did a bunch of testing with just vanilla A3 running (along with Contact and the associated regular DLCs...no cDLCs were running).

 

2) It appears it's the actual "init.sqf" in the mission folder that causes the issue.  When there is an init.sqf file in the mission folder, even if it's completely empty, I get the error that it can't find the init.sqf ("Cannot load C:/...../missions/testmission.altis/init.sqf").

 

3)  As soon as I delete the file and reload the mission, the message goes away.

 

4) None of this happens in Stable Branch, just the current 8/14/24 Dev Branch.

 

I can report it on the tracker, but I'm not sure how much that helps if no one else is experiencing this.  Is there anything else I should be checking, like the extra switches that get added?  I've tried the above using both the Steam Launcher and Arma3Sync.  File Patching is turned on, but I'm not sure what that would matter now all of a sudden.

 

Help!

[.kju 3244]

should be fixed again with today's dev branch update