Battlezone Forums

Cinco de Mayo (depending on your time zone...) 8)

This is the first build on the push to a Release Candidate, and I'll be doing things a bit differently from here on out.

First up, I've added a new Testing build. The Testing build is fully optimized but includes debugging features that should help track down some lingering problems. It prints debugging output visible in a debugger like Visual C++, pops up warning messages when expected conditions aren't met (usually before something bad happens), and catches divide-by-zero or invalid floating-point operation rather than let them slide and corrupt the game state. The Release build is still available, but I ask that everyone try out the Testing for a while. Unfortunately, the new game executable check means it isn't compatible with the Release build in multiplayer games. (I may need to disable that test temporarily...)

Second, I've renamed the "Program Database" links "Debug Symbols" since that's what they are. While they're still optional, I ask that everyone get them since reporting call stacks helps me fix problems faster.

Third, I've replaced the "Changes" sections with a "What's New" section. It only includes changes relevant to players and I've tried to write it in a friendlier, easier-to-read form. The normal change log is still included with the executable if anyone cares.

I think these changes are for the better, and I wish I had made them sooner...


Downloads:

Testing Executable and Debug Symbols
Release Executable and Debug Symbols


What's new:

* Fixed missing smoke on damaged vehicles after loading from a save game

* Fixed a bad calculation after a unit took damage from its own weapon and attempted to flee from itself
- This would corrupt the unit's game state and might have trigger the blank-screen problem

* Made UnitTask smarter about using charge weapons based on suggestions from DarkVim:
- Start charging immediately upon entering combat
- Start or continue charging even when out of range or unable to hit
- Choose the "best" charge level based on damage rate and ammo efficiency

* TurretTank can use special weapons if so equipped
- This is of interest only to modders since the stock Turets lack special hardpoints

* FollowTask only engages in attacks of opportunity when following normally
- It breaks off when it needs to catch up with its follow target
- This restores 1.4 behavior when it gets too far away

* Player will respawn while in the net game escape screen...
- ...but only in strategy games, where it's a known exploit
- Letting players take a break in DM games should be fine

* Raised the scrap drop limit for Craft and Bulding to up to +2 above scrap cost
- Odd scrapCost: allow up to scrapCost+1 (1->2, 3->4, etc.)
- Even scrapCost: allow up to scrapCost+2 (2->4, 4->6, etc.)

* Fixed a crash in multiplayer with sniper off when a weapon was missing

* Mission asset check includes the game executable as a security precaution
- Unfortunately, this makes Testing and Release builds incompatible

* Replaced game input key codes with virtual keys
- This should have no player-visible effect, but please report any key input problems

* In-game chat text input now works more like the shell
- Get character input from Windows instead of working it out on its own
- This should fix input problems on non-US keyboards
- Allow key repeat like a Windows edit control
- Get multiple events per frame for better response at low frame rates

* Restored 1.4-style UnitProcess "defend" behavior during repair/reload
- Units circle around the building until given another command
- NOTE: Scavengers and Tugs still use the "go near and sit" behavior

Release candidate... I like the sound of that.

So do I.

Trinity wrote:Release candidate... I like the sound of that.

This.

I tested the "Release Executable and Debug Symbols"
and I crash every time I start a mission

> bzone.exe!read_gamekey_table() Line 1433 + 0x8 bytes C
bzone.exe!FirstInputs() Line 1676 C
bzone.exe!WinMain(HINSTANCE__ * hInstance=, HINSTANCE__ * hPrevInstance=, char * lpszCmdParam=, int nCmdShow=) Line 1303 C
bzone.exe!__tmainCRTStartup() Line 578 + 0x1d bytes C
kernel32.dll!76873677()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
ntdll.dll!77c99f02()
ntdll.dll!77c99ed5()
bzone.exe!MineLayerFriend::`scalar deleting destructor'() + 0x8 bytes C++

I was concerned that something like this might happen, which is why I asked people to check for key input problems. I don't like committing changes that I can't easily test but this was a case where I didn't have much choice. I'll apply a fix tonight when I get home, but until then try using aUS English input mapping as a workaround.

Here's some background for what went wrong:

Some surprisingly-common character values have different virtual key codes in different input layouts: semicolon/colon, plus, comma, minus, period, slash/question mark, backquote/tilde, square/curly bracket, backslash/vertical bar, and quote/double quote are assigned "OEM" key values and may not always have the same value. The previous input system used a hard-coded alternate mapping for German key layouts, but this approach was not scalable. Those keys would simply not work in "unsupported" layouts.

To compensate for this, I added code to read_gamekey_table() that builds a "reverse lookup table" mapping character codes to virtual key codes using an OS call (MapVirtualKey). The problem is that while it behaves itself in US English, the call can return return values far outside the range I expect in some input mappings and write to invalid memory. That's the crash you're seeing. The fix, of course, is to skip any code that falls outside the range of legal values.