Hi,
I have no games installed, so the Launcher and the Viewer crash immediately.
It would be nice to inform the user that no game is found.

Tarcontar

ShaderGen is currently used for the Sprite shader.

We need to use it for all shaders, in order to output GLSL / MetalSL for cross-platform support.

You are most likely already aware of this, but I think it's a good idea to write it down regardless.

The tests use hard coded paths to game files, which makes it hard to run them portably. Most tests seem to use InstalledFilesTestData, but some other tests (such as the BigArchiveTests) use their own paths.

There are a couple of ways to solve this.

The easiest to implement solution would be to have a configuration file which a developer would enter the path[s] to the game installation folder[s].

From developer experience perspective an even better solution would be to automatically detect where the game is installed. (Much) further down the line, the same logic could be used for the game itself.

There are at least 3 different editions (original, The First Decade and Origin) of the game, which might require different approaches. I have the Origin copy, and having done some preliminary Windows registry searching and %appdata% grepping I couldn't find any non-machine specific references to the game installation path. There must be a way to do this, but I haven't found it yet. :)

Can only be done after removing xamarinmac20 from the multi-targeting csproj files.

Hi there tgjones, I didn't knew many ways to contect you so I tried my luck here, I wanted to ask if you would like to join some c&c sage room in discord, most of the C&C devs are there and I'm sure some take interest in your work and may want to help https://discord.gg/TfdcQTn

Cheers!

Oppsi, didn;t notice you already have discord xD

I have a question. I see that there is an active work on this game engine and I believe in the next 2 years you will be able to finish your work. In this regard: can I start the parallel work on preparing a remaster version?
The creation of 3d models and textures also takes some time, and considering the forthcoming amount of work (civil models and fractions models), I think that it will take as much time as work on the game engine.

The future system requirements are also interesting.
How much RAM do I need to count? Can I use high poly models (20000-40000), normal maps, specular maps?

P/s
Now I'm busy porting the generals to the C&C 3 engine, I've overcome many difficulties (even implemented the dozer), but thanks to your work, I can switch my attention to the remaster version.

I'm trying to build the DataViewer on Windows 10 and Visual Studio 2017, but it seems MSBuild picks the first SDK version it can find, in my case Windows 8.1 SDK, thus breaking the build.
When running the build process with MSBuild set to verbose, this is what happens:

5> C:\Program Files (x86)\Windows Kits\8.1\bin\x86\Fxc.exe /nologo /Emain /T vs_5_1 /Fo obj\Debug\Shaders\ParticleVS.cso Shaders\ParticleVS.hlsl
5> Unsupported shader model specified "vs_5_1"

I tried to look for a solution but it seems that Visual Studio, unlike with C++ projects, doesn't let us target a specific SDK version while using C#. I tried manually setting <TargetPlatformVersion> in the project file but it seems to be ignored.

The launcher executable will use netcoreapp2.0.

Remove multi-targeting - use single element in the csproj files.

We'll find out at this stage whether we have any dependencies that are incompatible with netstandard2.0.

Can't tell if its a rendering or reading issue

Could be issue with unconventional resolutions maybe? I do see some DDS textures rendering correctly but most are like this.
Tested on
OS: Windows 7 SP1
CPU: Intel i5 6500
GPU: Intel 530

This will require adding platform interfaces (IGraphicsDevice, ITexture, etc) to OpenSage.Game, and then changing the game code to use them.

Shadows are very important for the visual look of Generals.

Generals implemented them using shadow volumes, but we might implement them using shadow maps instead. TBD.

When viewing .tga files that make use of transparency i am getting artifacts at the edges;

In FinalBig the image is displayed correctly:

Likely depends on #104.

We need to construct a navmesh from the passability data stored in the map file, create paths for bridges and carve out areas where there are buildings and other map objects. The navmesh should be efficient to update with newly constructed and destroyed buildings. We then need to implement a pathfinding algorithm (probably A*) to query the navmesh.

I did a highly scientific experiment which suggests that units are not included in the nav mesh:

The tanks are in an another team than the officer in the middle, so they don't move to let him through. When I order the officer to move out of the square of tanks, he'll start moving but gives up when he reaches the point nearest to his goal.

If I try to move to a completely unreachable place (like this conveniently placed group of barracks) instead, the cursor turns to 🚫 when I hover over it, and the unit moves to the closest point it can.

(The cursor is different because my screenshot key combination includes CTRL)

Unit movement "plans" can be seen by holding down ALT. The same key is also used to give multiple move orders in a row. Using that + good old spam clicking resulted in the following image:

All unit positions are aligned to a grid, perhaps with a resolution of 1 game unit. This might or might not tell something about the navmesh.

Tracking issue for which campaign maps load and which don't. Loadability just means that the map doesn't crash the engine.

Generals

China

• CHI01
• CHI02
• CHI03
  • Crashes on load, because TerrainPatchIndexBufferCache tries to create an index buffer with the length of 0. The patch has the size of 1x17 and CalculateNumIndices(1, 17) returns 0.
• CHI04
• CHI05
• CHI06
• CHI07
• CHI08 (a cut, unfinished map)
• CHIfinal

GLA

• GLA01
• GLA02
• GLA04
• GLA05
• GLA06
• GLA07
• GLA08

USA

• USA01
• USA02
• USA03
• USA04
• USA05
• USA06
• USA07
• USA08

Misc

• Training01
• ShellMap1
• ShellMap1Low

Zero Hour

Debug maps

• AllBuildingsAllSidesUnitTest_Save
  • Uses the nonexistent model "Art\W3D\NONE.W3D", causing a crash.
• _Art Review New Units
• BUG_SavedGameandEnabledFolders

Once implemented, we should use it load the correct launcher image for the current locale.

This is a more long-term solution for #68.

Z-fighting with the terrain is prevalent with buildings with flat / low geometric features. Notable examples of buildings with these issues include GLA's command centre and USA's barracks and war factory.

The football stadium in USA02.map is especially bad; it has z-fighting at any realistic viewing distance and angle.

Hello.

I am just wondering if you guys plan on adding Emperor Battle for Dune game to this as well? I read up on W3D and Sage 1 and I seen that both actually used the same rendering techniques, plus that game could use a good remaster, too.

We should add some unit tests that test against more data files. The constraint here is that we can’t test against files/assets that are copyrighted by EA.
For those reasons we should maybe consider using own test assets as we do for the .map format.
I think a coverage of at least 80% is realistic by adding more file format parsing tests and running the launcher & viewer against some test installation.

Self-explanatory title. I couldn't build the graphics DLL on Windows 10 without removing xamarinmac20 from <TargetFrameworks> in the .csproj. Do I need to install the Xamarin SDK or do something else to fix this properly? 🤔

I'm the running the latest VS Enterprise with all recent .NET targeting packs installed.

Farewell Metal, we barely knew you...

I believe (based on imports in the Mac version of ZH) that ZL5 is decompressed with zlib uncompress.

Ideally we'll use ShaderGen to automatically generate shader code for all backends from C# shader classes. Need to push some PRs to ShaderGen to make that happen.

It will be in the Git history if we ever want to bring it back.

I was debugging a map script error in the shell map, when I encountered the following script:

*** IF ***
    Counter 'Reset Camera' IS Equal To  1 
*** THEN ***
  Enable Script 'Follow Circle to see battlefield'.

'Reset Camera' is a timer, not a counter. A bit of googling led me to the World Builder manual for BFME, which states:

Timers always count down from the start time you set. A timer can be used as a counter,
too. You can perform all of the operations on a timer that you can perform on a counter.

I experienced problems in the linux version of OpenSAGE regarding the OpenAL-CS library.

Unhandled Exception: System.DllNotFoundException: Unable to load shared library 'soft_oal' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libsoft_oal: cannot open shared object file: No such file or directory
at OpenAL.ALC10.alcOpenDevice(String devicename)
at OpenSage.Audio.AudioSystem..ctor(Game game) in /home/patrick/Workspace/OpenSAGE/src/OpenSage.Game/Audio/AudioSystem.cs:line 41
at OpenSage.Game..ctor(IGameDefinition definition, FileSystem fileSystem, GamePanel panel) in /home/patrick/Workspace/OpenSAGE/src/OpenSage.Game/Game.cs:line 204
at OpenSage.GameFactory.CreateGame(GameInstallation installation, FileSystem fileSystem, GamePanel panel) in /home/patrick/Workspace/OpenSAGE/src/OpenSage.Game/GameFactory.cs:line 34
at OpenSage.Viewer.UI.MainForm.ChangeInstallation(GameInstallation installation) in /home/patrick/Workspace/OpenSAGE/src/OpenSage.Viewer/UI/MainForm.cs:line 272
at OpenSage.Viewer.UI.MainForm..ctor(GameWindow gameWindow, ImGuiRenderer imGuiRenderer) in /home/patrick/Workspace/OpenSAGE/src/OpenSage.Viewer/UI/MainForm.cs:line 45
at OpenSage.Viewer.Program.Main(String[] args) in /home/patrick/Workspace/OpenSAGE/src/OpenSage.Viewer/Program.cs:line 51

When trying to build the project, OpenZH.DataViewer.Windows doesn't compile because of a shader compilation error.

SpritePS.hlsl and SpriteVS.hlsl include a file called Sprite.hlsli, which is not present in the current master. It seems to have been removed (or renamed to Particle.hlsli) in the commit d94eda7.

In IniParser.cs, ScanFloat uses Convert.ToSingle without specifying InvariantCulture. This can be fixed by using ParseUtility.ParseFloat() instead.

Issues like this are likely to appear again, since they are easy to make and hard to spot. They could be prevented with a couple different ways:

• Run the test suite with a few different thread cultures, either a fixed set or even a random selection.
  • Not sure if there's an established way of doing this with Xunit.
  • If it's done with the entire test suite, it would essentially at least double the execution time.
  • Only catches the code covered with tests.
  • From what I've gathered, the test suite is not currently being run in CI, so this would rely on contributors running the tests manually after each and every change.
• Write a Roslyn analyzer which forbids (and possibly quick-fixes) the use of float.Parse, Convert.ToSingle and other functions which require a culture parameter to work portably.
  • Unless one exists already, requires a bit more engineering.
  • Only catches a specific set of issues, although they are the most likely ones to occur.

I could look into contributing either solution later in December, if you think it'd be useful.

This needs to be resolved until we can start writing game logic in any meaningful capacity.

There are a lot of options:

• Use floats/doubles and SIMD, and hope for the best.
• Use decimal. Pretty slow and takes 128 bits.
• Use a custom number struct, like the fixed-point implementation in this Stack Overflow answer.

The Vulkan backend isn't working because ShaderGen is producing some incompatible shader code. This is an issue on Linux in particular because Veldrid is using Vulkan as a default backend there when it's available. For now this can be fixed by using the OpenGL renderer in this case.

This is a topic that will be very important when we start implementing actual gameplay.

Once the fundamentals have been implemented OpenSAGE will face a bit of a dilemma: how do you play and test it? The campaigns and the skirmish mode will require at least some form of AI, and the multiplayer will obviously require networking. Neither is easy to implement, but my guess is that focusing on multiplayer will lead to fun & engaging gameplay sooner ( - if that is the goal).

Furthermore, a lot of games tend to implement single player as a special case of multiplayer, where a singleplayer match is actually just a local server with one player. This avoids code duplication, and ensures both modes work in the same way.

There are at least two popular ways implementing RTS multiplayer:

1. Peer-to-peer lockstep
   • This is the classic approach, used by the vast majority of classic RTS games (including all(?) SAGE games). Every client has a complete copy of the game state, and every client has a connection to every other client. Game logic runs at a fixed rate (10-20hz) on all clients, and player actions are broadcasted to other clients. Clients compute a hash of their game state and compare it regularly to other clients.
   • If the game logic is 100% deterministic, this model uses very little bandwidth and CPU time.
     • Reaching determinism might require using fixed-point / integer numbers for all game logic calculations, keeping all collections in a fixed order and syncing RNG seeds.
   • If it's not, the game has to either re-sync all clients or just kick everyone out (like Generals sometimes does).
   • The game speed is bottlenecked by the player with the slowest connection; if there's an 8-player match where 7 players have 20ms ping between each other and one player has 800ms ping to one other player, everyone has an input latency of at least 800 milliseconds,
   • Might require port forwarding or NAT hole punching for every player.
   • Every client has all the state, so "maphacks" and other cheats are unpreventable.
   • Players have to know each other's IPs, so DDOS attacks are possible.
   • StarCraft 2 uses a variant of this, where all traffic is routed through a central server. The server is only a proxy and doesn't run any game logic. This solves the port forwarding and DDOS problems, and allows for things like replay recording and leaderboards.
2. Authoritative client-server
   • Used by most non-RTS games and some modern RTS games such as Planetary Annihilation and Grey Goo. There's a single server which everyone connects to, and the game logic is only run on the server. Clients send actions to the server and update the state with changes from the server. State is synchronised to clients on a need-to-know basis. The server is either one of the clients, or an actual dedicated server.
   • Small performance overhead for individual clients, but higher requirements for the server.
   • Port forwarding is only required for the server.
   • Replication happens at a lower level, so in the worst case this requires order(s) of magnitude more bandwidth than lockstep. Not necessarily an issue on modern broadband, and since this is a custom engine we can do some clever byte-level optimizations to minimize the bandwidth required.

Articles:

Don’t use Lockstep in RTS games

1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond

Fixed-point math in C#, part 1

Lockstep Implementation in Unity3D

Synchronous RTS Engines and a Tale of Desyncs

The Tech of Planetary Annihilation: ChronoCam

This will require some trickery to get the embedded 3D view in the Viewer working.

As part of this change, we'll remove the windowing and input code from OpenSage.LowLevel.

We'll probably need to use SDL_CreateColorCursor. This doesn't support animated cursors so we'll have to revisit that at a later date.

Hey guys,

I'm messing around with the Amazon Bistro scene that's free to use from Nvidia. The textures are all DDS files, and the loader that OpenSAGE has seems to work quite well. Is there any interest in separating out the DDS loader into a standalone library / nuget package? At the moment, I am compiling a forked copy of the code, which pulls in quite a few helper classes and types. The Bistro scene uses BC5 pixel format (or "ATI2" in DDS parlance), which I've added to Veldrid 4.4.0 and to my forked version of the DDS loader. I will make a pull request with those fixes back to the repository here (assuming you guys are okay with updating to 4.4.0 once it's stable), but it would be great (at least long-term) to have just a single version of the code here.

Thoughts?

e.g in Lone Eagle, you can only see one supply depot, one sewage pipe, one copy of each tree and building and so on.

Will investigate later.

Switch from Direct2D to SixLabors.ImageSharp.Drawing for drawing text.

At the time of writing the game loop is very simple: Game.Tick() is called as often as possible. Game.Tick() polls for input, processes incoming messages from the network message buffer, updates game systems and renders the frame. This has been fine for now, but it doesn't match how SAGE works.

As far as I know, SAGE works kinda like this:

• The scripting system updates at 30 FPS.
• Other game systems also update at 30 FPS.
• The game normally renders at ~30 FPS (GeForce Experience reports the framerate in the shell map as 32 fps)
• Network messages and (possibly) player input are processed at 15 FPS
  • Could we poll input more often to reduce input lag without breaking compatibility?

If I had to guess I'd say the original implementation runs a single game loop at 30 FPS, updates network messages and input every other frame and then does everything else, including rendering.

There are some special cases, some of which we need to support and some which we might want to support:

• When the pause menu is open, all units freeze, particles stop animating and vertex animations (tree sway) stop. At least in Generals, animated textures (rivers) continue animating, although this could be more of an oversight rather than a decision. The UI system operates normally.
• The "freeze time" scripting action works very similarly to the pause menu. The script which starts the pause should probably continue executing, so that the game doesn't get stuck. This requires further research.
• In single player skirmish Generals has a game speed slider, which goes from 15 to 60 + unlimited (shown as two minus signs) and defaults to 30. This affects both gameplay systems and rendering. At unlimited the game runs as fast as it can (on my computer about 700 FPS in a small 1v1 map).
  • On my computer with game speed set to 60 the game renders at 67 FPS, which is probably unintentional.

Personally I would love to see rendering supported at arbitrary framerates. This is probably the biggest enhancement we can do to for the original games, since AFAIK every single SAGE game is locked to 30 FPS. In the age of powerful enough hardware and enthusiasts having 120-240hz screens, it doesn't make sense to stick to 30.

It seems that the new msbuild target doesn't create the output directory.

I fixed it by adding a call to Directory.CreateDirectory(outputFolder) in CompileShader.

gbmtgametest.w3d and orcpile.w3d crashes at
modelloader.cs
if (w3dHierarchy.Pivots.Length > ModelMesh.MaxBones) {
throw new NotSupportedException();
}

sauroneyecine.w3d crashes in private static FixedFunctionMaterial.TextureMappingType ToTextureMappingType(this W3dVertexMappingType value), value was StepLinearOffset

This is probably going to be updated is i poke around the files more.

I think a this project should go linux also
it seems like a switch to OpenGL should be mostly enough

Also known as the only map ever to use DEFLATE compression.

Crashes on load, because MapFile.ParseMapData contains the following line:

context.PushAsset(nameof(MapFile), reader.BaseStream.Length);

.. and DeflateStream doesn't support the Length property.

[External Code]		Annotated Frame
OpenSage.LowLevel.dll!OpenSage.LowLevel.Graphics3D.Buffer.PlatformSetData(byte[] data, int dataSizeInBytes) Line 101	C#	Symbols loaded.
OpenSage.LowLevel.dll!OpenSage.LowLevel.Graphics3D.Buffer<OpenSage.Graphics.ParticleSystems.ParticleVertex>.SetData(OpenSage.Graphics.ParticleSystems.ParticleVertex[] data) Line 89	C#	Symbols loaded.
OpenSage.Game.dll!OpenSage.Graphics.ParticleSystems.ParticleSystem.UpdateVertexBuffer() Line 457	C#	Symbols loaded.
OpenSage.Game.dll!OpenSage.Graphics.ParticleSystems.ParticleSystem.Update(OpenSage.GameTime gameTime) Line 239	C#	Symbols loaded.
OpenSage.Game.dll!OpenSage.Graphics.ParticleSystems.ParticleSystemSystem.Update(OpenSage.GameTime gameTime) Line 28	C#	Symbols loaded.
OpenSage.Game.dll!OpenSage.Game.Update(OpenSage.GameTime gameTime) Line 270	C#	Symbols loaded.
OpenSage.Game.dll!OpenSage.Game.Tick() Line 261	C#	Symbols loaded.
OpenSage.Game.dll!OpenSage.GameView.OnGraphicsDraw(System.EventArgs args) Line 19	C#	Symbols loaded.
OpenSage.LowLevel.dll!OpenSage.LowLevel.HostView.Draw() Line 50	C#	Symbols loaded.
OpenSage.LowLevel.dll!OpenSage.LowLevel.HostView.OnPaint(System.Windows.Forms.PaintEventArgs e) Line 36	C#	Symbols loaded.
[External Code]		Annotated Frame
OpenSage.DataViewer.Windows.exe!OpenSage.DataViewer.Program.Main(string[] args) Line 27	C#	Symbols loaded.

Repro: Load a map in the data viewer, and change into another map as soon as it loads. Usually takes 2-3 switches.

I don't know the renderer and/or SharpDX very well, but it seems that this is caused by the ParticleSystem trying to update a vertex buffer that has already been disposed. Presumably this only affects levels that contain particle systems.

Hey

I was wondering, hopefully not too early, ofcourse no conclusion has to be done at this time and this could stay open to future suggestions from other people.

I personally would have it only in launcher, also avoids the restart issues, not having to bother the user with dialog, and not having to implement a restart too, change options and run cleanly imo makes it simpler and less prone to weird circumstances.

Secondary if in launcher, would it be global, or per-game, so you would have tabs.

Unless some of you guys are big on max authenticity of the original, I understand.

Has there been any talk or thought about such a system, to make it more easily manageable?

For example, the original engine would parse INI's case sensetive, if you created a command button reference on the control bar with "Airf_AmericaVehicle..." instead of "AirF_AmericaVehicle..." it would work but as soon as the user would hover the mouse over the button the game engine would freeze.

Or such thing would be put directly to the implementation? I just think it makes it more clear if it's put in a specific structre in the code, so you have it more or less in one place.

By re-interpretation I mean, that what you put into INI's is interpreted differently than by the original engine, but in a way that you can do more weird things in the INIs but it would still work, maybe better name for this is "parse robustness", maybe this could be done in the INI parser, I'm just wondering, if this would be nice for other things, not just INIs, more of a vague idea.

At the time of writing, OpenSAGE only runs on Windows. There's also some code for macOS support.

In order to support Linux we need to do at least the following things:

• Handle window creation
  • With fullscreen support
• Handle mouse and keyboard input
• Implement an OpenGL or Vulkan renderer
  • Preferably OpenGL, since it also runs on macOS and on older GPUs.
• Make sure OpenSAGE builds and runs on Mono or CoreCLR
• Implement an IInstallationLocator that doesn't use the Windows registry
  • This could be done with a config file or a command line argument.
• Embed the game view into Eto.Forms for the data viewer
• Make sure OpenSAGE works on a case-sensitive file system

These will also benefit the macOS port.

Feel free to comment with your ideas, recommendations and war stories.

This is what the test looks like:

[GameFact(SageGame.CncGeneralsZeroHour)]
public void ReadFirstEntryStream()
{
    using (var bigStream = File.OpenRead(_bigFilePath))
    using (var bigArchive = new BigArchive(bigStream))
    {
        var firstEntry = bigArchive.Entries[0];

        using (var firstEntryStream = firstEntry.Open())
        {
            Assert.Equal(9334, firstEntryStream.Length);

            var buffer = new byte[firstEntryStream.Length];
            var readBytes = firstEntryStream.Read(buffer, 0, 10000);
            Assert.Equal(9334, readBytes);
        }
    }
}

It throws an ArgumentException on the line containing firstEntryStream.Read, because it's trying to read (up to) 10000 bytes into a buffer with the length of 9334. This matches the documented behavior.

I dont't think this could ever pass. 😄

After fixing #22 CHI07.map still crashes the map loader, because waypoint path INTROConveyMove doesn't exist. I looked at the map loader and apparently OpenSAGE uses the name of the first node as the name of the waypoint path:

foreach (var waypointPath in mapFile.WaypointsList.WaypointPaths)
{
    var start = result.Settings.Waypoints[waypointPath.StartWaypointID];
    var end = result.Settings.Waypoints[waypointPath.EndWaypointID];

    result.Settings.WaypointPaths[start.Name] = new Settings.WaypointPath(
        start, end);
}

WorldBuilder and the scripting system seem to identify paths by their waypoint path label. You can configure up to 3 labels per path, and any of them is a valid identifier for the path.

From what I've gathered, these are not currently parsed.

Hello

Noticed your attempt to improve GenZH, however while you said you have similar but different goals, I don't see anywhere what those specifically are. I was following Thyme for most of this year, but I can't really do anythign as I don't have deep C++ knowledge, the creator of Thyme recently said it's 1-2% done, I don't know if he meant total progress or just his deep C++ work, that to me sounds like slow progress considering this is going for 6 months now, if it takes too long I am afraid the community that is left might lose interest and dry up in the next 4 years, especially some of the younger (exceptions) ones that might be enjoying GenZH, I don't think it's just superhardcore old cats still playing every day.

I don't play much simply because I'm way too demanding user, I'm a technical geek and I just can't stand laggyness and mismatches.

So my goal is to fix the hard bugs that are limiting modding as well as AI bugs that are present without modding and may or may not be able to be fixed by just INI modding, fixing the underhood of AI scripts to make sure it's optimized, and then moving off DX8 and jumping ahead to Vulkan.

Personally I don't mind much about multiplatform however I agree others probably do want it eventually, so it would be Win7, Win10 and MAC and maybe 2 most common linux distros, if MAC can't have Vulkan that's their problem, so one less thing to deal with. Plus Win7/Win10 don't need separate compilation anyway.

Thyme is focusing on MAC support that's the primary reason of using OGL 3.2 or something, I'm simply not a fan of supporting old stuff nor have any interest in MAC, and I don't want to deal with an old API when there is a new shiny high-performance one out now, I want to see hundreds/thousands of units and all the effects/particles in Generals Zero Hour WITHOUT LAG at 60FPS at 1440p. And playing against 8 AIs and huge bases all without LAG.

Infact if something like this would be started, I'd focus on Win-64 build anyway cause there's really no need for multiplatform when I can put a 50Euro HDD into any PC an install the necessary OS to play, similarly to how I use Win10 on another HDD just to play DCSWorld smoothly (not working good on Win7 for me) It's just a non issue.

Hi,
Excellent work on this OpenSage port, any possibility to release the Graphics LLGfx and the game framework as separated libraries?

Probably some user will benefit of it.
Thanks

If someone can't help with new lines of code, is there any financial way to help?

LoadObjects in MapLoader.cs should do a bounds check before calling GetHeight. If the object is outside of height map boundaries, it should use a different height.

I don't know what that height should be. I encountered this in CHI07.map, where two jets were placed outside boundaries so that they can fly in in a cinematic. Maybe PreferredHeight for things that have a locomotor, and 0 for others?