Topics

We have a new race.  This time, our guest track is by Alan Rotoi!  Waiting for those Porsche March Indys. I'm just about to post a replay myself!

Happy day, Dreadnaut, KyLiE and myself and probably several of you, guys 

Well, folks. This is the little project I'm currently working in. I'm making a prototype for a platform to run our live races. As I've learnt to do years ago, I'm working exclusively on the functionality and won't do the looks until everything does what it's supposed to do. This first phase is about 80% complete. When I'm done with that, I'll create a basic look and I'll make it available for some live testing. Then, I'll do some debugging and once it's fully reliable, I'll get to making it look as it deserves.

The intention of the platform is:

• To automate the track and replay uploading and handling during live races
  
• To control the racing times
  
• To create a historical database where we can go and look for previous live races
  
  While this will make it much quicker and more comfortable to get the right version of the track and upload your replays during a live race, I think that the classical way of posting here in the forum has something special, so probably, if this gives good results, a forum thread with the same information should also be created when a live race is held, I don't know. I'll let you guys know once it's up

I'm starting this topic so that we can drop any ideas or thought about the possibility that tournaments and other sites related to Stunts could have a unified login system or anything similar. If I know well, we have the following currently:

- ZakStunts
- The forum
- The wiki
- Stunts chat
- Race For Kicks
- CCC (and potentially any other EasyTour-based website)

that use a login system. The forum and Stunts chat use the same login and when you log in to one, you're automatically logged into the other. However, sometimes, you get kicked from the chat and when you re-log-in, you end up in the forum instead. However, you're never kicked from the forum. All others listed use independent login systems. I have the same credentials for the Wiki as for the forum, but I think I purposedly chose to. Yet, I don't remember. But one thing I know: logging into the forum does not log me into the Wiki.

Race For Kicks has a simple system in which, you sign up with a user "name", which is translated to a user "ID", that's much simpler and, for example, is case insensitive. So all transactions are done with the ID and the name is only visual. That means if you signed up as "pipsqueak" you can later login as "pipsqueak", but you will show up as "pipsqueak". You have an avatar image and some permissions. EasyTour-base sites including CCC have mostly the same system, but each will have its own user data base and do not currently interact.

If there's any unification, of course, permissions would not go across websites, but some information could, such as avatars, the ID and name, the password hash, etc. It could be that each site will have its credentials but you can, additionally, use the "universal Stunts ID", ha, ha... or it could be that we simply begin using just one login system. I think the former is safer because if one site goes down, we want the others to still be able to log in users.

Anyway, I'm interested in any ideas regarding this and I'm willing to help in anything I can. Cheers!

Hi, guys!  I'm beginning to plan a trip to Europe. If everything goes well and according to plan, this could be a reality for next November. However, I don't have a lot of money or a lot of time... yet enough to make it worth it. I really would like to have a whole year to travel through Europe, but I can't even make myself a whole month this time, so I'll have to get picky.

I'm interesting in knowing what the CoViD situation is in your countries. In particular, if people are required to prove vaccination to go to restaurants, shopping centres, etc., and in that case, how they normally prove it. I am vaccinated, but I have the Russian vaccine that's not recognised almost anywhere and even worse right now. I think now it is possible to get other vaccines so if I'm to get another dose, I'll try to pick according to convenience.

Also, if some of you are going to travel within Europe and get together, we could sync. As I said, I don't have a lot of time, but at least meeting some of you guys along the way briefly would be great. I still have to calculate where I can go. I think I'd be visiting probably three countries and one city in each. If I make it to have more stops, it will be too quick.

[EasyTour]

EasyTour
Current version uploaded: 2022-06-30

I'm working on this little project since a few days ago. The idea came from a question Alan Rotoi asked me, so hopefully, Alan, it can be of use to you. Also, maybe Duplode is interested. Anyway, it's a very modest thing and far from perfect, but might be of help for somebody who needs to quickly set up a race event.

It's called EasyTour and it's a very small php package that you can simply drop in a web server. It has to support php, but does not need a database system. Also, you don't need to configure anything at server level. You can just work on the same page the package provides. In other words, you drop it and then you load it in your browser. Once there, you log in as "admin" and use the password "admin". Then you can proceed to change the administrator password to whatever you want and you can customise your website look by changing the CSS from the interface!!!

You set up a race by uploading a track and you can edit the tour.cfg file to change things like the tournament name, deadline, etc. You should create a user name for yourself besides the "admin" user, for posting your replays. While logged in as an admin, you can moderate the scoreboard and you can download replays that are private.

If everything went well and I didn't make a mistake, once your server is set up like that, you can add it to Bliss in the Tournament option and it should be able to interact with it. There are many simple features I can easily add, but I'd like to make sure what it has now works well. You can only hold one race at a time, there's no chat, no PM. When a race is over and you upload another track, every replay file is deleted, so you have to download everything (each replay and the track one by one) if you want to keep a backup. The track image is auto-generated.

One thing I would like to do with this project is, as it matures, in future versions, use it as a base for a next version of Race For Kicks, once it becomes more powerful than the current, monolithic version, since this project is fully configurable. But right now, this one can only do about a 5% of what R4K can.

Anyway, feel free to experiment with it and let me know what you guys, think.

I've been getting this error 403 whenever I want to upload a replay and it's been happening since maybe five months or so. It seems I can easily just ignore the error, as I can post and my lap appears on the scoreboard normally, but I wonder if there's anything that can be done about it or an explanation and if anybody else is getting it. I've mentioned it a couple of times in the Shoutbox, but nobody seems to notice, so I reckon you guys don't know what I'm talking about. You probably don't see it. So I took a picture of it, ha, ha.

The error appears after I browse and pick a replay. It happens every time, no matter how long or short the replay, what car I use, anything.

I have been wanting to make an important change to the mentioned article ("Car parameters") for a long time, but because of its significance, before doing it, I would like to explain what it is about and the reasons to check your opinions, guys, and probably I'd also get suggestions to do it some other way or anything helpful... So here I go:

The problem I find with the current form of this article is that it describes the structure of the CAR*.RES files by giving absolute pointers (relative to the beginning of the file) for each parameter. This is OK for original, unmodified car files, but the truth is that the format is much more general than that. These files are composed of four chunks and one of these chunks, "simd", contains virtually all of the parameters. While on original cars, "simd" is always located at the same position, this varies widely when Stressed or CarWorks are used and because these other files work just as well in Stunts, in my opinion, it makes more sense for the parameter positions to be expressed relative to the beginning of the "simd" field.

A note could be added that, for original cars, the beginning of this chunk always lies at the same position and that you can just add that to obtain where each field can be found and the chunk structure should be described. This would make the article valid for every case, not just for original cars.

If you guys think it's fine, I'll proceed to make the changes carefully and making sure it remains perfectly easy to understand and very clear, but I'll take into account any suggestions.

Here's what I have been thinking about how collision and driving physics should be faced when developing a new engine that's compatible with that of Stunts, in the sense of giving a similar feel.

There should be two "moments": one when the car is completely on a driving surface and another in which the car is in the air. Of course, there are some transitions, like when the car has begin to touch the ground, but it's not fully on it yet, but this could be solved by correcting the car orientation and making it part of the "air" moment and there's also when the car is fully on the ground, but upside down. This could be just the same as normal, only the car does not respond to driving. I think this is what Stunts does and then if the car hasn't carshed, it crashes unless it gets back to normal or to the air very soon.

While in the air, the car should respond only to a constant gravity as a force, generating a parabolic movement, and preserve angular momentum, which would cause it to roll until it gets back to a surface. But then there's air friction, which provides many things when the speed is high enough, like terminal fall velocity, dissipation of roll and some air-braking. This is complex. The good thing is that, given that the math has to be done, adding "wind" does not give any additional work, so that could be a new feature. Air density and gravity could be made configurable, which again, wouldn't make it any harder or slower and would allow driving on other planets, ha, ha.

While on the ground or on a driving surface, we can first assume the car is a point and separate azimuth from the other two angles. Azimuth should be constant unless one steers. On the other hand, pitch and roll should be resulting components from the steepness at the point and they can be split via dot product against the gradient and its complement. Then, the altitude of the ground, plus the height of the car become the new altitude of the camera. This appears to be what Stunts does when the car is fully on the ground. There never is a problem with one wheel or two being in the air. Yet there is an effect if one or more wheels are in the air because the car is reaching the end of a bridge, for example. Not sure if each wheel should be calculated separately all the time or only when there are exceptions.

It looks like Stunts loads a number of planes in memory that corresponds to the tiles the car is interacting with. The plane altitude at the car position is calculated via proportions and they are sorted from top to bottom with the current car altitude among them. Then, if the car at a certain moment is no longer on a plane, the next plane towards the ground is found and the car will fall until it reaches that surface. Pretty complex, as this can induce rotation when some wheels are on one plane and others in the air or on another plane.

Then there are walls. I don't know if walls can have a non-vertical steepness. I think it makes more sense for them not to and planes could be flagged as drivable or non-drivable. There's a certain crashing speed. If you hit a wall or plane at over that speed, the car breaks. If you hit it slower, the car will adjust to the surface if drivable or bounce if non-drivable.

All this is blowing my mind. If you guys have any details that could simplify this for me to be able to start working well on physics and collision, I'll be happy to read that. Also, if there's any important detail I'm missing, please let me know. Thanks!

Hey, guys. I've recently bought a new monitor for my desktop computer. Until a couple of days ago, I was using a monitor at 1360x768 pixels. My new monitor does have full-HD. Among other things, I wanted to have 1920x1080 because, with my previous monitor, 3x was OK for 320x200, filling a significant part of the screen when in a window, but 640x480 looked very small at 1x and doubling it was not possible as it would've been larger than my screen. I was calculating that full-HD would allow very good proportions at 4x for 320x200 and 2x for 640x480.

To my surprise, the new graphics mode did not trigger a larger window in 640x480 and it seems 3x is the maximum (normal3x) for 320x200    I can, of course, use full screen and that looks perfect. The problem with that is that I'm forced to go out of that mode if I need to do anything with another program and then come back and that is slow. With a window, I can disable mouse pointer auto-lock and access the window like it were any other program window, which is great. Also, I would like to use an integer multiplication factor, so that the scaling will look natural and is faster, and I don't want to apply any interpolation, as that makes games look very different from what they were originally and I like the classic look.

So I wanted to ask you what you guys use for a configuration, what you suggest and if you know how I can achieve what I like. The last changes I've been trying to make appear to have no effect or a very different effect from what I look for.

When I coded version 2.0 of Race For Kicks, I made sure to include not just races (also called "challenges"), which are part of the tournament seasons, but also tracks that can be raced occasionally at any time. All tracks used for races appear when you select the "Tracks" menu, but some of them are also active for the Permanent Competition. This includes all original tracks that come with Stunts as well as a few of our own. To quickly filter the tracks, click on "See classic tracks only", which will display only original Stunts tracks (although other tracks are active too, as you can see when you go back to "See full list").

When you post a replay for a track in the Permanent Competition, you are allowed to use any of the cars currently available in R4K and you can select any set of rules (Freestyle, like in ZakStunts; Free OWOOT; Strict OWOOT, like is usual in R4K or GAR). All replays will share the same permanent scoreboard and all replays there are public (if I remember well, because I've coded this long ago). Your replay will be verified according to the rule set you select. Both the replay and the lap information will be kept so there is proof for the future. If you have created a better replay for one of these tracks in the past, you can upload it too.

Since this has been available on the site, few people appear to have noticed it so it is not as thoroughly tested as the race system is, but it should be OK. Let us know if you find any bugs. If we see more activity there, we'll keep improving the system.

[Most recent version:]

I have had an idea very similar to Dreadnaut's CarPark in the relatively recent past. That is, besides the idea of a more complex and elaborate car manager more like what Daniël and KyLiE would like, which I also like, at a point, I thought that I could make something command-line-oriented to have it working soon and to make it flexible for the keyboard-centric user like me.

My idea was not exactly the same, but similar. Instead of using command line arguments for the main program, I envisioned the program like you'd call it and you'd get a command line interface inside it. Then you'd type command to list the cars, delete, backup, restore, etc. You'd also have commands to tag cars, so that groups of cars could exist that you could backup or move together quickly.

In my experience, nothing takes more time in developing a program than working on the interface visuals, so making this a command-line program would make it possible to complete the project very quickly, although it wouldn't be the nicest car manager for most users, which leaves space for somebody else making another with a different style as well.

Metadata?  Well, that's another topic. I don't think it should be dynamically added or removed from cars while handled by a car swapping program. Whether metadata should be added by the author when creating the car, that's another thing and I think it's up to the author.

EDIT: OK, I got tempted by the idea and I made this simple command-line-based garage manage. I didn't want to steal the name, so I called it Simple Garage. It's made quickly and my own way, but if you like it, just tell me, or I could just add things to it to make it more like the CarPark idea. Anyway, I'm willing to collaborate. The zip I've uploaded contains the Linux and DOS versions. I can also compile it for Windows if you guys want. If you call it with a command line, it'll execute the command. If you just call it alone, it'll open a console and you can call commands there. Type "HELP" for... well, help. "EXIT" to exit, of course.

Dreadnaut: if you like it and if you want to guide me a little, I can make this one work more and more as you want and then, if you prefer it, we could use the CarPark name. What it currently does is pretty simple. You can create groups of cars and move either individual cars or whole groups between Stunts and the garage. If a car has a number of files other than four, they're still all copied together, but you get a warning when you list them.

Most recent version:
Simple Garage 2.1 - 2023-02-02

Older sgar 1.1 and 2.0 kept just in case for now

[zakize]

Hi, guys!  This is a DOS EXE file. Just put it with your Stunts files and run it from DOSBox to modify your R4K replay files to be accepted by ZakStunts. This is for you to be able to post your R4K Symbolic Link replays in the Symbolic Link race that's being held at the same time in Stunts. They won't be good laps for free-style, but they could go well for GAR!

Just type:
zakize myrpl.rpl

and it will make its hocus-pocus

So, I analysed the format of Stunts fonts, as I mentioned before, and found that it's really very flexible. I created a Wiki article describing the format, which you can read here. It was Daniel3D that prompted me to take a look at this matter and I've created a font editor and a couple of format converters that I will soon publish here.

Daniel3D and I have been testing Stunts to see how it behaves with modified fonts and we've encountered that it is feasible to add diacritical marks and new characters for better support of other languages. Daniel is now in the process of creating a font that will use a code page mostly compatible with Latin-1, but allowing some extra characters so that languages that are not fully supported in Latin-1 (such as Hungarian) can be supported as well.

With these fonts, it will become possible to create translations like what GTAMan15 has been working on with all necessary characters, so we'll start by facilitating these fonts and a code page converter I'm going to develop to him, so that he can continue with his work more comfortably. We could also develop translations to other languages. Expect the software here in the next few days

EDIT: Current version of the editor and coverter can be downloaded from here

I've been looking at tournaments of the past in the Wiki and it calls my attention that ISA does not have a wiki page. The lack of information about this competition, which is said to have first defined OWOOT makes me worry that what is known about it could be lost as time passes and some people in the community become busy and enter hiatus or leave permanently or perhaps just forget details because of so long without thinking about them.

I would like to gather as much information as possible about this competition... and also, why not, about others that are represented, but without much detail, in order to construct a more thorough set of articles about the history of the Stunts community. So whatever you guys know that can help, please post it or point me to where I can find more info. Thanks!

Updating R4K banner for Stunts hub. Here's the new one

You better get KITT out of the garage, give it some polishing and some tuning, check the oil, inflate the tyres and load some fuel, because next month, we're having a challenge for you guys with this newcomer at Race For Kicks!

Start practising!  We're not accustomed to driving this TV star on an actual race and being skilled with it may make a huge difference

[Origins of the problem]

As you may have read in another thread, I've realised that we've been doing it wrong about handling Car Resource files. I think it's important to point this out and explain it and, well, do something about it. I'll expand here:

Origins of the problem
Stunts stores most of its resources in a file format we normally call the resource format. This is nothing but a chunk-based binary format. The header specified a number of chunks and for each chunk, you have an ID and a position within the file. The notable thing about this format when compared to so many other existing chunk-based formats is that it does not specify the chunk lengths. Some format may also not include this, but they seem to have a rule that chunks are described in the same order as they are situated in the file and one always starts just after the previous one. With this, we can easily calculate the chunk length by substracting a chunk's position from the next one's. The thing is, Stunts does not do this, or not always. Some resource files (particularly, Car*.Res files) originally coming with Stunts include their chunks in another order. This complicates loading these resources for editing when creating tools.

What we have done about this in the past
Because most original resource files do have chunks in the expected order, most files have been analysed as what they are. But for Car Resource files, as all original cars had the fields in the same order and the most important one is of fixed length, we have been describing this file with fixed offsets from the beginning of the file. To the point that this is the way in which the Wiki lists the contents of the files. Some tools have been taking it for granted that files will be ordered like this. I can think of a few examples: CarWorks, Dash Manager, Car Swapper, Car Blaster, etc. One tool that does not do this, for instance, is Stressed. And all this would be fine if Stressed saved the files with the chunks in the order we're used to, but this isn't the case. Car Resource files created with Stressed use the growing order instead of Stunts ordering and thus, are incompatible with tools like Dash Manager and Car Swapper.

What I think we should do
Really, we can't blame Stressed. It really tries to be as clean as possible, cleaner than Stunts itself. And it does it well, because Stunts does not complain about the new ordering. That means that it's us that should make the change. To quickly patch this issue, I can try to develop a little program to convert between these two orderings, but this is a patch, not a solution. I will need to change Dash Manager... oh, and CarWorks... to be able to handle the files for input the same way Stressed does. But I recommend that, for saving, when we develop tools, we continue to save in the original order that came with Stunts. Stunts will be able to work with files in any order, but using this order guarantees that tools that didn't take the precaution that Stressed took will be compatible with our files. Apart from this, I think we should be updating the Wiki to make this clear and also to describe car parameters in terms of the chunks they're contained in. I can do that.

A way to do the loading easily
I've been thinking what would be an easy way to load these files, since they don't specify chunk lengths. I suggest the following. We read into an array all IDs and their corresponding offsets. Then, we sort this array by offset and optionally, add one extra item and set its offset to the total file length minus the header's length. Finally, we load each chunk's contents calculating the chunk length from the next chunk's offset minus the current chunk's offset. When we get to the last one, this calculation will work too if we've included the extra item. It's not super nice, but it's easier than any other loading method I can think of that is compatible with any ordering. This loading procedure can be use with any resource file. Saving is a lot easier.

I decided to make a thread for this even though it's not really useful like resolving the opponent's path is. I previously found a solution to how Stunts decides where to place turning signs and at that time, I tried to solve this, but I couldn't. Uhm... maybe there already is a thread?  I couldn't find one. Anyway, if there is, let me know

Here's the riddle: How does Stunts decide on the placement of the cameras for F4 view?  I've been making tests and, by placing objects around, it's easy to see where the camera is placed if you follow a replay. But I haven't been able to find a way to predict this. I should have written down what I had tested, even though it was not a solution. It's not as simple as the corner sign problem I resolved. Cameras are sometimes placed on top of bridges and if you count the number of tiles between cameras, it appears like you could predict it at first, but sooner or later, the track has to turn and with turns, all predictability is lost.

Anyway, I'll keep on testing, but if anybody has an idea to add, here we have a thread

I'm starting this thread without much information just so there is a place where we can drop whatever we have about this topic. The idea is  getting to fully understand how Stunts resolves what is going to be the opponent's path on a track. There has been some discussion about this in the past in different threads, but I think there isn't a thread specially for this, so it'd be better to put everything together.

We know, of course, that Stunts will try to find the shortest path for the opponent and it seems it first adds the number of tiles for each path and apparently ignores the numbers and types of obstacles there may be. However, I've made experiments in which I tried to force two equally long paths in different orientations and I haven't been able to find a theory that can predict Stunts' choice in those cases.

To show how counting tiles is non-trivial, when counting, single-tiled objects count as one tile and two-tiled objects count as two tiles, of course. Then, four-tiled objects are less clear because you can either turn or go straight and, in the case of the cork u/d, you go straight, but you follow a whole circle in the middle. My guess is Stunts ignores this and takes it as two tiles. But what if you turn?  Is it two tiles or three tiles?

My original guess was that, when path lengths were equal, Stunts would pick either the first path it resolved from the group of candidates or would display a preference either towards going straight or towards turning. I also suspected that orientation could break this, that is, rotate the track 90 degrees and the path may change. I don't remember the results of this test, but it's worth trying again.

Anyway... shoot everything you can think of!

EDIT: Maybe this should be moved to reverse-engineering...