Messages

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.

This is a very good idea. Each attribute should have a weigh and also, some might be lineal, while others might be more logarithmic or square-root like and others more quadratic or exponential. But... to make it all simpler, I would say start in the other direction: first think of which original cars are harder and which are easier and in which order and with how much "distance" you'd place them and then go and calibrate the attributes so that the cars get sorted that way. You can tune this better by asking several people to list the original cars in this fashion and set up an "average ordered list" before calibrating.

In my case, and thinking quickly from my experience, I find the Acura and the Countach two of the hardest cars to drive, while I feel especially comfortable with the IMSAs... the Jaguar being slightly easier than the 962. The easiest non-fast car to me is the Lancia. I feel that speed only has a negative impact if very, very high and because it's more or less the same for slower speeds, it's easier to pick a faster car, because I feel slow and not-so-slow cars are equally easy to handle, so I prefer then one that's faster from them, but yes, once they get very fast, it's harder to get a good RH replay. Now, very slow cars can also be negative because some stunts are hard to perform with them.

The issue here lies in how Stunts engine does rendering and physics during gameplay.

In my graphics engine, track grids are converted to a group of models that are placed at the right positions and with the right rotations to agree with the map, but in theory, the engine supports placing them at non-integer locations and with non-right angles and it's perfectly possible to put one on top of another. As you play, elements are rendered by distance at their designated positions.

But Stunts does not do it this way. It does still use the grid while rendering, so a tile remains a tile during the game and two elements cannot share a tile. This sets a limit to what we can do by tweaking, unless we found a way to separate these attributes.

Your suggestion of using terrain codes to render track elements does have a greater chance of working. I don't know where in the code terrain codes are resolved, but if I find that, I could have the engine look at codes beyond the currently available and load other graphic models. The physics models of these new elements, if the attributes (graphical and physical identity) are not split, would have to be, for example, all equivalent to plain grass at low level, but if we could split that, we could choose to assign any of the existing terrain models to the new graphical models. Then the only thing that would not work would be Stunts recognising them as part of the track, so we'd have to use a trick like your trials to actually use these elements, but it's still a pretty good thing!

ALAN ROTOI - LIKE THE WIND

1. 1:00.95 (1:00.95)
2. 1:56.30 (0:55.35)
3. 2:50.25 (0:53.95)
4. 3:45.15 (0:54.90)
5. 4:38.85 (0:53.70) - Best lap!
6. 5:32.70 (0:53.85)
7. 6:26.95 (0:54.25)
8. 7:25.40 (0:58.45)

8:00.00 - In the middle of the bridge after the banked road

Done!

ALAN ROTOI - SUBMERGED

1. 1:04.65 (1:04.65)
2. 2:03.40 (0:58.75)
3. 3:01.00 (0:57.60) - Best lap!
4. 4:00.35 (0:59.35)
5. 5:00.20 (0:59.85)
6. 5:59.45 (0:59.25)
7. 6:58.25 (0:58.80)
8. 7:59.45 (1:01.20)

8:00.00 - Still in the starting tunnel, nearer the exit