Transport Tycoon Forums

And onother way to crash the patch...
When two station gui (train and road tested) are ovelapping,
selecting the bottom one will crash the game.

ChillCore wrote:And onother way to crash the patch...
When two station gui (train and road tested) are ovelapping,
selecting the bottom one will crash the game.

I concur. Selecting bottom station gui by clicking title bar does not crash, however selecting it by clicking within the bottom station gui widget I get a seg fault.

ChillCore wrote:And onother way to crash the patch...
When two station gui (train and road tested) are ovelapping,
selecting the bottom one will crash the game.

Fixed in git. Thanks for reporting. Actually it occured whenever you clicked in the cargo display at some place where there wasn't a cargo entry, no matter which windows were overlapping.

ftk wrote:On occasion I want to get quick positive cash flow and will create a coal route right off the bat. Create coal mine station, a little bit of track, create train, and set to full load any cargo. I start the train and have it load while I finish the rest of the line and build the power plant station. Next, I modify train orders to append the power station.

Once the train is done loading I get the crash. Savegame attached.

This way of playing invalidates the concept of freezing links while a vehicle is loading as I can't know which link to unfreeze after it has finished loading. Thanks for pointing this out. I'll have to think of some other solution for the problem of decreasing capacity while loading. However, I won't be able to do so in the next two weeks .

Hi fonso!

Thanks for your great work. I'm sure you can fix any remaining bugs and the links freeze design problem when you're back in 2 weeks! Really looking forward to it.

Well, no more bugs to report here - just wanted to say thanks.

Bug report:

Clicking Gossau-Zug station (or Meyrin, or Prilly) crashes the game.

I know fonso's currently away, but perhaps he'd like to have something to do when he gets back.

dose your patch work with Infrastructure Sharing will it know it can take some offer palyers train or bus then re join

will it link them togiver or not

here is a win 32 build and a bit of an update to this patch

Quick question for Alain.

Did you pull the git or did you just update the version i posted ?
I still can crash the game in the same way...

I cannot check myself as i do not have git stuff installed.
I did compare to the previous version and there are some changes that should not be there and were not there before. (eg. spaces, misalignment of for loop ...)

here is a win 32 build and a bit of an update to this patch

What excactly do you mean by a bit?
Would you mind sharing some details.

The only difference between last git commit and the diff in the first post is added check in station_gui.cpp.

i took of the frist post also has any one got this working with shared track

jub wrote: The only difference between last git commit and the diff in the first post is added check in station_gui.cpp.

Thank you jub.
Now i can test without crashing.
Having a small monitor i needed that fix.

Alain wrote: i took of the frist post also has any one got this working with shared track

Ok. I just wanted to know.



Now let's see if we can find some more todo for fonso.

moved post

friendly nudge:

Alain this is the cargodist thread.
Ask questions about patchpaks in your thread please.

/ end friendly nudge.

Nice patch, cargodest and autoseparate (which is really nice if you use passenger buslines, which in turn is great fun with cargodest) are two of the patches I'd like to have in trunk the most .

Bug: there are passengers generated for 'unknown station'. Busses do load them somehow. Savegames for different versions: http://home.casema.nl/van.bokhorst/1618 ... 0Alain.sav and http://home.casema.nl/van.bokhorst/1611 ... llcore.sav (4MB+).

Furthermore, a question about passenger generation. IMO from a gameplay perspective it should be rewarded to connect cities so you should usually make more money connecting them than if you only build some intra-city connections. In the current implementation it's rewarded mostly by my own motivation to make a nice network. Solution would be to give passengers predetermined destinations instead of only choosing available destinations. Your earlier reply to this was "You don't want to have cargo for every possible destination on the map piling up at some bus stop in a remote village.". Ofcourse that's true. In previous cargodest attempts (f.i. Prissi's), if I understood correctly, part of the generated passengers just chose a destination available just as in your patch and part wanted to go to a predetermined destination ánd if you didn't have a connection to that destination the passenger just wouldn't show up. So, it wasn't too hard to make a profit in the beginning as it would be in if this principe would be adhered to for all passengers (which I heard is in Simutrans), it was rewarded to connect more cities (as in more passengers) and there weren't any passengers piling up / showing up for destinations which weren't available.
Also, because of the nature of cargodest the capacity of transport has to be larger because travelled distance is bigger so a 'reduce passenger amount' switch as in other cargodest attempts would be nice but this is only a minor issue (because it's also a challenge) and could also be achieved by a cargodest.grf which lowers passenger production so not including it in the patch would probably be preferable.
And the last question, TrueBrain offered to automagically compile your source. Is this already the case? This would make it easier for me and other people to test your patch .

Your patch has a lot of potential, so.. good luck!

If you connect more towns, and add more links to your network, you get a double positive effect: you get more passengers, and the passengers travel further. The only negative effect is that some long-range passengers would decide to take shorter trips if you add a halfway station at a small town. I don't think this effect measures up to both positive effects. So unless you go to the extreme of not creating a network at all, and just build seperate lines that go all the way across the map (in which case any station added would lead to your passengers taking shorter trips and thus decreasing profit, possibly off-setting the extra passenger-effect), adding stops to your network does increase your profit.

I haven't tested this hypothesis of course, but this is my intuition. Moreover, anyone who's going to use this patch will want to build networks.

You're probably right but it still seems strange to have the same amount of passengers when only building an intra-city network as when you connect it to the rest of the map .

:S

That's not true. Cities have limits to how many passengers they can have y'know.

about "unknown station": This is normal. As long as there are no routes for the cargo in question it is traditionally routed and thus goes to some "unknown station". The link graph is only recalculated in finite intervals so you can't avoid getting some traditionally routed cargo in some places, especially on new routes. I will change the text in the GUI to something like "unrouted".

about cargo generation based on destinations available: This is an advanced application of the link graph. You could easily add another handler to the link graph, evaluate the available destinations and then set some supply modifier for each station on Join(). For example you could count the accepting nodes in the component and generate more passengers for larger components and less passengers for smaller ones. This should have the same effect as Prissi's implementation. However I don't do this as part of cargodist as it is not critical for a working cargo distribution system.

fonso wrote:about cargo generation based on destinations available: This is an advanced application of the link graph. You could easily add another handler to the link graph, evaluate the available destinations and then set some supply modifier for each station on Join(). For example you could count the accepting nodes in the component and generate more passengers for larger components and less passengers for smaller ones. This should have the same effect as Prissi's implementation. However I don't do this as part of cargodist as it is not critical for a working cargo distribution system.

It's true it's not part of cargo destinations in technical terms, and getting the basics working reliably first is much more important, but it is very important for 'realistic' gameplay. Also the implementation will have to be specific to a particular cargo destinations patch, so it can't be completely independent.

Having thought about it, I'd personally go for doing it via station ratings (basically - more available destinations = higher rating).

The new overviews of passenger flows at a station in the Station GUI - which look wonderful, by the way - seem not to be sticky. It might be nice to either make a patch setting for the preferred view (in my case, Via-Destination-Source, but of course others will prefer other views) or (in addition?) a station-by-station stickiness.

Also, the patch settings for cargodist are still under 'link graph', aren't they? That seems slightly inappropriate; having 'cargo distribution' under 'vehicles', 'stations' or a 'routing' category sounds more suitable.