BZ2 1.3.6.4z28 - Open beta & testing

[GSH]

Download this and unpack over your existing 1.3.6.4 install's exe. This is a quick patch that re-enables construction rig upgrades and other tweaks

If you can, please install and test this. I think that this build is about 99.9% of what I want to put into a 1.3.6.5 release. Your best chance of having bugs fixed for 1.3.6.5 is to report things on the 1.3.6.4 series. Logfiles -- battlezone.log and chatlog (if enabled) -- are useful. Otherwise, reporting things in a way that makes them happen here is best.

See the changelog for the fuller descriptions of what's changed. Since 1.3.6.4n:

- Construction rigs can upgrade once again
- Much work to make griefers less able to annoy people
- Anyone can now ban anyone at any time - if you're a client in a game, you can ban a host or another client. Anyone you've banned who's hosting a game won't show up on the list of servers. Anyone you've previously banned who is a client in a game you joined is now warned about
- CUT the 1.2-style physics craft variants. The 1.3 patch series does not encourage that monoculture of overpowered scouts. Learn to explore the tech tree.
- Tweaked session registration and browsing to hopefully work around antivirus with overactive web shields better
- Chroming of objects is now SSE-powered for greater performance
- Tracked vehicle physics ought to be more solid. BZ2's collision code is still garbage, though
- On players leaving in a teamplay game, their units are redistributed to remaining players to avoid orphanage
- Upscaled shell fonts to look less klunky at large resolutions - note that this will require mods with custom extra options pages to also be upscaled
- Ingame UI can be upscaled by a preference - see graphics options, page 2, bottom right
- Input smoothing option from Ken, also pathing system tweaks and particle render from him.
- MP escape screen chat should scroll better
- Fix for input getting stuck at edges of range
- Crash logs aren't overwritten next boot, up to 10 crash logfiles and 5 regular logfiles are kept
- Smoother timeskew code, and servers will now time out delayed moves for clients to keep the game smoother.
- More work run in background thread while waiting for vsync for smoother
- More retransmits of player packets for more lossy connections
- A few graphical glitches fixed
- Various optimizations to help slower systems. If your framerate is already > 60, probably not noticeable

-- GSH

[Commando]

Ill give this a try when i get home. Internet here is crap. Now that this is available to the public, it has a chance of getting tested. Za and gbd helped me test z27, even though it was a short game.

[ScrapPool]

Hey thought I'd pop this in and give it a try.

After a few minutes of play, particles seem massively more resource intensive. I'm on a decent laptop that has pulled 600 some fps previously, and now I'm choking pretty majorly (down into 20-30fps from 110) when firing an AT-Stabber at 1280x1024.

Interestingly, it's only when particles are "near the screen": every time a stabber comes out of my tank in first person, there is a stutter/slow down. As soon as the projectile gets a few meters away, back to normal. This does not happen in third person/chase view, I'm hangin out at a relatively steady 100 ish out there.

EDIT: I I'm able to produce this effect just by picking any scrap pool and driving towards it. The closer my screen is, the lower the fps, until I'm sitting on it and am chugging along at 15fps.

Taking particles to "low" pretty well fixes the problem. But I like pretty things! /whine

Let me know if specs are helpful.

[vlad_C0M]

I noticed too , more "hard" HOT work in laptop. Less fps.
Game log

I use [MSI Afterburner] FOR LESS productivities of video of the card that the laptop was less heated.
and so, to productivity became less. And temperature become high from 63 Celsius to 68...

(edited)
Who on the contrary had an increase in productivity, at a low temperature?!
-
PS: It doesn't mean that improvements need to be done. There is a strong wish for significant splash in productivity.
Code improvement, and elimination of all graphic leaks!

[GSH]

You want your CPU/GPU to run cooler? Turn vsync on. Because if I make the code run faster by eliminating stalls, it'll make your CPU/GPU work harder. And the laws of thermodynamics state that the more work that's done, the more waste heat that's generated. Doing less work is the way to run cooler.

Provide savegames if you think some code path is running slower, along with precisely which build(s) things regressed on -- none of this vague handwaving that is useless. You can't see frames past your monitor's refresh rate, and I really doubt you have a monitor capable of 120+Hz.

-- GSH

[Red Devil]

tried looking at a pool using particles on high and only noticed a 200 fps drop from 600 to 400, which i think is to be expected.

[ScrapPool]

Just to clarify: Overall performance is definitely better. Something about particles is just unusually taxing all of a sudden.

While firing an AT-Stabber with high particles on 1.3.6.4n:
~110 (Recent ~50 .. ~250)

While firing it on 1.3.6.4z28:
~50 (Recent ~20 .. ~90)

It recovers very quickly, but there is a noticeable (and short) slow when the "stabber tail" is right in my face, making things lurch along awkwardly. A soon as I don't have particles right in my face, as in third person, things are fine. Something about Ken's particle render isn't playing nicely for me, I guess.

[Jabbapop]

hey gsh you're the superfly coderman with leet skills and i know ur busy spinning code with surgeon like precision but i was wondering MPI players are getting a bit bored lately the game is becoming a little stale. we know the ropes the tropes the whens and wheres of the ai's movements so it's become nothing more than a time sync. on behalf of the community i was wondering if the next patch could introduce a little bit of variety in this regard? pepper up the experience so to speak? how, you may ask? well i've got a few suggestions. maybe randomize certain ai paths; an easy way could be to integrate more community maps in the next patch? i know ur busy and all and i appreciate we all appreciate the areas you're focusing now so this is just a super minor forget-me-not suggestion. thank you and have a fine lovely spring day.

(Dang I wish i had some macdonalds french fries right now.)

[General BlackDragon]

The next VSR Map pack release will feature MPI on all of it's ST maps.

[Jabbapop]

The next VSR Map pack release will feature MPI on all of it's ST maps.

Oh my goodness OH MY GOODNESS if that is true if you guys actually have the elbow grease and know how to pull that off you're gonna have gained A LOT OF CONVERTS!

[Zero Angel]

The feature is fully working already in the dev version and the AIPs for the extra races (Hadeans and IC) are done. We just have to do more testing/tweaking to make sure there is no bugs, particularly in the IC/Hadean AIPs which are not tested very thoroughly yet.

We will also be using a unified AIP system with one AIP file per race which will greatly simplify the process of AIP development for anyone who wants to write their own AI scripts.

[Red Devil]

sounds...familiar.

[Zero Angel]

Been getting a lot of reports of 'ZwWaitForSingleObject' AV's recently. This one was reported to me on z28+VSR right after players deployed their recyclers.

Code: Select all

DIAG|            iconsole:530  |20:13:40|266307 |[CONSOLE] Assets look good
DIAG|            iconsole:530  |20:13:40|266324 |[CONSOLE] -- Resynchronized Gamestate at tW=1
ERR |      WatchdogThread:343  |20:14:25|311828 |Main thread seems deadlocked! Callstack of main thread:
ERR |    ExceptionHandler:188  |20:14:26|311880 |7741F8D1 +0001F8D1 00000015 ntdll            (ntdll): : ZwWaitForSingleObject

ERR |    ExceptionHandler:188  |20:14:26|311880 |769E1194 +00011194 00000043 kernel32         (kernel32): : WaitForSingleObjectEx

ERR |    ExceptionHandler:188  |20:14:26|311932 |769E1148 +00011148 00000012 kernel32         (kernel32): : WaitForSingleObject

ERR |    ExceptionHandler:188  |20:14:26|312080 |013BC176 +0005C176 00000385 bzone            (bzone): : MissionHandler::State::RunState::Process

ERR |    ExceptionHandler:188  |20:14:26|312158 |013B985F +0005985F 0000001E bzone            (bzone): : MissionHandler::Process

ERR |    ExceptionHandler:188  |20:14:26|312176 |0158FC04 +0022FC04 00000064 bzone            (bzone): : Main::MessagePump

ERR |    ExceptionHandler:188  |20:14:26|312198 |013ABBA4 +0004BBA4 000004F9 bzone            (bzone): : HandledMain

ERR |    ExceptionHandler:188  |20:14:26|312198 |013AB84E +0004B84E 000001A3 bzone            (bzone): : HandledMain

ERR |    ExceptionHandler:188  |20:14:26|312243 |013A890D +0004890D 00000069 bzone            (bzone): : WinMain

ERR |    ExceptionHandler:188  |20:14:26|312243 |01530295 +001D0295 00000191 bzone            (bzone): : exp

ERR |    ExceptionHandler:188  |20:14:26|312243 |769E336A +0001336A 00000012 kernel32         (kernel32): : BaseThreadInitThunk

ERR |    ExceptionHandler:188  |20:14:26|312243 |77439F72 +00039F72 00000063 ntdll            (ntdll): : RtlInitializeExceptionChain

ERR |    ExceptionHandler:188  |20:14:26|312243 |77439F45 +00039F45 00000036 ntdll            (ntdll): : RtlInitializeExceptionChain

DIAG|      WatchdogThread:358  |20:14:26|312248 |Callstack of MWUpdateThread:
ERR |    ExceptionHandler:188  |20:14:26|312255 |7741F8D1 +0001F8D1 00000000                  (): : (func)

ERR |    ExceptionHandler:188  |20:14:26|312255 |769E1194 +FF5E1194 00000000                  (): : (func)

ERR |    ExceptionHandler:188  |20:14:26|312255 |769E1148 +FF5E1148 00000000                  (): : (func)

ERR |    ExceptionHandler:188  |20:14:26|312255 |62EE6FE2 +EBAE6FE2 00000000                  (): : (func)

ERR |    ExceptionHandler:188  |20:14:26|312256 |62EE7BCA +EBAE7BCA 00000000                  (): : (func)

ERR |    ExceptionHandler:188  |20:14:26|312256 |62EF6000 +EBAF6000 00000000                  (): : (func)

ERR |    ExceptionHandler:188  |20:14:26|312256 |665E8C27 +EF1E8C27 00000000                  (): : (func)

ERR |    ExceptionHandler:188  |20:14:26|312256 |665E8900 +EF1E8900 00000000                  (): : (func)

ERR |    ExceptionHandler:188  |20:14:26|312256 |665E8E82 +EF1E8E82 00000000                  (): : (func)

ERR |    ExceptionHandler:188  |20:14:26|312256 |665EF297 +EF1EF297 00000000                  (): : (func)

ERR |    ExceptionHandler:188  |20:14:26|312256 |665EFC5C +EF1EFC5C 00000000                  (): : (func)

ERR |    ExceptionHandler:188  |20:14:26|312256 |6662E3BC +EF22E3BC 00000000                  (): : (func)

ERR |    ExceptionHandler:188  |20:14:26|312256 |6662E346 +EF22E346 00000000                  (): : (func)

ERR |    ExceptionHandler:188  |20:14:26|312256 |66603365 +EF203365 00000000                  (): : (func)

ERR |    ExceptionHandler:188  |20:14:26|312256 |0156DDD1 +8A16DDD1 00000000                  (): : (func)

ERR |    ExceptionHandler:188  |20:14:26|312256 |0B8007A0 +944007A0 00000000                  (): : (func)

ERR |                 log:1370 |20:14:26|312280 |abort() requested from '.\utility\WatchdogThread.cpp':367
DIAG|                 log:1377 |20:14:26|312296 |End of line...

I'm wondering if this happens on stock bz2 as well.

sounds...familiar.

The only logical conclusion is that it's a stolen idea, because obviously nobody else would think to finally utilize virtual classes to fix the mess that is currently the AIP system.

[Red Devil]

Yes, of course it's a obviously my stolen idea...not.

It sounds like my idea, but using "virtual classes" to make a single-race AIP is not my idea; pretty sure that was Commando who came up with that idea. Well, not for single-race AIP's, but for stock AIP's.

My idea (first implemented in G66 about 5 years ago) was to eliminate the second race requirement in the G66 MPI DLL so I could make what I called, "Generic AIP's", so that the number of AIPs would not balloon when adding another race.

Then I added some new generic ODF names in the [Match] section and in the provideName# entries for buildings and craft ODF's, like was done in the [Plan#] entries in the stock AIP's.

That way, providing the generic ODF names existed for each race, only one AIP was needed for each race.

So, yes, it does sound familiar.

Also, with a lot of help from GSH, I added Lua calls to the G66 AIP's, which really helped with checking the path points, etc.

But, as I've said before, if it weren't for GSH actually adding a bunch of Commando's and my feature requests in the past and some I didn't even think of - like some Lua functionality - we wouldn't have been able to do much of anything.

So, yeah, sorry it's such a mess. I reckon you have GSH to blame for that, right?

[Zero Angel]

I wouldnt know about that. Havent played G66 since you took it over. Heard you've been running it into the ground pretty hard where strat players who previously thought G66 to be fun and challenging are now turned off by all the extra RD crap being added to it, but I digress.

Using generic targets is a natural answer to the problem of ballooning AIP counts as more races are added and in fact even for ISDF/Scion would cut the AIP count in half, even if no other attempt was made to amalgamate the AIPs, (mind the current system with the multiple AIPs, e.g., s,0,1,2,3,a,l does have its advantages), even though the triggers for anti-seige AIPs (in stock) can still be silly.

I reckon you have GSH to blame for that, right?

Don't know where you get that idea. I simply stated that stock AIPs are messy and unnecessarily tedious to write for. Has always been that way, even before 1.3. Assigning blame would be pointless.