Messages

Hand over

I'm hesitant adding even more tables to the scoreboard page, but I'll think about alternatives. There is probably a decent visualisation that can show similar details 🤔

Yes, I would be too. Maybe something that would lead to a separate page for that purpose so that the site itself doesn't get too convoluted.

The Sierra isn't included in the Stunts download for this month. I had to take it from the forum

It's not as straightforward until you're familiar with the files in Stunts. The binaries for Stressed should run well on your system. The track element graphics are stored in the GAME?.P3S files. These files are packed. Stressed includes a program called stunpack, which reads P3S, but I think it can't save in the same format, so after you modify these files, you'll have to rename them out or something and place the GAME?.3SH files in their place. When Stunts cannot find the P3S files, it will look for the unpacked 3SH counterparts instead.

The first idea reminds me of the movie "Déjà vu", with Denzel Washington, in which the protagonist drives a car on the highway while he's seeing the past through his goggles!  I don't know who came up with that idea, but it's genius.

The second one, we've been talking about recently. I was considering "tunneling" physics information from Stunts through DOSBox out to the host system like it was done by another Stunts fan, who managed to have two cars play together through sending each other's information and placing it in the opponent's car. Daniel3D and I suggested back then that this tunneling could be used to play with my graphics engine without having to develop a physics engine, but it really isn't a comfortable thing and it's not easy to do because the input still has to be sent to DOSBox. Yet, if it were easy, it'd be a very interesting experiment.

Hey, guys. We've been previously discussing the possibility of switching to another form of chat or improving it in a way that will make us use it more. At the same time, the Telegram group came up and also, we experimented with Element. Our official chat, we still use, mostly for live races and to gather to wait for the end of ZakStunts races, but sometimes, it and the forum won't let somebody in when there are many already online.

So my question is why each of us uses or does not use the chat at any one time and how important it is to us to have an official chat. I'm not the one running it, but I do care about it, so I'm willing to help if we can do something about it.

Personally, I like about the official chat that it's part of our community, run by community members and that, potentially, we can have access to older chats, we own the data, there's no spyware involved, etc. I find it very "family-like" when we gather there for a live race or to wait for race results and I enjoy that. What I don't like is that I sometimes can't log in if there are many people connected, that there isn't a way to use an external client and that, I think, it's not possible to share files and images there, but none of those is a serious matter to me. However, because the Telegram group exists and I can open that immediately and I see many other folks use it, I tend to get directly to it instead of going to the chat, but I would really like for that environment to be "ours".

About Telegram, I like that I can get to it very quickly, because I have the client on my computer and that so many of you guys use it and that we can share files and photos quickly. I don't like that it's spyware, like mostly every commercial chat nowadays, that it doesn't use a standard protocol that would allow me to easily find another client personalised for my tast, that we never know when we might lose the chat text and we can't easily export and store all that in a way that we can comfortably analyse it later.

I liked Element too, although, even being free software, it is spyware too because it relies on Google reCAPTCHA and similar stuff, but it is much freer (is it spelled that way) than Telegram, but well, it wasn't well embraced.

Although it's not my case, I realise that probably, being able to run a chat platform on your cell phone is a reason why many of you feel comfortable with Telegram better than Stunts chat, but I don't know.

Anyway, what are your reasons?  Would you, like me, like that Stunts chat were comfortable enough so that we can just use it all the time instead of Telegram?

What I can help with is this: I could develop or help develop a web based chat that looked more like something modern and very Stunts-looking, with some perks that would facilitate Stunts-related activities. I can make my source completely open if I do and give it so it can be modified, enhanced or whatever and put where you think is best, maybe to co-work with the current chat or whatever. Would that help?  Or otherwise, I'll help any way I can that's good.

Also, for those of you who're heavy cell phone users, are web-based platforms comfortable to pull up and use or are they a lot less comfortable than native apps?  I have no idea about how to program cell phone applications. But who knows... maybe, say, there is some software that allows to convert web-based code into compiled apks?  Anyway, I'm here offering any help I can give if needed. Cheers!

America (continent)

I think it all can fit there. It's just a matter of sorting things. I like what it looks like now, but maybe yes, we could study what would be the best way to make stunts.hu catch as much fish as possible, because that'd be the purpose of a main portal.

The chat is still in good use, just not permanent use. We do use it a lot for live races. We've been discussing this in the past, but I think I'll make a new thread about the specific problem there because I'm interested in helping there.

I think something of that sort had been proposed some time ago. Say, you select a car and the page reloads, then, on hovering on top of the lap times, you can see the equivalent lap with the selected car

I've been working with Daniel3D on the needle-colour mod, which, I think, is the first assembly-poking mod in Stunts. What I can tell you from having tried... and succeeded is this:

My first idea, something I predicted by taking a look at the code before touching anything, was that replacing a single word, a pointer, could allow for turning what previously was a constant (the needle colour) into a variable that could be pointed at a field in the car parameter structure. This change, we later made and worked perfectly, it was super simple and I can assure you, completely stable, but most modifications we will be interesting in making cannot be solved by changing a single word. We were lucky that this was the case.

Then, as an improvement, by injecting additional code, we set sail to try something active, that would allow for independently changing the colours of the two needles. This is something we made chiefly to demonstrate that it is possible to make effective mods by assembly code injection (or to fail miserably and prove myself wrong otherwise). It worked, but we had to add some nops to fix code alignment problems and while the code hasn't failed ever so far, we will never be 100% sure that it's stable. The same thing will happen with any code injection we make this way. We do it this way because we don't have the original source code. If we had it, it'd be a million times better to work on that source instead.

The best thing we can do with what we have, that is, before one day the whole code is ported to C or before I or somebody else can come up with a whole new engine, is, instead of making tons of code-injecting mods, make a single code-injecting "hub" that accepts external plug-ins. This way, there would be a single source of potential instability. This is akin to what Forge does on Minecraft, I guess. It's no easy work, but I think it should be done before mods begin to proliferate wildly

In case of integration, I'm thinking the site could remember which cars we tend to prefer and, based on the bonuses and the user currently logged in, suggest one to three cars and what lap time you need to get to the next pipsqueak in the scoreboard (to you) and the one following

Wheat

Well, as for a full-asphalt tile, the closest to that I know in Stunts, at least physically (not graphically) is the chicane, which works like a 2x2-tile full asphalt surface. Of course, it has one entry and one exit, but through the magic of "illusion", you can merge two of them and create a two-input/two-output such block.

The more I read about ideas like this, the more I wish I could crack the physical part of the engine or come up with a good idea of how to develop my own, because the graphical part is pretty much resolved.

Dune (by Westwood Studios)

In my understanding, surface type is handled by Stunts as an attribute already separate from collision, which is handled via physical models based on two structures called "plan" and "wall". At some point of the source, it is hard-coded which track code leads to which combination of surface type, collision model and graphical model. If this place in the source is found (which surely has already been found when it was disassembled and analysed, so it must have labels and comments there), we could tweak this, but for a track element won, there's a track element lost.

An issue here would be that, if we change the collision model of a track code, it's logic circuit part correspondence will not change. So your track piece will continue to fit only in the same combinations as it used to fit before (except in trials-like tracks, of course).

Going back to graphical models and using terrain codes, I forgot to say the last time that Stunts works out terrain codes by applying a "special product" operator. That is, you take one terrain code and one track code and you obtain a new track code as a result. This is only done for track elements on the sides of hills. When there is water, the models are indeed both rendered. When there's something on top of a hill, it's elevation is updated and also, the hill model is rendered. This means that higher track values are often reserved for models of roads on the sides of hills.