Transport Tycoon Forums

Savegame is attached. The route in question runs from Findinghattan Ridge Wells => Frabourne Terminal => Bardston => Trindinghead Refinery.

All the GRFs should be on bananas or in the OTTDCoop pack.

eyeMWing wrote: Savegame is attached. The route in question runs from Findinghattan Ridge Wells => Frabourne Terminal => Bardston => Trindinghead Refinery.

I see the problem but I do not yet know where it comes from ...

Might be the fact that the ship from company 1 transfers to the harbour of company 2.
I think it is caused by IS being unfinished in that area but untill tested and confirmed I dare not say so ... I'll need too dig the code to see what happens, or rather does not happen, might take me a while ...




I am almost done with the next version, putting back the selectable owner view in the smallmap_gui, but I am having some problems with undefined string showing up in te owner view.
The game does not crash (anymore) and toggling works as expected. It is just some visual stuff that remains to be solved (-> merged correctly), the company names are drawn corectly under the undefined strings. See attachment.

it's technically not a bug, but a missing feature.

the only way it can occur in trunk is if cargo is being routed through oil rigs, so it is such a marginal case that it's not deemed worth fixing. infrastructure sharing then fails to implement it.

the problem is the way which it should be implemented. every cargo packet needs not only remember the transfer credit, but must provide a mapping to remember transfer credit for each company, i.e. every cargo package needs 16 times the current memory in a naive implementation.

Well, at first instinct the easy solution would just be to transfer the feeder income from the company receiving the packet to the company that brought the packet so far, on transfer of the packet between the companies' vehicles/stations/whatever. The company receiving the packet can then "reclaim" this as part of the acceptance income.
The issue would then be if that was easily abusable.

I figured it was a missing feature.

I did a source dig myself to see what was going on and have a general outline of a solution. This can also be easily extended for more equitable sharing between transfer legs, and more accurate per-vehicle profit tracking.

Come to think of it, this is probably a candidate for a new patch and sounds increasingly like that excuse I've been looking for to get some practical C++ experience.

Eddi wrote: it's technically not a bug, but a missing feature.

Ah I see. No much point in digging the patchpack code then.

the only way it can occur in trunk is if cargo is being routed through oil rigs, so it is such a marginal case that it's not deemed worth fixing. infrastructure sharing then fails to implement it.

With IS it goes for all station so the problem is bigger.

CargoDist does not seem to mind IS as it is station based. When a vehicle stops at a station CargoDist will route the cargo towards possible destinations based on vehicle orders. When looking at the station gui, while testing a bit, the source was company 1's station, the destination company 2's station, transfer station was in the middle of nowhere. Passengers were routed as expected from town A to town B. Nothing to fix there, lucky me.
The only "problem" I saw is that the linkgraphs are drawn on a company base -> when playing with company 1 you do not see the part of the other company. It would be nice, but not needed per se, if I could find where I can enable drawing linkgrahs for all companies at the same time if IS is on.

IS is nowhere near ready for trunk but CargoDist seems to be getting there piece by piece judging from recent commits ... as the behaviour also shows with oilrigs in clean trunk a solution may have to be found at some point (*)?

(*) Hopefully soon. Go go fonso!

the problem is the way which it should be implemented. every cargo packet needs not only remember the transfer credit, but must provide a mapping to remember transfer credit for each company, i.e. every cargo package needs 16 times the current memory in a naive implementation.

Hmm memory usage might become too much if 16 times more yes.

How about:
If cargo is transfered to a station that does not belong to the own company (using IS or transfering passengers to an oilrig in clean trunk) do the payment as if it was a final payment but still transfer the goods while adding this final payment to the transfer share amount. Then company 2 can pick them up and gets the payment as normal when delivered to the final destination or the process can be repeated if transfered to a third company.

JGR wrote: Well, at first instinct the easy solution would just be to transfer the feeder income from the company receiving the packet to the company that brought the packet so far, on transfer of the packet between the companies' vehicles/stations/whatever. The company receiving the packet can then "reclaim" this as part of the acceptance income.
The issue would then be if that was easily abusable.

I think that it could be abused, yes.
eg. Final payment being negative when transfer share was too high.
If company 1 sets the transfer share in such a way that he gets overpaid for his trip he earns too much while company 2 loses money. With only one company in the game it is not a problem that the last vehicle loses money as payment goes to the same account anyway.

eyeMWing wrote: I did a source dig myself to see what was going on and have a general outline of a solution. This can also be easily extended for more equitable sharing between transfer legs, and more accurate per-vehicle profit tracking.

Come to think of it, this is probably a candidate for a new patch and sounds increasingly like that excuse I've been looking for to get some practical C++ experience.

If you want to have a go at writing a patch for trunk.
There is the case with the oilrigs. Company 1 can transfer cargo to them and company 2 can pick them up from there.
It is the only case in trunk where there is a usable station that does not belong to a company. (Not counting GRFs that include a station tile)
I have not yet tested this in clean trunk myself to see what happens to the transfer money but judging from Eddi's reply it is the same.

Good luck and have fun.
Looking forward to read about what exactly you have in mind.

Hi,

first: Thank you for your work, really nice patch.

But, i have a problem with the departure boards and the timetables. As you can see on the pictures, the time isn´t displayed in the right way. I´ve tried to use other settings, but there is no difference. I´m using the binary which was uploaded a few days ago (page51), but the problem is equal to other versions of your patch.

Maybe you can help me.

Hey chester00,

Addi in the German forum has a solution for this. Look here.

Seems to be the original TTD font that causes this problem. Try OpenGFX or accept Addis offer to release the GRF which fixes the problem.

Dwight_K._Schrute wrote:Hey chester00,

Addi in the German forum has a solution for this. Look here.

Seems to be the original TTD font that causes this problem. Try OpenGFX or accept Addis offer to release the GRF which fixes the problem.

Thx.

Hi all,

any new win32 build?

ZecK wrote:Hi all,
any new win32 build?

Here you are

Compiled using this tutorial.
If game cannot find OpenGFX library, it could be downloaded from here.

PLEASE REPORT ALL BUG TO THIS AND ONLY THIS FORUM !

Update:
new version 11_9_5 added. Play and enjoy
To ChillCore, no more patches tonight!

To Muzzly: Thank you

Hello,

r21900 seems like a nice round number for an update.
Below are a few of the changes that I have made (There are a lot more but none that you would notice while playing).

- I finally managed to get the selectable owner view back in the patchpack without undefined strings.
Note that while doing so I have messed up the legend height resizing according to smallmap witdh somewhere. First there were glitches as the legend height overflowed the legend window.
I will try and fix this in one of the later versions, at least the smallmap is functional again without losing features.

- Also someone requested to have the different railtypes back in the smallmap.
I agree with Eddi that in the stuck signals (highjacked routes) view the different railtypes and the stuck signals at the same time is a bit to much.
For the moment you can see them in the link stats view when disabling the heightmap (I fixed it there already) and I might introduce them back in the routes view by means of a (¿heightmap?) switch.

- As an experiment I have enabled the links in the linkstat view for al companies. I hope this does not crash ... It did not when I tested.
I will be making a swith for this later on. What I have in mind is a setting with three options ¿in Advanced Settings?. -> "Show linkstats for all companies: Never / Always / Only with IS." Opinions anyone?

- Removed the copypaste patch from the scenario editor toolbar as it does not work there anyway.



Next thing to do is update the code further to trunk and update CargoDist, the smallmap code is dangling somewhere between r21666, my own changes and current version, fuctionallity of the rest is still at r21666. First I am having a little break, it has been an interesting week to say the least.


Enjoy.

ps:
Sorry Muzzly. I was checking my changes and typing while you posted.

Thanks, Muzzly!

BTW, it helps if you extract the individual folders to your Chill's Patchpack installation and not just extract the whole archive. Too cold- brain not working. . .

ZecK wrote:To Muzzly: Thank you

Im not sure if this is a patchpack bug or a trunk bug, but take a look at this save. Train 155 wont find a proper way to go to its destination, but if the signal that is pointed out is converted to a normal block signal, then the train routes correctly.
The train do not belong to that station, and have gotten there because it were lost somehow (probably during upgraing to a second ring).

Please check it out, or if its not part of the patchpack, then i need to handle it over to the 'devs

ChillCore wrote:- As an experiment I have enabled the links in the linkstat view for al companies. I hope this does not crash ... It did not when I tested.
I will be making a swith for this later on. What I have in mind is a setting with three options ¿in Advanced Settings?. -> "Show linkstats for all companies: Never / Always / Only with IS." Opinions anyone?

Not terribly useful at the moment, but I'm working on that. A patch against trunk isn't looking likely at the moment - I'd have to reimplement most of Cargodist's changes to cargopacket handling - so I may as well just patch against cargodist.

An option on the map screen itself to show just your company's links, versus everybody's (or hell, a specific company's) would be helpful in keeping clutter down.

ChillCore, do you know that game crashes by generating heightmap with smaller dimension as they made for ?

DJ Neckid wrote: Im not sure if this is a patchpack bug or a trunk bug, but take a look at this save. Train 155 wont find a proper way to go to its destination, but if the signal that is pointed out is converted to a normal block signal, then the train routes correctly.
The train do not belong to that station, and have gotten there because it were lost somehow (probably during upgraing to a second ring).

Please check it out, or if its not part of the patchpack, then i need to handle it over to the 'devs

Fixed in r21815 by rubidium. See FS#3908 for more info on the cause.

You have two options to fix it, either play with a newer version of the patchpack or go to Advanced Settings -> Vehicles -> Routing and set "Back of one-way PBS is safe waiting point" to off. (That bugsie is the reason for the switch being there.)
Technically I could ditch the switch as the back of a one-way pbs signal now receives a penalty, but personally I prefer if trains do not go there at all under any circomstances so I am keeping it. (On is behave like trunk.)

Please next time tell me what version you are playing with DJ. It would help a lot in finding bugs as I had to try a few earlier versions to see the bad behaviour in your savegame and see if the switch helped in this case.
Good thing that I have a somewhat decent memory and read all commits.

eyeMWing wrote:

ChillCore wrote: - As an experiment I have enabled the links in the linkstat view for al companies. I hope this does not crash ... It did not when I tested.
I will be making a swith for this later on. What I have in mind is a setting with three options ¿in Advanced Settings?. -> "Show linkstats for all companies: Never / Always / Only with IS." Opinions anyone?

Not terribly useful at the moment, but I'm working on that. A patch against trunk isn't looking likely at the moment - I'd have to reimplement most of Cargodist's changes to cargopacket handling - so I may as well just patch against cargodist.

An option on the map screen itself to show just your company's links, versus everybody's (or hell, a specific company's) would be helpful in keeping clutter down.

I agree that showing all companies at all times may be too much. For the moment I have enabled all to see if it was possible and does not cause crashes.
Maybe the "future" switch could be better located in the smallmap gui itself but if there are switches for choosing individal companies in that legend as well it may become too cluttered IMHO, especially when using FIRS or the ECS vectors.

Also note that the smallmap linkstats in the patchpack are not the same as what is in the "official" cargodist patch. I am still using an older version that I liked better.

Muzzly wrote: ChillCore, do you know that game crashes by generating heightmap with smaller dimension as they made for ?

Yes I know, More height levels bug.
In trunk there is a warning that does not show in the patchpack. (It does show in the scenario editor.)
As a general rule only resize heightmaps by a factor of two in either direction.


Thank you for reporting and the feedback.

ChillCore wrote:Please next time tell me what version you are playing with DJ. It would help a lot in finding bugs as I had to try a few earlier versions to see the bad behaviour in your savegame and see if the switch helped in this case.

Uuuuuuuuuups, my bad! I should really know better, but iirc was it in the middle of the night, and i also probably thought the version were noticable in the screenshot (OpenTTD r21xxxM in the titlebar you know). But thanx Also, at the time i started that game 11.5 were the only binary that were built.

DJ Neckid wrote:

ChillCore wrote:Please next time tell me what version you are playing with DJ. It would help a lot in finding bugs as I had to try a few earlier versions to see the bad behaviour in your savegame and see if the switch helped in this case.

Uuuuuuuuuups, my bad! I should really know better, but iirc was it in the middle of the night, and i also probably thought the version were noticable in the screenshot (OpenTTD r21xxxM in the titlebar you know). But thanx

When I take screenshots the titlebar (and version string) is not included ...
I could have checked the gamelog for the version number but I did not think of doing that at the time ... I keep forgetting that there is a console where I can see the gamelog.

DJ Neckid wrote: Also, at the time i started that game 11.5 were the only binary that were built.

I can not know what you are playing with from the version number alone unfortunately: downloaded binary, selfcompiled not modified, selfcompiled and bumped, selfcompiled with extra modification?


Since you prefer playing OpenTTD over sleeping, I forgive you.