[patch] Programmable waypoints

[Yexo]

This particular case could be solved with the option "next order", couldn't it?

But different penalties for differen't groups would be wonderful, anyway

Yep: one waypoint one the route all trains want to take and a panelty for those trains that should take the other route. But I'll implement it anyway.

[octernion]

I'm still pretty sure that it shouldn't be just waypoints that are programmable- signals should be as well.

For a useful resource of what is programmable in TTDPatch (I think?), check out this site: http://uwe.s2000.ws/ttdx/signal/restric ... hp?lang=en; it has a comprehensive list of routing criteria.

I think that 'Signal status' is an incredibly useful one, myself.

[Yexo]

Updated the patch again. See first post for details.

[T-Unit]

@ Octernion: Yexo has said that it is likely that he is going to work on making signals programmable. Also someone else is working on their own version of the patch.

[octernion]

@ Octernion: Yexo has said that it is likely that he is going to work on making signals programmable. Also someone else is working on their own version of the patch.

Oh, awesome. I'll check out the updated version of the patch and see if I can break it!

Edit: aw, it won't compile on mac os x... it dies when linking, complaining about a slew of undefined symbols related to the commands you added (like CmdCreateRule, etc.). If you want more debug information, or if I'm doing something very stupid, let me know

[Yexo]

@ Octernion: Yexo has said that it is likely that he is going to work on making signals programmable. Also someone else is working on their own version of the patch.

Oh, awesome. I'll check out the updated version of the patch and see if I can break it!

Edit: aw, it won't compile on mac os x... it dies when linking, complaining about a slew of undefined symbols related to the commands you added (like CmdCreateRule, etc.). If you want more debug information, or if I'm doing something very stupid, let me know

Did you run ./configure prior to running make? My patch adds two files (progsignals.h and progsignals.cpp) and if you don't configure these won't be compiled. If you did run ./configure or still getting errors can you please post the exact error message here? I don't have a mac myself, so testing it is difficult.

[octernion]

Did you run ./configure prior to running make? My patch adds two files (progsignals.h and progsignals.cpp) and if you don't configure these won't be compiled. If you did run ./configure or still getting errors can you please post the exact error message here? I don't have a mac myself, so testing it is difficult.

I was pretty sure I ran configure, but I re-did it just to make sure, and I get the same error- it isn't actually building progsignal.cpp. For building, I checked out a fresh version of 11814, did a svn revert and cleanup just to make sure, did a ./configure and make. Since no one else is having problems, I assume I'm doing something silly, but I have gotten patches to work in exactly this fashion before, so it must be something new and exciting that I am doing stupidly.

The error message is boring (linking fails obviously as the symbols don't exist in the object files since it wasn't compiled...), but here it is:

Code: Select all

[SRC] Linking openttd
Undefined symbols:
  "CmdCreateRule(unsigned int, unsigned int, unsigned int, unsigned int)", referenced from:
      __command_proc_table in command.o
  "__RuleSet_pool", referenced from:
      __RuleSet_pool$non_lazy_ptr in train_cmd.o
      __RuleSet_pool$non_lazy_ptr in waypoint.o
      __RuleSet_pool$non_lazy_ptr in yapf_rail.o
  "ShowRulesWindow(Waypoint const*)", referenced from:
      ShowRenameWaypointWindow(Waypoint const*)in main_gui.o
  "CmdRemoveRule(unsigned int, unsigned int, unsigned int, unsigned int)", referenced from:
      __command_proc_table in command.o
  "CmdChangeRule(unsigned int, unsigned int, unsigned int, unsigned int)", referenced from:
      __command_proc_table in command.o
  "CmdChangeRuleData(unsigned int, unsigned int, unsigned int, unsigned int)", referenced from:
      __command_proc_table in command.o
  "InitializeRuleSets()", referenced from:
      InitializeGame(int, unsigned int, unsigned int)in misc.o
  "__ruleset_chunk_handlers", referenced from:
      __chunk_handlers in saveload.o
  "CmdCopyRuleSet(unsigned int, unsigned int, unsigned int, unsigned int)", referenced from:
      __command_proc_table in command.o
  "CmdChangeRuleSetPenalty(unsigned int, unsigned int, unsigned int, unsigned int)", referenced from:
      __command_proc_table in command.o
ld: symbol(s) not found

Edit: I noticed the patch doesn't change source.list... is it supposed to?
Edit edit: I changed source.list to have progsignal.cpp, and it compiled fine, hooray.

[Yexo]

Edit: I noticed the patch doesn't change source.list... is it supposed to?

It is supposed to do that, and when I checked, I saw you were right. For some reason, svn diff doesn't take source.list into account unless specially told so.

Anyway, v0.6 is out! It's now possible to make rules based on the group a vehicle is in and based on the current order a vehicle has. I've added the changes to source.list to this patch, so just update to 11834 and apply the new patch.

[Rubidium]

For some reason, svn diff doesn't take source.list into account unless specially told so.

It normally does take source.list into account; at least when I am using svn diff.

[Yexo]

For some reason, svn diff doesn't take source.list into account unless specially told so.

It normally does take source.list into account; at least when I am using svn diff.

I know it should, but how can this happen?

Code: Select all

~/openttd/progwaypoints$ svn diff source.list 
Index: source.list
===================================================================
--- source.list (revision 11834)
+++ source.list (working copy)
@@ -1,4 +1,5 @@
 # Source Files
+progsignal.cpp
 airport.cpp
 articulated_vehicles.cpp
 autoreplace_cmd.cpp
@@ -99,6 +100,7 @@
 window.cpp
 
 # Header Files
+progsignal.h
 aircraft.h
 airport.h
 airport_movement.h
thijs@s070411:~/openttd/progwaypoints$ svn diff | grep source.list
svn: Expected 'bin/data' to be a directory but found a file
thijs@s070411:~/openttd/progwaypoints$ 

[glx]

you replaced the bin/data dir

[Yexo]

you replaced the bin/data dir

I know I did, but that wasn't the point. The diff is created anyway, but source.list is clearly not in the output.

[DaleStan]

you replaced the bin/data dir

And svn, therefore, gets confused, and bails.

When things appear on stderr, the program very likely did not finish its task successfully.

[Yexo]

you replaced the bin/data dir

And svn, therefore, gets confused, and bails.

When things appear on stderr, the program very likely did not finish its task successfully.

Even if I put the original data dir back (I have to do that every time I want to update) I don't get any output from grep. The error message from svn disappears then, but still no output.

[Forked]

Most excellent idea

It compiles just fine under linux (kubuntu, x64) .. however in windows it fails both with BuildOTTD and VS C++ 2008 express. Logs are attached in case anyone can make any sense of whats borked on my system

[Yexo]

Most excellent idea

It compiles just fine under linux (kubuntu, x64) .. however in windows it fails both with BuildOTTD and VS C++ 2008 express. Logs are attached in case anyone can make any sense of whats borked on my system

Thx, I develop under linux myself, and don't test it under windows. With these logs however, it's easy to fix.

[Forked]

Thx, I develop under linux myself, and don't test it under windows. With these logs however, it's easy to fix.

sweet. I play under linux but I compile it in xp (vmware) for friends that use windows

thanks

[Yexo]

Thx, I develop under linux myself, and don't test it under windows. With these logs however, it's easy to fix.

sweet. I play under linux but I compile it in xp (vmware) for friends that use windows

thanks

I updated the start post to contain the new patch. It is fully compatible with v0.6, so you don't have to recompile under linux to play with them.

[SquireJames]

Could someone compile the latest version of ChrisIn with this patch for me? I have tried myself with BuildOTTD (I also have Tortoise) but it just fails at several hunks and never outputs anything.

[Bilbo]

Latest chrisin is for release 11355, which is few months old. So you won't be able to compile current trunk with chrisIN patch without heavy modifications to the patch, as too many things have changed in the meantime. This patch is for 11834 (quite recent version), so combining these two would be probabbly very hard work.