I spent some time and wrote a patch for simutrans. With the patch you are able to increase the map size in game. It works appropriate only with random maps (and if you not change the map number).
The zip-file contains the patch-file, 2 new gui-files and a sample menuconfig.tab (originally from pakHAJO) - You have to add "dialog_tool[24]" in your menuconfig.tab in order to use this patch.
TODO:
Add forests, cities and industries to the new part of the map.
Good idea. :)
It would be nice if we could select the direction to enlarge.
[edit] Well... rotating map solved this, and this is the easy way. ;D
One thing...
Please use only low ascii character for master text to translate.
Yeah, it's my brothers idea.
But with a rotated map the calculation of the heightmap must also be "rotated". I will fix this in a new version. I will also fix the "bug" with the master texts.
Is a preview needed? In my opinion it's not so necessary, is it?
I think you hagve not done enough. I think you need also to check for stops, which were outside the map beforehand and add them to the planquadrat list of connected stops or p****enger will not be able to travelfrom/to this tiles. I.e. the catchment region for each stop must be recalculated. And I am not sure, if the route_t buffer handles this well ingame (I mean the dirty tile list of marker_t.) I have to investigate a little more on this before inclusion.
By the way, there is a formatting rule for simutrans C++ in documentation for a reason ...
Ok, I can't know, which regions of code I have to change, because I don't read it all.
I will look for this.
It would be nice, if you can tell me, which parts of the code I have to consider.
Until now I have used my own style, but I will change it.
Look for marker_t. It maintains an image of the map, I think, and each bit represents a tile. This must be extended too, otherwise it will cause errors during way search outside the old map ...
And you know the marker for catchment region (boxes resp. transparent areas)? These represent the catchement of a stop. Just recalc them for each stop and you should be save.
Bug fixes:
- only lowercase ascii in master text
- checked catchment region of stops
- coding style ;)
I have done my homework, here is a new version ;)
Now increasing the mapsize of a rotated map works properly. So you can extend the map in all 4 directions (with combined increasing and rotating).
A new update and it's almost done but the progress bar is flickering when increasing the map size. Prissi, can you tell me why?
Sorry, need to have a depper loock at it. However, I am not sure I can do this until sunday.
Ok, I've found it! I had to call
intr_disable();
before increasing the map size. Now everything works fine and also the progress bars was pimped 8)
Should new industries also be added? Any more suggestions?
Todo:
- clean up gui/bigger_map_frame_t.*
- remove map preview
D you need a "deeper test", a nightly? ;o)
I think it's a good idea if you include the patch in a seperate nightly.
But you need also a modified menuconf.tab!
mhh .. dou you have?
But not today ... tomorow?
You have to add
dialog_tool[24]=0
to the menuconfig.tab and you have to add it to some menu
toolbar[0][21]=dialog_tool[24]
Sorry for the double post but you can't edit and append a file.
Here is an amazing new version, now with preview map and interpolated number of towns estimate.
Any more suggestions?
Edit:
Some strange things happens. When I compile my version (rev 2035 + patch) with
DEBUG = 3
in config.default everything works fine. But when I compile it without it then I get a segfault when viewing a schedule (with at least one stop)! I didn't touched the schedule window!
Edit2:
I tried it at an other pc and there even the base rev 2035 without my patch produces a segfault without DEBUG=3. And again with DEBUG=3 it works fine!
Anybody can help me? Or is it just a bug from rev 2035 which is fixed in newer revisions?
Seems to work here, though...
EDIT:
Yes, it works.
Ok. I realized now that there are two modify buttons still working different.
Since I won't open a new thread for each patch I created this one and will post here a thread every now and then.
The first one causes karte_t::init() to call karte_t::enlarge_map() for creating the heightfield etc. So it removes some redundancies and improves the behaviour of the progress bar while enlarging the map size.
Actually people are encouraged to open one thread per issue in other parts of the forum (e.g. help requests, bug reports) so I don't know if it's necessary/good to do it different here. Well, that's for the admins (and developers, well mainly prissi) to decide.
It might be more sensible to create (a) subsection(s) here for finished/included/rejected patches. I agree with Dirk that collection-topics are hard to maintain and lead to too much off-topic and loss of potentially valuable and important content.
Jörg
SInce it originall stems from the enlarge map patch, I think it is appropriate to put it here. Otherwise I would suggest a new thread per function or I will get lost fast.
Ok. I will do so :)