News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Distant signals

Started by Erik, March 26, 2011, 10:32:13 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Erik

Hey everyone I have made a new signal who let slowdown the train if the next signal is (keeps) red.
This is to prevent that a faster train after a slower train has stop and pull up all over again.

Some part of the code are a bit ugly and I working on it to make ik more smooth.
But for that I have to rewrite the whole part of the "block_reserver".
So that would take a while.

On the attachment I have put the .patch and the signal.

Try it  ;)


Erik

#1
I have resolved the ugly part of the code I've build.
It wasn't needed to rewriting the whole block_reserver.

What I have done now is quiet similar to something I had already tried.
But is seems I has somewhere made a mistake.

I hope I can make the new patch soon.
EDIT: patch has been made from source r4397. :D
Unfortunately it's not directly compatible with the previous patch.
So remove (unpatch) the previous one and then use this patch.

(I hope also I have made a better type op patch.)


paco_m

Nice thing, this is more ore less the way how real presignals work ;)

Erik

Thanks, that's why I build it.  :D
I hope it will be implement soon.

Actually I wand also to rebuild a big part of the signals to make it more real.
But this would be a big patch, where waiting one whole month is too long.


jamespetts

Quote from: Erik on May 10, 2011, 06:40:32 PM
Actually I wand also to rebuild a big part of the signals to make it more real.

What had you hoped to change?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Erik

A few points.

- Seperate the different vehicle types in different files. It will blown all existing patches as it is now, but it will be much more clarifying to work on it in the future. (This one is fast done, but can't wait one month for implement. Becouse it will blown all the changes made in that month.)

- To make the signals reserve till the next signal before the next crossing if the whole track is free. It has a few advantages.
- With the previous one, make it possible that a faster train takes a track parallel to pass the slower one. Also useful on very busy tracks.
- Prevent traffic jam on the track. This would be the hardest one and jet I don't see exactly how it can be done.


Dwachs

Erik, am I right that the only differences to simutrans-standard-classic presignal are (1) check max 2 blocks and (2) speed limit?
Parsley, sage, rosemary, and maggikraut.

Erik

Yes,
(1) check max 2 blocks and not more.
(2) If it could only check one block, it gives a speed limit.


prissi

But then you would need a real two block signal, since this is needed in certain situations.

Erik

Yes, that is one of the changes who I have made and put it in the patch.


VS

Did this... umm... resolve in any way? It looks like the thread died without any result or a clear "no".

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Erik

At the moment I'm not working on it.
I know all patches are broken by now.  :-[

With the little time I have I'm working on rebuilding of the ns-pak set.

After that, I will go further with this.  ;)
Perhaps even rebuild the whole way that the signals are working now.


Max-Max

While you are at it I may suggest the following:

1) A real pre-signal also shows at what speed the train should proceed with and never stops a train. In Sweden there are 2 kind of speeds; 80 and 40
2) A real main signal may be combined with a pre-signal.
3) Pre-signals for road crossing.


1) This would be a new signal type in simutrans and could be implemented by setting is_presignal to the maximum speed to proceed with in case of red light at next signal. This signal will never stop a train. To make it simple, just allow one speed.

2) This could be an extension of the existing main signal by adding both is_signal=1 and is_presignal=60 (for example max 60km/h). As long the main signal is green the train will pass, if the pre-signal is activated (next block red) it will pass at the pre-signal speed. For this we need more images in the main-signal graphics and we can keep it simple by only allowing one pre-signal speed.

3) This has to be a new type that shows if the next road crossing signals shows stop for traffic. This signal shows red if crossing traffic is allowed to pass and white light if it is safe for the train to pass.

To further elaborate a normal engine will proceed with the pre-signal speed to the next signal, even if the status changes. If we expand the engines to have an ATC parameter, those can go up to full speed as soon the next signal shows green.
- My code doesn't have bugs. It develops random features...

jamespetts

Sadly, since the last post in this topic was in October 2011, I rather doubt that Erik is any longer at it. Adding realism to the signalling is somewhere in my long queue of things to do for Experimental one day, though.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Max-Max

I happen to have all the time in the world right now, but I'm not familiar with the code design to do this on my own. My German really sucks too, so I'm having difficulties to read the code as well.

Although I would e happy to try with some guidance.
- My code doesn't have bugs. It develops random features...

jamespetts

I see! Interesting. What I was planning to do is something that interacts very specifically with the code for braking distances in Experimental: have a look at the "railway signalling" section in this post. The basic idea is to have proper pre-signals ("distant signals" in UK nomenclature) and a sighting distance for signals, so that trains must travel within the speed that allows them to stop (according to their braking ability) within the sighting distance of the next signal that might be at danger, as well as multiple-aspect signals (signals that can be distant and stop signals at once). The idea is that a train driver would be presumed to know where the next signal is, but not the aspect that it is showing except by what has been indicated by a previous signal, until that signal is close enough to come within that train's sighting distance.

I had also planned to implement a system requiring railway signals to be placed within the coverage radius of a new type of signal box object, for such signal boxes to have a monthly maintenance cost, and be able to support a limited number of signals (depending on settings in their .dat files; for example, a small ground frame signal box might support six signals, a medium sized lever frame type might support 12 signals, and so forth) and to require that signals be of a compatible type to the signal box (e.g., semaphore signals for a lever frame box, colour light signals for a power signal box).

I had also considered implementing systems other than absolute block, including moving block, drive by sight (the code for the former two could be essentially the same, as drive by sight is in effect a crude form of moving block signalling that works at low speed: it is mainly used for trams) and radio electric token block (the signal boxes in that case would have an extremely wide catchment area, but the trains would have to stop at every "signal" (sign board/radio post) before continuing).

Are you interested in implementing any of this? If so, I can provide assistance as to how to find the relevant parts in the code and what sort of things need to be done (I can say now that most of the relevant parts of the code will be in route.cc, simvehikel.cc and simconvoi.cc).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Max-Max

Well I will try to read through the code to see if I can get an idea of how to code this. I guess a first step would be to have a pre-signal to limit speed and then work from there.

A silly question: What is the difference between the experimental and the standard version? Are the Experimental transitioned over to teh Standard when Stable? (like an RC version?).
- My code doesn't have bugs. It develops random features...

Erik

Sorry, I know.
I'm a bit off line the last two years. (First full job, looking for a house, etc.)
I didn't get much time to it.

Also I discovered my programing skills weren't sufficient enough. So for the last year also there I was working on. (Far as I did get the time for it.)

Quote from: Max-Max on May 01, 2013, 05:11:25 PM
I happen to have all the time in the world right now, but I'm not familiar with the code design to do this on my own. My German really sucks too, so I'm having difficulties to read the code as well.

Although I would be happy to try with some guidance.
Exactly also my point. Perhaps I can start over again and we work together?

O, for I forget. The correct English name is distance signal.


Max-Max

Erik, where are you located, Holland?

I'm in Sweden and sure we can work together on this. Are we doing this in the Standard code base? Can we reuse your old code or do we need to design this all over again?

I guess we first need to agree on a road map for this and make some design strategies.
- My code doesn't have bugs. It develops random features...

jamespetts

Erik - welcome back! Simutrans does require some fairly complicated coding, which is not always easy for a new coder; but I knew very little about C++ when I started, so it is not impossible (but does take a lot of work to get up to speed).

Max-Max - have a look at the Simutrans Experimental FAQ. In general terms, Experimental is a permanent fork with a (slightly) different design philosophy to Standard, focussing more on detail and realism, whilst Standard focusses more on good performance on limited platforms and gameplay simplicity. For that reason, in a number of respects, the code has diverged from Standard quite significantly, although in other areas (graphics processing, for example, and many low-level operations), it is identical. Most of the code from Experimental is identical to that in Standard, but there are number of quite important differences (see the FAQ and the posts linked there for more details). The most relevant difference for signalling purposes is the simulation of braking physics.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Max-Max

Allright, I'm installing GitHub for Windows now and will see if I can compile and run the game. I need to play around a bit with it to understand the new game mechanism...
- My code doesn't have bugs. It develops random features...

Erik

Yes, I'm from the Netherlands and also from the province North-Holland.
I think it's best if we use the Experimental source.
I do like the Experimental pak very well.

About my old source code. I'm afraid it is mostly useless.


jamespetts

Do let me know either of you if you have any queries about the Experimental specific aspects of the code, or the general layout (although I am afraid that I cannot much assist in relation to the details of the code from Standard in most cases).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Max-Max

Okay, I pulled the source from GitHub, added the external libs as I did for standard edition and compiled. I used the files from Simutrans-Experimental-Complete.zip to get the structure and PAK128.Britain-Ex-0.8.3.

Dropped in my compiled .exe but when I start i get the message "Fatal ERROR: vehicle_reader_t::read_node() - Do not know how to handle version=18184 Aborting program execution ..."

The .exe file that came with the zip works fine so it must be something VC settings that isn't right.

Any ideas what this might be?
- My code doesn't have bugs. It develops random features...

jamespetts

Hmm - very odd. The number 18184 is entirely spurious, as the version number there should be in the single digits. Which Github branch are you using?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Max-Max

I used the Master branch... wait there is one more "Experimental" =)

Okay I will try again...
- My code doesn't have bugs. It develops random features...

jamespetts

Which Github repository are you using? This is my repository, and this is the branch with the latest code on it (which will form part of the next release version).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Max-Max

That was a different one :)

Okay, I will clean up and begin fresh again...
Should I use the second link to the "latest code on it..." ?
- My code doesn't have bugs. It develops random features...

Max-Max

jamespetts and Erik,

I sent you my contact info in a PM.

Erik I have received yours, thank you.
- My code doesn't have bugs. It develops random features...

Max-Max

Okay I got it to compile and the Executable works :)
- My code doesn't have bugs. It develops random features...

jamespetts

Yes, indeed, do use the link with the latest code, as that is the code base that will become the next major version release in due course. Perhaps we could start a separate discussion as to the detailed implementation on the Simutrans-Experiemental development forum?

Incidentally, you might want to create your own GitHub repository with a specific branch for this project, with the master version being synchronised with the latest version on my repository.

As to the warnings, many of those are also present in standard (especially the signed/unsigned integer warnings).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Max-Max

But I got 555 warnings!!! (no errors although)...

I would estimate that about 95% of them are:

warning C4373: 'wkz_lower_t::get_tooltip': virtual function overrides 'werkzeug_t::get_tooltip', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers...

...and there are some conversion warnings like float to const int.
- My code doesn't have bugs. It develops random features...

jamespetts

That particular one arises in Standard code, as I suspect that the rest do, and are probably nothing to worry about.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

The are indeed to worry about, as virtual const char *xz cannot be overlaid by char *cz, be first one would not be called on many compilers. I do not get those warnings in standard, so those are not from standard. Rather a definition has missing a const I suspect.

What I get are float in int warnings (or sint64 in sint32 and the like) one volatile is ignored. But then I use MSVC 2010 or mingw GCC 3.4.5

Ters

I checked werkzeug_t::get_tooltip in standard, and there is some slight difference in const. The warnings are therefore valid for standard as well. Raise, lower and similar tools for some reason declare a constant pointer to constant spieler_t, while werkzeug_t only declares a non-constant pointer to constant spieler_t. Ironically, the warning applies to the compilers that don't emit the warnings, the compiler that spits out the warning does the right thing, or so I understand it.