Track Editor Module System

A little while ago, I decided to split the Chapman Track Creator project up into two projects.  One specifically for NR2003 called “Sandbox 2” and the other for the rest of the simulators called “Chapman Track Creator”.  Because of this split I have now decided to use this blog to post updates that concern both track editors.  And I’ve been working on making DLL files that both track editors need in order to work properly.  These DLL files will contain the necessary components for both track editors.  I will attempt to explain how this new system is going to work.

To start, one of the changes I have made to the scene objects is that they no longer have anything being derived from them.  Instead, they will have “components” attached to them that give them their functionality.  The old system was based off of how Roblox does it’s game objects.  The new system is based off of how the Unity and Unreal game engines do their game objects.

Under the old system, there would be a “Geometry” object that was derived from the “SceneObject” class.  Parented to the Geometry object would be several “Segment” objects also derived from the SceneObject class.  But in order to make the paths work correctly, there would need to be an “Arc” or “Spiral” object which would be derived from the “Path” class which would be derived from the SceneObject class.  So we have a minimum of three levels in our hierarchy just to get track geometry.  That’s in addition to the Geometry object being parented to a “TrackCourse” or “RaceTrack” object, which are themselves derived from SceneObject.  If Geometry was parented to a TrackCourse object, then that object would be parented to a RaceTrack object.

As I have recently discovered, this old method of deriving new objects from SceneObject was the hard way to do things.  The functionality of the entire SceneObject would be hard-coded into the objects derived from it with the complexity of integrating the functionalities together becoming more and more difficult.  By changing all those derived objects into components that are attached to a SceneObject instead of being derived from it, I gain a lot more flexibility in how these objects are combined.

For example:  Let’s say we want to have a wall that also defines the edge of a surface.  With the old method, we would create a WSection and FSection object.  For the FSection, the inheritance is “SceneObject->Section->FSection” and for the WSection, the inheritance is “SceneObject->Section->FSection->WSection”.  The WSection would essentially override all of the functionality of the FSection, which is why we would need two separate instances under the old system.

But under the new system, we only need to create one SceneObject and attach “Section”, “Surface” and “Wall” components to that object.  The effect is the same, but the code does not have to be implemented twice for the two objects.  And all three of the components mentioned derive directly from the “Component” class, making the inheritance hierarchy much simpler to maintain.

Now, let’s say that you don’t want that section to be both a surface edge and a wall, but rather a surface edge, and elevation profile.  Just remove the “Wall” component and add the “Elevation” component and you’re done!  Plus, since we can’t have elevation profiles in the same spots as walls, rather than checking to make sure our WSections and XSections don’t overlap, we just check to see if there’s a Wall component already in place.  We also won’t have to drag the XSection into the proper position for it to overlap with the FSection.

The SceneObject and Components will be in one DLL.  There are other DLLs that I’m making which both track editors will need:  One for the Scene Explorer, one for the Properties Window, and one for the Component Viewer.  The Component Viewer will simply be a list of components that a SceneObject has.  The Properties Window will only list the properties for the selected component of the selected SceneObject.  Tests of the Scene Explorer DLL have shown that the track editors will accept these modules as DLLs, but it also means that some of the code needs to be reworked to prevent potential conflicts between the DLLs and the track editors.

Now, because of how much trouble Visual Studio has given me with this project, there is a lot of code for the track editors scattered all over my hard drive which I need to get organized into the current, working project.  I also need to sort out which bits of code to keep and which to discard.  Also, I tried to take a shortcut with the event system which didn’t work.  Fortunately, I discovered that I simply went the wrong way with the shortcut, so reimplementing the event system didn’t take very long.  The real hold-up with the new system is how to keep the menu items and other resources from conflicting with each other.  Although I might be overthinking that one too.