Transport Tycoon Forums

You're right.

But the idea is different, I think.
As it works no, if a blue train encounters a blue marker, it get's a penalty (this works with A* because the penalty adds to the cost of the route)
in my version, if a blue train encounters a blue marker, it get's no penalty, instead, every train that is not blue, will get a penalty at this marker (this works with A* too as it's basically the same thing, only different coloured trains get the penalty).
To me, it looks more natural and understandable this way.

As I tried to make clear this has drawback - an unmarked route will look as good to a blue train as a blue marked one. To solve this, a junction with one marked exit has to have all exits marked. I'd reserve one colour for marking unmarked exits, and trains can't be of that colour. This constraint may be superfluous, but I think it makes things more understandable and intuitive for the user.

richk67 wrote:The bottom line with the A* pathfinding algorithm is that you *CANNOT* have negative penalties on a tile. If the cost of a tile < the cost of a straight piece of track, then the A* performance is *multiple* times slower.

When I speak about "-10 penality", I just put a minus sign as it's a penality. But my whole post was about using penality correctly, to simulate a nevative penality.

Haukinger wrote:You're right.

But the idea is different, I think.
As it works no, if a blue train encounters a blue marker, it get's a penalty (this works with A* because the penalty adds to the cost of the route)
in my version, if a blue train encounters a blue marker, it get's no penalty, instead, every train that is not blue, will get a penalty at this marker (this works with A* too as it's basically the same thing, only different coloured trains get the penalty).
To me, it looks more natural and understandable this way.

You're right, it's exaclty what about I said
But I think both markers should exists.
We should just need a new marker picture (the same without the red cross sounds perfect), then use the "old" marker with CTRL key.

By default, we should be able to put "every color gets a penality but the current color" marker, and CTRL should use the "this color will get a penality" marker.

I think reversed markers is good. We will have two types of markers: 1) don't prefer this route if color not match and 2) don't prefer this route if color match. Because we just need filter all other trains from marker it will work But, it will not work as «please, prefer this route instead of unmarked one», so we need to place marker on shorter path for fast trains instead of on longer for freight.

Have you considered another type of markers, that would mark the track for the train as blind (i.e. exactly like RR in TTDPatch)? It would be useful when there is no place for adding many normal markers in line (like station platform enterance). Or at least a marker with much more significant penalty, though I think marking a route blind shouldn't be a problem in the pathfinder algorithm.

So I suggest having 4 types of markers (still not too much):
1. Don't prefer matching colour
2. Don't prefer not matching colours
3. Mark blind for matching colour
4. Mark blind for not matching colours

This would allow a variety of route specifications, almost like RR (still missing restrictions based on signal state, though ) but with simpler UI.

Another question, I'm not sure if it is possible to have a marker and a signal on the same tile. It looks so in the screenshots. Is it really?

Is the patch still in development?

I use it and it's great. I have only made a little changes:
- added the suggestions from Bjarni (now the route marker colour will be cloned/copied)
- change the location from the button, it's now next to the signal button
- you can use the shortcut 'm' to build a route marker
- and of course make it compatible to the current trunk

BamBam

Edit 04. July 2007: removed download, newest one see below

Wow - thanks. I've sort of parked this while I have a bit of a hiatus before digging into airports in a big way. Nice to see people like & use it.

I must say this sounds really cool. And do agree that making a blue sign to mean "blue trains will prefer this route" is better than "blue trains won't take this route", but I also think that both type of markers are required (click build a "same color prefers marked route" signal, and ctrl+click builds a "same color dislikes marked rout" signal.

In order to do that and in addition to adding 10 penalty for each non-blue color, you could just get the speed sign to set the penalty of the tile it sits on to be 1 (or 0 if A* permits it), or max(1, tilePenalty - 10). When I say that, I assume the default rail penalty is something like 5, is it the case?

Oh, and one UI concern. Wouldn't it be more usable if the color selection was in the order window instead of the train status window? That would save 2 click (close the order window, open the status window) for each train built, plus it would put the control at a place more easily visible and logical (after all, both orders and colors decide where your train goes...) for beginners.

I hope richk67 has nothing against it that I editing his Patch .

Before some revs the Signal bit was changed and so the patch doesn't work. I have edit it but I am not lucky with this changes because I changed Tile.m4 from byte to uint16. I have no idea to avoid it.

I know only one bug: the route markers can be overbuild with roads. I will fix it the next days unless richk67 has nothing against it.

I love this patch very much. What must be change to get it into trunk?

Regards,
BamBam

Edit 04. July 2007: removed download, newest one see below

There are enough free bits in the map, so you don't need to increase m4 size.
Check docs/landscape.html and docs/landscape_grid.html to find free space.

glx wrote:There are enough free bits in the map, so you don't need to increase m4 size.
Check docs/landscape.html and docs/landscape_grid.html to find free space.

Excellent idea though, just make m* uint32s !! no more map array problems

BamBam wrote:I hope richk67 has nothing against it that I editing his Patch .

Before some revs the Signal bit was changed and so the patch doesn't work. I have edit it but I am not lucky with this changes because I changed Tile.m4 from byte to uint16. I have no idea to avoid it.

I know only one bug: the route markers can be overbuild with roads. I will fix it the next days unless richk67 has nothing against it.

I love this patch very much. What must be change to get it into trunk?

Regards,
BamBam

I have sent you a PM regarding this,

It wont compile, i get lots of errors, i have included the buildlog

boekabart wrote:

glx wrote:There are enough free bits in the map, so you don't need to increase m4 size.
Check docs/landscape.html and docs/landscape_grid.html to find free space.

Excellent idea though, just make m* uint32s !! no more map array problems

Keep in mind that a 32 (8*32 bits) byte tile, would use 128 MiB of memory for a 2048x2048 map, which is too much.

madman2003 wrote:

boekabart wrote:

glx wrote:There are enough free bits in the map, so you don't need to increase m4 size.
Check docs/landscape.html and docs/landscape_grid.html to find free space.

Excellent idea though, just make m* uint32s !! no more map array problems

Keep in mind that a 32 (8*32 bits) byte tile, would use 128 MiB of memory for a 2048x2048 map, which is too much.

I rather suspect that was his point.

madman2003 wrote:

boekabart wrote:

glx wrote:There are enough free bits in the map, so you don't need to increase m4 size.
Check docs/landscape.html and docs/landscape_grid.html to find free space.

Excellent idea though, just make m* uint32s !! no more map array problems

Keep in mind that a 32 (8*32 bits) byte tile, would use 128 MiB of memory for a 2048x2048 map, which is too much.

You get 1GB for under 40€ - why should one care about memory usage ?

Haukinger wrote:

madman2003 wrote:

boekabart wrote:Excellent idea though, just make m* uint32s !! no more map array problems

Keep in mind that a 32 (8*32 bits) byte tile, would use 128 MiB of memory for a 2048x2048 map, which is too much.

You get 1GB for under 40€ - why should one care about memory usage ?

That's just one type of memory. Having A LOT of memory still doesn't make it acceptable to use the hole lot.

Haukinger wrote:

madman2003 wrote:

boekabart wrote:Excellent idea though, just make m* uint32s !! no more map array problems

Keep in mind that a 32 (8*32 bits) byte tile, would use 128 MiB of memory for a 2048x2048 map, which is too much.

You get 1GB for under 40€ - why should one care about memory usage ?

thats why office 2007 is on a DVD!

Thats why some HP printer drivers are 75Mb

its just bad programming

Ding ding. Time out.

Please keep this thread on the topic of the Routemarkers patch. Please!

(As a general point: If you are going to quote, just quote the last relevant line not the whole post. We dont need to see 5 levels of nesting, when we can see the original a few posts above.)

perhaps a stupid question, but why make it 10041 when the sources u can DL is 32,43 and 48 ?

7of9 wrote:perhaps a stupid question, but why make it 10041 when the sources u can DL is 32,43 and 48 ?

Maybe because you can use svn to dowload specific build..? http://wiki.openttd.org/index.php/SVN#W ... version.3F