ARMA 2 : OA beta build 84391

[xeno 234]

The "footstep" bug is really worse.

It happens that you may see the model of another player several seconds later although he stands already right in front of you. Best visible when you start with two clients on the same machine, one that runs and one that just watches, let one client run on a road.

The faster the other client runs, the longer it takes for the model to show up/catch up to its correct position.

The position of the other client is correct, it's just the model which is delayed.

Edit: All three instances, dedicated server and both clients were using the latest beta patch.

Xeno

Edited September 9, 2011 by Xeno

[gL33k 0]

See http://dev-heaven.net/issues/23555 and related tickets. Interpolation is supposedly disabled in MP still, so you might experience good old http://dev-heaven.net/issues/1915

etc. Or new bugs, I suppose you are at least on the latest beta build on both server and clients.

i'm absolutly SURE that my 1.59 behave better considering AI displacement.

what you said is odd. because the way the trooper move , feel different.

first this back warping didn't happen before.

and second point , i see clearly soldiers running, but moving slower than their motion let you think . the soldiers "slow down" while the running motion is still in progress, they "slide" on the ground. and that make me think interpolation has something to do with it.

in a nutshell, the average position error of units is worst than 1.59

considering suma answer :

The only exception would be if someone can create a really simple and short repro with only a few units

this is strange, because this regression is easily seen. i hope it's not a patent problem

Edited September 9, 2011 by gL33k

[Vixente 10]

i seriously don't like the new interpolation stuff. soldiers warp back every seconds even with 40+ fps server and low bandwith (on LAN).

it maybe has something to do with my personal basic.cfg settings, wich are :

MinBandwidth=320000;

MaxBandwidth=10000000;

MaxMsgSend=256;

MaxSizeGuaranteed=1024;

MaxSizeNonguaranteed=64;

MinErrorToSend=0.0049999999;

MaxCustomFileSize=1600000;

Try lowering MinErrorToSend more. I have my server at 0.001 and it runs pretty well.

http://community.bistudio.com/wiki/basic.cfg

[sickboy 13]

Try lowering MinErrorToSend more. I have my server at 0.001 and it runs pretty well.

http://community.bistudio.com/wiki/basic.cfg

AFAIK just means a lot more bandwidth used but not much effect, which could result in the opposite effect.

[OMAC 254]

From my perspective, this new bug should get very high priority:

Not every grass type blocks AI view - model issue

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

[maruk 80]

Thank you, this summary is very useful.

On the CIT, at least for me, it is quite difficult to notice what are newly introduced bugs and what not...

They are on the CIT and discussed with Dwarden / CIT crew.

All of them describe issues introduced in 1.60 beta, compared to 1.59.

[Morbid_DK 10]

From my perspective, this new bug should get very high priority:

Not every grass type blocks AI view - model issue

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

Yeah, I was running some CTI last night, and couldn't fathom why I got spotted and killed repeatedly some 500-700 meters out, no matter where I tried to hide, on manoeuvres I have previously done with success. This certainly could explain it.

[sickboy 13]

Thank you, this summary is very useful.

On the CIT, at least for me, it is quite difficult to notice what are newly introduced bugs and what not...

NP.

Generally there's communication between CIT crew and BIS, but agreed,

there was no way to easily extract which issues were introduced since the 1.60 betas.

As such I've introduced a "First affected ArmA II version" field, which contains the same versions list as the "Affected ArmA II version" field.

Most 1.60 beta introduced tickets have been updated to reflect the change.

The field is searchable and filterable.

Example of filtering, from: http://dev-heaven.net/projects/cis/issues

1. On the right side "Add Filter" field, select "First affected ArmA II version".
   
2. Then on the left side, set the First affected ArmA II version field "Please select..." to "1.60 Beta".
   
3. Click Apply
   

You can also save the filter or adjust it to further narrow or widen the search.

The "ArmA II Affected version" field instead tracks in which version the bug still occurs.

Edited September 10, 2011 by Sickboy

[f2k sel 164]

I like the update To CIT but how do I get back to the default after doing a filter.

If I press View all issues sometimes it restores the default sometimes it brings up another page. Sometimes using clear returns it to default layout.

Also Maybe a box to enter the actual Beta patch to help narrow down the problem still further.

[sickboy 13]

The Clear button resets the filters. Perhaps issue with browser/cache/cookie? Or perhaps Back/Forward navigation?

There is aready a field "First affected build", this can be used for the actual build number.

Yet this field by itself is inadequate for the requirements specified by Maruk.

Edited September 10, 2011 by Sickboy

[f2k sel 164]

The Clear button resets the filters. Perhaps issue with browser/cache/cookie? Or perhaps Back/Forward navigation?

There is aready a field "First affected build", this can be used for the actual build number.

Yet this field by itself is inadequate for the requirements specified by Maruk.

Same in all my browsers.

I can work around it by selecting due tickets and then view all.

Clear only works sometimes, it was the same on my previous PC.

Using View All does take it back to the issues layout but it's different.

Of course there is a field "First affected build" and I've been using it Cheers.

Edited September 10, 2011 by F2k Sel

[nobrainer 0]

[84388] New: New entry requiredBuild=xxxxx; in server.cfg preventing obsolete clients to connect. Not reliable until 1.60, clients are still able to connect.

How do you use this?

Can't find any info on the wiki about this.

Is it as easy as:

requiredBuild=1.59.84391;

Or is it more to it.

Do people have to have that "correct" version to connect?

[Dwarden 1125]

into server.cfg add this line

requiredBuild=84391;

it's just about the build number not full version number ...

to connect You then need to have same or higher build

Edited October 12, 2011 by Dwarden

[nobrainer 0]

ah, great!

Thanks!

Testing later I hope

Works like a charm.

Can connect and start a mission, but get kicked out after a while if build version is lower than recuired.

Nice feature!

BTW, I don't like how you have solved this, regarding messages:

console message:

11:50:20 Player xxxx: Signature check timed out

Server rpt:

No message at all

It's hard to find out what is missing for a client with no hint at all to why he / her get kicked out.

Is there a possibility to get a "readable" message for the reason?

Both in server.rpt and console message and preferrable in game.

Edited October 12, 2011 by NoBrainer