Author Topic: General pak-britain v1 feedback (Read 34901 times)

prissi · « **Reply #70 on:** October 17, 2009, 07:26:20 PM »

Tender should not cause crashes, as the AI ignores them. ANd you are right, the AI should not crash at all ...

The Hood · « **Reply #71 on:** October 18, 2009, 02:08:28 PM »

Dwachs, I can't reproduce what you describe. Can you sned a screesnhot?

TheMacpau · « **Reply #72 on:** October 18, 2009, 02:43:33 PM »

I'd like to start my first post on the forums by expressing thanks to all those who have contributed to the awesomeness that is simutrans, and my appreciation for the subdued more mature stylings and consistency of 128.Britain.

I'm still in the playing about with the buildings and trainsets stage and am not playing economically so to speak, learning the ropes as I move over from 128. I've noticed I have a problem with the forest/sawmill, it renders properly in the demo save and gives me no issue when it's is generated with the map at the start of a new game. However if I use the public player to try to add a new factory of this type although it places the construction site, brown squares with cranes... as soon as the construction period is over and it's due to be replaced with the forest graphic the game crashes. I'm running the most recent pakset and today's stable release. Any help would be appreciated. :-D

The Hood · « **Reply #73 on:** October 18, 2009, 09:09:28 PM »

Thanks for the feedback TheMacpau. I had noticed that bug with the forest and was reminded of it about half an hour before your post again when it did it to me. I haven't tracked down the cause yet though :(

On a separate note, bugs reported by Martinwh1 are now fixed in r224 on sourceforge, so they will be in the next release.

prissi · « **Reply #74 on:** October 18, 2009, 10:46:11 PM »

Most likely dims is defined like 2,3,3, but has only 2 or less than announced.

TheMacpau · « **Reply #75 on:** October 19, 2009, 12:10:07 AM »

I assumed from the look of memory dump that it was somekind of overflow, but my programming experience is seriously limited, is there anything I can do to help with the enquiry's?

z9999+ · « **Reply #76 on:** October 19, 2009, 12:55:00 AM »

Productivity=0 is the problem. It causes Divide By Zero.

Quote

sim.exe caused an Integer Divide By Zero at location 0055ab1f in module sim.exe.

Registers:
eax=00000000 ebx=051782a8 ecx=06afe9c8 edx=00000000 esi=01ca5055 edi=c4c54dac
eip=0055ab1f esp=0023c6e0 ebp=0023eac8 iopl=0 nv up ei pl zr ac po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000256

Call stack:
0055AB1F sim.exe:0055AB1F fabrik_t::step(long) simfab.cc:801
   ...
   if(!besch->is_electricity_producer()) {
   // one may be thinking of linking this to actual production only
>   prodfaktor = 16 + (16*power)/(n_intervall*prodbase*PRODUCTION_DELTA_T);
   }

The Hood · « **Reply #77 on:** October 19, 2009, 08:11:54 AM »

Gotcha! z9999+ was right. I'd defined productivity as 0 because all the productivity was supposed to come from the fields. Obviously that's not very friendly to the program, so I've changed that now.

Dwachs · « **Reply #78 on:** October 19, 2009, 06:40:45 PM »

Quote from: The Hood on October 18, 2009, 02:08:28 PM

Dwachs, I can't reproduce what you describe. Can you sned a screesnhot?

It happens with the loaded image of the '20t open car' (rail) with all directons. the empty wagon is fine.

AP · « **Reply #79 on:** October 20, 2009, 10:22:07 PM »

Just found another 'issue' - rail is available at 1800 (uncertain of the precise start date) - as horse drawn wagonways - but there are no signals available until some later date. Very difficult to run trains (especially at 5km/hr!) when you can't divide the line into block sections. The earliest signals (flagmen / whatever) ought to be available from the beginning, surely? Otherwise I have to create stations-serving-nothing every few tiles on passing loops, which rather clutters the map!

Also, early rail seems to be limited to 5km/hr, where the canals are limited to 10km/hr. Wondered why this difference exists?

The above two facts in combination meant that, when I tried to build a nice rail route to feed into my very profitable canal network, it just wasn't worthwhile, couldn't move the material fast enough. May as well build canals over the mountains! Resolves itself in 1813 when the first steam loco becomes available, plus signals!

prissi · « **Reply #80 on:** October 21, 2009, 08:31:02 AM »

Any way point will act as a signal too ...

AP · « **Reply #81 on:** October 22, 2009, 08:33:49 AM »

It will? Now that I did not know. Cheers Prissi!

AP · « **Reply #82 on:** October 22, 2009, 04:29:23 PM »

Another thing. Pre-rail-passenger transport, the game seems to generate an inordinately large number of passengers.

I mean, if I in 1800 start up a stagecoach network between 15-20 small towns, 8 passengers per stagecoach, doing 10km/h.

In real life, the "flying coach" between Oxford and London took an entire day to do that journey from about the 1680s until the coming of the railways, and there was ONE coach each way daily. So 8 passengers in each direction, or thereabouts.

In simutrans, I'm having to depart stagecoaches as though they were minicabs, back to back, I have congestion on my roads!

I presume the game uses the same mechanism to calculate passenger numbers across the whole time period. In reality, the availability of transport at a given area drives demand, along with the wealth/social group who want/need to travel. Until the coming of the railways made the country 'smaller' the demand was fairly limited.

I don't know whether the passenger generating mechanism can just be tweaked to be minimised until the opening of the Liverpool & Manchester railway, say, or if there's a smarter way to do it (based on whether a town has a rail station in it's vicinity say).

jamespetts · « **Reply #83 on:** October 22, 2009, 07:15:44 PM »

AP,

Simutrans-Standard, unfortunately, does not have a variable demand model. The only things that affect passenger numbers are: (1) the size of towns; (2) the number of connected towns to the network; and (3) the "passenger level", that is a single fixed number specified in the simuconf.tab file. This problem is insoluble by pakset authors.

In Simutrans-Experimental, however, there is a feature whereby the demand for passenger travel to any given destination is directly proportionate to the time that it takes to reach that destination: just as in real life. The faster that passengers can be transported somewhere, the more that will want to go there. Thus, as the age of railways dawns, and travel is much faster than by stagecoach, far more passengers will travel overall than did before.

AP · « **Reply #84 on:** October 22, 2009, 08:06:43 PM »

More and more, experimental seems the way to go...

jamespetts · « **Reply #85 on:** October 22, 2009, 08:10:12 PM »

Thank you :-)

prissi · « **Reply #86 on:** October 22, 2009, 10:37:05 PM »

Well, in simutrans standard this mechanism relies on the pak set. The lower the house levels are (maximum levels before 1871 are 13 in pak64) the less passengers can be generated at one stop.

The Hood · « **Reply #87 on:** October 27, 2009, 02:19:15 PM »

Quote from: Dwachs on October 19, 2009, 06:40:45 PM

It happens with the loaded image of the '20t open car' (rail) with all directons. the empty wagon is fine.

The bug was only with steel images. Now fixed for next release.

jamespetts · « **Reply #88 on:** October 27, 2009, 08:27:27 PM »

Quote from: prissi on October 22, 2009, 10:37:05 PM

Well, in simutrans standard this mechanism relies on the pak set. The lower the house levels are (maximum levels before 1871 are 13 in pak64) the less passengers can be generated at one stop.

But that is not a complete answer, since if all the buildings have low levels, the cities simply sprawl, which means that, for the normal arrangement of having intra-city transport feeding hubs for inter-city links, the level of usage of the inter-city links is not affected by the levels set in the buildings' .dat files.

The Hood · « **Reply #89 on:** October 27, 2009, 08:46:40 PM »

On the issue of passenger generation - is there a way that the passenger generation per housing level can be varied over time? This way could prevent crazy city sprawl from limiting the levels of citybuildings, and also prevent crazy amounts of people wanting to travel early on. Alternatively, could city growth be factored differently over time, e.g. slower growth in early years, but progressively more and more growth over time?

Anyway, back on topic, I have fixed signal intro years

jamespetts · « **Reply #90 on:** October 27, 2009, 09:53:45 PM »

The Hood,

in Simutrans-Experimental, the system of journey time tolerances will indirectly vary city growth over time. Because fewer of those people who want to travel feel able to do so because of the journey time in early years (owing to the poorer technology available at the time), the proportion of passengers travelling will be lower, and thus city growth will also be lower.

The Hood · « **Reply #91 on:** October 27, 2009, 10:00:58 PM »

Yes, I was aware of that in experimental. I was thinking of simple ideas that could be applied to standard without too much fuss. Either that or support for the journey time tolerance to be part of standard

jamespetts · « **Reply #92 on:** October 27, 2009, 10:10:30 PM »

Or just use Experimental

wlindley · « **Reply #93 on:** February 28, 2010, 01:39:54 AM »

Quote from: wlindley on August 23, 2009, 01:10:40 PM

The #1 issue making it difficult to lay roads and track is that the "grid" color hardly shows up against the transparent trees, and Underground mode is seemingly black-grid-lines-on-black-background... perhaps red grids more like standard pak64?

Quote from: The Hood on August 23, 2009, 03:40:16 PM

Sounds like a good suggestion to me. Does anyone know how to change it? I will investigate and perhaps do a poll with some options once I've figured it out.

Sorted! It's quite easy (once you find the answer). Change the color of the dashed lines (currently #040500 which is indistinguishable from black) to perhaps #400000 like in pak64.

jamespetts · « **Reply #94 on:** February 28, 2010, 01:40:56 AM »

I quite like the subtle colouring in Pak128.Britain. Perhaps a light grey?

wlindley · « **Reply #95 on:** February 28, 2010, 03:31:04 AM »

Hm, yes, perhaps something reddish-grey like #503030. You really need some color tint to it; pure grey blends too much with the green grass, as does yellow; bluish gets lost on water. #703070 is a purplish possibility, too.

jamespetts · « **Reply #96 on:** February 28, 2010, 10:30:30 AM »

I vote for purplish...

ӔO · « **Reply #97 on:** February 28, 2010, 11:59:23 AM »

how about orangeish or brownish? any caveats in those?

The Hood · « **Reply #98 on:** February 28, 2010, 12:25:25 PM »

Wlindley/others - could you put some screenshots up of various options and we will put it to a vote in a new topic...

wlindley · « **Reply #99 on:** May 13, 2010, 01:01:29 PM »

Only six months for me to get back to this! Eeep. But the purple looks very good:

and the border file

The Hood · « **Reply #100 on:** May 13, 2010, 01:38:58 PM »

Wow, some serious post-digging there! And you're still the first to respond to my request for various colour options!

ӔO · « **Reply #101 on:** May 14, 2010, 02:06:52 AM »

the purple looks pretty good.

wlindley · « **Reply #102 on:** December 18, 2010, 04:14:05 PM »

Absent any objection, for the next revision, can we please replace grounds/borders.png with this one as above: http://blog.wlindley.com/images/borders.png ... black-on-black borders for underground is unusable; we can always change the purple later on.

jamespetts · « **Reply #103 on:** December 18, 2010, 04:41:26 PM »

Thank you for that - that will be in the next Experimental version.

The Hood · « **Reply #104 on:** December 20, 2010, 12:06:28 AM »

My bad - now in standard nightlies.