General Discussion (dev branch)

[twisted 128]

/Close thread

 

 

 

 

 

 

 

 

 

*faints

what does ai autocombat mean?

 

edit - so its: Disables automatic switching to combat mode, unit will respect behaviour as set by player / waypoint.

 

nice!

[tortuosit 486]

a. With CTRL+R Eden can jump to any position on any? terrain. I.e., it must know its size. Is there a command which I can use to get a terrains dimension for scripting?

b. "Player"/"Playable" as checkboxes: good.

[R3vo 2654]

I am sure they get the map size from the map config

[Electricleash 133]

Eden editors INIT box on objects/units, is not 'Word wrapping' the text anymore, so it just ends up endlessly disappearing.

[St. Jimmy 272]

Is anyone still experiencing heavy FPS drops on dev branch? These were supposed to be fixed by this Dev Branch update:

https://forums.bistudio.com/topic/140837-development-branch-changelog/?p=2964148

Thanks!

Oh my I think I got this bug again somehow. I had the game windowed. Happened now two times in a row in heavy AI fighting (same mission where it didn't happen yesterday) when I moved my mouse/view quickly. Even in the menu the fps was horrible and switching to full screen didn't help.

 

I've couple things I need to check if any of these things help:

I had -malloc=system

I had the game windowed

 

I'll post more later.

[twisted 128]

a. With CTRL+R Eden can jump to any position on any? terrain. I.e., it must know its size. Is there a command which I can use to get a terrains dimension for scripting?

b. "Player"/"Playable" as checkboxes: good.

 

this may help

 

https://community.bistudio.com/wiki/BIS_fnc_mapSize

[gippo 38]

FYI: New dev branch reset all of my settings. Might happen to you as well.

edit: It resets it every time you launch the game. (for me at least) So do before you launch the dev Branch, just backup your settings.

Is it happening only to me?

[Electricleash 133]

Is it happening only to me?

I haven't had any issues in this regard.

[St. Jimmy 272]

Is it happening only to me?

Didn't happen to me.

[lexx 1392]

Arsenal integration in Eden is so damn useful, it's hard to put in words. Really, right now I don't see how anyone would ever want to stick to the old 2d editor.

[da12thMonkey 1943]

Arsenal integration in Eden is so damn useful, it's hard to put in words. Really, right now I don't see how anyone would ever want to stick to the old 2d editor.

Absolutely.

 

I'm particularly impressed that you can right-click the individual default crew members inside a crewed vehicle from the assets list, and use the Arsenal to change their loadouts as easily as any normal unit places on the map.

[Alwarren 2767]

I'm 100% positive there isn't an issue, it sounds like your gear code is making incorrect assumptions (most likely concerning locality). Eventhandlers have been understood for a long time, they don't magically run unexpectedly. The init event will:

 

As I said, it was confirmed to me that the multiple running of the init field is "intended behavior". Locality should not be an issue. If unit A had run its init field, and unit B JIP's, unit A should not run it again, but this was exactly the behavior observed.

 

It most definitely did not happen under all circumstances, but locality aside, the init field should (in my understanding) only be run once, which did not happen.

[killzone_kid 1333]

As I said, it was confirmed to me that the multiple running of the init field is "intended behavior". Locality should not be an issue. If unit A had run its init field, and unit B JIP's, unit A should not run it again, but this was exactly the behavior observed.

 

It most definitely did not happen under all circumstances, but locality aside, the init field should (in my understanding) only be run once, which did not happen.

I think you might be confusing multiple running of init statement (once at every new locality) with multiple running of init statement at the same locality (which should not happen)

[Alwarren 2767]

I think you might be confusing multiple running of init statement (once at every new locality) with multiple running of init statement at the same locality (which should not happen)

 

Okay, let me describe in detail what happens. I have a mission with custom loadout scripts. The init field calls them via

 

this call preprocessfileLineNumbers "scripts\loadout_teamleader.sqf"

 

The beginning of each of the loadout scripts is

 

private ["_unit"];
_unit = _this
if (!local _unit) exitWith {};

The result is that when the mission starts, each units get their customized loadout. For example, in this case the teamleader was the only one that gets an M4 with an ACOG.

 

When I drop my M4 and have another guy JIP, I end up with my loadout replaced with the loadout that was assigned via loadout_teamleader.sqf, i.e. I get another M4 with ACOG.

 

The other M4 was still on the floor.

 

As you can see, the script correctly checks for locality, and the player that JIP'ed got the loadout he should have (i.e. M4 with AImpoint).

 

That is the behavior I have observed. My conclusion was that the init field of the team leader got run again when someone JIP'ed. I couldn't verify it, but I told this to someone from Bohemia on a chat, and he said it sounds like a bug. A few minutes later he came back to me saying he checked with the programmer, and the programmer said it was intended behavior.

 

Locality of the team leader did not change, the only locality that changed was that of the joining player. From my understanding of locality, the AI must have been local to my machine (since I was the group leader) and switched over to the joining client's machine when he joined, so indeed that AI's locality changed, but the team leader (me) did not.

 

But I am absolutely positive that the same loadout script for my team leader role ran again on my unit.

 

What this means I do not know, as I said, I concluded that my team leader's init field was run again.

[gippo 38]

Didn't happen to me.

Yeah, I think I need to reinstall arma or my whole system to fix it then :D :D

[killzone_kid 1333]

..............

 

That would happen if you have "player" somewhere in your script instead of "_unit". Because when JIP joins your squad, his unit is created on the PC of the leader (your pc), and while the local check correctly limits the script to run only once, if the script has reference to "player" in it, it will reference your unit since it runs on your PC, not his unit. Check for local means "run where unit is local" and not "run where player is local". I hope I explained it ok.

[Alwarren 2767]

That would happen if you have "player" somewhere in your script instead of "_unit". Because when JIP joins your squad, his unit is created on the PC of the leader (your pc), and while the local check correctly limits the script to run only once, if the script has reference to "player" in it, it will reference your unit since it runs on your PC, not his unit. Check for local means "run where unit is local" and not "run where player is local". I hope I explained it ok.

 

I guarantee you there is no "player" in that script.

It's also worth noting that the effect wasn't with the team leader only, it affected all units in the group. It is also not restricted to my own missions, it happened in a number of missions.

 

It might be that this issue is no longer present since the last patch changed the way init event handlers are executed. I can only point out again that I reported this behavior and it was confirmed to be intentional. Plus, this issue did not only occur with my missions, we noticed it with a number of missions. It might be related to something else, maybe the problem is in the call, or the usage of 'this', but in any case, I am absolutely positively sure that this was the behavior I experienced. I would have investigated further but for the confirmation that this was a "feature".

 

I certainly don't have your level of expertise when it comes to SQF, but I (as a rule :) ) know what I am doing. This thing really beat me. I ended up using setVariable on the unit to prevent it from running the script twice, and that worked.

[Jona33 51]

Anyone else have an issue with the new sound stuff, any unsuppresed rifle shots or grenades instantly cause a crash to desktop? I'll make a proper ticket in a moment. 

[makkuranin 19]

Anyone else have an issue with the new sound stuff, any unsuppresed rifle shots or grenades instantly cause a crash to desktop? I'll make a proper ticket in a moment.

Yes. Same thing here.

[f2k sel 164]

I'm 100% positive there isn't an issue, it sounds like your gear code is making incorrect assumptions (most likely concerning locality). Eventhandlers have been understood for a long time, they don't magically run unexpectedly. The init event will:

• Run once on each machine when the unit in question is created.
• Including on JIP machines when the unit is first "created" for them (aka when they join).

 

It sounds to me like you might be running AI enabled, so that when a player JIP's into them the gear is ran again because the unit changes locality to that players machine. In which case, yes, the correct course of action would be to somehow mark the unit as already processed and check for that initially. That isn't unintended though, just a misunderstanding in designing whatever gear system you're using.

 

 

They can go off for no reason at the start of a mission, at least this one does although not really what your talking about in this case.

 

place in the init of a metal barrel

this addEventHandler ["handledamage",{hint "EVH test"}];

 

result EVH fires at mission start.

[SilentSpike 84]

I guarantee you there is no "player" in that script.

It's also worth noting that the effect wasn't with the team leader only, it affected all units in the group. It is also not restricted to my own missions, it happened in a number of missions.

 

It might be that this issue is no longer present since the last patch changed the way init event handlers are executed. I can only point out again that I reported this behavior and it was confirmed to be intentional. Plus, this issue did not only occur with my missions, we noticed it with a number of missions. It might be related to something else, maybe the problem is in the call, or the usage of 'this', but in any case, I am absolutely positively sure that this was the behavior I experienced. I would have investigated further but for the confirmation that this was a "feature".

 

I certainly don't have your level of expertise when it comes to SQF, but I (as a rule :) ) know what I am doing. This thing really beat me. I ended up using setVariable on the unit to prevent it from running the script twice, and that worked.

 

What you're telling us goes against all known SQF behaviour though. A unit cannot be local to more than one machine at any given snapshot in time. If your gear code is really checking the locality then it makes no sense that it would run more than once unless the unit changed locality (which, for players should never happen).

 

It really sounds like a design problem, otherwise what you're saying implies there is a huge issue in arma that should break everyone's MP scripts.

 

Would you mind linking to where you reported this? Because I'm very intrigued to see what the devs had to say.

[SilentSpike 84]

They can go off for no reason at the start of a mission, at least this one does although not really what your talking about in this case.

 

place in the init of a metal barrel

this addEventHandler ["handledamage",{hint "EVH test"}];

 

result EVH fires at mission start.

 

Interesting, did you observe this happening to multiple metal barrels? Or even other objects? That's a weird quirk.

[f2k sel 164]

Only ever noticed it for metal barrels no matter how many you have it will trigger for each.

 

Never been a massive issue if you spawn the EVH with 0.2 sec delay it will be fine.

 

I suspect it's contacting the ground somehow causing damage.

[Alwarren 2767]

It really sounds like a design problem, otherwise what you're saying implies there is a huge issue in arma that should break everyone's MP scripts.

I know, but it is what I observed. There was nothing spectacular in that script, just the usual removeAllWeapons and adding stuff parts, no use of "player" etc.

 

And as I said, it isn't restricted to my missions, we had this repeatedly. Not always, which lead me to believe that it requires very specific circumstances, but which those would be, I don't know. Sometimes someone would join and all of a sudden night vision would go out because the loadout included NVG's and they were removed and re-added.

 

 

Would you mind linking to where you reported this? Because I'm very intrigued to see what the devs had to say.

 

It was on a private chat so I can't really quote it here. The gist of it was that because of e.g. Identities, quote "init is supposed to be local and launched everywhere on any init" end quote, and that local could be used to ward against it.

 

However, there *is* a local in the script, and it passes it so locality is obviously "correct". The only "oddity" might be the call, and it might be that this was a real bug that only existed for a certain timeframe because I haven't seen it happening in a while, but I am really 100% sure that the script was correctly testing for locality and still ran for all members of the group at least (possibly more, I couldn't tell).

[zukov 490]

 if you use the assassin helmet in game at least fix the shadow/artifact's error, It is for two years that is there