BZ2 1.3.6.4z15 - Open beta & testing

[Wolfen]

I haven't seen that white scout yet juggs, don't forget that we were also playing vsr. Game seems very stable with this patch, but restricting movement is something you have to be careful with because we all get used to the maneuvering in say an MPI, then it can get harder, say to hit archers, or bombers, etc if you can't maneuver to shoot them down. I have not seen anyone complain about an opponent out maneuvering them, instead they learn to do the moves as well so I am finding it difficult to understand the restrictions in that area. Other than the known bugs on this patch the game works great, much appreciated.

IDK what you are talking about with maneuverability, that hasn't been touched in ages. Perhaps a side effect of something else?

No I'm talking about limiting the physics of the game.

[Zero Angel]

Hover unit physics has been a touchy and fiercely argued subject all throughout the 1.3 patch dev cycle (started 10 or so years ago) and arguments/debates about it have never went anywhere. It's understood that the current hover unit physics will remain in effect and so is generally impolite to bring up.

[GSH]

On an unrelated note, which file does BZ2 prioritise in the event of an asset clash?

It's random per system, though usually the same between launches of BZ2 if the filesystem hasn't changed. Basically, BZ2 uses the default Windows function to find all file(s) and directories. I don't recall whether the first or last file Windows hands back "wins" (i.e. is used by BZ2), and it doesn't really matter. (It'll never be any file in the middle; it's either first or last.) It's a bad problem that BZ2 1.3 will open a dialog at startup saying "these files clash, fix it NOW."

It's all up to that paragon of stability and good judgment, Microsoft Windows, as to the order. /sarcasm. BZ2 should be 100% consistent in what it does given a specific ordering. Technically, I could burn a lot of time to take the results of that Windows function, parse it to a separate list, order it alphabetically (which should guarantee a mostly stable ordering, though that gets into edge cases with unicode), then have BZ2 use the sorted list. Or, I could just do what I already do -- prompt the user that dupes are bad.

And for a .cfg file that is now clashing due to the expanded UI sets, I'd say the best solution is to rename it so it doesn't clash. It's not a problem that'll go away when 1.3.6.5 comes out and the expanded UI goes into the .pak. Mods don't own the UI. Never have. Never will. And now there are 5 variants of all stock UI files, so mods will need to be updated to match -- if your version isn't expanded 5 ways, end users might not be loading the version they expect. I made it safe (by having unique filenames per file) to give end-users running pre-1.3.6.4 the 5 expanded UI files; they just won't be used.

-- GSH

[Red Devil]

just checked and G66 doesn't use any varbs with the name of i1.

[Nielk1]

just checked and G66 doesn't use any varbs with the name of i1.

Note that your var names probably wouldn't show up in AVs unless you ship with the debug PDB. Though the release PDB might have it I don't think so.

[GSH]

ERR | animtypes:85 |23:58:11|1422392|i1 out of range: 192
ERR | log:1368 |23:58:11|1422418|abort() requested from '.\utility\animtypes.cpp':86

That's some more stringent checks added after Visual Studio 2013's code analysis pointed out some possible reading un[der]initialized memory, going off the end of arrays. Reading such memory could cause resyncs as the data's not guaranteed to be consistent. I added in guard code, which brought the hammer down rather than allow a read of that data.

-- GSH

[jaydenbz2]

I downloaded this patch to get a few problems:

Patch z13 was good, but z15 made the following graphical problems.

1. Lighting if behaving funny, the scion units look as if their specular highlights are blown 1000 times over, far too intense and no smooth transition at all.
2. Water transparency is blending as if it is behind objects, and in front of particles.
3. Scion morph causes scrambling vertexes EVERYWHERE..doesn't even remotely resemble the shape of the unit at all.

[Zero Angel]

Some feedback as to the networking code

Wanted to ask you, since youre an aussie. How are you finding the multiplayer to be in z13 (stability, playing experience, etc).

What do you like or not like about it?

Honestly I'm not sure if there's anything good about it.

I freeze in place for 5-10 seconds after every resynch, which includes people joining, leaveing, pilots dying, etc. During this time I can be killed by people and ai, it's happened multiple times already.

During games I teleport around the place and I've been getting something similar to those mini resynchs and not being able to fight or command properly because of it.

I was collecting feedback to provide to gsh about the netcode changes, but then he released z15 which sends extra packets to try and lower the amount of bad effects that the z13 stuff caused for people with lossy connections.

That said, is it improved at all? Is it still a problem?

Tbh I don't know why he doesnt just revert it to z6 which was pretty good.

The weird lag synch things last about 5 seconds instead of 10 now, damage bug seems possibly worse but there's no way I can know for sure.

From a player in serbia. I never got his z15 updated feedback, so this is based on z13

I played some games, yes. maybe it's a bit worse than before. There is that huge lag on the begining, and one time my bz even froze when I entered a game
but player position was not so bad in the old version. As far is Im concerned, that rubber band is a good idea, but I'm not sure if that really works

[GSH]

As I've requested several times now, post actual data from the ingame scores panel, especially the lag column. It'll show more info as to what's going on than subjective impressions.

-- GSH

[Zero Angel]

How do I do that? Printscreen?

[Red Devil]

thinking that the histogram file would show detailed info, too.

KeepHistogramLogfile = true

[Zero Angel]

[4:01:40 PM] Zero Angel: played much z15?
[4:02:01 PM] Kebbz: did one stock strat
[4:02:10 PM] Zero Angel: I'm wondering if that improved things over z13
[4:02:20 PM] Zero Angel: I guess one strat is still too early to tell
[4:02:37 PM] Kebbz: yes, but I did not noticed any improvements
[4:02:44 PM] Kebbz: that huge lag was still pesent
[4:03:07 PM] Zero Angel: So it would seem that there's guaranteed starting game lag, right?
[4:03:12 PM] Zero Angel: like about 10 seconds or so worth?
[4:03:26 PM] Kebbz: yeah

Just posting this here for later. I'll see if I can get people to watch the ingame scores panel more and see if there's any early game extra latency or packet loss. In my experience testing with commando before, it seems that there's guaranteed starting game lag (even if im not dropping packets at the time) but it clears up after some time.

[GSH]

Feel is a third degree of separation from actual facts.

My advice: Test. Don't merely go for TheWin(tm).

And, if packet loss knocks out 5/5 packets holding a timestep's moves in a row, then you would have caused laggy play for everyone else pre-z13. Guaranteed. This change makes problem clients suffer for their own problems, rather than making everyone suffer for a problem client.

-- GSH

[Zero Angel]

Then why not assert the host's version of what's going on whenever a clean worldswap occurs?

I mean if everyone is already recieving whatever the host sees anyways. If the host sees a client who's dropping packets moving in one direction, when said client is moving in another direction (due to changing direction during the effect), then simply 'keep' what the host sees and reset the lossy client into whichever heading that the host thought they were going in when the clean worldswap does eventually happen. If it works how I think it works, then would that reduce the effect of a 'bad client' while still keeping the game running smoothly?

[Nielk1]

Then why not assert the host's version of what's going on whenever a clean worldswap occurs?

I mean if everyone is already recieving whatever the host sees anyways. If the host sees a client who's dropping packets moving in one direction, when said client is moving in another direction (due to changing direction during the effect), then simply 'keep' what the host sees and reset the lossy client into whichever heading that the host thought they were going in when the clean worldswap does eventually happen.

THAT'S WHAT IT DOES NOW...
That is what people are bitching about!