Patch: RouteMarkers

[doghousedean]

after a successful compile after running i get 2 errors, openttd.grf is corrupt or missing and flags.grf is corrupt or missing,

where do i find the correct version files?

Thanks

[doghousedean]

never mind, I've woken up now, i got them from them SVN.

[BamBam]

I changed the routemarker bits to m6 2..5, if I read right they are free?!
So no increase of the m4 size.

I also fixed the problem that a RM can be overbuild with road by "SetHasSignals(tile, true)" for RMs too. And of course a query if you remove a Signal or RM which only set "SetHasSignals(tile, false)" if both not exist.

@doghousedean: I don't know why you get errors. I use VS2005 and Fedora-gcc and both without errors. Maybe you compiled in debug mode and not release? Try to change that.

Regards,
BamBam

Edit 19. June 2007: v1.0.4 - update to r10213

Edit 04. July 2007: deleted the download from 28 Mai 2007 (patch) above with 56 downloads
Edit 04. July 2007: deleted the download from 06 Jun 2007 (patch) above with 41 downloads

Edit 08. July 2007: v1.0.5
- I made a GUI for the routemarkers (see picture)
- now you can build not only penalty routemarker but also vantage (right word?) too.
- fix a bug of the last version: routemarker cann't be saved
- extract much code to the new files routemarker_cmd.cpp and routemarker_gui.cpp and the old one routemarker.h
- changed the location of the RMs in the map-array, see (landscape.html)
- update to r10472
- and a lot more
- special thanks to my friend BeSt-Com who draw the new images and make the grf-file: thank you

[BamBam]

An update, see above.

[kaan]

very nice

[MagicBuzz]

Hello,

When cloning a train, the train marker color is correctly duplicated.
But after, if you change the color marker of one of the trains, it's isn't duplicated to the others.

I think it's a issue with the color marker system, as all trains sharing orders should prefer the same path.

So I updated the patch to share marker color exactely the same way than shared order.
If you wan't to stop sharing the color, just stop sharing the orders

Here is a new release patch then.

[Smoovious]

Rather than have trains, default to 'none', how about defaulting them to white instead? Or perhaps, be able to set in the gui, which color 'none/default' is supposed to be?

Or... if I set, say, a blue post on a path, say, to a shorter-than-usual platform so only my short local trains use it, how are the 'none' trains dealt with. The blue post, would give all other colors except for blue, a penalty. Would 'none' trains, get the same not-blue penalty? And, how is 'none' handled with the no-entry blue (with red X)?

Just need a tad bit of clarification. I understand the rest of it, except for the handling of the 'none' case.

-- Smoovious

[PhilSophus]

I found a little bug in ChrisIN r10780 that is probably caused by the route marker patch. In the attached savegame and screenshot, when the train (marked pink) arrives at the junction the following assertion fails:

Code: Select all

openttd: /home/pub/games/openttd/chrisIN/src/yapf/yapf_destrail.hpp:166:
bool CYapfDestinationTileOrStationRailT<Types>::PfCalcEstimate(typename Types::NodeList::Titem&)
[with Types = CYapfRail_TypesT<CYapfRail2, CFollowTrackT<TRANSPORT_BEGIN, false>, 
CNodeList_HashTableT<CYapfRailNodeT<CYapfNodeKeyTrackDir>, 12, 16>,
CYapfDestinationTileOrStationRailT, CYapfFollowRailT>]:
Assertion `n.m_estimate >= n.m_parent->m_estimate' failed.

The message sounds a bit as if the routing graph has an edge with negative cost. If I remove one pink route marker and one no-yellow marker from the right track the problem will vanish (don't ask me why I put them twice, but nevertheless it should not crash).

EDIT: openttd.cfg added

route_marker_bug.png (88.79 KiB) Viewed 8900 times

[dimon22_g]

Is it possible somewhere to find a list of all trains which are assigned particular color? I did not found it, but think that would be very useful.

[Renton]

Great Idea, this is certainly an issue that needs addressing.

I'm curious, why did you pick a colour-based solution? Did you consider giving trains a 'priority' setting and letting them decide for themselves whether or not to take the priority route, based on the train behind?

This could work by defining alternate routes as 'detours' with a marker at their entrance and exit, then letting the trains decide to take these 'detours' when a faster train of equal or higher priority approaches from behind.

This would solve the problem and save a lot of extra markers, plus the slower low priority trains would still take the priority route when there are no faster trains behind. Also, this way existing waypoints would still be useful for to re-directing traffic permanently, but wouldn't have to be used in excess.

It would of course be harder to program a train that can detect other approaching trains and make a decision based on speed and priority, and not being a programmer there are probably many issues I'm not aware of but I'd just like to know if you see an advantage with your system?

[blitzkrieg]

Hello,

When cloning a train, the train marker color is correctly duplicated.
But after, if you change the color marker of one of the trains, it's isn't duplicated to the others.

I think it's a issue with the color marker system, as all trains sharing orders should prefer the same path.

So I updated the patch to share marker color exactely the same way than shared order.
If you wan't to stop sharing the color, just stop sharing the orders

Here is a new release patch then.

Is the grf in 1st post updated to the latest version(1.06 i think) of this patch??
If not then can i request it to be updated???

[MagicBuzz]

i did not update the patch fix since i released this version.

rick now know how to fix it basing on mine, so he might fix it himself. keeping up to date two revisions of the same patch is useless i think.


for the grf itself, i'm not sure there is any need to update it.

[blitzkrieg]

i did not update the patch fix since i released this version.

rick now know how to fix it basing on mine, so he might fix it himself. keeping up to date two revisions of the same patch is useless i think.


for the grf itself, i'm not sure there is any need to update it.

Hi
I downloaded the grf from the first post & installed it into the data folder ,but i am neither getting routmarkers on train detail list nor able to see it in the grf list.
I don't know how to compile (i find it a little too complicated for me). Is it going to be merged into trunk??
If not then what options do i have to use this patch??

[Buran]

I have two questions about the usage of this patch:

1. What does the "grouping" feature in the vehicle list do, what is its purpose? And does it have anything to do with the RouteMarkers?

2. Is there a way to give a certain color to a specific group of trains, for example all the trains that arive at a specific station or so?

Thanks in advance!

[chrissicom]

I have two questions about the usage of this patch:

1. What does the "grouping" feature in the vehicle list do, what is its purpose? And does it have anything to do with the RouteMarkers?

2. Is there a way to give a certain color to a specific group of trains, for example all the trains that arive at a specific station or so?

Thanks in advance!

1. You can put vehicles into groups, it's not related to routemarkers but a feature in trunk.

2. You can clone trains with a routemarker colour and the colour will be cloned/copied as well, but there is no option to set a specific group of trains to use one colour with a single click.

If I am wrong correct me

[pavel1269]

Can anyone update this patch please? Since i cant update it to r11000 on my own and later, there are much more changes in the code. It worsk fine for r10641, but its outdated. Can anyone please?

[Emperor Jake]

Hello,
I would like to use this patch and other ones as well, but could someone please give me a link with instructions on how to install\use these patches.

[andrewas]

Installing a patch is a matter of reading the relevant sticky in this very forum. However, updating the patch to run on a more recent version of the code is another matter, you can sometimes just merge the patch in by hand if the source files have been edited to much for the patch to be applied automatically, but most of the time you need to rewrite the new code to work with the updated version.

[didomusicuk]

Maybe I'm missing something but I've just downloaded the GRF, put it in the /data folder, and it didn't load up. I'm using a nightly build.

[richk67]

Its a patch. You have to build the patch against trunk, and have the .grf in the data folder. It is not a newgrf, and doesnt load that way.

Also, given that there has been no development on this for over 9 months, I doubt it even compiles against trunk.

There is a reason some threads are left to die... because they are dead.