Patch: More conditonal orders (r15271)
Moderator: OpenTTD Developers
- cmoiromain
- Chief Executive
- Posts: 655
- Joined: 15 Jan 2007 21:45
- Location: FRANCE
- Contact:
Re: Patch: More conditonal orders (r14173)
very nice indeed! I particularly like the jump XX percent of the time function, which allows for split metro lines without having trains with different orders! Hope this makes it into trunk!
I am little, ugly, and nasty. How do you do?
Re: Patch: More conditonal orders (r14173)
Wouldn't it be appropriate to merge this patch with the "stop in depot order" patch? This patch is rather small and the two patches fit together perfectly, as the stop in depot order is only useful with conditional orders.
Re: Patch: More conditonal orders (r14173)
The patch needs a little update for late nightlies: convert _local_player to _local_company and it works fine.
Edit: There's also a small problem with SAVEGAME_VERSION, also easily solved.
Edit: There's also a small problem with SAVEGAME_VERSION, also easily solved.
Spanish translation of OpenTTD
Extended heightmaps
Have fun, don't quarrel too much and add as many advanced settings as you can.
Extended heightmaps
Have fun, don't quarrel too much and add as many advanced settings as you can.
Re: Patch: More conditonal orders (r14173)
Update to current trunk, no functional changes.
As Terkhen noted, savegame compatibility is broken due to trunk bumps. This version is compatible with trunk games, but unfortunately not with older games made with this patch applied.
Also attached is a combined patch file of this patch and the 'stop in depot' patch by PhilSophus. Note that this patch has not been tested at all, so use at own risk.
As Terkhen noted, savegame compatibility is broken due to trunk bumps. This version is compatible with trunk games, but unfortunately not with older games made with this patch applied.
Also attached is a combined patch file of this patch and the 'stop in depot' patch by PhilSophus. Note that this patch has not been tested at all, so use at own risk.
Create your own NewGRF? Check out this tutorial!
Re: Patch: More conditonal orders (r14497)
Thanks!
Spanish translation of OpenTTD
Extended heightmaps
Have fun, don't quarrel too much and add as many advanced settings as you can.
Extended heightmaps
Have fun, don't quarrel too much and add as many advanced settings as you can.
-
- Engineer
- Posts: 44
- Joined: 06 Sep 2008 12:41
- Location: Hamburg, Germany
Re: Patch: More conditonal orders (r14497)
Hi,
I tried myself in adding another conditional order. This is the first time I created a patch, so any suggestions are welcome .
I took the more_cond_orders+stop_in_depot-r14503.patch and added a conditional ordner that compares the amount of cargo at the Next station to the vehicles capacity multiplied by a percentage factor.
So if the conditional order is set to: "has more than 80 percent of vehicle's capacity" it only jumps if the amount of cargo at the next station exceeds 80 percent of the vehicles capacity.
But there is more. In order to avoid that if you start 10 trains with this order, that they all would execute the order list jump, even though there is only enough cargo for one of the trains, the patch checks if there are already trains with the same shared order list heading to this station right now and substracts their capacity from the available cargo at that station.
I added an example savegame to show what my intention was and to show that this should work
As mentioned above, any suggestions are welcome
Update: I uploaded the wrong save game. I added the right one now.
I tried myself in adding another conditional order. This is the first time I created a patch, so any suggestions are welcome .
I took the more_cond_orders+stop_in_depot-r14503.patch and added a conditional ordner that compares the amount of cargo at the Next station to the vehicles capacity multiplied by a percentage factor.
So if the conditional order is set to: "has more than 80 percent of vehicle's capacity" it only jumps if the amount of cargo at the next station exceeds 80 percent of the vehicles capacity.
But there is more. In order to avoid that if you start 10 trains with this order, that they all would execute the order list jump, even though there is only enough cargo for one of the trains, the patch checks if there are already trains with the same shared order list heading to this station right now and substracts their capacity from the available cargo at that station.
I added an example savegame to show what my intention was and to show that this should work
As mentioned above, any suggestions are welcome
Update: I uploaded the wrong save game. I added the right one now.
- Attachments
-
- even_more_cond_orders-r14565.patch
- (30.65 KiB) Downloaded 265 times
-
- Grinningworth Falls Transport, 17th Jun 1953.sav
- (17.34 KiB) Downloaded 241 times
Re: Patch: More conditonal orders (r14497)
I was just thinking about the original problem I suggested; where the decision is made too early.
Although the waypoint idea is a way around it, it's not perfect. (It's defiinately a good way to do it, and would usually work fine, but what if you use multiple conditionals?)
Eg
Order 1
If x goto order 2, otherwise goto order 3
-Order 2 or 3
If mill accepts coal, goto mill, otherwise goto power station
Your solution, which worked fine when this is the fork, doesn't work aswell if 2 and 3 are not in the same direction (eg the order 2 location is to the north, but the order 3 location is to the south)
I don't know if this is in any way feasable, so it's just a "what if?" rather than an "OMFG you should do it this way!"; but would it be possible to make the decision at the last place where the following orders could be reached?
Eg if there are several routes each to the mill and power station, then it follows a route which could lead to both for as long as possible, and makes the decision only at "the point of no return" so to speak... eg the last junction the power station could be reached from before getting to the mill?
Although the waypoint idea is a way around it, it's not perfect. (It's defiinately a good way to do it, and would usually work fine, but what if you use multiple conditionals?)
Eg
Order 1
If x goto order 2, otherwise goto order 3
-Order 2 or 3
If mill accepts coal, goto mill, otherwise goto power station
Your solution, which worked fine when this is the fork, doesn't work aswell if 2 and 3 are not in the same direction (eg the order 2 location is to the north, but the order 3 location is to the south)
I don't know if this is in any way feasable, so it's just a "what if?" rather than an "OMFG you should do it this way!"; but would it be possible to make the decision at the last place where the following orders could be reached?
Eg if there are several routes each to the mill and power station, then it follows a route which could lead to both for as long as possible, and makes the decision only at "the point of no return" so to speak... eg the last junction the power station could be reached from before getting to the mill?
Jon
-
- Engineer
- Posts: 44
- Joined: 06 Sep 2008 12:41
- Location: Hamburg, Germany
Re: Patch: More conditonal orders (r14497)
audigex wrote: Eg if there are several routes each to the mill and power station, then it follows a route which could lead to both for as long as possible, and makes the decision only at "the point of no return" so to speak... eg the last junction the power station could be reached from before getting to the mill?
I think for for this to work the order list must be deeply interwoven with the pathfinder, which is not wanted, since the order list has to work together with all the pathfinders in OpenTTD.
Besides that if you apply your problem to planes "the point of no return" is most likely direct at the starting airport, if both destinations are in different directions.
So if you want to delay that decision I think the only realistic solution is to do that manually by building waypoints and make the decision right after reaching it.
There aren't waypoints for planes yet?
Re: Patch: More conditonal orders (r14497)
True, but would it actually be a problem for planes to work in the same way? A slight performance hit at most - and I generally dislike waypoints within train tracks - they make for a very static way of working (and are no use for multi-track lines).
Most of my networks allow multiple routes between junctions, so if there's a problem on one track the others can route around it.
The wanting to keep it seperate from pathfinding makes sense though - it was just an idea
Most of my networks allow multiple routes between junctions, so if there's a problem on one track the others can route around it.
The wanting to keep it seperate from pathfinding makes sense though - it was just an idea
Jon
Re: Patch: More conditonal orders (r14497)
I noticed you patch for some (or no) reason disables the monorail wood carriage. Why do you do so?
-
- Chairman
- Posts: 776
- Joined: 20 Jan 2007 12:08
- Location: Germany
Re: Patch: More conditonal orders (r14497)
I haven't written this patch, but I doubt that it causes such an effect as it deals with completely different code. (If it did that would be a very strange bug, indeed).excel20 wrote:I noticed you patch for some (or no) reason disables the monorail wood carriage. Why do you do so?
Do you use any NewGRFs? If so, it's probably that.
"The bigger the island of our knowledge, the longer the shore of our ignorance" - John A. Wheeler, Physicist, 1911-2008
Re: Patch: More conditonal orders (r14497)
It's propably some of the patches from the dutch train setPhilSophus wrote:I haven't written this patch, but I doubt that it causes such an effect as it deals with completely different code. (If it did that would be a very strange bug, indeed).excel20 wrote:I noticed you patch for some (or no) reason disables the monorail wood carriage. Why do you do so?
Do you use any NewGRFs? If so, it's probably that.
Re: Patch: More conditonal orders (r14497)
The dutch train set is not a patch. And, unless there's some great huge inside joke going on, neither does it contain any patches.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: Patch: More conditonal orders (r14497)
A really usefull one for me would be
if train length <is greater than/Is less than> <X> jump
for when i have many trains with shared orders of various lengths and non even platforms in the stations
(i normally run PAX only using clestars patch)
if train length <is greater than/Is less than> <X> jump
for when i have many trains with shared orders of various lengths and non even platforms in the stations
(i normally run PAX only using clestars patch)
Re: Patch: More conditonal orders (r15271)
After all the recent changes this patch had become incompatible with trunk. I finally updated it. It compiles, it runs and it doesn't crash when using it, so I guess/hope it is without (new) bugs.
To download the patch, see the first post of the thread.
To download the patch, see the first post of the thread.
Create your own NewGRF? Check out this tutorial!
Re: Patch: More conditonal orders (r15271)
I
have a bug when compiling under linux with more_cond_orders+stop_in_depot-r14503.patch [39.82 ]
i tried to compile under Cygwin, it all went succesfull, but under linux i can't because of this error.
can anyone help fixing it ?
thx
have a bug when compiling under linux with more_cond_orders+stop_in_depot-r14503.patch [39.82 ]
Code: Select all
[SRC] Compiling order_gui.cpp
/srv/r14503/src/order_gui.cpp: In function 'void DrawOrderString(const Vehicle*, const Order*, int, int, bool, bool, int)':
/srv/r14503/src/order_gui.cpp:340: error: jump to case label
/srv/r14503/src/order_gui.cpp:295: error: crosses initialization of 'const OrderConditionVariable ocv'
/srv/r14503/src/order_gui.cpp: In constructor 'OrdersWindow::OrdersWindow(const WindowDesc*, const Vehicle*)':
/srv/r14503/src/order_gui.cpp:713: warning: unused variable '__ct_assert__'
make[1]: *** [order_gui.o] Erreur 1
make[1]: quittant le répertoire « /srv/r14503/objs/release »
make: *** [all] Erreur 2
can anyone help fixing it ?
thx
Re: Patch: More conditonal orders (r15271)
Fast guess from the patch file only: in the mentioned line 340 of order_gui, there should be "} break;" (without quotes). Try to change it to "break;" and then in the next line "}" and see if it helps.Chico008 wrote:I
have a bug when compiling under linux with more_cond_orders+stop_in_depot-r14503.patch [39.82 ]
i tried to compile under Cygwin, it all went succesfull, but under linux i can't because of this error.Code: Select all
[SRC] Compiling order_gui.cpp /srv/r14503/src/order_gui.cpp: In function 'void DrawOrderString(const Vehicle*, const Order*, int, int, bool, bool, int)': /srv/r14503/src/order_gui.cpp:340: error: jump to case label /srv/r14503/src/order_gui.cpp:295: error: crosses initialization of 'const OrderConditionVariable ocv' /srv/r14503/src/order_gui.cpp: In constructor 'OrdersWindow::OrdersWindow(const WindowDesc*, const Vehicle*)': /srv/r14503/src/order_gui.cpp:713: warning: unused variable '__ct_assert__' make[1]: *** [order_gui.o] Erreur 1 make[1]: quittant le répertoire « /srv/r14503/objs/release » make: *** [all] Erreur 2
can anyone help fixing it ?
thx
edit: actually it's two lines above, i.e. 338
edit2: ah, you're not working with the newest version... why don't you use that one? (r15271) It's at the bottom of the first post...
edit3: but it's the same thing for the both of them...
Last edited by Roujin on 25 Jan 2009 22:19, edited 2 times in total.
Re: Patch: More conditonal orders (r15271)
if i do so, the break command will be in the else
lines around are :
lines around are :
Code: Select all
case OT_CONDITIONAL:
...
if (timetable && order->wait_time > 0) {
SetDParam(6, STR_TIMETABLE_AND_TRAVEL_FOR);
SetTimetableParams(7, 8, order->wait_time);
} else {
SetDParam(6, STR_EMPTY);
} break;
default: NOT_REACHED();
Re: Patch: More conditonal orders (r15271)
it's ok, i managed to fix this
but i notice something in the game now
when i use the Transfer command, vehicule don't make virtual benefict anymore.
before the patch, when i use the transfer commande, for transfering cargo from truck to train for example, the truck have yellow moyen (virtual), but with the patch it's not the case.
but i notice something in the game now
when i use the Transfer command, vehicule don't make virtual benefict anymore.
before the patch, when i use the transfer commande, for transfering cargo from truck to train for example, the truck have yellow moyen (virtual), but with the patch it's not the case.
-
- Chief Executive
- Posts: 658
- Joined: 11 Nov 2007 12:06
- Contact:
Re: Patch: More conditonal orders (r15271) EDIT
updated to r 15913
Last edited by 2007Alain2007 on 03 Apr 2009 23:02, edited 2 times in total.
For Community Integrated Version http://code.google.com/p/civopenttd/
Who is online
Users browsing this forum: No registered users and 18 guests