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
Competition 2019 / ZCT212 analysis
« on: April 07, 2019, 09:00:01 PM »
Top 4 analysis for ZCT212:

Code: [Select]
0 0.00 0.00 0.00 0.00
1 22.30 22.55 22.70 22.70
2 39.20 39.45 39.95 40.25
3 53.60 54.20 54.75 55.55
4 60.10 60.65 62.15 61.95
5 68.55 68.90 71.15 70.15
6 81.60 82.50 85.90 86.65

0 0.00 0.00 0.00 0.00
1 22.30 22.55 22.70 22.70
2 16.90 16.90 17.25 17.55
3 14.40 14.75 14.80 15.30
4 6.50 6.45 7.40 6.40
5 8.45 8.25 9.00 8.20
6 13.05 13.60 14.75 16.50

0 0.00 0.00 0.00 0.00
1 0.00 0.25 0.40 0.40
2 0.00 0.25 0.75 1.05
3 0.00 0.60 1.15 1.95
4 0.00 0.55 2.05 1.85
5 0.00 0.35 2.60 1.60
6 0.00 0.90 4.30 5.05

Two remarks. Firstly, this was a tough track, with multiple spots where one subtle misstep (for instance, a fumbled gear change at the loopcut) could derail one's plans entirely. Carrera tracks do have a penchant for being unforgiving, one (in)famous example being Z86. Secondly, the final cut was absolutely decisive, as comparing FinRok's dream line by the first roof and Marco's spotless take on the second tunnel with everything else reveals. In particular, I have lost a podium place by not realising quite how much that would matter enough (my purple sectors 4 and 5 weren't worth much when followed by a somewhat careless final cut -- in fact, I had to abandon a partial replay with even better sectors 4 and 5 because I couldn't pull off a sufficiently good sector 6 before the deadline).

Competition 2019 / ZCT211 analysis
« on: March 19, 2019, 03:11:49 AM »
Here is a top 6 analysis for last month's race -- it's been a while since we last did that, and also it is a nice opportunity to try it out with multiple cars:

(From the second table on, Audi times were corrected by the car bonuses to fit the Ranger ones.)

Code: [Select]
0 0.00 0.00 0.00 0.00 0.00 0.00
1 41.15 41.95 34.60 43.25 34.95 35.25
2 74.25 75.05 59.50 77.90 62.70 63.70
3 109.80 109.95 88.25 113.75 91.95 93.70
4 125.60 126.65 101.15 130.85 105.00 106.90
5 148.80 149.75 118.75 156.15 123.85 126.80

1.00 1.00 1.29 1.00 1.29 1.29

0 0.00 0.00 0.00 0.00 0.00 0.00
1 41.15 41.95 44.49 43.25 44.94 45.32
2 74.25 75.05 76.50 77.90 80.61 81.90
3 109.80 109.95 113.46 113.75 118.22 120.47
4 125.60 126.65 130.05 130.85 135.00 137.44
5 148.80 149.75 152.68 156.15 159.24 163.03

0 0.00 0.00 0.00 0.00 0.00 0.00
1 41.15 41.95 44.49 43.25 44.94 45.32
2 33.10 33.10 32.01 34.65 35.68 36.58
3 35.55 34.90 36.96 35.85 37.61 38.57
4 15.80 16.70 16.59 17.10 16.78 16.97
5 23.20 23.10 22.63 25.30 24.24 25.59

0 0.00 0.00 0.00 0.00 0.00 0.00
1 0.00 0.80 3.34 2.10 3.79 4.17
2 0.00 0.80 2.25 3.65 6.36 7.65
3 0.00 0.15 3.66 3.95 8.42 10.67
4 0.00 1.05 4.45 5.25 9.40 11.84
5 0.00 0.95 3.88 7.35 10.44 14.23

Some of the highlights:
  • Sectors 1 (GAR-esque) and 3 (flat out) do suggest a Ranger advantage under those bonuses.
  • Other sectors, however, gave the Audi pipsqueaks enough margin to (barely) remain in contention. There was the high speed outer line in sector 5, and, in my lap, one extra shortcut in sector 2 that wouldn't be as useful with the Ranger due to the lower attainable speeds.
  • While one would be forgiven for thinking nothing interesting would happen in sector 3, it turns out that Seeker managed to claw back almost the whole gap to Marco there, centisecond by centisecond.
  • Following that, Marco managed to fend off the challenge with a quite excellent line through sector 4 (the first dual-way sector).
  • Marco's lap also features an interesting inner dual-way cut through sector 5. Among the top 6, the only one to attempt a somewhat similar line was Heretic -- the alternative provided by outer line, though, meant the inner line was rather less effective with the Audi than with the Ranger.

Stunts Chat / Keyboard issues and ghosting
« on: November 30, 2018, 01:37:12 PM »
Folks sometimes report not being able to press some of the keys needed to drive simultaneously (I remember BJ talking about that in the past). Such issues are, in all likelihood, a problem with the keyboard itself, and not with the operating system or with the configuration of any software. The heart of the matter is that, unless you are using one of those fancy mechanical keyboards plugged to a PS/2 port, there will be an upper limit on how many simultaneous key presses can be registered (a limit which might vary depending on which parts of the keyboard you are using). Some cheaper keyboards are bad enough in that respect that they are unable to handle enough simultaneous key presses for Stunts to be played properly. The keyboard of my newish laptop, for instance, has this issue, and so I still need my old desktop keyboard to race. The keyword to use when looking for more information about this issue, or for choosing a keyboard adequate for Stunts, is "ghosting". This page provides an interactive test for your keyboard. In my case, it reveals my laptop keyboard can't handle "Down Arrow", "Right Arrow" and "Z" simultaneously, which is clearly unacceptable.

Motor sports, Racing / Formula One in 2019
« on: November 22, 2018, 11:46:40 AM »
Robert Kubica will be racing for Williams in 2019! Robert stallin Kubica!!   :o :) 8)

Competition 2018 / Z209 - pArAnOiA
« on: November 20, 2018, 04:51:12 AM »
A bona fide CTG arena track! This is auspicious. Later I will try GAR -- it is a must, given the name.

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.

Competition 2019 / 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 Reverse Engineering / 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.

Pages: [1] 2 3 ... 7