Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Duplode

Pages: [1] 2 3 ... 7
Stunts Forum & Portal / Competition Archive 2018
« on: November 12, 2018, 04:42:35 AM »
After months of procrastination and computer woes, I can finally announce that there will be a 2018 update to the Competition Archive. The plans are for it to be ready before the new year. Here are the competitions the update should cover (please do tell me if I forgot anything!):

  • ZakStunts (2016-2018)
  • ZakStunts GAR (2016-2018)
  • ZakStunts NoRH (2016)
  • R4I (2016)
  • R4K (2016-2018)
  • LeStunts (2017; Dorsal and Second)
  • Superkart Special Event (2010)

I think almost all of those either are somewhere in my computer already, or are otherwise easy to retrieve. In any case, I will ask you folks if anything turns out to be missing.

On an additional note, another thing I would like to do is setting up some architecture for the Archive more resilient than a bunch of folders, textfiles and spreadsheets loosely correlated with each other. I'm not sure I will have time to play with that before the release, though.

Site Announcements / Cars and rules for 2019
« on: September 23, 2018, 02:25:00 AM »
Let's get it rolling! On the subject of cars, I would like to begin by making a pitch for two of them:
  • Superkart: I like the Kart, and would enjoy seeing it again at ZakStunts. If it comes up at a insufficiently twisty track during the season, we can always slap a -10% penalty on it. If you want to try it for yourself, head to the current race at Cas' competition.
  • Toyota Sprinter Trueno: It would be good to give one of the Toyotas a chance to shine. I feel the Trueno is a more interesting car than the Corolla, as due to its low real top speed it is closer to the LM002 than to all the other mid-slow cars. There is one problem: the Trueno has extra off-road grip similarly to the Lotus, but exaggerated to the point it becomes more bug than feature. However, as the Trueno was never used in a competition, it would be straightforward to prepare and distribute a bugfix release -- I will do just that if we decide to use it next season.
As both of my candidates are slow cars, it sounds sensible to bench the Skyline this time if either or both of them are approved for 2019.

There are all those other cars to consider, of course, and perhaps I'm overlooking some great candidate (you can find all of them, or at least the released ones, at Southern Cross). So please have your say  :)

Competition 2017 / ZCT193 - No Imagination
« on: August 07, 2017, 11:40:57 AM »
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  ::) :)

Competition 2017 / ZCT192 - Freestyle Fever
« on: August 07, 2017, 11:30:36 AM »
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 :)

Competition 2017 / ZCT191 - Facetrack
« on: July 07, 2017, 06:05:03 AM »
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...

Competition 2017 / ZCT190 - AR Turbo
« on: May 20, 2017, 09:50:45 PM »
Long straights, hard braking and an enjoyably peculiar layout...

Competition 2017 / ZCT189 - Walking the Valley
« on: April 17, 2017, 09:44:29 AM »
I like valleys, and bridges that span them :) I'm going to try this out anytime soon -- no clue about cars, though.

Competition 2017 / ZCT188 - AbuRaf's Boulevard
« on: April 17, 2017, 09:41:56 AM »
(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.

Competition 2017 / Z187 (Anelio's) analysis
« on: April 17, 2017, 09:34:51 AM »
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]
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]
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]
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

Stunts Code Extraction / Brain dump of a lost inquiry
« on: December 30, 2016, 06:55:44 AM »
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_car_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_car_state.
    • There is some confusion in the 2010 annotations to update_car_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.
  • 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.

Stunts Chat / Race for Kicks
« on: December 09, 2016, 06:18:08 AM »
Every competition should have a place in the forum, so here is a thread for Cas' holiday OWOOT competition.

Competition site:
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.

Competition 2016 / ZCT185 - Shangai Highway
« on: December 09, 2016, 05:40:55 AM »
Driving in a city track with Skyline makes me think of Gran Turismo  :)

Competition 2016 / ZCT183 - Napalm
« on: October 01, 2016, 07:59:39 PM »
I like tracks such as this one which start rather slow and get progressively faster as you drive along them.

Competition 2016 / ZCT182 - Mittwoch mit vomit
« on: September 02, 2016, 05:22:22 AM »
Trickless for the most part, yet quite demanding -- and outright hard under GAR...

Competition 2016 / ZCT181 - Sk8erboi
« on: August 28, 2016, 10:28:24 PM »
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 ::))

Pages: [1] 2 3 ... 7