Transport Tycoon Forums

Seems to be a common problem, I had it too. Wonder where it originates from...

And I thought it was just my crap rail-building skills

it's a remnant from config files of very old YAPP versions, where the setting had a different value range (and default value). so all people who played with the YAPP patch before it was merged to trunk are potentially vulnerable to this problem.

_________________
You might not exactly be interested in Ferion, but if you are, have fun

I've seen a few problems, even though I renewed my config file after YAPP made trunk.

Edit: station penalty was 800, as it should be. I'll try to see if I can reproduce my problems. It might just be that my network is a mess...

crashed when i tried to view transport routes in scenario editor. Nothing placed, just after loading a heightmap. Sorry for no decent bugreport.

Given that it happened after you tried to load a heightmap, have you tried to open that again and see if you can reproduce the crash? If you can reproduce it, upload that heightmap togeather with an instruction.

Edit: Also make sure to include what version of cargodest you use and if you use any form of patch-pack or you've used a vanilla cargodest.

_________________
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)

To make a more decent report of it: The minimal reproducing steps are just starting the scenario editor (no need to open or generate anything, just keep the empty plane) and opening the transport routes view. It then triggers the following assertion:

openttd: cargodest/src/ai/../oldpool.h:125: T* OldMemoryPool<T>::Get(uint) const [with T = Player]:
Assertion `index < this->GetSize()' failed.

cargodest hg revision: ac3014e37a77

_________________
"The bigger the island of our knowledge, the longer the shore of our ignorance" - John A. Wheeler, Physicist, 1911-2008

I don't know how to reproduce. Isn't the network button disabled in the scenario editor?

Celestar

No, it wasn't for me. I just re-checked with f300dd89df75.

Strange, I just retried with an empty openttd.cfg and than the button is disabled.

Please try to reproduce with the attached openttd.cfg, there the button is not disabled for me.

_________________
"The bigger the island of our knowledge, the longer the shore of our ignorance" - John A. Wheeler, Physicist, 1911-2008

Fixed

Celestar

i'd still vote for a second button showing the cargo netweork by vehicle type [possibly remembering the cargo filter]

the current number of buttons in the map window is... odd...

_________________
You might not exactly be interested in Ferion, but if you are, have fun

Celestar, I'm just adopting the order list rewrite for the cargodest branch and have a question about code in CmdInsertOrder starting at order_cmd.cpp:619:

if (order == NULL && GetVehicleOrder(v, sel_ord) != NULL) {
   /* There is no previous item, so we are altering v->orders itself
       But because the orders can be shared, we copy the info over
       the v->orders, so we don't have to change the pointers of
       all vehicles */
   uint32 mask = v->GetCargoForSharedVehicles();

   RoutingBase_t::ProcessOrder(&RoutingBase_t::ProcessOrderListRemoval, v->orders, v->type, mask);

   SwapOrders(v->orders, new_o);
   /* Now update the next pointers */
   v->orders->next = new_o;
   new_o->prev = v->orders;
   if (new_o->next != NULL) new_o->next->prev = new_o;

   RoutingBase_t::ProcessOrder(&RoutingBase_t::ProcessNewOrderList, v->orders, v->type, mask);
} else if (order == NULL) {
   /* 'sel' is a non-existing order, add him to the end */
   order = GetLastVehicleOrder(v);
   order->next = new_o;
   new_o->prev = order;

   uint32 mask = v->GetCargoForSharedVehicles();

   RoutingBase_t::ProcessOrder(&RoutingBase_t::ProcessOrderInsertion, new_o, v->type, mask);
} else {
   /* Put the new order in between */
   new_o->next = order->next;
   if (order->next != NULL) new_o->next->prev = new_o;

   order->next = new_o;
   new_o->prev = order;

   uint32 mask = v->GetCargoForSharedVehicles();

   RoutingBase_t::ProcessOrder(&RoutingBase_t::ProcessOrderInsertion, new_o, v->type, mask);
}

In the first case you use a pair of the following:

RoutingBase_t::ProcessOrder(&RoutingBase_t::ProcessOrderListRemoval, v->orders, v->type, mask);
RoutingBase_t::ProcessOrder(&RoutingBase_t::ProcessNewOrderList, v->orders, v->type, mask);

In the other cases you use only that:

RoutingBase_t::ProcessOrder(&RoutingBase_t::ProcessOrderInsertion, new_o, v->type, mask);

Due to my patch the swapping is no longer necessary, so can I just use RoutingBase_t::ProcessOrderInsertion? I don't even understand why the removing/re-adding the full list is needed in your original code. The swapping is just a way to insert a new order at the list head without changing the address of the head.

Do I run into trouble somewhere (maybe caching?) if the address of the first order of the chain changes? If so, I would try to replace references to the first order by references to OrderList.

Thanks in advance for your help.

_________________
"The bigger the island of our knowledge, the longer the shore of our ignorance" - John A. Wheeler, Physicist, 1911-2008

I did the removal/adding of the whole new order list just because it is easier than messing around with individual orders. The problem is that each edge in the routing network has an identified that associates the edge with the order by the order index. However swapping the order also modifies the indices of the swapped orders (evil!). Thus I either have to find the correct edge and change its ID or just remove the whole order list and add it. No matter what, all the caches have to be recomputed anyway, so the performance difference is basically zero.

Celestar

Okay, so since I don't swap and thus no order changes its index I can go the straight way of processing only the added/removed order itself, right?

_________________
"The bigger the island of our knowledge, the longer the shore of our ignorance" - John A. Wheeler, Physicist, 1911-2008

I stopped playing openttd a while ago, figured I'd have a break until something like this was properly implemented, and checking up on it I just found this thread, so I have a few questions.

Does this work properly in multiplayer?
How stable is it?
Is there any timetable for getting this code into svn?

This is such an extremely important feature for me, pax just isn't interesting without it, so keep up the great work

Although I have never tested multiplayer myself, the wiki article which is linked in the first post of this threads claims that cargodest is network-safe. I believe this is in contrast to previous pax implementations.



When using cargodest, I did encounter at least one bug. However, these bugs have now been fixed. Therefore, I would say it is rather stable, although there may be a few minor issues remaining.



None that I am aware of. As far as I know, the developers of cargodest want to first add quite a few new features to it, before they consider it ready for inclusion into trunk.


By the way, in case you are looking for a Win32 binary to test it yourself, you may want to try my binary, which uses the latest cargodest and realistic timetables patch. However, this binary may not be as stable as cargodest by itself, as the realistic timetable patch has had quite a few problems recently, although all known issues have now been fixed.

Brilliant, tested it in a local game now and it's great, I will defenatly not play openttd again without it.

On a side note, I think enabling this for passengers + mail by default would be a good thing.

no, the plan, as i could follow, is to merge the current status relatively soon into trunk, before adding new features to it.

_________________
You might not exactly be interested in Ferion, but if you are, have fun

That's what I understood, too. Seems that it may soon pay out that I maintain a cargodest branch of my patch

_________________
"The bigger the island of our knowledge, the longer the shore of our ignorance" - John A. Wheeler, Physicist, 1911-2008

I'd like to put the current implementation into trunk before adding new features to it. However, I've already done a bit of work on extended features. But when playing with cargodest (especially with PAX), you'll notice that you need a load of RVs, thus fixing the multistop for DTRS will have a higher priority.

Celestar