News:

Herr Otto Partz says you're all nothing but pipsqueaks!

Main Menu

Bliss / Cas-Stunts track editor

Started by Cas, March 08, 2015, 01:16:12 AM

Previous topic - Next topic

Shoegazing Leo

I like it because is easier to make some dual tracks and design tracks without Dosbox use.

Cas

Well, I've been into other things really, but when I'm bored, I make some touches to Bliss. As you all know, it's already totally functional since long ago, but I wanted to tell you I've updated a bit. So...

Bliss 2.5.3

New features:

  • Time estimates can now be done for every car. There's a pull down list
  • Better quality starting scenarios
  • Take trackshots by pressing CTRL+S
  • ZakStunts track identification when metadata is lost

Fixed bugs:

  • Some menu options had persistent buttons. Strange I hadn't seen them before. It's fixed
  • Found out why it didn't work in DOSBox and made it work. It's slower and doesn't look as good, though, but yes. Now you can run it under DOSBox too!

If you haven't updated the last time, for the custom directories option, I really recommend you to do so. It's a lot more comfortable to navigate the filesystem with that.
As always, you can get this update from http://www.dimioca.com/bliss. I would be very thankful if Bliss were included in the Downloads area in ZakStunts.
Earth is my country. Science is my religion.

dreadnaut

#92
Quote from: Cas on November 26, 2017, 06:10:33 AM
I would be very thankful if Bliss were included in the Downloads area in ZakStunts.
Good point, I actually thought it was already there! Well, it will be in a minute :)

Cas, do you prefer just a link to your website, or a link and we keep a copy of the zip?

Cas

Thanks, Dreadnaut!

Well, while I would like, of course, to have traffic in my website, I reckon that it serves a better purpose for the community to have the ZIP accessible there. Remember in the past, I was off for some time and the website I had at that time was lost, so Duplode had to share his copy of Bliss. I don't intend to abandon my current site or the community, but it's safer if it's uploaded there, I reckon. What do you think?
Earth is my country. Science is my religion.

dreadnaut

I put a link, but I'm also keeping a copy of the zip file for safety :)   I'll probably "upgrade" the download page in the next weeks, so they'll both be available. I think it's nicer to send people to your page because you have more information about the software and source code, and all the rest of the website!

Cas

Yes, that's true. Yeah, I think having both is the best, because people can choose to go to the site and see the latest version and all the details, but if something fails, it is also available right there. You may want to add that Bliss also runs in GNU/Linux, as that's probably not expected.
Earth is my country. Science is my religion.

Shoegazing Leo

The website is suspended. I need to show this program to a group that is thinking a type of car race simulator and Bliss will be an inspiration for the track design mode.

Duplode

Quote from: Shoegazing Leo on February 12, 2018, 01:29:43 PM
The website is suspended. I need to show this program to a group that is thinking a type of car race simulator and Bliss will be an inspiration for the track design mode.

I have just uploaded the latest version of Bliss (which I had downloaded a few days ago) to Southern Cross.

Cas

Yeah, the site sometimes goes offline. Is not that they are unreliable. What happens is that the web hosting is free, so one requirement is that I log in to the client area website at least once per month. When I fail to do that, they disable the page until I re-enable it. It's up again now.

Hey, I would like to know these guys. I wanted to recreate the essence of Stunts, but it's a lot of work and I had never given much attention to 3D before. I managed to make a simple 3D rendering engine similar to that of Stunts, but I have a little problem with clipping near the camera.
Earth is my country. Science is my religion.

afullo

#99
Hola! I would like to write down some suggestions about things that can be improved in the following releases of the tool:

- If you design a track with a bifurcation just after the start/finish line (see image), the analyzer said that the track will run fine, but in fact due to a well known bug of Stunts, the race comes to an end in the very first seconds, when the bifurcation is reached.

- If you run analysis on a track without winning path, and you access estimated pipsqueaks' times, results are given while it is impossible to complete the race. By doing some computations, it seems that the time is computed as the track would have 100 000 tokens (or 99 999, no precision to determine exactly with the tests done).

This is inferred by the fact that I computed, for Duplode driving an Indy, a ratio of 0.0688170 ± 0.0000043 sec/token for a 1175 tokens long track, and a ratio of 0.0688155 ± 0.0000033 sec/token for a 1545 tokens long track (while the uncertainty reduces to 0.0000006 for a 10215 tokens long track). Since the time proposed is 1:54:41.50, or 6881.5 s, the computation follows easily.

- Some typos are present, like "Alipne" instead of "Alpine" in the scenery selection, "Nissasn" instead of "Nissan" in the car selection for time estimates.

- When a split later joins to a path that is already forked and then rejoins, the analyser does not identify correctly the paths, and as a consequence their number could be computed wrongly. Maybe for particularly complicated tracks it would be easier to write, by basing upon their structure, some lower and upper bounds on that number, instead of the exact value (quantities L and U such that the number of paths N satisfies L <= N <= U); nevertheless to do so, by having L and U in general sufficiently close to N to be information of practical interest, would probably require an adequate amount of not so trivial combinatorics.

- By going on Track Analysis and then to See Times, then pressing OK and finally trying to start a New Track, old buttons will appear.

They are just aspects which could guide future development of the utility, which is already quite great at the state-of-the-art.

Cas

Thanks for posting, Afullo. Some of these bugs, we had already discussed. I've already fixed some things, others I had pointed out to you. In general, it's complicated for me to work on the Track Analysis menu because it's a really big not. Maybe I should rewrite it completely. But to be more precise:

- If you design a track with a bifurcation just after the start/finish line (see image), the analyzer said that the track will run fine, but in fact due to a well known bug of Stunts, the race comes to an end in the very first seconds, when the bifurcation is reached.
> I knew about this bug in Stunts, but really hadn't brought to my mind that I could apply it to the Analyser. I guess it shouldn't be too hard. Still, this bug can be avoided. Sometimes, if you start the track by driving to the side opposite the split, you're able to continue driving just fine. Other times, you can drive normally, but when you watch the reply, it finishes prematurely. Maybe I should just make this come up as a warning.

- If you run analysis on a track without winning path, and you access estimated pipsqueaks' times, results are given while it is impossible to complete the race. By doing some computations, it seems that the time is computed as the track would have 100 000 tokens (or 99 999, no precision to determine exactly with the tests done).
> I had not realised this happened. I'll make a few tests and fix this. I wonder why this happens.

- Some typos are present, like "Alipne" instead of "Alpine" in the scenery selection, "Nissasn" instead of "Nissan" in the car selection for time estimates.
> Both typos have been corrected. You'll see them fixed in the next issue

- When a split later joins to a path that is already forked and then rejoins, the analyser does not identify correctly the paths, and as a consequence their number could be computed wrongly. Maybe for particularly complicated tracks it would be easier to write, by basing upon their structure, some lower and upper bounds on that number, instead of the exact value (quantities L and U such that the number of paths N satisfies L <= N <= U); nevertheless to do so, by having L and U in general sufficiently close to N to be information of practical interest, would probably require an adequate amount of not so trivial combinatorics.
> This is very hard to resolve and it's something I found out as I was building the current track (No Kidding). The number of paths is always calculated exactly because individual paths are loaded in buffers, that is, in an array. I believe the difficulty in analysing this type of path lies deeply in the strategy used to analyse them currently, so to fix this, the simplest way would be to rewrite the analyser. This may take a couple of months, ha, ha. Unless I invent a new, much simpler an elegant method.

- By going on Track Analysis and then to See Times, then pressing OK and finally trying to start a New Track, old buttons will appear.
> I noticed this one some time ago. Easy to fix. No problem.
Earth is my country. Science is my religion.

afullo

#101
Quote from: Cas on April 26, 2018, 08:35:05 PM
Thanks for posting, Afullo. Some of these bugs, we had already discussed. I've already fixed some things, others I had pointed out to you. In general, it's complicated for me to work on the Track Analysis menu because it's a really big not. Maybe I should rewrite it completely. But to be more precise:

- If you design a track with a bifurcation just after the start/finish line (see image), the analyzer said that the track will run fine, but in fact due to a well known bug of Stunts, the race comes to an end in the very first seconds, when the bifurcation is reached.
> I knew about this bug in Stunts, but really hadn't brought to my mind that I could apply it to the Analyser. I guess it shouldn't be too hard. Still, this bug can be avoided. Sometimes, if you start the track by driving to the side opposite the split, you're able to continue driving just fine. Other times, you can drive normally, but when you watch the reply, it finishes prematurely. Maybe I should just make this come up as a warning.

Good idea, a warning could be a proper compromise between not signalling anything and stating that the track will substantially fail (because it could happen or not).

- If you run analysis on a track without winning path, and you access estimated pipsqueaks' times, results are given while it is impossible to complete the race. By doing some computations, it seems that the time is computed as the track would have 100 000 tokens (or 99 999, no precision to determine exactly with the tests done).
> I had not realised this happened. I'll make a few tests and fix this. I wonder why this happens.

Maybe you set a maximum somewhere, and the analyzer tries to compute the tokens until the end is reached, with this condition never satisfied, so the computation ends while the maximum is hit.

- Some typos are present, like "Alipne" instead of "Alpine" in the scenery selection, "Nissasn" instead of "Nissan" in the car selection for time estimates.
> Both typos have been corrected. You'll see them fixed in the next issue

Great.  :D

- When a split later joins to a path that is already forked and then rejoins, the analyser does not identify correctly the paths, and as a consequence their number could be computed wrongly. Maybe for particularly complicated tracks it would be easier to write, by basing upon their structure, some lower and upper bounds on that number, instead of the exact value (quantities L and U such that the number of paths N satisfies L <= N <= U); nevertheless to do so, by having L and U in general sufficiently close to N to be information of practical interest, would probably require an adequate amount of not so trivial combinatorics.
> This is very hard to resolve and it's something I found out as I was building the current track (No Kidding). The number of paths is always calculated exactly because individual paths are loaded in buffers, that is, in an array. I believe the difficulty in analysing this type of path lies deeply in the strategy used to analyse them currently, so to fix this, the simplest way would be to rewrite the analyser. This may take a couple of months, ha, ha. Unless I invent a new, much simpler an elegant method.

There is probably some literature on that (by considering every path morphic to a simpler figure and so on), maybe there are interesting results in graph theory.

- By going on Track Analysis and then to See Times, then pressing OK and finally trying to start a New Track, old buttons will appear.
> I noticed this one some time ago. Easy to fix. No problem.

In my opinion it is a secondary issue, anyway.

Another observations concerning estimated times could be:

- rounding times to the nearest multiple of 0.00:05, since Stunts express times in terms of multiples of 1/20th second;
- not allowing times higher than the maximum admitted by Stunts, which I remember to be near 25 minutes, probably something like 32767/20 seconds, but I need to (re)check precisely.

Cas

Well, found a few more bugs that were fixed. Some are remaining. Track analysis is very difficult to change. Sometimes I don't even remember my intention from some lines. I'm still studying the thing about the premature race ending when there's a curve right after start. As I said in the shoutbox, you were right about the time estimations when a track is incomplete: I had set some maximum values that I believed would never show up and used them as a start for the estimations. Because there were no such estimations when the track was incomplete, the default value was left. I have now made the estimation list unavailable when the track is incomplete.

Another thing I've been working on is track-shots. Bliss already has the ability to take a snap-shot image of the track when you press CTRL+S, but this is not obvious, so I've added a button and a menu to select the image format. Besides, there are some bugs with this in the currently available version. I'll soon post the update.

Graph theory does help with the analysis, but there is a catch. I can tell easily whether there is a cycle, but in principle, there always is for every complete track. Now, I should make as if start and finish were two separate points and I can detect any cycle other than the default circuit. But this isn't enough, because I want to calculate the paths, so what is a path if it contains a cycle?  And this is what I thought was defined and now I see is not. Say you drive from point A to a split. If you take one of the sections and end up returning to point A, then this is a cyclic path, so you should instead take the other section. The problem is, if A was located before a joint and then afterwards you reach such split, it is not clear whether the path is a cycle because it depends on whether you had come from A or from the other section before the joint. Sounds confusing?  With words, it does, but use the analyser on No Kidding, see the path problem and you'll understand exactly what I mean. In other words, it's not just I don't know how to do it, but I don't really know what I'm supposed to do, ha, ha.
Earth is my country. Science is my religion.

afullo

Hmm, it gives indeed several aspects to think about. At least, see what I posted on the shoutbox today, we know now what happens when the replay and the race limits are hit (not counting the abnormal freeze occurring to me with BB1.1; MS1.1 was fine). I will copy that observations here to keep the material ordered...

Cas

I believe the behaviour of Stunts with replays deserves its own thread so that people can find it more quickly. I think I'll have the time today to post the updated version of Bliss. Still, there are a few things I would like to do that would require major changes, such as fixing the way the paths are counted and analysed and allowing one to make analysis of a particular section of the track or display all sections in different colours.
Earth is my country. Science is my religion.