Hmm. Maybe I wont, or at least not in a hurry.
After going through the H10/Berkshire file I have most of the points nailed down for function. However, when I got to the end I noticed my tally was slightly off. Instead of the 827 points the file claims it had, I had totalled up 822. So, five point discrepancy. Awesome.
There is currently good news and bad news. The good news is that the five point discrepancy appears to be fairly early in the file. I simply missed recording five points somewhere. That means that a lot of the stuff I have recorded is accurate
if I simply take the point numbering and add five to it. IOW, I have the vast majority of the points fully documented, and they can easily be found in both the points declarations and the triangle declarations.
The bad news is that there are a few which are really nasty to track down, and of course they are useful ones that people are likely to want to change. One such point is the right rear bottom corner of the cab. There are actually two points there, sitting on top of each other. One is grouped with the rest of the cab points and is mapped. The other is hiding somewhere in the hex. Where? Dunno yet.
What this means is that if you want to move the cab around it's easy....................................except for that one corner, which will mess you right up. At this stage I was fairly sure that traps like this had been built in on purpose. There just didn't appear to be any other explanation for the way some of the points and triangles are arranged.
OTOH, I had only tried the one file, so perhaps this was just an odd one. I figured it may be worth checking some of the other loco bodies. I looked around a bit, and the simplest steam loco bodies are the Mallard (371 points) and the Class A1 (392 points), followed by the Duke (492 points). Any of these would be a lot less work to map than the 827 points in the H10/Berkshire file. So I opened up the Class A1 file and starting juggling points around.
It turns out that even though it is a lot simpler than the H10 file, the Class A1 file still has points ordered all over the place. It would be possible to doucment it all, and it would be about half the work required to document the H10, but at the moment I really cannot be bothered. After putting in quite a bit of time over the last few days, I am now sure that building locos from scratch is going to be faster, easier, and infinitely more enjoyable than trying to reverse engineer the crud that PopTop inflicted on us.
Even if I do move something around it would still have the image mapping of the original, which means blurry gfx close up and smokeboxes that look like they are built out of bricks. I'm kinda over all that. It's not worth trying to fix it for the old locos, IMO. I'm going back to building a new Garratt.
If anyone wants to take a look at the stuff for the H10, just ask.
==================================
Anyway, regarding building new Garratts
and making things easy to find in the code, I thought about the idea of set markers that I mentioned in the
Australian steam locos thread.
What is wanted for set markers in the points declarations is something that gives an easily recognised/searchable block of code, but doesn't give daft coordinates since the game engine will have to map them in real time. Check the screenshot:
- Set_markers_hex.png (16.98 KiB) Viewed 9311 times
The example file starts with the standard file header up to INST, then the declarations for number of points and triangles (just make those whatever works). After that is the proposed set marker, highlighted in blue. This is simply another point, with coordinates chosen to be very close to zero for x,y and z axes. IOW, it will sit in the middle of the loco at track height. This can be repeated as many times as necessary, since there is no prohibition on different points being at the same location in space. Each use of it will have to be tallied in the total count of points, but that's no problem.
The result will be a clear marker at the end of every group of points. All the boiler stuff can be grouped together, with END.SET.NEW. after it. The cab stuff (or whatever) can then follow, and would obviously have END.SET.NEW. at the end of it too. There probably wouldn't be more than ten marker points in any file. This should make finding bunches of stuff to juggle a lot easier, and should have no ill effects during gameplay.
After that, highlighted in grey and red, is an example for a marker to be used in the triangle mapping. The row highlighted in grey would just be the relevant point numbers, as usual for triangles. These wont be a problem. The first three rows of the stuff in red define the normal vectors for each point, and can just be set to pointing straight up for all points (which is what the 00 00 0080 3F at the end of each line means).
The next two rows define the mapping to the image, and for a 512x512 image mark out a triangle from top left (0,0) to top right (512,0) then right and one pixel down from the top (512,1). IOW, all that would be needed would be to leave a one pixel high transparent strip across the top of the image (or 2px in the case of a 1024x1024). Since the marker points will map to that area, you wont see anything in the game. The block of code should be easy to search for, since it's highly unlikely that any other part of the file apart from markers will use that exact sequence.
This means that is should be possible to find stuff without going bonkers.