"HAS HEIGHT" --- Bug?

[Mraah]

Erik,

I came across a possible bug regarding the "Has Height" attribute of an object added to a map when it comes to the AI understanding it's existance.

The AI appears to move unit's to a location that coincides with the TERRAIN MESH's X, Y, and Z coordinates. If the AI moves (or selects?) a location that contains a seperate object that contains the "Has Height" attribute then it will move the unit inside of the object ... basically it ignores the new "Y" coordinate of the object and literally has the power to move inside it.

The result is that it "may" lock up the game during the "AI PLANNING" or the "RESOVLING TURN" phase. I say "may" because I'm not too sure if it happens in both phases or just in one of those phases. For example, I saw a tank move inside an object during the phase and it disappeared, next AI Planning phase it locked the game up. Other times it will just lock the game up.

Humans don't have a problem moving units "on top" of the objects because the rubberband will move "up" as you move it over the object ... hence it understands the new Y coordinate and moves the unit to the proper Y value.

Anyway, it's not a show stopper since map design will (or may) generate bugs if we (me) mess with new ideas.

I just thought you guys might want to know about it ... if it really is a bug or not, I dunno.

Rob

EDIT NOTE : The only way to work around this (for map designers) is to actually work around it ... ie surround the object with impassable terrain. This is the only known problem that I've had with the "Has Height" attribute.

[Mobius]

I'm glad you caught this. I was thinking this just cut the LOS. It actually has control of movement and position. In a new map I set telephone poles to Has Height. And I set them on Wall colored spots. I sent a tank to run over the pole.

It climbed straight to the top of the pole then came back to the ground past the pole at a 45 degree ange.[:D]

[Mraah]

ORIGINAL: Mobius
It climbed straight to the top of the pole then came back to the ground past the pole at a 45 degree ange.[:D]

[:D][:D][:D] It's pretty cool if you surround the pole with tank obstacle, then only your infantry can climb the pole ... but, now it appears the AI has a problem with their troops getting stuck at the bottom.

For now, I'm not going to play with HasHeight since it needs to be "impassable" and there's no point in using it since impassable terrain takes into consideration of height anyway from the model height (so it seems).

[Mraah]

Everyone ... (pasted from Rick's thread in the mods section) ...

Ok, I have a theory about HASHEIGHT and why bridges don't cause problems while walls would. As an example, open the KHARKOV_L1B map in scene editor ... note the bridge is called L1B_terrainBRIDGE ... and, note the two previous children also contain the term "terrain" in name. My theory is that the object name has to contain the term "terrain" for this to work (ie, AI movement and hull down) ... also note, the NodeID is 1 (may not be a factor).

So, before we play with hasheight anymore I want to try some more tests and see if this is true.

Rob

[Mraah]

To follow this up (from my tests) .... the name or ID doesn't matter ... hull down still debatable.

However, regarding units getting stuck ... Vehicles more prone to get stuck (locks up game), Infantry have no problem with objects being "hasheight".

Anyway ... it's a user created bug.

Rob

[rickier65]

Rob,

I've been trying to check this out with different units. I used a part of the existing Piepsk map (shown below.

I've tried the following units, with both human and AI ordering:

Russian: BA10, Russian Truck, T34-76, Infantry

German: SdK 250, SdK 222, Pz 38t, Infantry, Opel Blitz

Wall was stone wall, (stonewall.x or stonewall03.x), buried nominally .3 into ground. I say nominally because the wal was made of multiple segments, and I made slight adjustment to bury depth to so that joins matched. The terrain color initially was set to impassible, but for this series of tests, I set the terrain type to "wall" 200, 50, 0. I confirmed with LOS tool that this was the terrain type seen.

Results were not entirely consistent, but in no case did the game hang-up.

1st test with Russian units contolled by AI inside of "pocket". I had German object set out side of pocket as shown. Also had German snipers in two positions in woods to observe (set to hol all fire).

While running this I set German units in town near a another stone wall location.

For Russian AI - In almost all cases, the BA-10 and Russain trucks set a path back out of pocket to opening then back toward the object. The Infantry and Tanks set a path directly over the wall to the objective. I had one instance where the BA10 went over the wall, but not sure if that was due to being placed too close to wall at start.

In the same run I controlled the units in town. In some test runs I was able to order all units over the wall, but in some tests, the Sdk and the Opel Blitz would apth around the wall, but not always.

I reversted the test, using russian snipers to observe the wall pocket, and setting a Soviet objective outside of pocket. with the German units all inside.

German AI routed infantry and Pz38t direct over wall, the Sdk 250, sdk 222, and opel all routed back around wall then on toward the object.

I then tried controlling German units in pocket. In this case though, I was unable to order paths any different than what the AI chose. ie, I would set unit objective and it would route the unit the same as the AI routed the AI controlled unit.

THe pocket was pretty crowded, and there was some traffic jams that sometimes took a couple of turns to sort out (but they did always get sorted - Good job on that KOIOS!

Observations:

1. Tracked tanks were always able to go over wall

2. Infantry was always able to go over wall

3. wheeled, or semi-tracked vehicles were "sometimes" able to go over a wall, regardless of human or AI controlled.

4. Game didn't hang during any of the tests (I probably ran about a dozen different runs.

I'm confortable with the way the walls are working - thanks again. Time to get back to playing Mcensk recon2 and creating a template for Piepsk!

Thanks Mraah!

Rick

[Mraah]

Rick,

Ok ... very good testing ... I'm glad they worked.

The other walls I sent you with the ending ID 5,52,53 (beveled walls) were giving me problems ... Perhaps the additional polygons inside the walls were causing the glitch ... So stay away from those walls.

At any rate ... It's not a bug for vanilla Pck ... just a bug for modding.

Thank you,

Rob

[rickier65]

I've just used the straight walls. Just finished converting all of the Stone Wall impassable terrain to wall terrain. Going to start putting in art and air into the map template now.

Thanks!
Rick

[rickier65]

I've been spending quiet a lot of time with this. I've converted my walls to 1 meter high walls by about ,4 meter thick.

To get the corners to match, I used vairous combinattions of pitch, together with very small adjustments to y value (this is because of uneven ground). I tested after each adjustment and ran through with no trouble.

After I had the walls adjusted. I had tested about 3 times with no trouble. Then I went in and changed the HasHeight to true for the 4 walls in and around the pocket. The next test failed by hanging up during the simulate turn phase.

I had to use Task Manager to kill the PcK process. I checked the log and below is the first part of the log. The rest of the log repeats the last few line over and over.

I appears to be looking for an invalid x.z coordinate.

I'm going to remove the HasHeight value and recheck.

A strange part of this is that I had done this with 2.4 meter high walls about 1 meter thick, with HasHeigth set to true. Same units and orders. and test quite a few times with no problem.

In any event, here is the log file:

Rick

11/3/2008 12:08:20 AM: Assembly Name: Lib, Version=1.0.1.37727, Culture=neutral, PublicKeyToken=null
11/3/2008 12:08:20 AM: DeviceIdentifier: d7b71ee2-1921-11cf-a769-4d40a1c2cb35
WhqlLevel: 0
Revision: 0
SubSystemId: 1615270011
DeviceId: 23137
VendorId: 4098
DriverVersion: 6.14.10.6764
DeviceName: \\.\DISPLAY1
Description: ATI RADEON XPRESS 200 Series
DriverName: ati2dvag.dll

11/3/2008 12:08:20 AM: Manager Adapter value: 0
11/3/2008 12:08:20 AM: Create device.

11/3/2008 12:08:20 AM: HardwareVertexProcessing
11/3/2008 12:08:20 AM: MultiSampleQuality: 0
PresentationInterval: Immediate
FullScreenRefreshRateInHz: 0
PresentFlag: None
AutoDepthStencilFormat: D16
EnableAutoDepthStencil: True
Windowed: True
DeviceWindowHandle: 0
DeviceWindow:
SwapEffect: Discard
MultiSample: None
BackBufferCount: 1
BackBufferFormat: X8R8G8B8
BackBufferHeight: 477
BackBufferWidth: 696
ForceNoMultiThreadedFlag: False

11/3/2008 12:08:20 AM: Create Flags: HardwareVertexProcessing
11/3/2008 12:08:20 AM: Device Type: Hardware
11/3/2008 12:08:20 AM: Begin Device Resize:
11/3/2008 12:08:20 AM: Device Reset
11/3/2008 12:08:20 AM: Begin Device Resize:
11/3/2008 12:08:20 AM: Begin Device Resize:
11/3/2008 12:08:20 AM: Device Reset
11/3/2008 12:08:20 AM: Begin Device Resize:
11/3/2008 12:08:20 AM: Begin Device Resize:
11/3/2008 12:08:20 AM: Device Reset
11/3/2008 12:08:20 AM: Begin Device Resize:
11/3/2008 12:11:22 AM: ******************** New Game *******************
11/3/2008 12:11:22 AM: Current Directory: C:\Matrix Games\Panzer Command Kharkov
11/3/2008 12:11:22 AM: OS Version: Microsoft Windows NT 5.1.2600.0
11/3/2008 12:11:22 AM: CodeBase: file:///C:/Matrix Games/Panzer Command Kharkov/PCKharkov.exe
11/3/2008 12:11:22 AM: Assembly Name: PCKharkov, Version=1.0.1.37729, Culture=neutral, PublicKeyToken=null
11/3/2008 12:11:22 AM: Managed DirectX:
11/3/2008 12:11:22 AM: Microsoft.DirectX, Version=1.0.2902.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
11/3/2008 12:11:22 AM: Microsoft.DirectX.Direct3DX, Version=1.0.2906.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
11/3/2008 12:11:22 AM: Microsoft.DirectX.DirectInput, Version=1.0.2902.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
11/3/2008 12:11:28 AM: Loading Guns...
11/3/2008 12:11:29 AM: Loading Armoured Units...
11/3/2008 12:11:29 AM: Loading Infantry...
11/3/2008 12:11:29 AM: Loading Scenarios...
11/3/2008 12:11:29 AM: Loading Campaigns...
11/3/2008 12:11:29 AM: Loading Tables...
11/3/2008 12:11:30 AM: Assembly Name: Lib, Version=1.0.1.37727, Culture=neutral, PublicKeyToken=null
11/3/2008 12:11:30 AM: Graphics format: R5G6B5
11/3/2008 12:11:30 AM: DeviceIdentifier: d7b71ee2-1921-11cf-a769-4d40a1c2cb35
WhqlLevel: 0
Revision: 0
SubSystemId: 1615270011
DeviceId: 23137
VendorId: 4098
DriverVersion: 6.14.10.6764
DeviceName: \\.\DISPLAY1
Description: ATI RADEON XPRESS 200 Series
DriverName: ati2dvag.dll

11/3/2008 12:11:30 AM: Manager Adapter value: 0
11/3/2008 12:11:30 AM: Create device.

11/3/2008 12:11:30 AM: HardwareVertexProcessing
11/3/2008 12:11:30 AM: MultiSampleQuality: 0
PresentationInterval: Immediate
FullScreenRefreshRateInHz: 60
PresentFlag: None
AutoDepthStencilFormat: D16
EnableAutoDepthStencil: True
Windowed: False
DeviceWindowHandle: 0
DeviceWindow:
SwapEffect: Discard
MultiSample: None
BackBufferCount: 1
BackBufferFormat: R5G6B5
BackBufferHeight: 768
BackBufferWidth: 1024
ForceNoMultiThreadedFlag: False

11/3/2008 12:11:30 AM: Create Flags: HardwareVertexProcessing
11/3/2008 12:11:30 AM: Device Type: Hardware
11/3/2008 12:11:45 AM: i18nstrings does not contain a value for key = 'testwallhasht.description'
11/3/2008 12:11:47 AM: i18nstrings does not contain a value for key = 'testwallhasht.description'
11/3/2008 12:11:50 AM: Unit Purchase - campaign:
11/3/2008 12:11:50 AM: Unit Purchase - scenario: testWallHasHt
11/3/2008 12:12:02 AM: Current Level: testWallHasHt
11/3/2008 12:12:27 AM: Can't find file with media id: _
11/3/2008 12:13:53 AM: Invalid bitmap location: (x,z) = (-2147483648,-2147483648)
11/3/2008 12:13:53 AM: System.IndexOutOfRangeException: Index was outside the bounds of the array.
at GameLib.Pathfinding.TopographicMap.GetTerrainAt(Int32 x, Int32 z)
11/3/2008 12:13:53 AM: Invalid bitmap terrain color: (x,z) = (-2147483648,-2147483648)
11/3/2008 12:13:53 AM: Invalid bitmap location: (x,z) = (-2147483648,-2147483648)
11/3/2008 12:13:53 AM: System.IndexOutOfRangeException: Index was outside the bounds of the array.
at GameLib.Pathfinding.TopographicMap.GetTerrainAt(Int32 x, Int32 z)
11/3/2008 12:13:53 AM: Invalid bitmap terrain color: (x,z) = (-2147483648,-2147483648)
11/3/2008 12:13:53 AM: Invalid bitmap location: (x,z) = (-2147483648,-2147483648)
11/3/2008 12:13:53 AM: System.IndexOutOfRangeException: Index was outside the bounds of the array.
at GameLib.Pathfinding.TopographicMap.GetTerrainAt(Int32 x, Int32 z)
11/3/2008 12:13:53 AM: Invalid bitmap terrain color: (x,z) = (-2147483648,-2147483648)
11/3/2008 12:13:53 AM: Invalid bitmap location: (x,z) = (-2147483648,-2147483648)
11/3/2008 12:13:53 AM: System.IndexOutOfRangeException: Index was outside the bounds of the array.
at GameLib.Pathfinding.TopographicMap.GetTerrainAt(Int32 x, Int32 z)

[rickier65]

I was able to duplicate this problem and solution consistently over 4 attempts at changing the HasHeight attribute.

Rick

[mbelew]

Ah, tank physics. My favorite. I think perhaps the issue here is that there is quite a bit of simulation stabilization going on, that the calculation is throwing a fit for extreme cases. Behind the scenes, movement is calculated every 500ms. I expect slightly odd things to happen when there are abrupt elevation changes in the case of even a small wall.

The hang up on the HasHeight flagged object sounds like a bug (could be the art or the code). The position returned to the engine is obviously invalid.

Invalid bitmap location: (x,z) = (-2147483648,-2147483648)

Yikes!

What happens in game if you try to place a vehicle or infantry on the wall?

Marshall

[rickier65]

ORIGINAL: mbelew

Ah, tank physics. My favorite. I think perhaps the issue here is that there is quite a bit of simulation stabilization going on, that the calculation is throwing a fit for extreme cases. Behind the scenes, movement is calculated every 500ms. I expect slightly odd things to happen when there are abrupt elevation changes in the case of even a small wall.

The hang up on the HasHeight flagged object sounds like a bug (could be the art or the code). The position returned to the engine is obviously invalid.

Invalid bitmap location: (x,z) = (-2147483648,-2147483648)

Yikes!

What happens in game if you try to place a vehicle or infantry on the wall?

Marshall

During the setup phase I set a tank on a wall (flagged as HasHt). Thne for first order phase I gave no porders. Tank fired sat on wall and fired as expected.

Next order phase I gave movement order to platoon. hung up in same place as before.

See pic below.

Thanks
Rick

[Mobius]

OK, I recognize that bug. There is a setup bug where it causes a CTD when you setup a tank on a foxhole or trench.

[Stridor]

I think that Marshall clued you all in to what the likely problem is.

The walls are vertical (and so are the lip edges of the foxholes). So it is possible that the tank physics engine is running into a div by zero error.

The men don't have any physics apart from simple Z changes so are not affected.

One way to test would be to remake the walls with a slight slant /--\ so that the gradient doesn't div by zero.