General Discussion (dev branch)

[ceeeb 147]

Anyone on Dev Build know if the new command getRelPos takes position as first param as well? Biki says only accepts object as reference.

b:OBJECT getRelPos ARRAY

 

Objects only sadly.

[Greenfist 1863]

 

Anyone on Dev Build know if the new command getRelPos takes position as first param as well? Biki says only accepts object as reference.

_relpos = object getRelPos [array,integer];

The result is related to the object's direction. Positions don't have directions. :)

You may want to use getpos:

(pos or object) getPos [distance, heading] 

[fn_Quiksilver 1633]

 

The result is related to the object's direction. Positions don't have directions. :)

You may want to use getpos:

(pos or object) getPos [distance, heading] 

 

ahh

 

getPos

 

Since Arma 3 v1.55.133361, an alternative syntax is added that allows to get position given distance and heading away from original object or position, the equivalent of BIS_fnc_relPos

[johnnygitarr 4]

when you are shooting or when you are not shooting? Maybe it's the smoke effects from shooting, they can kill fps from 60 to 30 or something crazy like that, just if you get too close to a handfull for particles. It's one of the biggest fps killers out there... Maybe try and reduce your particle settings (this will only reduce particle amount but not solve this issue entirely)

 

hi x3kj,

 

thnx for your answer ...

 

no i think it has nothing to do with the smoke effects.

the fps loss starts right after im in the scope without shooting.

 

i tryed another vanilla scope (the one with the nightsight)

same loss here.

 

a mod (dunno which mod) dependent scope was not effected

the fps was more or less the same.

 

maybe it has to do with mods. i try to investigate further this evening

when i have more time ...

[Mr. Charles 22]

Now with the staging of Apex content on dev branch you could get a little bit squeezy when you see a 473.4 mb update.

[Greenfist 1863]

Now with the staging of Apex content on dev branch you could get a little bit squeezy when you see a 473.4 mb update.

True, but there's so many updated files that I assume it's just repacked old data.

[roberthammer 582]

Now with the staging of Apex content on dev branch you could get a little bit squeezy when you see a 473.4 mb update.

Hardly - if anything that will be surely related to Eden update

[themaster303 22]

found something intressting:

 

https://www.youtube.com/watch?v=Je3Cs_0Jq7U

 

i dont know how cpu intensive that is, but it sounds cool, and would add

realism to the sound.

 

but i think the sound-engine of arma is to diffrent to the source engine

they used to show there audio-ray-tech.

[dna_uk 30]

Still missing the Arsenal option in Eden  :mellow:

[inlesco 233]

Still missing the Arsenal option in Eden  :mellow:

Bet it's coming tommorow... or some day next week ;)

 

But yeah - feeling very excited to use the integration, management becoming as fluid as ever!

[Varanon 892]

Just had another look at Eden, and two things: For one, I like the separation of individual vehicle types, like Tanks, APCs, Drones, Planes, Helicopters.

 

However, and that was really a facepalm moment: Why the HECK put ALL infantry into one "Men" category ? Instead of having Men, Men (Story), Men (Divers) etc, there's just Men now.

 

In CUP, USMC Men now has nearly 50 entries, vanilla NATO has nearly 60 entries in one category. How is that supposed to help make selection of units more intuitive ?

 

Sorry, but if that is not a bug, it's a design decision that I just don't understand

[R3vo 2652]

I just hope they also make it JIP compatible.

[Alwarren 2765]

I just hope they also make it JIP compatible.

 

Yeah, especially considering the nonsensical behavior of the Init field, I hope it won't cause duplicates or in-mission resets when someone JIP's.

[R3vo 2652]

Yeah, especially considering the nonsensical behavior of the Init field, I hope it won't cause duplicates or in-mission resets when someone JIP's.

 

It's a really easy fix at least for the Arsenal. They would only need to add a check at the beginning of each script:

 if (!local this) exitWith {};

[inlesco 233]

for Eden - I'd like to see an option to exclude selected factions / type of faction's X from search results, etc.

 

Sometimes, when you're making an RHS misson, you'd love to see all the RHS factions without NATO, CSAT, etc.

 

Just a thought. I suppose this feature has already been in the plans for a long time.

[Alwarren 2765]

 

It's a really easy fix at least for the Arsenal. They would only need to add a check at the beginning of each script:

 if (!local this) exitWith {};

 

The init field is run for each unit in a group if someone joins in that group, so just checking for locality is not enough. You need to use setVariable or some similar mechanism, otherwise when someone JIP's into a team you will run your loadout scripts again.

[das attorney 857]

I was moaning recently about menus taking ages to open - turns out my profile was so bloated with variables in the namespace that it took ages to load pause menu and other data, so that was my bad.

 

Hope this helps anyone else who has any similar issues.

 

 

Oh and the sounds/sound engine are/is a lot better - could do with some more work/tweaking but definitely heading in the right direction.

[pettka 694]

Just had another look at Eden, and two things: For one, I like the separation of individual vehicle types, like Tanks, APCs, Drones, Planes, Helicopters.

 

However, and that was really a facepalm moment: Why the HECK put ALL infantry into one "Men" category ? Instead of having Men, Men (Story), Men (Divers) etc, there's just Men now.

 

In CUP, USMC Men now has nearly 50 entries, vanilla NATO has nearly 60 entries in one category. How is that supposed to help make selection of units more intuitive ?

 

Sorry, but if that is not a bug, it's a design decision that I just don't understand

Good point, sir. This is still in progress, what You see is a temporary state that should be addressed by the end of this week :icon_twisted:

[R3vo 2652]

Good point, sir. This is still in progress, what You see is a temporary state that should be addressed by the end of this week :icon_twisted:

 

I created two tickets with suggestions, would be great if someone would look into them

 

http://feedback.arma3.com/view.php?id=27470

http://feedback.arma3.com/view.php?id=27498

 

The init field is run for each unit in a group if someone joins in that group, so just checking for locality is not enough. You need to use setVariable or some similar mechanism, otherwise when someone JIP's into a team you will run your loadout scripts again.

 

Hmm, interesting. I just quoted what killzone kid wrote in his blog about multiplayer scripting. And using the !local check, never caused any issues for me.

Source

[killzone_kid 1326]

The init field is run for each unit in a group if someone joins in that group, so just checking for locality is not enough. You need to use setVariable or some similar mechanism, otherwise when someone JIP's into a team you will run your loadout scripts again.

 

Sounds like one of those Arma myths that everyone heard of but no one have seen one ;)

 

 

 

Hmm, interesting.

 

 

Or not. Tested it right now, init works as intended, no extra init execution on unit joining a group or jipping into a group.

[Alwarren 2765]

Or not. Tested it right now, init works as intended, no extra init execution on unit joining a group or jipping into a group.

 

I am 100% positive that there is such an issue, unless it was fixed in a very recent build. We had numerous cases where equipment suddenly recent when someone JIP'ed, or suddenly your NVG's went dark because they have been added again, and your radio setup in TFAR was messed up because the radio was just re-added.

 

As a matter of fact, I mentioned this once to oukej, and he got back to me (after checking with someone, can't exactly remember whom) saying that it was indeed intended behavior, which is why I never reported it as a bug or even tried to find out the exact circumstances when it happened.

 

I will dig into it and come up with a repro mission. It might be only an issue on dedicated server, or it might be fixed in the meantime, but it was there: Under certain circumstances, the init fields of all units in a group, or even all playableUnits, would be run again when someone JIIP'ed during the mission.

[Alwarren 2765]

 

Hmm, interesting. I just quoted what killzone kid wrote in his blog about multiplayer scripting. And using the !local check, never caused any issues for me.

Source

 

I agree with you, it's just that there definitely was the need for me to set a variable on a unit to indicate that its loadout had already been done. During a mission, equipment would randomly double during JIP (if the loadout script added to an existing loadout), or TFAR would suddelny report "Getting ID from server" because you got your radio twice.

 

I hadn't checked locality, but even if this was executed on a different client or the server, it wouldn't change that the init field is run twice. I don't get the logic behind it, but as I said one of the programmers said it was intended like this.

[SilentSpike 84]

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.

[tortuosit 485]

Yay, Arsenal is back in Eden.

[froggyluv 2130]

Added: disableAI / enableAI "AUTOCOMBAT"

 

 

/Close thread

 

 

 

 

 

 

 

 

 

*faints