List of regressions between 1.62 and 1.63 betas

[Dwarden 1125]

please post here any regressions / game breaking bugs alike between 1.62 and 1.63 OA beta ...

either URL to CIT (community issue tracker) ticket if present

or short post with repro / description / url to repro mission etc.

note: it helps to mention which build number was ok and which is broken etc.

[Tansien 2]

Stuff I know for sure:

Between 103718 and 108074 the automatic cleanup of empty "WeaponHolders" and Parachutes was broken in MP environments. According to issue on CIT it's MP only.

https://dev.withsix.com/issues/74473

Might be related to: https://dev.withsix.com/issues/72574

Edit: Apperently when it comes to parachutes atleast, it might be that the delete is not synchronized over the network. In this screenshot, the player who just landed cannot see his parachute, but the player up in the helicopter still can.

Edited May 7, 2014 by Tansien

[Viba 1]

https://dev.withsix.com/issues/72574

Indeed often when deleting vehicles, if you run up to the location where the vehicle was deleted you can still get the action menu options for gear, get in as driver etc. And the isNull check returns false.

Two of the most disturbing current bugs are these that mainly happen under high server load:

1. Player A enters a vehicle, player B enters the same vehicle. Player B is inside the vehicle on his computer but in player A:s screen player B is standing next to the vehicle where he supposedly got inside -> other players can kill the player B who is just standing where he boarded the vehicle. Clients relogging/restarting seldomly/perhaps never fixes the problem, creating a new similar vehicle and boarding that one fixes it. Vehicles that bug like this are created by the server, might happen with client created too, haven't tested.

2. Destroyed buildings cause random "silent and invisible explosions" or in other words deal random damage to players, vehicles etc. next to them as if they were still exploding. This usually causes a chain reaction with other buildings close by as they also receive the damage and get destroyed, after that the newly destroyed buildings start dealing this weird damage and so on. My theory is the engine is syncing the damaged buildings to new players who join and that somehow causes this? For now I have put enabledamage to false on all house objects to all clients because of this. Sometimes you can die from this with a delay, say stand next to a destroyed building -> move 2000m away from it and get randomly killed after a while.

Those two bugs might be hard to reproduce but I have played, tested and torn out my hair about them for over a year now and simply outruled anything else that could cause those problems.

The bugs are in both 103718 and 108074 beta versions (tested with same/mixed versions on both client and server), I haven't been able to test with a 1.63 version since most players still use 1.62 for a good reason.

Edited May 7, 2014 by Viba

[tobiassolem 11]

Modifications that utilize the Artificial Intelligence, such as Wicked AI ( epochmod.com/forum/index.php?/topic/4427-wicked-aimission-system/ ) lead to AI from the same faction shoot each other; other reports other than mine here: epochmod.com/forum/index.php?/topic/4427-wicked-aimission-system/page-32#entry69570, relevant codesnippet here

createCenter east;
WEST setFriend [EAST,0];
EAST setFriend [WEST,0];

[Viba 1]

Don't want to clutter this thread, but had similar problems that got solved by doing it like this:

_actualgroup = createGroup civilian;
_dummygroup = createGroup civilian;
_man1 = _dummygroup createunit ["BAF_Soldier_AAT_W", position, [], 0.5, "Form"];
_man2 = _dummygroup createunit ["BAF_Soldier_AAT_W", position, [], 0.5, "Form"];
... etc.

_NPCs = units _dummygroup;
{
[_x] joinSilent _actualgroup;
} forEach _NPCs;

Creating the AI directly to the _actualgroup resulted in them killing each other, using a _dummygroup before and transferring them afterwards to the _actualgroup solved it.

Edited May 7, 2014 by Viba

[Vipera 10]

Original CTI missions do not work. Game is broken in MP with the latest beta (not sure from which beta exactly). I start MP by LAN, Utes map, War welcome scenario on my first computer. Then I join to this server from my second computer and start the game. The problem is that the player on the host computer cannot respawn after death. The player from joined computer can respawn fine. If I disable beta on both computers then everything works good.

---------- Post added at 06:00 PM ---------- Previous post was at 05:58 PM ----------

One of the latest updates (before 1.63) breaks guided missiles controlled by AI gunner. Can someone test it please? In Editor put Apache controlled by the player as a pilot. Put some T-72s in a distance for the targets. Play mission. Highlight the target. Try to hit target by Hellfire missile commanding to your AI gunner. In my case missiles fly straight forward as unguided missiles. Now switch to manual fire mode and try to hit the target by yourself. In manual fire mode Hellfire missile is guided and hits the target.

---------- Post added at 06:01 PM ---------- Previous post was at 06:00 PM ----------

There is no missile warning sounds on aircraft.

[Tansien 2]

Oh yeah,

Previously you could get a couple of hundred of messages like this during a 3 hour-timeframe...

16:15:00 Server: Object 4:19 not found (message 99)

16:15:00 Server: Object 4:20 not found (message 91)

But with 1.63 beta, you have to disable the logging because otherwise you'll end up with a log that is 500MB. It's usually just a few NetIDs and it will get logged ~25-50 times every second for each NetID.

Edited May 8, 2014 by Tansien

[goliath86 11]

.....

---------- Post added at 06:00 PM ---------- Previous post was at 05:58 PM ----------

[/color]One of the latest updates (before 1.63) breaks guided missiles controlled by AI gunner. Can someone test it please? In Editor put Apache controlled by the player as a pilot. Put some T-72s in a distance for the targets. Play mission. Highlight the target. Try to hit target by Hellfire missile commanding to your AI gunner. In my case missiles fly straight forward as unguided missiles. Now switch to manual fire mode and try to hit the target by yourself. In manual fire mode Hellfire missile is guided and hits the target.

---------- Post added at 06:01 PM ---------- Previous post was at 06:00 PM ----------

There is no missile warning sounds on aircraft.

Exactly, same bugs that prevent the ah-64 training mission of OA to complete when you have been ordered to fire Hellfire missiles on targets (you can't hear the beep of locking targets). Without beta the mission is ok.

[foxyboy1964 0]

Sorry, my bad. Rockets can be fired.

Edited June 2, 2014 by foxyboy1964
Original post was bollocks.

[Groove_C 267]

Two of the most disturbing current bugs are these that mainly happen under high server load:

1. Player A enters a vehicle, player B enters the same vehicle. Player B is inside the vehicle on his computer but in player A:s screen player B is standing next to the vehicle where he supposedly got inside -> other players can kill the player B who is just standing where he boarded the vehicle. Clients relogging/restarting seldomly/perhaps never fixes the problem, creating a new similar vehicle and boarding that one fixes it. Vehicles that bug like this are created by the server, might happen with client created too, haven't tested.

Can confirm this. Happens sometimes. Today on one of our servers one player bought BMP-2 and boarded it as gunner. Another player managed to board it as gunner as well despite the fact that gunner place was already in use. The last who boarded the BMP-2 as gunner was seen as standing near it by first player and not inside.

Both players were asked to disconnect to see which patch they had installed. Once reconnected both told me that they had patch 1.62.95248 installed.

Same thing happened yesterday with Su-34, where the pilot asked several times the gunner to hurry up to board the plane, but the gunner told the pilot he was already inside. The pilot told the gunner he sees him as standing near the plane and not being inside. Patch 1.62.95248 for both as well.

And yes, you can kill the player standing at the place where he boarded the vehicle and he will die inside the vehicle (flying plane or rolling tank).

Edited June 1, 2014 by Groove_C

[icomrade 1]

Can confirm this. Happens sometimes. Today on one of our servers one player bought BMP-2 and boarded it as gunner. Another player managed to board it as gunner as well despite the fact that gunner place was already in use. The last who boarded the BMP-2 as gunner was seen as standing near it by first player and not inside.

Both players were asked to disconnect to see which patch they had installed. Once reconnected both told me that they had patch 1.62.95248 installed.

Same thing happened yesterday with Su-34, where the pilot asked several times the gunner to hurry up to board the plane, but the gunner told the pilot he was already inside. The pilot told the gunner he sees him as standing near the plane and not being inside. Patch 1.62.95248 for both as well.

And yes, you can kill the player standing at the place where he boarded the vehicle and he will die inside the vehicle (flying plane or rolling tank).

I can confirm this as well. in a server with a large amount of players and mission objects the gunners boarding will remain on the ground next to where they got in. Each gunner will have their own set of ammo. However, it seems to be a JIP issue as players that join before high desync on the server are unaffected on their screen only.

For example, if I am the first person out of 10 to join before desync all of our games will show the correct gunners in the seat for each of the 10. However, if someone is to join after high desync and hop on a gun, not only will they be standing on the ground on the original 10 players screens, if an original player is to get out and on a gun they will only be standing on the ground in the late joiner's screen. In other words players that join before high desync and after will hive out of sync screens.

Also, in the venom if the pilot is on manual fire before the crew chief hops in the crew chief's bullets do not make impact (it shoots but the impacts are inside of the gun).

[dr. hladik 231]

> Between 103718 and 108074 the automatic cleanup of empty "WeaponHolders"

> DeleteVehicle doesn't delete any Objects

fixed in 124802

---------- Post added at 12:20 PM ---------- Previous post was at 11:46 AM ----------

> One of the latest updates (before 1.63) breaks guided missiles controlled by AI gunner. ....

Cannot reproduce

> Modifications that utilize the Artificial Intelligence, such as Wicked AI ...

> 1. Player A enters a vehicle, player B enters the same vehicle....

> 2. Destroyed buildings cause random "silent and invisible explosions" or in other words ....

Is it regresion?

Edited June 2, 2014 by Dr. Hladik

[Viba 1]

>

> 1. Player A enters a vehicle, player B enters the same vehicle....

> 2. Destroyed buildings cause random "silent and invisible explosions" or in other words ....

Is it regresion?

Maybe not but thought it would be good to mention if you guys are still working on A2, those are probably the nastiest bugs on servers with lots of players.

[Vipera 10]

> One of the latest updates (before 1.63) breaks guided missiles controlled by AI gunner. ....

Cannot reproduce

Can someone test it, please? In Editor put Apache controlled by the player as a pilot. Put some T-72s in a distance for the targets. Play mission. Highlight the target. Try to hit target by Hellfire missile commanding to your AI gunner. In my case missiles fly straight forward as unguided missiles. Now, switch to manual fire mode and try to hit the target by yourself. In manual fire mode Hellfire missile is guided and hits the target.

[Sari 18]

Just remembered about this from my early scripting days:

http://forums.bistudio.com/showthread.php?164272-quot-fired-quot-eventhandler-only-has-a-7km-range-for-other-clients

Any chance this could get looked at? (assuming its a bug and not intended...)

[rübe 127]

I've posted this yesterday already, but in the wrong thread (sorry :o)...

I think this belongs here:

Problem: Units can get easily stuck during a moveTo.

Presumed reason: moveToFailed does not fire when it should. Actually I think moveToFailed currently never gets fired at all!

Repro./demo mission: http://non.sense.ch/shared/moveToFailed.Chernarus.pbo

The scenario is as follows: 4 AI are spawned into the players group, which then execute the very simple move.fsm (see moveToFailed-fsm.png) by a call to doFSM. Unless the AI don't die, that move.fsm is supposed to run indefinitely: at each step a random position around the player is chosen for the next moveTo, which is issued and then we check if moveToCompleted or moveToFailed (this would get written to the RPT file - but never does...). Either way, completed or failed, the next moveTo is issued, and so forth. Thus, the spawned AI units are supposed to continously walk around the player here.

To get them stuck for this repro, a ruins object is spawned, but it's really not a problem with this object and the actual problem may occur anywhere else. This simply speeds this up a bit. Start the mission, speed up time and observe from commander perspective.

What can be noted is:

• moveToFailed never get's fired a single time. (I tried this too in cities and close to massive rocks - yet moveToFailed never fires...)
  
• stuck units - they don't move any longer, yet they don't issue a moveToCompleted nor a moveToFailed - can be occasionally unstuck, by having other AI or the player move into them. In the posted demo mission, often all but one unit get stuck, and after a while some get unstuck again, and get stuck again a bit later... and so on...
  

I hope this helps to narrow down, what is wrong here.

I did these experiments with 1.62.95248. Are you guys (maybe with newer beta patches) able to reproduce my experience with this?

And did anything with respect to low-level moveTo commands actually get changed?

I'm pretty sure this was not always the case, and that I've observed many moveToFailed in the past. But not any more? How come?

Edited June 27, 2014 by ruebe

[Dwarden 1125]

@ruebe - I'm confused

you did the tests on 1.62.95248, which is nearly 2 years old build

while latest beta is 1.63.125402 from yesterday

[rübe 127]

@ruebe - I'm confused

you did the tests on 1.62.95248, which is nearly 2 years old build

while latest beta is 1.63.125402 from yesterday

:o

Yeah, I didn't bother with beta patches since I've re-installed Arma2 this spring on my new machine.

And then this STEAM only patches and what not... yeah, I'm a bit confused.

But isnt 1.62.95248 the last "stable" version? :rolleyes:

But fine, so which patch do I need to install (at least) or do you suggest I should import Arma2 into my steam thingy (is there a how-to somewhere)? Would that need a complete reinstallation? :eek:

Either way, it would be nice if someone could check if, what I've reported, still happens with the most recent beta patch. Shouldn't take too long, to at least verify if moveToFailed get fired again or not.

[Iron_HFW 1]

Version 1.63.125402.

BIS Functions Module is still not properly reporting that it has been initialized. This was reported with 1.63 betas in the summer of 2013.

Countless mods and scripts expect this to work properly before they start their own processing. This is core functionality, and expecting players to use a workaround such as replacing core engine files in every single mission is not feasible.

A sample mission consisting of a single player infantry and the BIS Functions Module is enough to confirm this behavior. Like this one.

Here is an RPT of the process. No mods were running:

=====================================================================

== C:\Games\Steam\steamapps\common\Arma 2 Operation Arrowhead\ArmA2OA.exe

== "ArmA2OA.exe" -window -nosplash -skipintro -showScriptErrors

=====================================================================

Exe timestamp: 2014/06/27 17:57:32

Current time: 2014/06/27 20:03:38

Version 1.63.125402

Warning: looped for animation: ca\anims\characters\data\anim\sdr\mov\erc\wlk\non\non\amovpercmwlksnonwnondf.rtm differs (looped now 0)! MoveName: amovpercmstpsnonwnondnon_amovpercmstpsraswpstdnon

Warning: looped for animation: ca\anims\characters\data\anim\sdr\mov\erc\wlk\non\non\amovpercmwlksnonwnondf.rtm differs (looped now 1)! MoveName: amovpercmrunsnonwbindf_rfl

Error in expression <;

_recompile = (count _this) > 0;

if (BIS_fnc_init && !_recompile) exitwith {t>

Error position: <BIS_fnc_init && !_recompile) exitwith {t>

Error Undefined variable in expression: bis_fnc_init

File ca\Modules\Functions\init.sqf, line 28

Obviously it would be nice to see the animation error fixed as well.

[UK431-Soul 10]

second that Iron_HFW, should be easy to fix for the devs.

My tought as a dev would be: "let's get this out of our way first"

but yeah call me crazy.

[rübe 127]

while latest beta is 1.63.125402 from yesterday

Okay. I've uninstalled Arma2, imported all keys into Steam and reinstalled the whole thing, including the (marked as obsolete?) beta patch.

Then I've repeated the experiment (repro mission posted above) with 1.63.116523.

Same outcome - sooner or later all your units will get stuck: moveToFailed is completely broken (or the part of a moveTo that should detect a failure and consequently report it respectively). If I figure out how to install 1.63.125402, I'll let you know the results.

Edit: Ok, figured it out. Same problem with 1.63.125402.

Please have a look at it. Having reliable moveTo's is rather critical, and chances are this is still broken in ArmA3 (then again, I'm stunned how this went unnoticed for more than 2 years, apparentely...).

Edit 2: So either I can load A2OA as CO - or I can use the -mod startup parameter to load mods, but not both? Is that correct?

Also:

Error Undefined variable in expression: bis_fnc_init

What? Why is the BIS function module broken?

Since (at least) 1.63.116923?

Well, that's just awesome...

(or did something change, I'm not aware of?)

P.S. Please don't tell me, that the hack proposed by icomrade is the current/official(?!) "solution" to this?

P.P.S. File ca\ui\scripts\handleGear.sqf, line 521, Error Undefined variable in expression: bis_control_cam, and so on... well, no thanks. I'm back to something that isn't totally broken...

Edited June 30, 2014 by ruebe

[oukej 2911]

Then I've repeated the experiment (repro mission posted above) with 1.63.116523.

Same outcome - sooner or later all your units will get stuck: moveToFailed is completely broken (or the part of a moveTo that should detect a failure and consequently report it respectively). If I figure out how to install 1.63.125402, I'll let you know the results.

Edit: Ok, figured it out. Same problem with 1.63.125402.

Please have a look at it. Having reliable moveTo's is rather critical, and chances are there this is still broken in ArmA3

Acknowledged. There might be however something more to it. Thank you for your repro mission!

Would you by any chance remember which rev. it was still working correctly for you?

[rübe 127]

Acknowledged.

Good to hear!

:)

Should I bother opening a ticket on the community tracker?

And if so, I assume Arma3 is equally affected by this - needs to be checked though - should I open a ticket on the Arma3 CIT?

There might be however something more to it.

Hm, there always is, hu? :p

Care to elaborate?

Would you by any chance remember which rev. it was still working correctly for you?

Oh dear, I have no idea.

Given that this is broken already in 1.62 stable, I don't think I'll ever find out...

[opusfmspol 282]

I hope I'm posting this in the right place, I don't know whether this qualifies as a 'regression or bug' or not.

Question:

Did 1.63 change the function of the FOR-DO command, or is the Arma2OA report logging more efficiently than previous?

The reason I ask is the Arma2OA.rpt spams so many undefined variables. I succeeded at clearing up -A LOT- of those undefined variables in my editor CTI Warfare mission by tracking down a source, and it was a for-do function in one of the warfare module scripts causing that particular spam.

I previously ran 1.62 purchased from BIS download, stable and beta, and they didn't throw me an error report on that line. When GameSpy shut down I purchased 1.63 on Steam, and 1.63 spams the errors from that line (among others).

Debugging, I found that a for-do line in the warfare config_squads script is querying for one faction too many on each side. An undefined variable is being thrown for every single team configured for each side, as it queries for the undefined faction of each side.

I modified the for-do in my custom config_squads (a copy of the warfare config_squads) so it would query for two factions instead of three and those particular spams disappeared. As I said, it cleaned up my Arma2OA.rpt log a lot.

But my question is based on the fact that the script, copied over from the warfare module, didn't change between 1.62 and 1.63; but it throws an error now where it didn't before. I don't know if the function of the for-do command has changed somewhat, and what was then a correct line has now become an error, or if in 1.62 it was an error that went unreported.

FYI, in the config_squads, for each of East, West and Resistance squads, I changed a line that read:

for [{_count1 = Count WestTeamTemplateFactionIndex},{_count1 >= 0},{_count1 = _count1 - 1}] do

The faction count was two. It was querying for three factions; 2, 1 and 0.

I changed to:

for [{_count1 = Count WestTeamTemplateFactionIndex - 1},{_count1 >= 0},{_count1 = _count1 - 1}] do

The faction count was 1. It queried for factions 1 and 0. That cleared the undefined variables for the code being run.

EDIT: Oh yeah - I still get the spam from the module config_squads, I just don't get the spam from the custom config_squads anymore. The module runs core before running the custom.

EDIT1: Nevermind, I found this:

From the changelog for 1.63:

[84265] Improved: Abnormal program termination by an error message is now more robust, less likely to cause a bogus crash report or to miss the message box.

I am only assuming the "more robust" reporting is causing the spam.

Edited July 26, 2014 by OpusFmSPol
add another final note + make a minor correction