The International Simutrans Forum

As to the p****enger numbers, I am in the process of investigating that in detail myself. The system for generating p****engers has changed considerably in Experimental compared to Standard, and is now more subtle and sophisticated. I am currently experimenting with greatly reducing the proportion of "factory_pax" (from 33 to 15) and of "tourist_pax" (from 16 to , boosting the "p****enger_factor" to 20 (from 14 in Pak128.Britain-Ex 0.6) and reducing the "p****enger_routing_local_chance" from 40 to 37 and setting the "p****enger_routing_midrange_chance" to 36. I shall report back with my findings as to what constitute optimum settings. If anyone else has anything to contribute in that regard, I should be most grateful :-)

Hmm. That analysis only makes sense if and in so far as those numbers are indeed realistic relative costs of bridges to ordinary ways. If not, there is insufficient incentive to avoid bridges.

James wrote in another thread:

"In relation to an earlier suggestion about the ratio of production and consumption of farms and shops: whilst there is much to be said for lowering considerably the consumption of shops and increasing their distributionweight, care should be taken not to increase the production of farms too greatly, or else each farm will require a far more substantial transport link than would in reality be required. The idea, for example, that a single farm deserves a railway line all to itself is absurd, and the industries should be balanced with this in mind."

How about, for now, we just reset all the running costs to a flat number like $1.00 for all vehicles?
Or maybe halve the running costs?

D'oh.  Would you like to propose some sensible values instead?

all road vehicles shouldn't stop on railroad crossings, not only private ones.

- I've also fiddled around with river costs so smaller rivers aren't very expensive to delete, which means it isn't more expensive to upgrade rivers to canals than building new canals.

I have that same problem with official 8.2.
I think james suggested it might be a problem with the standard nightly experimental was compiled from.

By 'reverse' being separated, I mean if my convoy consists of:
Engine-Tender-dining-coach-coach-TPO-mail-mail-brake
I'll make a batch 2 or more of these to run on different lines.

When the train turns around at the end of the line, it'll now have:
Engine-Tender-brake-mail-mail-TPO-coach-coach-dining

When I go to replace the convoy through the replace function, if some convoys are facing in the 'reverse' direction, I will only get to replace convoys facing the same direction, as the 'replace all or 'replace all in line' function will treat the forward facing and reverse facing convoys as two different convoy consists.

seems like neroden fixed it already. That was quick  

Some remarks:
gui_coord is not a good choice, since it is rather drawing coordinates, draw_koord. (To indicate close relationship to koord, but this can be done by search and replace easily ... ). As such they should not reside in gui/ but maybe in dataobj.cc;

also all routines in simding.cc (and also other dings) simview.cc and all other drawing stuff should use those coordinates then too.

That the offset is not an sint16 might be a problem with some scrollbars. Did you test this with very large savegames?

For road vehicles "replace all" and "replace all in line" works fine for me.

I run mixed consists in all my road and train pax/mail lines.

One thing I've realized is that when the convoy, train, is in 'reverse' the consist is also reversed after the engine(s) and the 'replace' function will separate the two, despite being part of the same batch.

For road vehicles "replace all" and "replace all in line" works fine for me.

I frequently do... especially in the early early years when there f ex is no sensible road transport for both pax and mail (yes I do mail runs early on too...) and where my routes are set up for both pax and mail (to be able to use them later on as well...). I would not like my mail carriages to be upgraded to gardenseats once these are available...

The problem is, that current dialoge were not made with larger screens (and fonts) in mind. When renovating the screen coordinate system, It would make sense that dialogues would use a font relative system of displaying. (This might not affect your patch, but should kept in mind.)

zeichnen->display => why not, for dings_t it is already display. That is one easy search and replace.

About what functions you are thinking? The mapping of to_display_coords( koord3d pos, koord offset_in_tile ) ?

Hmm, I have been trying to test commenting out the part checking for like convoys, but it seems that the entire dialogue is broken: none of the buttons that are unique to the replacer dialogue work... :-(

I saw no harm in min, but I have also no aversions against your code. What is the problem with min?

Since all those stettings are pretty much independent, I did it this way (to show that this is only needed to climate_stats). I intended it to do it this way also for forest and citystats. You give a valid argument, and a comment could achieve the same. I feel this warrants a little more discussion on how to proceed. (Although I actually nearly convinced (together with a comment).

in a case where city A's city hall is contained in city B's limits, and city B's city hall is contained in city A's limits, then a square that is within both cities' limits will be registered as belonging to city B (on the ****umption that the order in the vector is alphabetical). This code does, however, have the added advantage that, when a city is entirely encased in another city, it will always be accessible for electricity supply purposes.

As to what needs to be done before 9.x, I need to integrate and test this feature,

as well as implement a feature to require depots to be built within city boundaries and have them contribute to local employment to an extent depending on their "level".

Nathaneal,

thank you very much for your help with this. I have been somewhat too tired to work on this to-day, but think that these warnings might be relevant, given what you wrote above:

Code: [Select]

1>f:\my documents\development\simutrans\simutrans-experimental-sources\gui\gui_container.h(79): warning C4091: 'virtual ' : ignored on left of 'gui_container_t' when no variable is declared
1>f:\my documents\development\simutrans\simutrans-experimental-sources\gui\settings_stats.h(209): warning C4584: 'settings_climates_stats_t' : base-cl**** 'gui_container_t' is already a base-cl**** of 'settings_stats_t'
1>          f:\my documents\development\simutrans\simutrans-experimental-sources\gui\gui_container.h(24) : see declaration of 'gui_container_t'
1>          f:\my documents\development\simutrans\simutrans-experimental-sources\gui\settings_stats.h(133) : see declaration of 'settings_stats_t'