Battlezone Forums

I always hit 'enter' while holding down the 'w' key to type/communicate while moving. A quick double-tap of 'Esc' clears the cruise control/autopilot.

Just press 'W' again, no need to take your hand away from 'WASD'.

Oh right. Old habits die hard.

Red Spot wrote:Just press 'W' again, no need to take your hand away from 'WASD'.

This.

Crash.
Generally it occurs when blows up whose or the ship. And at this moment I have few hp, and I have chance to blow up too
http://pastebin.com/ywbLa1ZD

found this on that dll crash; unsure if it is the culprit, on-board intel graphics may be kicking in. check in bios to make sure that it is not using on-board graphics?

http://forums.2k.com/showthread.php?151 ... he-desktop

Crash.
Generally it occurs when blows up whose or the ship. And at this moment I have few hp, and I have chance to blow up too
http://pastebin.com/ywbLa1ZD

That crash is deep in the DirectX drivers for your GPU (graphics processing unit). While BZ2 might be providing bad data to the graphics card, it is also likely that you have outdated drivers for your Intel GPU. Microsoft has previously written up that this is likely the case: http://answers.microsoft.com/en-us/wind ... 7791373606

If you provide either the output of dxdiag.exe, we can help figure out what Intel GPU you're running, and point you to the latest drivers download site.

-- GSH

Tracked Vehicle still have Problems with drive near Gun towers and Extractors,especially scavengers that try to collecting scrap, units stuck inside Gun towers and have huge problems to get free.


Maybe its possible to integrate improved Teamcolors from UEP to the next patch? ( http://prntscr.com/2ps65i )

And builders still freeze after upgrading a harvester.

Tracked Vehicle still have Problems with drive near Gun towers and Extractors,especially scavengers that try to collecting scrap, units stuck inside Gun towers and have huge problems to get free.

Sorry, BZ2's collision code stinks, as it had to run on a Pentium (original) with MMX, 166Mhz. And 64MB RAM. Fixing it is not on the table; the bugs you complain about date back to 1.0 and are not an easy fix at all. 1.3.6.* is focused on MP.

-- GSH

When i put turret to attack target it should wait for target to get in range instead of moving near target (which takes a lot of time!).

When i put turret to attack target it should wait for target to get in range instead of moving near target (which takes a lot of time!).

This is a gameplay change feature request, not a bug. If you keep this up, I'm going to split them out of this topic, and tell you to go make your own mod (Recycler Variant) and stop demanding the game work the way you want. And, the counterpoint to this issue is this: from the turret's point of view, how can it prove that the target will get in range? Can the turret prove that the target's current orders will make it eventually in range? What happens when the target's current orders change? If it just waits forever for the target to get in range, people will think it's broken.

-- GSH

Protrector wrote:When i put turret to attack target it should wait for target to get in range instead of moving near target (which takes a lot of time!).

Thats right this is Nasty, and Turrets will attack scavangers if they are in range first and dont stop attack them till its destroyed, even if they are under attack. Turrets should defend theireselfes if its not told otherwise,stop attacking the scavanger and attack attacking target if possible. So its dont needed to tell them to hold (4) to do that.

Telling a turret to hold, while it is attacking a unit causes it to switch to the next available target if there is one within range. Its always been like that, changing it would not be a good idea.

That select F7 issue is a bzgame_keys problem.
You need to add the following items:
// Teammate selection
Bind("-shift -ctrl F7", "control.team.toggle4");

// Teammate send units
Bind("-shift +ctrl F7", "control.team.moveto4");

The file is now in Addon/Config/Game

The reason this issue is reappearing is that z19 adds a new bzgame_keys that is used instead of the
newkeys version that fixes this.

Those lines are in the bzgame_keys.cfg that I hand out in the z19 patch file - lines 46 & 52. Perhaps newkeys is missing it instead?

-- GSH