Trying to compile
simsys_s2.cc generates the following errors:
- error: use of undeclared identifier 'env_t'
simsys_s2.cc uses env_t, but does not include dataobj/environment.h, where the type is defined.
error: functions that differ only in their return type cannot be overloaded
simsys_s2.cc defines the function uint32 dr_time(), which was declared in simsys.h as unsigned long dr_time(). On a 32-bit system, unsigned long and uint32 are almost certainly the same type; on a 64-bit system they may or may not be.
Best wishes,
Matthew
That is interesting - I do not generally use SDL in Windows, and I have not quite worked out what simsys_s2.cc is for, exactly. For this reason, it has not been kept fully up to date. May I ask why it is that you are keen to compile this? Are there some circumstances in which it is necessary?
Quote from: jamespetts on January 23, 2015, 10:09:27 AM
That is interesting - I do not generally use SDL in Windows, and I have not quite worked out what simsys_s2.cc is for, exactly. For this reason, it has not been kept fully up to date. May I ask why it is that you are keen to compile this? Are there some circumstances in which it is necessary?
I need
some backend. Up to now I've been using SDL; I thought the time had come to switch to SDL2. I could try going to OpenGL, but that still has an SDL dependence, and also opens up a whole new chain of broken dependencies.
Anyhow, with either SDL (which compiles cleanly) or SDL2 (which requires some hackery to fix the above errors), actually trying to run the resulting executable produces:
Reading low level config data ...
Parsed simuconf.tab for directory layout; multiuser = 1
FATAL ERROR: loadsave_t::start_tag() - expected "env_t", got "umgebbool>
Best wishes,
Matthew
May I ask what OS that you are using? I must confess to not knowing much about the difference between SDL and SDL 2; presumably, the latter is a later version of it? If SDL is needed for some reasonably mainstream OS, then I suppose that it would make sense to keep SDL 2 up to date.
Incidentally, as to the error to which you refer, that is easily fixed by deleting settings.xml (or settings-debug.xml if you are using a debug build).
I believe this is an error in the current version of Simutrans (not just experimental).
Quote
simsys_s2.cc uses env_t, but does not include dataobj/environment.h, where the type is defined.
Do not bother using SDL2 on Windows. From my personal tests there was no noticeable in-game performance difference over GDI (exact same frame rate which were both higher than the pre-builds for standard Simutrans, experimental pre-built might be faster already). It also appears to suffer from a bug whereby it will make all progress bars painfully slow (it will take 5-10 times longer to load stuff).
Ahh, yes, I remember now that you have provided some useful compiling work in the past for that operating system. I have fixed the specific things that you have identified - can you try compiling again?
Quote from: jamespetts on January 23, 2015, 10:25:26 PM
I have fixed the specific things that you have identified - can you try compiling again?
Yes, that's OK now. World generation (or more specifically, city generation) seems to be the next headache, but that's a topic for a new thread.
Town generation is currently broken: the plan is to fix that when town growth has a major overhaul sometime this year. You can, however, manually add a few roads and then use the "grow city" tool to build them manually for the time being. I am not sure why this does not work automatically at this stage.
Quote from: jamespetts on January 24, 2015, 12:39:18 AM
Town generation is currently broken: the plan is to fix that when town growth has a major overhaul sometime this year. You can, however, manually add a few roads and then use the "grow city" tool to build them manually for the time being. I am not sure why this does not work automatically at this stage.
I'm just about up to adding a few towns manually, but now I see that there is an further lack: we get lots of little lakes, but no rivers! Painting an entire map's worth of rivers by hand strikes me as distinctly UnFun.
Regarding town generation, I note that the problem towns are those whose town halls have no roads adjacent (or even nearby). Perhaps all that is needed is to ensure that a newly-created town has at least a couple of squares of road next to the town hall before trying to engage in town growth?
Probably not connected: trying to sort the town list by population just results in it being sorted backwards by name.
Best wishes,
Matthew
Hmm - there appears to be a problem with way generation on map creation if both rivers and town roads are not being generated. I may need to look into this as its own issue.
Edit: I think that I have now fixed this, and town roads and rivers are now generated on map generation. Can you test to see whether it is working for you?
Quote from: jamespetts on January 24, 2015, 10:38:48 AM
Edit: I think that I have now fixed this, and town roads and rivers are now generated on map generation. Can you test to see whether it is working for you?
I only spotted this this morning (edits don't show up in 'Unread posts since your last visit').
Anyway, yes it is much improved, but not yet completely right.
Town roads now appear as expected, and in consequence town generation is basically OK. There is still something fishy with the population counts though: the generated populations are systematically larger than they should be for the median requested (by about a factor of 2, I would say), and asking for a city list sorted by population results in a list
approximately sorted by population, but with the occasional individual town badly misplaced. I'm guessing that somewhere lurking in the code are two different ways of counting population: an 'internal' count that is used for generation and sorting, and a more inclusive 'external' count (perhaps counting jobs or visitors as well as inhabitants) that is displayed to the player.
Rivers are being generated, but only at the smallest size: no matter how long the streams are, and no matter how many of them combine together, they remain as just streams. Also, with 'lakes' on, there are so many little lakes that the rivers tend to be cut short, and a very large number need to be generated to get a reasonable density; for the moment I'm just turning 'lakes' off, but it would be nice to be able to turn it down instead of completely off. Separate buglet that I think has been around for a while: in Settings->Climate, the maximum river length is a reasonable 8196, but if you go directly to Climate settings from the Creation window, the maximum allowed is a mere 1024.
Best wishes,
Matthew
Thank you for that: I have now fixed the two river generation issues identified.
As to the towns, work on town generation is awaiting a complete overhaul of town growth, in which the two different systems for counting population will be reduced into the single (newer) system used for passenger generation.
Quote from: jamespetts on January 29, 2015, 11:09:24 PM
Thank you for that: I have now fixed the two river generation issues identified.
As to the towns, work on town generation is awaiting a complete overhaul of town growth, in which the two different systems for counting population will be reduced into the single (newer) system used for passenger generation.
OK, I'm now getting playable maps. (But I'm sticking with no lakes.)
Thanks,
Matthew
I don't think that I have changed the lakes code from Standard, so it may well be a calibration issue inherited from there.
Lakes have recently changed from the model used in the Experimental Server (a water level? Anything below a certain height becomes water) to water being a climate model (you can turn any tile to water even if it neighbours non-water tiles, and fill up depressions somehow resulting in all kinds of water and land heights).
Due to the extent that water has changed it is possible that anything from big to small changes/fixes can be missed. This might especially be the case if you were bulk merging code from standard involved with climate, water or cliffs.
It was Bernd Gabriel who merged the lakes code from Standard quite a while ago now. Is the lake behaviour notably different from Standard with the same settings?