Tool: TrackEditor (Former Problem with WM_MouseWheel)

[Michael Hartlef]

Hi Eros,

I had allready movement of the camera doen and also saving to a text based file. :-[ But I overwrote it somehow. Just wanted to let you know that I will implement your suggestions.

[Petr Schreiber]

Hi Mike,

that is great news, thanks for your work!


Petr

[ErosOlmi]

Thank you mike !

[ISAWHIM]

Ok, I have not added anything into the editor yet, because I am still determining what elements will be needed to make the track edit a full track edit program. I am not talking about making it into a 3D object creator, but there are other elements, other than model-position and rotation, needed for editing the track.

So... Here is what I have come up with so far. (This assumes that we will use a path of some sort.)

The editor needs three sections.
- CITY EDIT (Lays city-blocks, based on style selected in TRACK EDIT.)
- TRACK EDIT (Lays track-blocks, and determines the STYLE for the track.)
- PATH EDIT (Creates "Valid" track-blocks, required for custom track-blocks.)

NOTE: Only custom track-blocks can have a path edited. Otherwise that would interfere with game-play. Paths will be a one-way creation without the original edit file. The game will only use the original paths for normal game-play. Any path can be used for a custom made game/track.

Track blocks have these elements.
- Block ID (Unique)
- Display Name (For user only)
- M15 Model File Name (For loading)
- Orientation Base (Starting natural orientation. XYZ of the M15)
- Value for city-block fill. (City-block is not added in track-edit mode, but a value/type needs to be here.)
- Point Data (Indicates IN/OUT and PATH, in and out can be swapped.)

Point Data contains these elements.
- IN (Starting natural order, counts as a "JOINT" for connecting other track blocks.)
- PATH (Interpolation points between IN and OUT, not used for positioning blocks, but relevant for track-edit mode.)
- OUT (Opposite point in natural order, counts as a "JOINT" for connecting other track blocks.)

The track-edit needs three objects before an actual track-edit can begin.
- STYLE (City type, places the "LANDMARK" dead center, and track/city is built around it.)
- START (Determined by the "STYLE" selected, and may be placed within 10-2-2=6 blocks of the "LANDMARK".)
- TRACK (A valid track component, which has a IN/PATH/OUT data.)

NOTE: The "City/Track", assumes a full city-border which will consume the outer ring of the 10x10 max-area. The "Landmark" does not have to be centered, but has to be within the city border, as the track does. These two limits, determines where a valid starting position may begin, as well as the start-IN and start-OUT location.

The track will be built in order, from (START - OUT) to (START - IN), only allowing track-blocks that are available to be connected, available for selection. The track can not be "ADDED" to the list of available tracks, until the track is complete. An incomplete track may be saved, just not loaded into the game for play. A track is "COMPLETE" when it connects to (START - IN). Natural order is, Start-Out to Track-In-Out to Track-Out-In to Start-In. Only the TRACK - IN and OUT may change by the orientation. The START - OUT will always be the EXIT to the track, while the START - IN will always be the ENTRANCE to the FINISH-LINE. Orientation of the START will be limited to rotation only, no swapping direction.

Track blocks that are not START, can be rotated or swapped. Rotate is limited to 90 degrees. Swapping can only be done LEFT to RIGHT and FORWARDS to BACKWARDS. Swapping will not change the order of the points, only the location which the points connect. IN will still be IN and OUT will still be OUT.

When a track-block connects to another track-block, it can only connect at the IN or OUT joint/point. This is where point-order and IN OUT will reverse-order or reverse-flow. Since the START-OUT is where the track is built from... The piece being added will stay the same order, if its IN is connected to the START-OUT. If swapped or rotated, you are attempting to place a TRACK-OUT onto a START-OUT, and the points/joints will be swapped.

Ok... You finish the track-edit, and now you can go to the city-edit.

In the city-edit, depending where you have laid the track, your limits are shown as available spaces. The border is also pre-filled with city-blocks that can be changed, but can't be removed. (This could be the city-wall, but I imagine that having city-blocks would help cover the horizon which would normally fall out of view.)

The city-block "Fill" blocks, will be available for any track-block that has a compatible value. There may be 3 types of fills available for the same track-block, but not all fills will fit over all track-blocks.

The odd part will be the "POINT - EDIT" mode.

We can edit any points in a path, because we will have the edit-file for that path. Users, if we allow it, will only have the ability to edit the paths on those same track-blocks, but only for the game they save, not the paths that the game uses. Any-who... (I'll explain that later.)

For the paths, this is what I was thinking...
Just like the track, you first setup the NATURAL - IN and OUT. Those are limited to the designated locations for the block-shape. (EG, on a single 100 x 100 square, they are at the half-way point on each side.)

You are limited to 9 interpolation points in addition to the IN and OUT joint for each block-size. (100 x 100 = 9 points), (100 x 200 = 18 points) (200 x 200 = 36 points)

You are limited to a maximum angle between points. (This limits creating "Z" and "L" 90+degree points. This also makes point-direction/flow possible to detect.)

You are limited to a minimum distance between points. (This limits creating impossible paths, and ultimately with the angle limit, stops useless points from being created which would potentially slow down the game.)

You are limited to a maximum distance between points. (This limits unusually long paths between points, and limits point-crowding on one path.)

You are limited to a maximum path-length. (This is the distance between the furthest points on any path from IN to OUT.)

You are limited to a maximum path-connect quantity. (This limits single points from being used to connect to multiple points that would kill AI decisions. No-one needs to think that hard at an intersection!)

All that being said...

Here is what you CAN do...

Drop nine points in the block-area. Connect paths from IN to POINT-A, POINT-B. Connect POINT-A to POINT-C. Connect POINT-B to POINT-D. Connect POINT-D and C to OUT. (That leaves five points unconnected. They go away, you are left with four points, and two paths. (IN - A - C - OUT) (IN - B - D - OUT).

When the AI hits IN, it can see A and B, and will select one way to go. (It might think about it, or it might just be random.) From B, it can see IN and D, but D is marked as "Forward", from "IN", by the point data for this segment. etc...

The point-editor will "look" at the created paths, and set-up the flow of each point as forward and backward, from IN and from OUT, so the points can be read in any direction, by reading the first-set of values, or the second-set for each point, depending on the way the track is entered. (Which is determined by the track-edit, and thus the importance of points and the track as one edit.)

This gives us the ability to make forks with up to three directions, and the ability to create a wide-open area with solid obstructions to avoid. (Trees, barrels, poles, fences.) Without having to use complex in-game processing, other than... Do I go left, right, or down the middle?

This should work nice in 3D, (Using height, not just XZ) to create places that AI and the camera would not normally handle without points. (Loops, high banked walls/turns, over/under paths, and backwards travel while still progressing forward on the track.)

Ok, now my head hurts... Time for me to figure-out how to move 3D things with the mouse, in 3D.

[kryton9]

Jason, now my head hurts... I am glad I am not in the code or design team. Lots of good thinking it seems to me from what I read while my head spun

[Michael Hartlef]

Hi Jason!

Ouch, that is quite a mind challenging idea. And complicated. As it seems that you need this for implementing the AI, I can easily say that I won't be able to write such a tool.

Half of the stuff you said I don't understand or is unlogic to me. Also I think that there is a lot of time needed to implement the features you want so I can easily say that I won't able to do this from the timeframe alone. Plus my knowledge.

I'm sorry that I can't help you anymore to build such a tool. Someone else has to do it.

I hope we have someone here who can do it.
Michael