Topics

Behind the scenes: not only this is not the track I originally intended to make when I asked for the guest spot, it isn't even what it was supposed to be when I began working on it a couple days ago -- when I laid the first tile it was meant to be an USC-style "arena" track, but I never seem to get those right. In any case, it is a slow one. Hopefully not too slow 

This track looked interesting -- too bad I managed to race so little through the month that I couldn't even explore weirder dual-way lines... time to watch the replays, I guess

I rather like the flat and twisty "face" sector of the track. It had been a while since we last had anything like it. I probably should have one more go at it under GAR while there is still time...

Long straights, hard braking and an enjoyably peculiar layout...

I like valleys, and bridges that span them I'm going to try this out anytime soon -- no clue about cars, though.

(Catching up with the race topics...)

When it comes to tracks, "simple" does not imply "boring", or, for that matter, "easy". This race was a fine example of that.

Here is a top 4 analysis, which I originally intended to do several weeks ago. It shows how much of a difference Marco's (and, elsewhere on the scoreboard, Alan's) trick made, as well as how much FinRok's third sector stands out.

Edit: There was a silly mistake in the first version of this analysis -- I measured the second split at the foot of the hill, rather than at the exit of the banked turn, as shown in the map. I have adjusted the values -- the story being told remains largely the same.

Code Select Expand


Splits MAR FIN FRI DUP
0 0.00 0.00 0.00 0.00
1 25.70 28.55 28.20 28.35
2 47.80 50.60 50.55 51.50
3 64.55 66.70 68.10 69.55
4 90.05 91.95 93.75 95.40


Code Select Expand


Sectors MAR FIN FRI DUP
0 0.00 0.00 0.00 0.00
1 25.70 28.55 28.20 28.35
2 22.10 22.05 22.35 23.15
3 16.75 16.10 17.55 18.05
4 25.50 25.25 25.65 25.85


Code Select Expand


R. Gaps MAR FIN FRI DUP
0 0.00 0.00 0.00 0.00
1 0.00 -2.85 -2.50 -2.65
2 0.00 -2.80 -2.75 -3.70
3 0.00 -2.15 -3.55 -5.00
4 0.00 -1.90 -3.70 -5.35


A fried HD has just taken with it the preliminary results of some restunts-related investigations about the game engine that I had performed recently. This post is a brain dump of whatever I can remember from the findings, in case anyone else (possibly even myself, once my disgust over this data loss incident subsides) wants to follow the leads. I will use restunts terminology liberally and (as I am writing this from memory) inaccurately -- any field/subroutine names I mention might be wrong. If I get to recall things better, I will update this post accordingly.

Keep your backups up to date...

• (Preliminary note: "trackdata*" are the twenty-odd data blocks which hold all sorts of track related information used by the game engine.)
• trackdata01 isn't, unlike some restunts annotations (motivated by its 900-byte size) suggest, a copy of the track map. I don't remember right now exactly what each of the early trackdata did. What was clear is that each byte in them corresponds to an element, in driving order, with alternate dual-way paths coming after the "main"/straight path, from last to first (which IIRC matches the order the cursor moves along the paths when you press "C" on the track editor). One of the trackdata holds the index of the next element, with 0xFF being used for dead-end paths. Another one, if I'm not mistaken, holds the index of the start of alternate paths for dual-ways splits, being 0xFF otherwise. The indexing matches that of a well-documented later trackdata (was it 16?) which holds element codes, also in the same driving order.
• The 900-byte size of the early trackdatas, which is not actually related to the size of the grid, is the reason why very complex multi-way tracks (I think I posted one example of these in the Bliss thread) are subject to buggy behaviour, such as valid paths not being detected and crashes in attempts to race against the opponents. In effect, there is a maximum limit of 900 elements (possibly slightly below than that, as IIRC some dual-way elements are counted twice) to the sum of the lengths of all paths in the track. This limit is not enforced by the game.
• One of the early trackdatas (was it 03?) sometimes changes while driving. It sets the path taken by the opponen. More on that later.
• Speaking of the opponents, a large chunk of the opponent AI is neatly contained in a branch of one of the opponent-named methods. It can be located by tracking down where the "sped" data (the maximum speeds through the elements for the opponents) is used. That leads to a clear decision point on whether to brake or accelerate depending on the difference between the actual speed and the target one.
• The update_grip subroutine, which in relative terms is not very difficult to make sense of, does perform the calculations which, from steer, grip and speed, enact skidding and spinning. From it, it becomes possible to understand the angle variables in carstate (fields 20 -- steering wheel input -- 36 and 40, and possibly some others). IIRC there is one with the direction change from steering, and another with the additional delta from spinning. Limit speeds for each behaviour and speed loss from skidding are also possible to figure out.
• A large part of the lost results were related to update_player_state, the subroutine which updates the car position according to the car state and its location on the track. While my 2010 investigation of it had stopped at the build_track_object call (which is responsible for materialising track elements), this time I had gone through and made sense of nearly the whole thing... Here are a few random findings:
  
  • One test which is particularly easy to identify is the one which checks whether all wheels are on water. While the location of that test was already known, it is worth pointing out that it leads to a crash-related function, where the branches correspond to all kinds of crash events, as well as (IIRC) the lap conclusion event.
  • After the build_track_object call, there is a thick jungle of code which is used to figure out interactions (including potential crashes) with track surfaces, walls and miscellaneous objects. There are lots of interesting things to be mined from there. One highlight are angle and speed limits for crashes. For instance, hitting a wall will never lead to a crash below 30mph, and always will above 100mph. In between those speeds, it depends on the angle between car and wall. The limit pitch angle for crashes against the ground (the one which was probably raised between Stunts 1.0 and 1.1) is also plain to see somewhere near the end of the branch dealing with car-surface interactions.
  • While there is a minimum speed for wall crashes (30mph), no such limit applies to trackside objects such as pillars and trees. Opponent cars are handled a bit differently, depending on speed and angle, contact with another car may merely push you away. This sort of collision is handled by a subroutine called somewhere near the end of update_player_state.
  • There is some confusion in the 2010 annotations to update_player_state with regards to the signs of the angles used in the rotation matrices. That confusion can be cleared away by realising some of the angles are in world coordinates, while others use the car reference frame (and thus have opposite signs). IIRC there examples of each of the coordinate systems being used in the carstate angles.
• There is one subroutine (bto_auxiliary, IIRC) called from build_track_object whose role is setting up miscellaneous non-wall trackside objects (such as tree trunks, start/finish pillars, etc.) for collision detection purposes. Wall gliding tricks are possible because there are no such objects for most bridge elements (one execption is the base of u/d corks), and so if you run into a wall while running parallel to the track direction on the edge of the road you simply won't find anything to crash with.
• Still on track side objects: they are defined by four values: width, height, length and a cutoff radius for collision detetcion. The values for trees, pillars, etc. are hardcoded somewhere in the data section of the executable. The "dimensions for car-car collisions" specified in CAR*.RES that the Wiki talks about also use this format.
• (The following has been struck out, as later investigations proved it to be completely wrong.) There is one special kind of "ghost" trackside object that you can't crash against, though collisions has other side effects. They are placed in seemingly arbitrary positions in tiles specified by one of the trackdatas (was it 10?). The whole thing is weird enough that it stands out while reading update_car_state. My theory (almost, but not quite, confirmed) is that these ghost objects are used as invisible checkpoints that, if hit, change the path chosen by the opponent. They are set in pseudo-random positions in a reproducible way, which would explain why, even though the opponents can take different paths in different races, they always follow a consistent path when the same lap is replayed. (By the way, I consider that the coolest and most elegant trick I have seen so far in the code.)
• The rc* values in carstate are used for fine adjustment of wheel position (though two of them are actually unused). One of them is related to the suspension travel vertical displacement you can see when looking from the side at a falling car. Another one adds extra vertical displacement to the wheels of a mid-air cair. This displacement is unequal between front and rear wheels, in a way that makes flying cars rotate downwards and eventually begin falling (changing these values can be used to manipulate flight time).
• Speaking of displacements, there is one place (at some early point of either update_speed or in update_car_state -- I don't remember exactly) where the overall displacement of the car is multiplied by a constant factor. Changing it can be used to e.g. set up a turbo mode, in which the car moves twice as fast than what the speedometer says, and the grip limits are adjusted in the appropriate proportions.
• Another trackdata (was it 09?) holds the positions of the cameras in the F4 view. There is a fair bit of interesting camera-related stuff which is not too difficult to track down, including a whole subroutine which adjusts the positions of the external cameras accodring to the car position and track location (one way to find it is looking where the weird "camera offset" data referenced from the track object data structures is used). There is also some camera-related data in gamestate and IIRC also in carstate (in particular, if I'm not mistaken one of the unknown vectors in gamestate is the position of the F2 camera).
• Quite a few branches of update_car_state are skipped if a certain "input mode" flag is not in its usual, waiting-for-driving-input, state (that is e.g. what makes it impossible to crash after crossing the finish line). If you track down the places in which this flage is not in its usual state, one nice thing that will be revealed is how the car is rolled out of the truck -- that is, the mechanics of accelerating it a little bit and then slowing down so that it stops at the right place.

[Competition site]

Every competition should have a place in the forum, so here is a thread for Cas' holiday OWOOT competition.

Competition site: http://dimioca.com/r4k http://www.raceforkicks.com
Driving rules: Strict OWOOT (IRC-like, speed-gathering bumps allowed, tunnel roof driving forbidden.)
Replay handling: RH is allowed; if you feel like driving NoRH you can mark your replays as such.

Do check it out -- a neat first track for Melange awaits you.

EDIT BY CAS: Website address updated!

Driving in a city track with Skyline makes me think of Gran Turismo 

I like tracks such as this one which start rather slow and get progressively faster as you drive along them.

Trickless for the most part, yet quite demanding -- and outright hard under GAR...

These days to Renato's magic I can only reply with guile. Guile can win, but only rarely. The middle cut in this race is a good illustration of that 

Right now I feel like doing a top 3 + FinRok animation for this race. The only problem is that Stunts Cartography seems to be misbehaving in my system for some reason... (Cartography is fine, the "misbehaviour" was just me forgetting a few steps when using the relevant build toolchain )

A very nice track, I'd say, with many passages which are hard to get right without being annoying.

Acura makes the track a PG speedway, which takes away some of the elegance of the original Z78. Nonetheless, parts of the puzzle remain interesting...

This was a really nice NSX track, but it wasn't to be. On the bright side, in spite of the not so small gaps the top 3 Vette lines were different enough that an analysis wouldn't be uninteresting.

The map seems to suggest a nice mid-speed Corvette ride. Thoughts?

An intriguing question about the interaction of OWOOT rules and invisible corners has been raised at the ZakStunts shoutbox. Given that there is no real precedent (tracks with mixed rules were, up to now, uncommon, and OWOOT-only illusion tracks even more so), I feel a straw poll and discussion thread might be useful. Some facts about invisible corners:

• You get an illusion corner by placing the main tile of a corner on an inner angled slope. While you can do so with small corners of any orientation, for large corners only south-to-east and north-to-west turns work -- with other orientations you get either a quasi-normal corner or further bizarre terrain glitches.
• The invisibility happens because the game gets confused with the illegal element-terrain superimposition and draws the track at zero height, rather than atop the hill. That makes the corner invisible from inside the car. The pavement can be seen from above, albeit at the wrong height.
• The corner behaves normally as far as physics go; that is, the part that counts as paved is the same one you'd get from a regular corner atop the hill, with the usual grass slowdown outside it.

My two cents: I think the rules shouldn't be applied in the invisible corner tiles. Having to follow something which you can't see is not very fun, specially in NoRH. Furthermore, even verification with the F3 camera can't be done properly in-game due to the height differences. I feel that any line should be allowed as long as you are OWOOT both when exiting the tile before the invisible corners and when returning to the track at the entrance of the tile after them -- which already restricts lines quite a bit in relation to what you'd get with shortcuts. 

It is nice that the track turned out suitable to both 911 Turbo and NoRH -- the former was somewhat expected; the latter, a pleasant surprise.

Pre-season testing has begun! A few random comments:

• I really hope Renault's black-with-a-dab-of-yellow livery gets changed before Australia, or else it and the black-with-a-dab-of-red McLaren will look very silly next to each other.
• Also, fingers crossed for Manor actually closing the gap to the lower midfield!
• The new "musical chairs" qualifying format sounds bizarrely complicated, but it might be fun.