ARMA 2: OA beta build 76815

[metalcraze 290]

Hopefully those fixes will do something to crashing AI pilots in planes too.

It still was nice to see how when I was in a chopper AI flew very close to a very very steep hill and yet managed to pull up without crashing.

[suma 8]

Is it possible to get some kind of comment/explanation/insight in what the problem was with the bobbing helicopters?

The problem was with with acceleration in a combination with terrain avoidance. When heli is flying under its assigned altitude, it limits its dive. The intent of this is to raise a nose once hill appears in front of a heli. The bug with acceleration was the heli tried to accelerate too much in high speeds, which resulted in losing altitude fast, trigerring the terrain avoidance.

The fix is that now the AI is not even attempting to dive that much when flying fast, therefore the acceleration is smooth, without losing altitude.

[maddogx 13]

The fix is that now the AI is not even attempting to dive that much when flying fast, therefore the acceleration is smooth, without losing altitude.

Thanks for the info. :)

Can you confirm whether or not this fix will make it into patch 1.57 final? Dwarden was previously saying it wouldn't be until 1.58, but that would imply that the 1.57 patch will have a lower build number than the current beta.

Any comment on this?

[Dwarden 1125]

Thanks for the info. :)

Can you confirm whether or not this fix will make it into patch 1.57 final? Dwarden was previously saying it wouldn't be until 1.58, but that would imply that the 1.57 patch will have a lower build number than the current beta.

Any comment on this?

i already said (no idea if here on forums) that by popular demand this fix is now part of 1.57 :cool:

[maddogx 13]

i already said (no idea if here on forums) that by popular demand this fix is now part of 1.57 :cool:

Awesome, thx. ;)

This is the last post of yours I could find on the subject:

well the copter fix would not get into 1.57 like i said in previous beta thread already ...

sometimes You need to wait for 1.58 beta :)

Hence the question. :)

[Mr. Charles 22]

Thx for the fixes. Will there be new Data changes in 1.57/1.58? Such as more actions for the Kasatka (open door) ?

[carlostex 38]

The fix is that now the AI is not even attempting to dive that much when flying fast, therefore the acceleration is smooth, without losing altitude.

It´s more a tweak than a fix, but anyway IMHO i agree it is the best solution right now.

Thaks BIS!!!

[SaOk 112]

I noticed that the "commandstop"-command dosent work anymore like before. After some short time (maybe a minute in firefight), the team-members return to formation (or they move to some random new position). I´ve been using that much to give fixed defense positions for AI groups (e.g. to use trenches) without having a separate group for every single soldier.

[VictorFarbau 0]

Whoops, with patch 76815 apparently the zombie voices are back :don 11: Played some MP yesterday and my mates could hear them as well.

VictorFarbau

[Machinist 10]

Whoops, with patch 76815 apparently the zombie voices are back :don 11: Played some MP yesterday and my mates could hear them as well.

It isn't beta issue. It happens sometimes with 1.56 too (soundmod related maybe? im using JSRS)

Thanks for beta and chopper fix and merry x-mas to bis and other armaholics.

[Zipper5 74]

Hm, the issue with a random identity being assigned to players, like the old setIdentity bug, is now in MP, but now it keeps the player name but changes your face and your voice. From what I've tested so far, it only seems to affect the host player, and therefore only in non-dedicated servers.

Edited December 21, 2010 by Zipper5

[Stagler 39]

I get this Zipper when I play on the LAN with friends and im the host. I will get a random identity but when i die and respawn it changes back to my one.

[Alwarren 2767]

Hm, the issue with a random identity being assigned to players, like the old setIdentity bug, is now in MP, but now it keeps the player name but changes your face and your voice. From what I've tested so far, it only seems to affect the host player, and therefore only in non-dedicated servers.

http://dev-heaven.net/issues/15011

Already reported it, I play a lot on the LAN without dedicated server so we had noticed it a while back, it's been there since 1.56 betas :)

---------- Post added at 09:07 ---------- Previous post was at 09:06 ----------

I get this Zipper when I play on the LAN with friends and im the host. I will get a random identity but when i die and respawn it changes back to my one.

Team-switching back and forth will also set the correct identity

[Hanzu 10]

Yesterday we played multiple hours Harvest Red Badlands with V1.57.76815 beta with 2-4 human players.

Recently a fix was added to 76560 beta

* Patch: Fixed: Locality issues of objects in MP (mainly updates from nonowner errors). Version raised to 1.57 due to MP incompability.

All I can say is that this fix that was done is just a good try. Noowner errors still crash game or cause team or weapon anomalities which crash the game in 10-15 minutes even when we are just running in the middle of the forest with nothing special happening around. So it must be a script process which is looping in the background until game just has had enough script errors and decides to crash.

This is what we experienced:

Game crashed about 5 times with .RPT file reporting noowner errors. Also both crashdump files were automatically created. I can send them to CIT or whetever but first I want to know they are not ignored just like pretty much everything related to playing SP campaign with multiplayer.

Most of the time when loading savegames one of us spawned as a bird even though others saw his character just standing there under the bird. The feature of spawning as a bird should be completely removed when playing campaigns where every player have to stay alive and there is no need for beeing a bird (observer)! Workaround for this is for that player to disconnect and reconnect to retake his character and get rid of the bird.

Most of the times when loading savegames players 2, 3 or 4 reported (in Teamspeak) they were spawned as russian, Chedaki, NAPA, CDF or what ever and not as a member of the Razor Team. The host also noticed that there is no bottom left sceen faceicon for those players who reported to be in wrong team. This may also be related to the fact that savegames always load in high command state (CTRL+SPACE) even though you did not have high command on when you saved. It has been this way ever since Arma 2 V1.00 I guess. Savegame function should be fixed to also save status of control mode (normal or high command) that was selected when game was saved . Workaround for spawning to wrong team was to for Host to load savegame alone and then game runs already players 2, 3 and 4 join. This process worked 99% times.

One time when loading savegame player 2's original sniper weapon was mystically changed as AK-47. This looks like that player almost spawned as russian, Chedaki, NAPA, CDF or what ever and not as a member of the Razor Team, but the bug process was interrupted and it only managed to change his weapon as russian origin.

Well you may say Badlands has always been one of the buggies missions, but in fact lots of old contruction or movement related bugs have been fixed, but it still has other trouble and its warfare related gamemode and high command it is a good stress test for noowner issues.

---

And no, none of us is using any mods. So it is not about that.

You may say do not use savegame in multiplayer, well but automatical saves will also happen and when one of the characters die they will load automatically so there is no way preventing that.

PS. Have anyone noticed mpcontinue.save will have higher priority than manual saves or autosaves? What I mean if I use SUSPEND to autosave and next time automatical save happens after cutscene or whatever, then someone dies and we need to resume (load), but for your surprise it will not load the last save game but the one before it. Actually it will l always load that saves done with SUSPEND fuction and never autosaves or manual saves made with SAVE function even though they are newer and done after SUSPEND save. So if you use SUSPEND save once, you need to use it for the whole mission to have any progress.

Edited December 22, 2010 by Hanzu

[Dwarden 1125]

HANZU do you have repro case (simple MP coop mission)?

can You please create ticket on CIT http://forums.bistudio.com/showthread.php?t=102991

for this ?

[Hanzu 10]

HANZU do you have repro case (simple MP coop mission)?

can You please create ticket on CIT http://forums.bistudio.com/showthread.php?t=102991

for this ?

I'm afraid these bugs are hard to be reproed in other MP coop missions and I have not studied yet how to make own missions.

CIT I'm familiar with since there are already 3 tickets from me. I will create ticket for this one too if it is any help and I can attach my savegame folder there to serve as repro. Do you want dumps and .rpt files for all 5 crashes I experience or just for one?

Edited December 22, 2010 by Hanzu
typo

[celery 8]

I have noticed that 1.56 or 1.57 has changed the way the "Fired" eventhandler works. Before, you could get the weaponDirection of the weapon at the very moment it fires but now you get a value where the recoil has already kicked in, making single-script checks of weapon direction (incl. accuracy scripts) obsolete. I have made a workaround with a fast-looping script that saves the weaponDir for the "fired" script to use but it feels a bit awkward.

[andersson 285]

The problem was with with acceleration in a combination with terrain avoidance. When heli is flying under its assigned altitude, it limits its dive. The intent of this is to raise a nose once hill appears in front of a heli. The bug with acceleration was the heli tried to accelerate too much in high speeds, which resulted in losing altitude fast, trigerring the terrain avoidance.

The fix is that now the AI is not even attempting to dive that much when flying fast, therefore the acceleration is smooth, without losing altitude.

Thank you, much appreciated! :D

[maddogx 13]

I have noticed that 1.56 or 1.57 has changed the way the "Fired" eventhandler works. Before, you could get the weaponDirection of the weapon at the very moment it fires but now you get a value where the recoil has already kicked in, making single-script checks of weapon direction (incl. accuracy scripts) obsolete. I have made a workaround with a fast-looping script that saves the weaponDir for the "fired" script to use but it feels a bit awkward.

Sounds like another value that could be added to the return array of the fired event. Probably best to make a CIT ticket for it and make sure it gets Dwardens attention. ;)

[celery 8]

It seems that the "MPKilled" eventhandler isn't functioning at all, SP or MP. Units that have it don't fire up the EH when killed, and their killers don't either.

Reproduce:

Place a unit with this addEventHandler ["MPKilled",{hintSilent format ["%1",_this]}] in its init and kill him. Nothing happens. Change the EH to "Killed" and you get a hint.

Edited December 22, 2010 by Celery

[xeno 234]

Reproduce:

Place a unit with this addEventHandler ["MPKilled",{hintSilent format ["%1",_this]}] in its init and kill him. Nothing happens. Change the EH to "Killed" and you get a hint.

addMPEventHandler -> http://community.bistudio.com/wiki/addMPEventHandler

Xeno

[celery 8]

addMPEventHandler -> http://community.bistudio.com/wiki/addMPEventHandler

Xeno

D'oh! :p

[Dwarden 1125]

this was released as final 1.57 so guys enjoy and continue discussion in full release thread ...

[Defunkt 431]

Woot! And the Linux server at the same time. Thanks for all your work on this and every other patch Dwarden & BIS. Merry Christmas!

[Hanzu 10]

Great!

Small typo here in title "Operaton"

Thanks Dwarden and BIS. Merry Christmas all!