This is a testing release - it will load saved games from previous standard releases of simutrans, however any saved games generated will most likely not be compatible with future releases of simutrans, or even future versions of this patch. I have tried to make sure there are no severe bugs (only issues I know of relate to powerlines) in the patch, but wider testing usually reveals many bugs!
This patch adds support for double heights, different heights of water and per tile climates to svn trunk version 5830. These features are currently accessed via an extended landscaping tools menu and do not cost anything (this may change, or be restricted to public service player):
(http://simutrans-germany.com/files/upload/landscapetools.png)
Starting from the left we have standard simutrans up/down and slope tools, with variants for double heights. Next there is the water down/up tools - these alter the water height in a lake (or will create a lake in a suitable basin). Finally there are climate tools for each climate (8 available, from water through to arctic) - these can also convert from land to shallow water and vice versa.
A version of pak128.Britain is included with double height graphics for many (but not all) ways and way objects. Notably of the available railways only wooden sleep steel rail track has double height graphics, and there are no double height graphics for maglev. Attempting to use a way which does not have support for double heights will result in graphical errors and not being able to build on steep slopes. Bridge building can be a bit tricky at times, and the graphics for bridge supports do not always look correct (but improvements to bridges in general are on my todo list, and are outside the scope of this patch!). Tunnels must start on steep slopes (this is pak dependent - for a full explanation see my previous double height patch).
This patch builds on my previous Water Height (http://forum.simutrans.com/index.php?topic=9520.0) and Double Height (http://forum.simutrans.com/index.php?topic=10081.0) patches. See those threads for more discussion on features, note that the following bugs discussed in those threads have been fixed:
Some terrain altering is not permitted when it should be when near ways - FIXED
Not considered 1 tile high climates yet when drawing terrain, so these will result in graphical glitches - NOT APPLICABLE (due to new climate system)
Pavement issues - FIXED (missing file in release)
Graphical errors when using slope tools near water - FIXED (dykes no longer enforced, new climate system allows level transitions)
Known issues:
Powerline Bridges do not build correctly. Altering height in Powerline Tunnels can cause the program to crash.
Edit: Downloads for 5830 removed - replaced with ones for r5886 below (http://forum.simutrans.com/index.php?topic=10242.msg98421#msg98421)
Existing install means simutrans 111.3 and pak128.Britain 1.11.
Bug reports, either with the patch itself, my files for pak128.Britain, or even just concerning files missing from the release zips (which happened last time) are very welcome.
Impressive! :thumbsup:
A most awaited patch growing better and better.
*bows* and *applause*
looks great its useful for our worlds - we could make desserts and snow places as separate regions
If you still need testing on this...don't know if I can be of any help but am willing to try.
From reading the thread it looks like I can just copy my existing simutrans.exe to a new directory and then download the "Windows executable" you linked above? Will I not need to do something to my user directory?
If explaining all this is too much trouble I certainly understand.
Create a directory and copy all standard simutrans and pak128.Britain files into it. Then copy the executable and pak128.Britain files linked to above over this.
Thanks Kierongreen. I've followed your instructions but not exactly to the letter. When I try to run sim.exe I get an error "can't find SDL.dll"
I ran c:/dir sdl.dll /s and did find that file in a media directory I have. I copied the file over to the new experimental directory and the game did try to load but Windows shut it down with no explanation. The message was simply "Windows has encountered a problem and needs to close."
The version of the game I have is 111.0...I'm guessing I need to download 111.3?
Quote from: Roads on July 25, 2012, 05:07:33 AM
Thanks Kierongreen. I've followed your instructions but not exactly to the letter. When I try to run sim.exe I get an error "can't find SDL.dll"
I ran c:/dir sdl.dll /s and did find that file in a media directory I have. I copied the file over to the new experimental directory and the game did try to load but Windows shut it down with no explanation. The message was simply "Windows has encountered a problem and needs to close."
The version of the game I have is 111.0...I'm guessing I need to download 111.3?
Yes. The pakset has changed to suit the latest simutrans nightly. If that fails, you can download the latest sdl.dll from the net.
Ah missing sdl.dll from windows executable version zip file - uploaded a new version please check.
and yes, will need to be copied over 111.3 files.
kierongreen, I'm still doing something wrong or missing something. In my Experimental directory, I can run simutrans.exe. I am not given a choice of what to run, it simply runs pak128.Britian version 111.3
Of course it does not have your changes.
I did get the new sdl.dll file and copied it to both my Experimental directory and to Windows/System32 directory.
When I try to run sim.exe I get the "Windows has encountered a problem and needs to close" message. I'm thinking this might still be a problem with sdl.dll
I had looked for that download on the net and every site I visited wanted to "install" it. Does it need something besides merely placing it in a directory?
By experimental I hope you aren't referring to simutrans-experimental because that will cause no end of problems. Without a lot of work new landscapes will not work with experimental.
My patch is based on simutrans-standard. For a Windows based install, create a new directory (no files in whatsoever). Unzip the following zip into it:
http://sourceforge.net/projects/simutrans/files/simutrans/111-3/simuwin-sdl-111-3.zip/download
This will create a directory inside this called simutrans, with sim.exe, sdl.dll, and a few other files and subdirectories etc in it.
Now unzip the following zip:
http://sourceforge.net/projects/simutrans/files/pak128.britain/pak128.Britain%20for%20111-0/pak128.Britain.1.11-111-2.zip/download
Rename the folder from Pak128.Britain.111 to Pak128.Britain and copy this into the simutrans directory above.
Then unzip my zips into this directory also, these will overwrite sim.exe, sdl.dll and various files in the Pak128.Britain directory:
http://simutrans-germany.com/files/upload/new-landscape-5830-binary-win.zip
http://simutrans-germany.com/files/upload/new-landscape-5830-binary-pak128.Britain.zip
This should work. I do not have access to a windows system, so I cannot test this though.
kierongreen
i have test it!
It look good out.
I have windows!
No Kierongreen, I was not talking about Simutrans Experimental. That was a poor choice of directory name. Thank you very much for breaking this down and I'll follow the steps in your last post. Looks like it is just something I'm doing wrong as greenling says it is working for him.
IT IS RUNNING! YAY!
Many thanks Kierongreen!
Will post any problems I encounter if that is okay.
Please pardon the double entry. I thought kierongreen would need to see this ASAP.
I had begun a new game and was acting as public player building roads. That included roads for stations. In Tweaksberry, I needed to use the landscape tool to lower the land for the station in two squares which I did. See screenshot below:
(http://simutrans-germany.com/files/upload/r5830s1.png)
Later after working other areas I happened to look back at Tweaksberry and this is how it had changed:
(http://simutrans-germany.com/files/upload/r5830s2.png)
Please note I only lowered the two squares next to the road by city hall.
Thanks for the report - will investigate!
--
Found what I think is the issue. Did you by any chance save and then load this map before the problem occurred? When trying to repeat your bug I found errors my save/load routines for ground tiles (I had to change these from standard simutrans as it doesn't actually restore grid heights correctly, which caused problems for water raising and lowering).
Also just checking that you did set the climate of the area to desert and that this wasn't another bug? But looking at your screenshot transitions between water and this seem to be missing, which shouldn't happen :s
Going to try and fix a bug or two more (climate transitions not being restored when buildings with foundations are demolished, and the powerline bugs) then I'll put up a new version to test.
Yes I did save and reload several times. I always do when building roads as my first attempt at a road is usually not what I stick with.
Before one of the reloads, I did not save it but I did try the desert and other terrain types to see what they looked like...also the water, raising and lowering.
If there is something specific I should not do, just tell me twice! Apparently I can't understand the first time I'm told...
Off topic: I kinda like the name "Tweaksberry "! :P
QuoteIf there is something specific I should not do, just tell me twice! Apparently I can't understand the first time I'm told...
Try anything! The purpose of testing is to find out bugs which I hadn't encountered :)
Actually this has uncovered more bugs related to the saving and loading of grids in the process, so very helpful :)
Good to know and just post when you have something to test. I'll be happy to do it.
I found one issue:
You can't change the water level when the water tiles are less than a tile distant.
And the water level don't increase to the same level of the shore, it always stops when the water level is 1 height below.
QuoteAnd the water level don't increase to the same level of the shore, it always stops when the water level is 1 height below.
Yes, this is due to the algorithm for detecting where the lake boundaries are. When you raise the water level the code tries to turn all land tiles at the same level into water, stopping if the height increases. As such if you try raising the water level to that of the surrounding ground, then this ground will be flooded. I could instead only flood land if it is below water level (rather than below or equal to) but there is no real advantage to this over current code.
QuoteYou can't change the water level when the water tiles are less than a tile distant.
Again, I think this is down to detection of edges. The algorithm looks for any gaps where water could flow through, and if it could it raises there also. So although two bodies of water might not look connected if there is even a tiny gap of land connecting them at the same level the algorithm will detect this. Again, I could change this, but this could cause additional problems if I'm not careful...
In both these cases you may have more success achieving these effects with the water climate tool as well as the lake height one.
Thanks for the answers kierongreen.
Are you planning a change in the heightmaps to generate the terrain and water bellow sea level?
Maybe Dwachs can extend his scripted scenarios to work with it.
I wasn't planning to change heightmaps to support different heights of water myself. Random maps and height maps do generate lakes above sea level if the terrain allows it (though prissi commented that there were too many so I reduced the height of water in these lakes). Actually these might get removed as they do slow down map generation. Dwachs scripted scenarios might allow different water heights, or a more general extension to heightmaps to support additional information might be better.
I'm encountering a number of issues with the landscape tools.
1. The extended landscaping menu only shows some of the new functions (no water or climate tools)
2. The slope tools don't seem to create the correct graphics
3. The slope tools leave a lot of graphical artifacts behind
The attachment illustrates these issues.
Are you sure you used Simutrans 111.3 and pak.Britain 1.11?
Cause here I don't see this problems.
This is what happens if you haven't copied all of the files I replaced in pak128.Britain over the originals.
I'm pretty sure that I copied over all of the new files (Vista prompted me, and I selected 'copy and replace', for every file). Actually I re-did it after initially encountering this problem, but still had the same issue. Approximately how many new files were there?
It might also happen if you are still using old binary - are you running sim.exe not simutrans.exe?
There's 40 files in total, sim.exe, makeobj.exe, 36 paks and 2 config files.
Ah...sim.exe not simutrans.exe...looks a lot better now!
Thanks a lot for your help!
Patch updated to r5886, new binaries included for Linux and Windows. No change in functionality but the following bugs have been fixed:
rotation of climates
save/load of height grid
crash on using change slope tool for powerlines
bridge building now more robust and working for powerlines
As a result of these fixes previous saved games made with this patch most likely will not load correctly, and likewise future compatibility is not guaranteed. All known issues are now resolved, although I'm not going to be shocked if people find more bugs, and reports are most welcome! :)
The only change to the files in pak128.Britain since 5830 is to the menuconf.tab file as menu entries have been renumbered following changes in simutrans trunk.
The following downloads are available - to test this you will need to either apply the patch and then make pak128.Britain from the source files provided, or download an executable (Linux or Windows) and pak128.Britain binary files:
Source files (http://simutrans-germany.com/files/upload/new-landscape-5886-source.zip) - the patch, along with all dats, pngs and simutrans config files necessary to make the updated files for pak128.Britain
Binary files for pak128.Britain (http://simutrans-germany.com/files/upload/new-landscape-5886-binary-pak128.Britain.zip) - copy over an existing install to use one of the executables below
Windows executable (http://simutrans-germany.com/files/upload/new-landscape-5886-binary-win.zip) - simutrans and makeobj, copy over an existing install of simutrans
Linux executable (http://simutrans-germany.com/files/upload/new-landscape-5886-binary-linux.zip) - simutrans and makeobj, copy over an existing install of simutrans
As before you are best making a clean install of simutrans 111.3.1 (http://forum.simutrans.com/index.php?topic=10292) and pakBritain 1.11 (http://sourceforge.net/projects/simutrans/files/pak128.britain/pak128.britain/pak128.Britain%20for%20111-0/pak128.Britain.1.11-111-2.zip/download), then copy the executable files for windows or linux, and binary files for pak128.Britain over this.
Definitely an epic patch. 8)
A few issues:
DOUBLE_GROUNDS not defined, can't compile:
simwerkz.cc: In static member function 'static const char* wkz_setslope_t::wkz_set_slope_work(karte_t*, spieler_t*, koord3d, int)':
simwerkz.cc:1102:67: error: 'const class weg_besch_t' has no member named 'has_double_slopes'
simwerkz.cc:1103:64: error: 'const class weg_besch_t' has no member named 'has_double_slopes'
simwerkz.cc:1104:64: error: 'const class weg_besch_t' has no member named 'has_double_slopes'
simwerkz.cc:1142:67: error: 'const class weg_besch_t' has no member named 'has_double_slopes'
simwerkz.cc:1143:64: error: 'const class weg_besch_t' has no member named 'has_double_slopes'
simwerkz.cc:1144:64: error: 'const class weg_besch_t' has no member named 'has_double_slopes'
make: *** [build/default/simwerkz.o] Error 1
DOUBLE_GROUNDS defined, resultant .exe can't load unmodified paks. No backwards compatibility.
simscr11: 2 single height slopes, constructed x2 artificial slope + flat artificial slope, built tunnel, then restored to natural slope on the flat artificial. Shouldn't be allowed?
simscr12: beach not displayed on some shoreline tiles. Water is just the standard ocean.
simscr13: beach not displayed on any shoreline. Water is a raised lake.
simscr14,15: ding_view_t goes psychedelic on zooms other than 1:1.
Beach behaviour is intentional - when generating a map indents in coastline will have wide beaches, headlands will have no beach. Edits to land height after will assume standard simutrans type beaches. Lakes will have no beaches as tides aren't a factor. Will try fixing compile error, with DOUBLE_GROUNDS defined old paks will load if landscape files are updated. Colours and tunnel are bug and will fix tonight after work hopefully.
Thank you very much for testing and fixing.
Just a quick note: I've traced and fixed the bug with altering slopes above tunnels (actually this affected the normal height lowering tool as well as the slope tool and restore slope tool). The psychedelic worldview display I'm stuck on at moment, it's to do with the pointer somehow not being set correctly for the image in display_base_img_alpha (the alphamap one seems ok though). I'll keep working on this.
Maybe different zoom levels? Or rather different routines for display? (They are displayed from world_view directly.)
Got it eventually. Here's another bugfix release then. Updated to 5914, bugs fixed with colours in info window, altering height above tunnels and improved map rotation performance.
Source files (http://simutrans-germany.com/files/upload/new-landscape-5914-source.zip) - the patch, along with all dats, pngs and simutrans config files necessary to make the updated files for pak128.Britain
Binary files for pak128.Britain (http://simutrans-germany.com/files/upload/new-landscape-5914-binary-pak128.Britain.zip) - copy over an existing install to use one of the executables below
Windows executable (http://simutrans-germany.com/files/upload/new-landscape-5914-binary-win.zip) - simutrans and makeobj, copy over an existing install of simutrans
Linux executable (http://simutrans-germany.com/files/upload/new-landscape-5914-binary-linux.zip) - simutrans and makeobj, copy over an existing install of simutrans
As before you are best making a clean install of simutrans 111.3.1 (http://forum.simutrans.com/index.php?topic=10292) and pakBritain 1.11 (http://sourceforge.net/projects/simutrans/files/pak128.britain/pak128.britain/pak128.Britain%20for%20111-0/pak128.Britain.1.11-111-2.zip/download), then copy the executable files for windows or linux, and binary files for pak128.Britain over this (have not tested with pakBritain 1.12 yet, it may or may not work).
"Not Found The requested document was not found on this server. "
Attachments at Simutrans-Germany server get deleted after 30 or 60 days by default.... unless you put "0" in "Days valid" field.
Reuploaded... but for some reason it's not recognising me when I log in, so will only store for 1 day. I'll upload another tomorrow. At moment it's still 5914 version - but patch works fine on 5936.
Apologies for delay, had so little time by the time I'd put together any kind of release it was significantly out of date :( Updated to 6032, no significant changes but hopefully I've managed to update it without adding any bugs...
Source files (http://simutrans-germany.com/files/upload/new-landscape-6032-source.zip) - the patch, along with all dats, pngs and simutrans config files necessary to make the updated files for pak128.Britain
Binary files (http://simutrans-germany.com/files/upload/new-landscape-6032-binary.zip) for pak128.Britain - copy over an existing install to use one of the executables below
Windows executable (http://simutrans-germany.com/files/upload/new-landscape-6032-binary-win.zip) - simutrans and makeobj, copy over an existing install of simutrans
Linux executable (http://simutrans-germany.com/files/upload/new-landscape-6032-binary-linux.zip) - simutrans and makeobj, copy over an existing install of simutrans
Use latest versions of simutrans and pak128.Britain as a base to copy these files over.
As version of simutrans is now 112 I've had to alter the file version used, so old games made with this patch will not load now (unless they are hacked).
Great! I'm going to test it when I got home back from the job. :)
mentioned on g+ simutrans page:
Quote
*new test version of multi-level--landscape*
kierongreen provides a new test version of his new landscape code, based on the latest simutrans versions. Don't forget it's a version intended for _testing_ so please don't build your mega project on it. You ought to report all bugs or issues to the forum thread.
This is one of the major projects being developed at the moment in simutrans, allowing the use of half-height (or if desired double height) and normal height slopes. Also adding the terrain manipulation tools, new coastlines etc. Since it is changing things so deeply and at so many places, the workload is huge. Another consequence is that there is a lot that can go wrong and might do so in not so obvious ways, thus the thorough testing it requires.
Thanks :) Forgot to say, the files from pak128.Britain have been updated - as such almost every way has half height support (only ones missing are TGV and Maglev).
Oops, simutrans-germany.com is derping. *derp*
I'm getting "Problem loading page". :(
Is working here :s
Is there any plan to incorporate the Water patch into the standard pak128 that you know of? Is it possible to apply this patch separately (i.e. not including the HH patch) and utilize it in existing games?
Water, climate and double height are all technically different but very closely linked extensions. It would be possible to modify the patch to include 1 or 2 of these extensions rather than all 3 but it would involve some work (which would be a waste of time when/if the complete patch is added)..
Thanks Kierongreen. I suppose where I was coming from was that the half-height patch seems to have a lot of implications for the pak set. If I understand it correctly all the ground tiles plus all the ways would require additional versions to be painted if they are to be used in a game that's using the patch. On the other hand the water patch seems to be a lot more self-contained and could be introduced into the existing (full-height) game with only minor modifications to the pak.
Is that an accurate observation? If so it seems like there could be an argument for having a 'water patch only' release.
The water only patch was released first and is available here (http://forum.simutrans.com/index.php?topic=9520.msg95796#msg95796). It will need a fair bit of updating to make it work with latest SVN version, and it will probably be worth backporting some bugfixes back from the landscape patch. Infact it doesn't require any modification to paks at all. The annoying part is if this is done (which would take some work) then I have to go back and make the rest of the landscape patch compatible with the new trunk (even more work).
The landscape patch has (at prissi's request), support for either double or half heights. The version of pak128.Britain I've created supports half heights, the idea would be for pak64 to probably have double heights. For double heights you wouldn't need new way images. You'd only need new lightmaps, marker, grid and a few more texture transitions.
Sorry, I understood that you need a double height aware pak, and this patch does not support single height paks any more. Is this no longer the case?
It might be possible to add support for single height paks - but this would complicate the code in some places as there would have to be support for 3 different behaviours: single, half and double height. Also there would have to be a way of storing whether a game had been made or converted to half/double height as it would then be unloadable in a single height pak. Paks need an additional texture transition image to cope with per tile climates even for single heights.
Well, but games are anyway tied to a pakset.
By single height support I ment single height only for all way and everything but landscape (since there only new grey render images and new cliffs are needed). Or did I missed something. I was just worried that many paksets with single height would need a lot of exercise to be converted to double height. Am I wrong?
Ways can indeed have single heights - if only one set of slope images are present then then they can only be built on shallow slopes, if 2 sets are present they can be built on shallow and steep slopes.
So double height would be the default for unmodified paksets (only requiring a couple of additional ground textures, copied into the pakdir)?
Quick simple query: does "double height" here mean double the current height of tiles, or double the new, smaller height of tiles?
Double height can mean either (a bit confusing I know). At present in standard most paks have a tile height of 16. With this patch you can have (for example), a tile height of 8, which will mean heights 8 and 16 appear ingame (i.e. allowing half height slopes compared to standard, which is what I choose for pak128.Britain), or 16, giving 16 and 32 in game (i.e. double height slopes compared to standard, which prissi preferred for pak64).
Thanks Kieron. So when we say that double height would be the default for unmodified paksets, does that also have this dual meaning, or does it refer specifically to 16 or 32 tileheight?
Since some version the height of tiles can be set in the pakset. Thus so far all released version only supported a single height step in z-direction "single height". This version support double steps in z-direction (double height). There could be then two variants: Bridge and tunnels require a single height step, or bridges and tunnels require double height steps )and in principle also both).
Just forget about the visuals since the logic is most important. My question was, that if no double height ways are available (due to loading a single height pak) is then automatically for this way the construction on double height slopes forbidden?
Because then you could easily upgrade existing paks like pak.abo with a double height texture map and new slopes. (Maybe for future compatibility slope graphics could be also textures. That would allow for different slopes to water, city and land more easily.)
Yes it is forbidden.
Quote from: prissi on November 16, 2012, 09:39:51 AM
Because then you could easily upgrade existing paks like pak.abo with a double height texture map and new slopes.
is also possible to recover the pak.TTD??
pak.TTD is on sourceforge and has nothing to do with this thread.
During the last double height experiments I found the blender soucres to generate those tiles. Might be for some use still today:
http://www.physik.tu-berlin.de/~prissi/simutrans/terrain.7z
Hi kierongreen: I think I've spotted a bug with the new (water, climates and half-height) patch. When I create a road bridge over open water it works perfectly when I initially create it but when I save the map and re-load it the top of the bridge has vanished leaving only the piers (think Tay Bridge disaster) and it cannot be used by road traffic. Only an issue when crossing open water; no problem when crossing rivers or other ways. May be a problem for other bridge types too but I've only tested it with road bridges.
Ok thanks for the report will check when I get home :)
---
Confirmed, working on fix....
switch the land again in water and this is what happened
(http://www.mediafire.com/view/w87wlnkzp388b8m/ffffffffff.jpg)
Did you try attaching a picture? I can't see anything.
hus apology, I think it was a problem with "Google Drive" switch to "mdiafire" and this solved it
blog de noticias (http://www.facebook.com/Simutrans.BLOG?) de simutrans al día, aunque esta en fase de crecimiento ya se han
publicado muchos anuncios en ingles y desde luego en español.1000saludos Simutrans-BLOG Face (http://www.facebook.com/Simutrans.BLOG?)
I can't see images. Probably there's a hotlink block.
Try this: http://imgur.com/
Right-click the broken image icon and open it in a new window. You'll get the mediafire window where the image can be viewed.
Quote from: Zeno on December 08, 2012, 10:35:41 PM
Right-click the broken image icon and open it in a new window. You'll get the mediafire window where the image can be viewed.
http://www.mediafire.com/view/?w87wlnkzp388b8m
Ok, it's still not appearing but I've managed to find the picture. I've tried reproducing the situation in the screenshot but I can't get it to crash - could you provide a saved game which this occurs in please?
here this the starting http://www.mediafire.com/download.php?pqr8d8nol3hox5h
for playback, cover the ground with water
in this manner
(http://sphotos-f.ak.fbcdn.net/hphotos-ak-prn1/s480x480/75280_385359348207889_1792901950_n.jpg)
Many thanks Yona-TYT, bug was crash when setting water climate next to map edge. Will be fixed in next release :) Still working on another couple of bugs then will release new version.
:) ok
Here's another update to latest trunk version (6161), also fixing the following bugs:
Bridge construction ending on single height tile with existing way was broken.
Bridge save/load over water.
Factories with location land, climate water were never built - now built if a tile is next to water.
Setting climate to water at edge of map crashed game.
Source files (http://simutrans-germany.com/files/upload/new-landscape-6161-source.zip) - the patch, along with all dats, pngs and simutrans config files necessary to make the updated files for pak128.Britain
Binary files (http://simutrans-germany.com/files/upload/new-landscape-6161-binary.zip) for pak128.Britain - copy over an existing install to use one of the executables below
Windows executable (http://simutrans-germany.com/files/upload/new-landscape-6161-binary-win.zip) - simutrans and makeobj, copy over an existing install of simutrans
Linux executable (http://simutrans-germany.com/files/upload/new-landscape-6161-binary-linux.zip) - simutrans and makeobj, copy over an existing install of simutrans
Use latest versions of simutrans and pak128.Britain as a base to copy these files over.
Notes:
As always, forwards and backwards compatibility with other versions are not guaranteed. If you get a crash on startup check that you've deleted any settings.xml or default.sve file lurking around in your personal directory.
makeobj isn't entirely up to date in binaries as it's not compiling for me at the moment, however this shouldn't be a huge issue.
Please let me know if you encounter more bugs :)
Hi kierongreen,
Don't know if this is a bug or not (might just be a backward compatibility issue) but I loaded a map using your latest new landscape binary that I had made with the previous version of the binary, and it crashed with the following error message:
loadsave_t::rdwr_str() string (2252652) longer than allowed size (6771884)
I can create new maps (and save and re-load them) without problems.
If it's not a bug is there anything you can recommend to hack the file to enable it to be opened using the latest binary?
Unfortunately not. There have been changes the save format in trunk which means that savegames made with older versions of the patch will not be compatible. To load these you would have to hack the load routines so that simutrans thought the game was new in terms of having new landscapes but old in terms of trunk changes. My priority is for standard saves to load over those from previous new landscape test releases so this incompatibility is to be expected (and I try to warn of it being likely).
I've finally got round to downloading this and having a play. Great work! One thing I miss is the ability for half height bridge ramps - I can understand not allowing half height bridges but it seems odd not to be able to build ramps sloping up at half height e.g. onto elevated ways for flyovers etc. How hard would this be to add in?
Finally got to testing this. And it's great! The beachheads are just... \o/
Anyway, two things:
1) I guess terraforming is (currently) meant to destroy climates?
2) Trains driving through bridges - see attached screenshot.
Yes changing height is designed to reset climates on affected tiles. Will need to look at bridge issue after the weekend when I am back at a computer. I suspect wrong height bridge graphics may be the cause. Tunnels can have single and double heights in them so it would be possible to have a more flexible elevated ways which could be freely adjusted rather than only following the landscape. This would be a more general extension request though, and would need new graphics also.
Quote from: kierongreen on January 02, 2013, 06:07:42 PM
Tunnels can have single and double heights in them so it would be possible to have a more flexible elevated ways which could be freely adjusted rather than only following the landscape. This would be a more general extension request though, and would need new graphics also.
That sounds great - which is why I'm concerned it would never happen :( - I'd do graphics for pak128.Britain at any rate.
The problem is the amount of graphics required - 64 images (or two lots of 8 ) for the base of pillars which have to seemlessly merge into 23 elevated track images (hence you might need several lots of 64), plus various combinations of 0->1->2 height slopes. All in all potentially many hundred images, for each type of elevated track. Unless there is an easy way to crop images in simutrans I can't think how this could realistically be achieved :(
That might be easier implemented as cutting pillars in two, the "always" and "extended bottom" part... More or less like bridges with zero and one height pillars, perhaps...
Incidentally, are there river graphics for the shallower slopes yet...?
Here?
http://forum.simutrans.com/index.php?topic=10223.msg97258#msg97258
Ahh, splendid, must have missed that.
Just an updated patch to latest svn version (no binaries as no real changes). I'm going to be busy moving the next few weeks so next update might not be for a while...
Good luck with it, I am still struggling with the outcome of my recent move ...
I hope this is incorporated soon :thumbsup:
Simutrans on facebook (http://www.facebook.com/Simutrans.BLOG?)
how much time do you estimate will happen till we incorporate this into trunk? I'd like to take this code into account because it's a bit related to my world limits not limited to water level project.
I'd also like to rename ist_in_gittergrenzen and ist_in_kartengrenzen to is_in_grid_limits and is_in_map_limits . I know it might sound an unnecessary change for german coders, but for non-german makes code quite cryptic.
No estimate. After the next bug-free release :P
Renaming: full support.
Split the discussion about translation, which can be found at:
http://forum.simutrans.com/index.php?topic=11386.0
Here's another update to latest trunk version (6428), making this work with the new map edges:
Source files (http://simutrans-germany.com/files/upload/new-landscape-6428-source.zip) - the patch, along with all changed dats and pngs and simutrans config files necessary to make the updated files for pak128.Britain when copied over the standard sources.
Binary files for pak128.Britain (http://simutrans-germany.com/files/upload/new-landscape-6428-binary.zip) - copy over an existing install to use one of the executables below
Windows executable (http://simutrans-germany.com/files/upload/new-landscape-6428-binary-win.zip) - simutrans and makeobj, copy over an existing install of simutrans
Linux executable (http://simutrans-germany.com/files/upload/new-landscape-6428-binary-linux.zip) - simutrans and makeobj, copy over an existing install of simutrans
Use latest versions of simutrans and pak128.Britain as a base to copy these files over.
Notes:
As always, forwards and backwards compatibility with other versions are not guaranteed. If you get a crash on startup check that you've deleted any settings.xml or default.sve file lurking around in your personal directory.
I've not tested all the new elevated ways, there might be problems there if I've made typos in the dats.
I've not been able to include all the source pngs to produce the now large numbers of elevated ways as it would be over the 10mb limit - as half height graphics are now in the Standard pak128.Britain images this isn't a problem.
Clicks to lower tiles at the edge of the map are not always detected - I think this is a more general problem?
Water height at edge of map must be groundwater height, in theory... even so some weird things can happen when extending map edges...
Please let me know if you encounter more bugs :)
Impressive!!!
One note: in umgebung.cc, you do not need to change line 289/290, then old settings.xml will load without problems.
Edit: I cannot understand the 'Raise water tool'. Will it flood over a tile if the tile's height is equal to new water height? This seems unintuitive, as the patch supports also lakes with flat shore ??? This tool also does not understand the concepts of dams :D
Oh, very nice work. :) And I see your patch and mine were much more compatible than I thought, you didn't had to make much adjustements from what I saw (I might have overlooked some details). Great!
Regarding umgebung - I've always incremented the release version by 1 so that existing games will be converted. When the patch is finally incorporated with a particular simutrans version this problem will be solved.
Raise/lower water does flood over all ground at the same level. This is so that you can create lakes where there is no water at present. I don't know whether it would be more intuitive to have different behaviour when the tool was used on existing water as opposed to on land?
A lot of changes that were made were just variables being renamed but a few required a bit more thinking than that! :)
Will this be released on next release? I see it's not able to load old paksets, is there something that can be done to achieve that?
Doesn't this deserve to be relased as simutrans 113.0? We can incorporate it to trunk now and work on that release.
Rather as Simutrans 200 :)
What is needed to make pak64 workable?
pak 128 doesn't have support for this yet I supose, no? coudn't find it anywere. :)
Quote from: kierongreen on April 03, 2013, 11:15:08 AM
Regarding umgebung - I've always incremented the release version by 1 so that existing games will be converted. When the patch is finally incorporated with a particular simutrans version this problem will be solved.
You do not save anything patch-related in umgebung.cc, only a file->get_version query is touched, which is totally unrelated to the patch.
Quote
Raise/lower water does flood over all ground at the same level. This is so that you can create lakes where there is no water at present. I don't know whether it would be more intuitive to have different behaviour when the tool was used on existing water as opposed to on land?
I would expect the tool to raise water one level but not to flood over the next level: build a dam, then increase water level, without flowing over the dam.
And support for old existing paksets should be continued. Maybe creating some fake heightmaps by stretching the single-height tiles?
pak64 has a set of double height lightmaps. As far as I understood, those are the only 100% requirements. THis will of course disallow steep strees and such things.
In addition double height markers and grid tiles, along with more texture transitions are required. Where are the double height lightmaps?
I will search them on my old harddrive. (Somehow this sounds like greenling now ;) )
Quote from: prissi on April 04, 2013, 11:00:45 AM
I will search them on my old harddrive. (Somehow this sounds like greenling now ;) )
Haha. So right... ;-)
Auf www.physik.tu-berlin.de/~prissi/simutrans
liegen unter anderem farms.zip fields.zip, field2.zip. trees.zip, bridgesxxx.zip, die alle von Alltaken für pak128 für doppelte Geländehöhe gerendert. Leider ist meine Blenderdatei galube ich unvollständig.
panoramam-grey.png ist die heightmap.
After some minor problems, I've been able to check the patch and I like it very much. But in order for it not to be only a change of appearance, I would include it in game mechanics... For instance, a new rule (maybe pak dependent) that states that rail track or high-speed roads cannot be built on 2x slopes, but roads can... A sufficiently well thought map would force the player to wisely use tunnels...
That property could be enforced simply: if the images for 2x tiles are not present in the pak, the way cannot be built in such tiles.
This is already in the patch. If a way has 4 slope images it can only be built on shallow slopes, if it has 8 it can be built on shallow and steep slopes.
As to whether this can be used in paks that's another question. pak128.Britain has existing slopes as the steeper of the two slope gradients supported, and I think this is also planned for pak128. This means that you must be able to build ways on the steeper slope to allow existing games to be converted (otherwise all rail slopes would disappear for example). pak64 doesn't have this problem as existing slopes will become the shallower of the two slope gradients supported - thus it doesn't even need any new way graphics at all.
Quote from: kierongreen on April 05, 2013, 12:34:31 AM
This is already in the patch. If a way has 4 slope images it can only be built on shallow slopes, if it has 8 it can be built on shallow and steep slopes.
As to whether this can be used in paks that's another question. pak128.Britain has existing slopes as the steeper of the two slope gradients supported, and I think this is also planned for pak128. This means that you must be able to build ways on the steeper slope to allow existing games to be converted (otherwise all rail slopes would disappear for example). pak64 doesn't have this problem as existing slopes will become the shallower of the two slope gradients supported - thus it doesn't even need any new way graphics at all.
Thus at the beginning players just can't use the shallow slopes in pak128 until someone draws those? At this point they can just decide to take out the steep slopes. Seems like a perfect solution for transition.
Shallow slopes must always be present, only steeper slopes are optional.
prissi - with that lightmap new images will be needed for ways as the shallow slopes are half existing pak64 ones.
I seem to remember someone writing that bridges only could be built from the steepest slopes. Is that the case? If bridges can be built from both shallow and steep slopes, several new images are needed for the ends, such as up from a shallow slope to match steep slope height at other end.
Bridges can be built from both types of slope, I've not coded there to be different graphics yet as it wasn't a real priority.
Nearly there for landscape, ways will take a while longer though...
(http://simutrans-germany.com/files/upload/pak64doubleland.png)
With those textures, sand will need more yellow ...
The lightmaps you provided do seem a bit dimmer than the previous ones used - I could brighten them, or alternatively as you suggest use a more yellow texture for sand. I don't want to play around too much with the style of graphics as I wouldn't want to interfere with the pak64 style.
It's completely impossible to make this patch able to load paks not updated yet to show double heights? That whould allow to incorporate it to trunk asap. I applied your patch and it works great, but now I can't load any other pak than pak128.britain with your modifications.
I tested pak128, pak96.comic and pak32, quite recent versions and all failedd to start, with a segfault, when they tried to generate images, it crashed here
case hang_t::suedwest*2:
all_rotations_slope[slope] = transition_slope_texture->get_bild_ptr(6)->copy_rotate( 180 );
all_rotations_beach[slope] = transition_water_texture->get_bild_ptr(6)->copy_rotate( 180 );
Can't we catch this error more gently and not segfaulting, marking it as not available or something.
If it can load older paks, I'd personally commit this now to trunk and let it go to next release so our users can use it already. It also easens development.
But that's only my opinion. And my excuses if you already discussed iover this, I missed that discussion.
Nothing is impossible, but having duplicate code for single and double heights active in the same binary is asking for trouble. Saved games would have to be incompatible between the two height types and it all just gets messy. Even having the conversion factor 1 and 2 started to make things a bit messy (and looking at the lightmaps prissi provided for pak64 I'm not sure was necessary but anyway...).
Adjusted brightness and contrast of lightmap - this any better?
(http://simutrans-germany.com/files/upload/pak64doubleland2.png)
Regarding segfaults - it's trying to rotate an image which doesn't exist. It's possible to have a more graceful error but it still won't load.
Urgh, I noticed those lightmaps are shaded from east rather than south, something else to fix...
As you wish, but waiting for paks to be updated for this I'm afraid it will take months or even a year for this patch to be incorporated then.
You know the code ofc, but isn't as simple as detecting the lack of 2xheight images and activate a flag that forbids any modification on the map that causes 2xheight difference on any tile of the map?
Flags slow things down. Also at present single height code uses 16 tile images, double height 81. This means different image offsets and so on. For a single height pak to load you'd have to translate all these offsets so it appeared to be a double height pak just with missing images (which hopefully would never be used else -> crash, and check to stop crash means slow down in performance).
As for it taking years, it's been one already, I've waited years before to get things into trunk. The patch is there if anyone wants to try and hack it to work with existing paks. It should be noted that when climates were first introduced a similar incompatibility happened. Generally as long as pak64 and pak128 load it's good enough for a release candidate.
Quote from: kierongreen on April 08, 2013, 12:29:30 AM
Flags slow things down. Also at present single height code uses 16 tile images, double height 81. This means different image offsets and so on. For a single height pak to load you'd have to translate all these offsets so it appeared to be a double height pak just with missing images (which hopefully would never be used else -> crash, and check to stop crash means slow down in performance).
Oh, didn't knew it changes offsets, then I understand the bug you mentioned on world borders, must be related to that. The fix will have to have #ifdefined DOUBLE_GROUNDS #else then. :)
If offsets have changed, I understand both algorithms shoudn't coexist in the game, you are right.
Anyway avoiding SEGFAULTS on lightmap should be done imho, and crash in a proper way (telling the user this pak is unable to be loaded). After all this calculation is done a few times in the game execution, not each frame, performance is not important there.
Quote
As for it taking years, it's been one already, I've waited years before to get things into trunk. The patch is there if anyone wants to try and hack it to work with existing paks. It should be noted that when climates were first introduced a similar incompatibility happened. Generally as long as pak64 and pak128 load it's good enough for a release candidate.
I want it incorporated so I don't have to think about how to integrate my code with it anymore, so we can all just work on other aspects of the game. So bugs on your patch become bugs of the game.
If it was for me I'd personally incorporate it in a week and break the back compability with not updated paks. It's a very nice patch, our players should be able to use it soon.
But it's your patch, won't insist more on this. ;)
Believe me it's just as frustrating keeping a patch up to date with changes going on in trunk!
To my mind plan of action should be:
Release a stable version of simutrans without double heights
Incorporate patch into trunk, compile release candidate for testing - at this stage if anyone wants to keep using old paks they can either keep using the stable version or compile their own version from source with DOUBLE_GROUNDS unset.
Once pak64 and pak128 are fully compatible, and new code has been tested release a new stable.
Some months down the line DOUBLE_GROUNDS #ifs can be removed along with old single height code to avoid having to maintain two lots of code.
Wanted to test some stuff tonight (and see what all will be involved to convert pak128 over), did a clean installation of Simutrans in to a different folder and put the newest patch files from April 3 over the clean install.
Got an error when running sim.exe:
FATAL ERROR: loadsave_t::rdwr_str() - expected "<i8>", got "<i3>"
Aborting program execution ...
Problem signature:
Problem Event Name: APPCRASH
Application Name: sim.exe
Application Version: 0.113.3.0
Application Timestamp: 515b5bf7
Fault Module Name: sim.exe
Fault Module Version: 0.113.3.0
Fault Module Timestamp: 515b5bf7
Exception Code: 40000015
Exception Offset: 001c5c4a
OS Version: 6.1.7601.2.1.0.256.48
I tried a few different approaches (put sim.exe in my trunk and put the pak file changes over my pak128.Britain install) but still got the same error result. I removed the demo.sve but it didn't matter.
When I run the regular simutrans.exe in the same folder it uses the modified lightmaps for pak128.Britain and it looks all funky, so I know that part is working fine.
Not sure if I am missing a step or if it just doesn't like me. :) Let me know if you need further details.
Quote from: Markohs on April 07, 2013, 11:59:48 PMIt's completely impossible to make this patch able to load paks not updated yet to show double heights? That whould allow to incorporate it to trunk asap. I applied your patch and it works great, but now I can't load any other pak than pak128.britain with your modifications.
My 2¢: we already have paksets that are 1 or 2 years outdated. It's impossible to get the major paksets ready for the new system in a few months. Is it possible to use placeholder graphics? In some games, when the engine finds a missing texture or graphic, the engine "paints" the objects or walls with a plain monochrome texture instead of crashing -- at least it "invites" people to complete the set. ;)
Unless there are too many required graphics that it's not worth doing.
sharlock it's the settings.xml that's incompatible too. on your simutrans user dir, i personally renamed it to test this so the game created a new one.
@Sarlock: please delete settings.xml. Kieron's patch has a small 'bug' concerning reading this configuration file.
@Kierom: Imho not having backwards compatibility (ie crashing with old paksets) is a show stopper. We should provide a work around programatically. By either
(1) distributing a set of lightmaps for all commonly used pak sizes
(2) computing not available lightmaps on the fly (stretching/scaling)
(3) disable double slopes if these images are missing (just no double slopes).
As to disabling double slopes: If not all images for light maps are there then treat the pakset as if the double height images are missing (then bridge and tunnel building works the old way). Terraforming is then restricted to single-height slopes. World generation has to obey this limitation as well. Imho no performance critic parts are concerned, only less ways of modifying terrain are supported. I would volunteer to work on this.
If the patch will be committed it should be done without any of those '#ifdef DOUBLEHEIGHTS'. After the patch has been submitted there is no point in supporting two ways of compiling the program.
(2) Seems reasonable, just supply a 128 or 256 pixels generic version and scale it up down/up if the pak we are loading doesn't supply one. That should do the trick.
This also makes creating new paks easier, because we have default lightmaps, the pak creator has the option to everride them if he wants to.
I offer my help whatever you need it too, ofc.
The game would be pretty much unplayable with placeholder graphics. Every tile on the landscape would look incorrect. However to just get a pak to load you will be able to copy the pak64 for 64 sized paks or pak128.Britain lightmap for 128 sized paks. That's the vast majority of paks covered - I know there are 32, 96 and 192 sized ones but how much are these actually used?
What do you think of suppling a default lighmap of let's say 256 or 32 pixels and scale to the needed one if the pak we load doesn't supply one?
All this calculations are just done on map creation/load, this shoudn't affect performance of the game.
If there's no proper graphics for double-height, then:
- For a normal user/by default: disable the double-height, since it's unplayable.
- For a pakset maker: enable double-height and load placeholder graphics, so that the maker can produce and test the new graphics.
I would agree to what Dwachs said. Probably just a pak option (like the diagonal_length=728) called "enable_doubleheight=1" Default would be of course off. Thus only paks enable this would do double height.
The only performance critical stuff is making very height mountains, due to the recurse calling sequence. It does not has to be recursive anyway, one could test a pyramide immediately. All other stuff should not matter I think so too.
Lightmaps scaling to paksize isn't guaranteed to work reliably. One reason I choose to use lightmaps to start with rather than just calculations was that I found it impossible to get the tiles to align correctly any other way. I'm trying to get pak64 working at moment if I have time I might try getting other paks to work.
Having single and double heights supported simultaneously is in my opinion just going to be messy both in terms of code and people using the program. At the moment there is a basic level of compatibility between all paksets - that would be broken if some were double height and some single.
Quote from: IgorEliezer on April 08, 2013, 09:59:46 AM
If there's no proper graphics for double-height, then:
- For a normal user/by default: disable the double-height, since it's unplayable.
- For a pakset maker: enable double-height and load placeholder graphics, so that the maker can produce and test the new graphics.
A set of default light maps seems to be sensible. Even when ugly it would work at least. With the setting where the height of today is normal height and double height is twice that way graphics would not be required to play. Building in restrictions seems seems superfluous.
There are only a few sizes required: 32 64 96 128 192. Two are already . For two more there are paks that are actively developed (comics). Including five sets of ptemade default light maps as a fallback?
This could even be done with the pak installer.
Yes, I thought that normal and double the height of way graphics was how prissi wanted pak64 to go, but the lightmap supplied is half and normal height. As such at present there are no heightmaps which would allow ways to be used without modification at present.
Anyway, flipped the lightmaps (more involved than I thought...). Problem is that the original lightmap had a light source actually from East North East, therefore flipping it gives a light source of south south west which doesn't quite match shadows which assume a light source ever slightly to east of south. See screenshot:
(http://simutrans-germany.com/files/upload/pak64doubleland3.png)
The lightmaps were done for OpenTTD, so half height as well as wrong shadow is likely from this. However, there is a graphics which spans the entire 64 pixel in height. THat could not be halfheight, of?
The installer is not used on unix. But for the paks on SF a new release could be easily made, by just adding the zip. However, then you will have lots impassable terrain, unlike older versions.
Well, the lightmap has a full set of halfheight tiles, however it also has some of the tiles necessary for double heights. Although 81 images are needed for 3x3x3x3 corner combinations infact 17 of these are duplicates, meaning it's actually only 64 images needed in game. This lightmap has an additional 21 images which are used to cope with up to 5 heights on diagonal tiles. This makes sense if they were designed for TTD - this had the possibility for 3 heights on diagonal tiles even when the rest of the tiles were single height.
Anyway, another comment regarding compatibility. This patch adds 3 main features to simutrans - climates, water height and double heights. The double height sections are all within #if DOUBLE_GROUNDS just as used to be the case. Therefore if this patch is applied, but DOUBLE_GROUNDS is left undefined then the only change necessary for existing paks should be to the texture transition images - water heights and climates should appear in game but ground height behaviour will be unchanged. This worked some time ago I'm not sure whether it still functions correctly.
This is very exciting!
Not related to development, but I have a question: I'm making a greyscale map for my future game. Since I want to do it for Pak Britain, which I understand is duoble height ready, and since this patch seems close to completion, I wonder if the greyscale done with the old parameters will still wor or what changes should I do to it to take full advantages of the new landscape.
Heightmaps work equally well with and without double heights. However the map will appear to be half the height it is at present as each tile height will be half the existing one.
Another quick note - I've now got all the #if DOUBLE_GROUNDS macros working again, and now with DOUBLE_GROUNDS left undefined existing patches work with the patch. I'll attach a new version here once I've fixed the bug with squares around map borders.
Is there any way, I wonder, of allowing for the full/double height slopes in a map generated from a height map?
I was about to ask something similar -- that is, will "steep" areas in heightmaps automatically generate double-height slopes? (Steep gradients are, as you know one of the things that the current heightmap system handles poorly).
Quote from: kierongreen on April 10, 2013, 10:27:20 AM
Another quick note - I've now got all the #if DOUBLE_GROUNDS macros working again, and now with DOUBLE_GROUNDS left undefined existing patches work with the patch. I'll attach a new version here once I've fixed the bug with squares around map borders.
I was just going to do that now, the function to fix is grund_t::display_border
Before DOUBLE_GROUNDS the x,y was assumed to be 3*height step upwards the center of the current tile to draw (iirc). With your patch that offset has changed. I can try fixing it with your patch (was applying it again now) or you can fix yourself, as you wish. :)
I've applied your patch and well, the fixed function, that fixes all glitches in both old version and DOUBLE_GROUNDS is this one, can you test it? I'll upload to trunk if it's ok in your oppinion.
void grund_t::display_border(const sint16 xpos, const sint16 ypos, const sint16 raster_tile_width, const uint8 border_direction)
{
if(!ist_karten_boden()){
return;
}
#ifndef DOUBLE_GROUNDS
const sint16 y_imp_offset = 0;
#else
const sint16 y_imp_offset = tile_raster_scale_y( TILE_HEIGHT_STEP*3, raster_tile_width);
#endif
// We'll paint 8*height from the center of the tile upwards, size width/2 on top borders (west and north)
if( border_direction & ribi_t::west ) {
const int height_to_paint = tile_raster_scale_y( TILE_HEIGHT_STEP*8, raster_tile_width);
const int corner_height = tile_raster_scale_y( corner1(slope)*TILE_HEIGHT_STEP,raster_tile_width);
const int y_origin = ypos + y_imp_offset - corner_height - tile_raster_scale_y( TILE_HEIGHT_STEP*5, raster_tile_width);
display_fillbox_wh_clip(xpos, y_origin, raster_tile_width>>1, height_to_paint, umgebung_t::background_color, false);
set_flag(dirty);
}
if( border_direction & ribi_t::nord ) {
const int height_to_paint = tile_raster_scale_y( TILE_HEIGHT_STEP*8, raster_tile_width);
const int corner_height = tile_raster_scale_y( corner3(slope)*TILE_HEIGHT_STEP,raster_tile_width);
const int y_origin = ypos + y_imp_offset - corner_height - tile_raster_scale_y( TILE_HEIGHT_STEP*5, raster_tile_width);
display_fillbox_wh_clip(xpos + (raster_tile_width>>1), y_origin, raster_tile_width>>1, height_to_paint, umgebung_t::background_color, false);
set_flag(dirty);
}
// We'll paint 8*height from the center of the tile downwards, size width/2 on bottom borders (south and east)
if( border_direction & ribi_t::ost ) {
const int height_to_paint = tile_raster_scale_y( TILE_HEIGHT_STEP*8, raster_tile_width);
const int corner_height = tile_raster_scale_y( corner3(slope)*TILE_HEIGHT_STEP,raster_tile_width);
const int y_origin = ypos + y_imp_offset - corner_height + tile_raster_scale_y( TILE_HEIGHT_STEP*3, raster_tile_width);
display_fillbox_wh_clip(xpos + (raster_tile_width>>1), y_origin, raster_tile_width>>1, height_to_paint, umgebung_t::background_color, false);
set_flag(dirty);
}
if( border_direction & ribi_t::sued ) {
const int height_to_paint = tile_raster_scale_y( TILE_HEIGHT_STEP*8, raster_tile_width);
const int corner_height = tile_raster_scale_y( corner1(slope)*TILE_HEIGHT_STEP,raster_tile_width);
const int y_origin = ypos + y_imp_offset - corner_height + tile_raster_scale_y( TILE_HEIGHT_STEP*3, raster_tile_width);
display_fillbox_wh_clip(xpos, y_origin, raster_tile_width>>1, height_to_paint, umgebung_t::background_color, false);
set_flag(dirty);
}
}
If you are using a simutrans executable with this patch applied heightmaps automatically use steep slopes yes.
Also can confirm that your fix works Markohs :)
Out of curiosity: in this new landscape system, will the climates be per-tile/region based or remain depending on the height levels?
On map generation (and when you raise or lower land) they are calculated depending on height level. However you can change the climate of any tile or region afterwards with the climate tools.
Commited @6446 then :)
Quote from: kierongreen on April 10, 2013, 03:41:26 PMHowever you can change the climate of any tile or region afterwards with the climate tools.
This is a thing, a good one.
I don't know the future plans as I sincerely don't want to push anything, but I see this as the 1st first step for a climate generation that is not so constrained to heights and looks more natural or simply random.
To see how this could be possible (I'd hate to look greedy on feature request), I made a search to find something about randomly generated regions for game environments: http://www-cs-students.stanford.edu/~amitp/game-programming/polygon-map-generation/ (http://www-cs-students.stanford.edu/~amitp/game-programming/polygon-map-generation/), the article looks interesting and the source code is available on github (https://github.com/amitp/mapgen2).
EDIT:
A demo is available for those who want to see how it works: http://www-cs-students.stanford.edu/~amitp/game-programming/polygon-map-generation/mapgen2.swf (http://www-cs-students.stanford.edu/~amitp/game-programming/polygon-map-generation/mapgen2.swf)
Don't forget about all the nice work already done here: NEW CLIMATES MODEL (was: The Equatorial Wind) (http://forum.simutrans.com/index.php?topic=984.0;all) ;)
Hahah... how could I forget that!
Can I bandwagon? A new geography for Simutrans: terrain, climate, towns, factories and stuff (http://forum.simutrans.com/index.php?topic=10438.0)
/me runs for the hills.
EDIT:
Hey, Fabio is reading this topic. I believe we will need a bigger bandwagon. :>
:thumbsup:
Excellent!
QuoteI don't know the future plans as I sincerely don't want to push anything, but I see this as the 1st first step for a climate generation that is not so constrained to heights and looks more natural or simply random.
One step at a time! Beaches are already dependent on more than just height, being based on the number of neighbouring water and land tiles as well. Having other climate features would not be that difficult :)
Igor - for what height of hill are you running?
By chance, did you mean the mountain height I like to play on? I like to use the max value, 320, and max value for roughness too, 7.
Max value for roughness is 10 with double heights by the way :)
Attached is the source for patch to 6448 trunk. pak64doubleheight-src.zip (http://simutrans-germany.com/files/upload/pak64doubleheight-src.zip) contains files to get the pak64 landscape working (pavement half height images are from pak64.Unity).
For pak128.Britain only change is to TextureGrounds.dat from the last release as only 5 images are needed now for this - the new ShoreTrans section is:
# these images define the beach transition
Obj=ground
Name=ShoreTrans
Image[0][0]=images/texture-shore.0.0
Image[1][0]=images/texture-shore.0.1
Image[2][0]=images/texture-shore.0.2
Image[3][0]=images/texture-shore.0.3
Image[4][0]=images/texture-shore.2.3
(the new pak128 branch will have to have this change applied)
I'm away for the next few days will make a proper release when I get back.
Oh by the way, Markohs - the patch you made to border tiles uses spaces rather than tabs to indent lines which doesn't match the style used in the rest of the code
Oh, ****, I found strange the diff showed so many different lines, but coudn't see what was wrong. That's what happens when you copypaste from forum.
Thx, will fix on next update. :)
Kieron, please REMOVE / REVERT this piece of the patch
--- dataobj/umgebung.cc (revision 6448)
+++ dataobj/umgebung.cc (working copy)
@@ -289,7 +290,7 @@
file->rdwr_bool( window_buttons_right );
file->rdwr_bool( window_frame_active );
- if( file->get_version()<=112000 ) {
+ if( file->get_version()<=113000 ) {
// set by command-line, it does not make sense to save it.
uint8 v = verbose_debug;
file->rdwr_byte( v );
This if-clause has no effect on your patch, but is responsible for the crash Sarlock reported above. I guess you did some global search & replace of file-versions, and this query on version was replaced unintended.
Ok will do when I get home.
Quote from: Markohs on April 10, 2013, 04:09:00 PM
Commited @6446 then :)
Is half height now in trunk then? Should I start enabling all the half height bits in the pak128.Britain code?
You could branch it the way we did in vanilla Pak128 ;)
Quote from: The Hood on April 13, 2013, 09:56:20 AM
Is half height now in trunk then? Should I start enabling all the half height bits in the pak128.Britain code?
I believe the only code added to trunk was that to fix the border.
Quote from: kierongreen on April 13, 2013, 10:04:37 AM
I believe the only code added to trunk was that to fix the border.
Thanks - nothing happening for now then.
Quote from: Fabio on April 13, 2013, 10:00:00 AM
You could branch it the way we did in vanilla Pak128 ;)
Kieron essentially has a branch for that purpose that he tests with. I'm hoping we can just copy those files over when we are ready to roll...
Quote from: kierongreen on April 10, 2013, 10:27:20 AM
Heightmaps work equally well with and without double heights. However the map will appear to be half the height it is at present as each tile height will be half the existing one.
Ok, thanks.
I'll try what happens when this will be included in some nightly.
I've made some new graphics and went to compile them with makeobj but it's asking for DLLs that I don't have... I'm really reluctant to just go out into the internet and start downloading DLL files because of the potential for damage.
libgcc_s_dw2-1.dll was the first one. I was able to find a copy that I *think* (hope) was safe.
Now it's asking for libstdc++-6.dll. I can't seem to find a site to grab this that I feel comfortable with. I imagine that since no one else is having this issue, they already have these DLL files. If someone can link to a safe copy I'd be very appreciative. And if there are any other DLL files I require after that one, it would help too :)
Is it intentional to require these DLL to be able to run the program? (pardon my computer programming illiteracy)
Where's your makeobj.exe from?
Asking for those .dlls indicates someone compiled it with MinGW but didn't statically link the standard libraries...
Edit:
Brainfart.... I assume you got it from kierongreens windows binary posting. For proper compatibility, you really to obtain the .DLLs from him. Any others might be from a different MinGW version and hence have issues...
@kierongreen - setting LDFLAGS = -static-libgcc -static-libstdc++
does the static linking...
Will have a look at that when get home. My windows builds are made with mingw running inside wine and tested with wine also so don't always pick up on these things...
Static linking seems to be enabled in simutrans but not makeobj for compiling under mingw - this is something that could be fixed in trunk.
Sounds good, I'll await an update regarding this question and continue to do the graphics conversion and test later. Thanks :)
Kierongreen, can you please post the latest patch file? (Or is the one you posted here is still the current state?)
Edit: I am working on making this patch work with traditional paksets. While I am at it, I will gradually remove the #ifdef DOUBLE_GROUND stuff.
Patch from latest trunk attached.
Regarding getting this to work with existing paksets. I'd really recommend not following this path because of potential errors but key things to think of are:
Will you have a variable in the saved game to store whether it is double height or not - will existing games be converted to double height if possible (this happens automatically at present)?
Will landscape when using existing paksets be converted to double height, but then heights limited to multiples of 2, or will you keep the landscape unconverted?
How will you deal with a double height map being loaded with a single height pakset
Edit
NOTE I've realised this version includes half ready code to have different images for bridges based on heights of slopes at the ends. It doesn't function correctly graphically in game but shouldn't cause any significant problems other than that.
I added a check in grund_besch.cc whether enough slope images are present or not. In the terraforming code I used
const sint8 max_hdiff = grund_besch_t::double_grounds ? 2 : 1;
Internally, it behaves like a double slope map, however slopes are restricted to the old single slopes. For the non-existent double slopes dummy images are generated. The indexes into border and marker images are converted internally.
Does this make sense?
What files did you change in you updated patch? I have updated it too here...
Quote from: kierongreen on May 09, 2013, 06:37:18 PM
Will you have a variable in the saved game to store whether it is double height or not - will existing games be converted to double height if possible (this happens automatically at present)?
Game will be internally double height, slopes are restricted to single height slopes.
Quote
Will landscape when using existing paksets be converted to double height, but then heights limited to multiples of 2, or will you keep the landscape unconverted?
I did not need to touch the loading part. Your implementation works ...
Quote
How will you deal with a double height map being loaded with a single height pakset
Add a fatal-error? do you think this case is realistic? Who will load a savegame, which was saved with a new pakset, with an old pakset?
I would like to throw out all the 'ifdef DOUBLEGROUND' stuff. What do you think?
Edit: I checked the difference between our patches with interdiff: they do differ in different places of the code, so no conflict...
Quote from: Dwachs on May 09, 2013, 06:57:01 PM
Who will load a savegame, which was saved with a new pakset, with an old pakset?
It will be someone who doesn't understand cryptic error messages. I'm certain of it.
Here is my patch. Imho, we can risk inclusion in trunk.
Quote from: Ters on May 09, 2013, 08:01:35 PM
It will be someone who doesn't understand cryptic error messages. I'm certain of it.
:) I tried: creating game with Kieron's modified pak128.Britain, loading in standard pak128.Britain: slopes are truncated, bridges are broken. It does not make sense to write code to transform such savegames.
Edit: there is some strange behavior of beach transitions for new created maps. If I do terraforming there and restore landscape, the transitions are then corrected.
Splendid (to quote James). Very good, that makes inclusion much easier.
This behaviour of beach transitions is intended :)
Edit: I think bridges will still be broken (graphically). I'm working on a fix for that though.
Edit2: Dwachs patch above doesn't include my changes to bridges. Therefore there's no fix required.
Dwach's patch updated to 6501. Have improved handling of bridges to prepare for graphics for 1 and 2 height end slopes (not actually implemented these yet though), and to correct hiding of asymmetrical pillars.
While both old and double height paks now work this is not foolproof. Loading an old (single height) saved game with an old (single height) pak crashes simutrans here (whereas loading it with a double height pak converts and runs correctly).
Edit:
Seems like that crash wasn't related to double heights as it also happens on trunk 6501 without patch applied. It's actually related to a missing factory pak (in the old pak128.Britain) and the new non-rectangular factory code. If a pak is missing then besch doesn't exist, therefore no valid building is returned for any of the factory coordinates, therefore trying to return the position of the building gives a segmentation fault.
Quote from: Dwachs on May 09, 2013, 08:23:55 PM
:) I tried: creating game with Kieron's modified pak128.Britain, loading in standard pak128.Britain: slopes are truncated, bridges are broken. It does not make sense to write code to transform such savegames.
No it doesn't, but an understandable, preferably translated, error message in the GUI is needed for such cases.
Split the bug report about crash with broken factories:
http://forum.simutrans.com/index.php?topic=11882.0
Here is an update. Did some tiny modifications to ribi.h and wegbesch.h.
It would be awesome if we could use the water animation also for the transition tiles. Would it be possible to implement this, Kieron? (not saying that you should be the one who implements..)
Edit: deleted patch
Water animation for transition tiles would be possible. You'd need to convert water animations to textures rather than tile images - then you'd need to generate flat images for each water depth, and slope images for water depth 0. For pak64 that means 5*8+64*8=552 images which is fine. The problem is likely to be having to redraw landscape tiles every animation step, as shore tiles require at least 2, more often 3 or more draws each (water, sometimes sand, land climate(s)).
Also your modifications to the code have broken climates only occupying 1 tile. Left shows behaviour as of 6500, right shows behaviour with 6503.
Quote from: kierongreen on May 11, 2013, 05:55:43 PM
Also your modifications to the code have broken climates only occupying 1 tile. Left shows behaviour as of 6500, right shows behaviour with 6503.
Did not notice that, I think this is already broken in the first patch I posted.
Edit: This is also broken in the patch against r6448 you posted above ???
Edit2: Updated patch. It seems that some index into transition_water_texture were wrong. The patch only uses index 0..3 and 11.
Since I seem to be timing everything lately, might as well here too:
sync_step sync: 2.5% slower. sync_step display: 1% slower. step: 2% slower.
Reasonable for the added features. This was with the normal yoshi game, so all single height, single climate per level.
A couple of anomalies - senke_t:sync_step was slowed 240%. possibly the get_climate() calls?
- karte_t:step pending season change slowed 17%.
- karte_t:step step players slowed 15%.
- karte_t:step step halts faster 25%. ??
None of these are overly significant to the overall, but standout as most affected.
What's the status with DOUBLE_GROUNDS? I note the compile fails without it defined. And with, it now loads old paks which is very good!
The water height tools can still use some work too. I frequently get greeted with 'Cannot alter water' when I would otherwise expect to be able to.
Taking flat terrain, and raising a levy around an area (slope up, slope down - no full level tile at the higher level) doesn't allow the raise water. But raise an extra ring of ground such that there's a slope up, level tile, slope down, and it allows the raise. You can then lower the outer ring ground back and things are fine.
You also can't raise the water up to the level of the surrounding flat tiles, yet you can use the set climate tile to set flat tiles to water and achieve the same thing. The results achievable using the tools should be the same IMHO.
TurfIt - try benchmarking when the view is showing some coastline - that'll give an idea of worst case performance hit.
The reason you can't have a one tile levy without a full tile at the higher level is that this would result in a transition with water at the top of the hill (which would look rather odd). As for raising water up to the level of surrounding tiles - the routine tries to cover all tiles at that height with water (and fails if any tile is occupied or it reaches the edge of the map).
The benchmark view was zoomed out at the default position the yoshi game loads to. Has about 30% water in sight - with the associated coast. Obviously no inland lakes since the game predates that ability.
I'll whip up some screenshots for the water tools to better explain...
(http://imageshack.us/a/img818/2876/simscr02watertool.png)
Won't allow the water raise inside the levy. If the levy is extended to have the flat tile too as shown to the east, then the raise succeeds. The extra flat tile can then be lowed again with the raised water remaining as shown to the north.
(http://imageshack.us/a/img822/7379/simscr03watertool.png)
Won't allow the raise. I'd expect the raise to occur resulting in what's shown above it. That was created using the set tile climate tool instead.
That's good if that slowdown is at maximum zoomout!
Btw snowline seems to be broken now as well...
Edit:
Right, with those levies with no central tile the issue is that it is finding no border at all as all tiles are at the same level - it's only tiles which have a greater height which are recognised.
Quote from: TurfIt on May 12, 2013, 12:08:38 AM
A couple of anomalies - senke_t:sync_step was slowed 240%. possibly the get_climate() calls?
these can be easily cached - it is only computing whether a snowy image should be shown.
Quote
- karte_t:step step players slowed 15%.
That is particularly funny, as spieler_t::step actually does nothing...
Quote
What's the status with DOUBLE_GROUNDS? I note the compile fails without it defined. And with, it now loads old paks which is very good!
I may have broken this. Imho we can throw all the non-DOUBLE_GROUND code away.
Here is the fixed patch - snow transitions working again. Took me a whole afternoon to find the reason, which was just a missing 'break'.
Many thanks have to say it had me puzzled too or I'd have fixed it :)
Was the change in the 6516 version in get_bild_ptr() intended here:
case hang_t::suedwest*2+hang_t::nordost*2+hang_t::suedost*2+hang_t::nordwest*2:
all_rotations_slope[slope] = transition_slope_texture->get_bild_ptr(0)->copy_rotate( 0 );
all_rotations_beach[slope] = transition_water_texture->get_bild_ptr(11)->copy_rotate( 0 );
break;
}
}
else {
all_rotations_slope[slope] = NULL;
}
break;
case hang_t::suedwest+hang_t::nordost+hang_t::suedost+hang_t::nordwest:
all_rotations_slope[slope] = transition_slope_texture->get_bild_ptr(0)->copy_rotate( 0 );
all_rotations_beach[slope] = transition_water_texture->get_bild_ptr(11)->copy_rotate( 0 );
transition_water_texture->get_bild_ptr(11) breaks compatibility with old non double height paks.
Reverting from 0,11 0,11 to the previous 14,4 0,0 appears ok. But I can't see anything wrong with the snowline even with 6503 and the missing break...
The final image from transition_slope_texture and transition_water_texture are images for a one tile section of climate surrounded by different climates on all sides. transition_water_texture->get_bild_ptr(11) doesn't need to be as high as 11, it could be 4 instead as only 0-3 are used, but transition_slope_texture does need to be at 14 as transition_slope_texture has a lot more images to allow for snow transitions. I thought the patch applied to 6516 worked but I'm going to test again today (unfortunately I have to go to work now so it will be this evening before I can confirm behaviour).
the following code functions correctly for both double height paksets and older ones:
case hang_t::suedwest*2+hang_t::nordost*2+hang_t::suedost*2+hang_t::nordwest*2:
all_rotations_slope[slope] = transition_slope_texture->get_bild_ptr(14)->copy_rotate( 0 );
all_rotations_beach[slope] = transition_water_texture->get_bild_ptr(11)->copy_rotate( 0 );
break;
}
}
else {
all_rotations_slope[slope] = NULL;
}
break;
case hang_t::suedwest+hang_t::nordost+hang_t::suedost+hang_t::nordwest:
if(transition_slope_texture->get_bild_ptr(14)) {
all_rotations_slope[slope] = transition_slope_texture->get_bild_ptr(14)->copy_rotate( 0 );
}
else {
all_rotations_slope[slope] = transition_slope_texture->get_bild_ptr(0)->copy_rotate( 0 );
}
if(transition_water_texture->get_bild_ptr(11)) {
all_rotations_beach[slope] = transition_water_texture->get_bild_ptr(11)->copy_rotate( 0 );
}
else {
all_rotations_beach[slope] = transition_water_texture->get_bild_ptr(0)->copy_rotate( 0 );
}
break;
Although thinking about it again if(double_grounds) should be just as good a check....
Anyway, attached is patch to latest svn with above code in.
Something still doesn't seem right with the transitions for non double ground.
simscr00 - double grounds.
simscr01 - single.
And, I still can't see any difference between 6503 with 14,4 0,0 and 6516 with 0,11 0,11 and now 6526 with 14,11 14,11/0,0. Where should I be looking? I find this entire huge switch full of magic numbers and not a comment in sight completely undecipherable.
Also, is it intended for single tile climates to have different sizes as shown in the screen shots? i.e. Setting a climate that used to be for lower heights at a higher level give a little dot whereas higher climates on a lower level extend into adjacent tiles.
Single height paks won't have the transition images to display climates properly, or the tools to create them. So unless you have added the tools to a single height pak, or loaded a game that was created in a double height pak then you wouldn't have different climates at the same height as shown in your screenshot. The only climate transitions you'll see in a single height game are those generated at map start, between climates at different heights, from land to beach to water, and to water directly. These all work correctly using the textures present in existing single height paks. I admit I've not tested a single height pak that's been updated to have climate transitions but not double heights but is this a likely scenario?
As for magic numbers - could maybe enum those? However that's likely to give rather cryptic too unfortunately as they'd be descriptions of the different textures. Some of these might seem to be obvious - straight, corner, dot for example, but there are variants of these to consider too. Comments would have the same problem as all you could add would be the slope type - which is already given in the line "case hang_t::suedwest+hang_t::suedost+hang_t::nordost*2:" for example.
I'll happily admit that the entire texture system (as first introduced years ago and extended with this patch) does have a bit of a voodoo programming feel to it but that's because it was all thought up in my head! See the transforms in create_textured_tile_mix for example...
The easiest way of thinking about this bit of code is that it calculates the texture to use when overlaying snow onto a tile with slope slope. The only non intuitive slopes are then hang_t::suedwest+hang_t::nordost+hang_t::suedost+hang_t::nordwest and hang_t::suedwest*2+hang_t::nordost*2+hang_t::suedost*2+hang_t::nordwest*2 (actually I'm pretty sure hang_t::suedwest+hang_t::nordost+hang_t::suedost+hang_t::nordwest isn't used) - these are transitions to the little dot climates. When I first coded the system water had a similar structure, but I then added climates too which allowed me to remove the more complicated water transitions. This means that while slopes need 15 transition textures water only needs 5.
That single tile climates have different sizes is purely a reflection of how the transitions work. A higher number climate spills over into neighbouring tiles. Water spills into all neighbouring tiles also. The only way to make these transitions consistent would be to split the transition over 2 tiles which is more effort, more textures, and lower performance.
The simscr01 attachment appears to show the four right climates with working flat (non-slope) transitions, and the water at the far left, only the two small squares appear transition lacking. Hence, I thought it was simply a problem displaying them, not that they didn't exist... but then why do those 4 look right?
I did add the climate tools to a non double height pak - just added the menuconf.tab entries.
Not sure how to make this code more readable, other than perhaps extensive comments. When I see " hang_t::suedwest+hang_t::suedost+hang_t::nordost*2", all I can think is WTF!
Beyond that, I think it's time to get this into trunk. It seems stable, and now has backwards compatibility with old paks/games, and with only a minor performance hit to old games.
If no one else has done any further work, I'll remove all the DOUBLE_GROUNDS #ifs. I don't think the 2.5% performance hit is worth maintaining a separate .exe for single heights.
Also, I'd like to give some consistency to the whitespace coding style - it's rather schizophrenic right now...
Quotehang_t::suedwest+hang_t::suedost+hang_t::nordost*2", all I can think is WTF!
Southwest corner Height 1, Southeast corner 1, Northeast corner 2, (Northwest corner 0 as not mentioned) - Simple! :p
QuoteI thought it was simply a problem displaying them, not that they didn't exist... but then why do those 4 look right?
The patch makes use of existing texture transitions where it can. This is enough to cover everything in single height paks apart from climate transitions to "dot" climates.
QuoteAlso, I'd like to give some consistency to the whitespace coding style - it's rather schizophrenic right now...
Well that's a wider issue in simutrans - I've tended to adopt the style of whichever section of code I've been working on at the time...
ahh. Corners - not slopes! I was having issues with southwest slope + southeast slope + ... !
But aren't transitions to 'dot' climates just 4 overlaid transitions from 'dot's? Anyways, not terribly important if can't be easily done; 'dots' should be rare.
Will never get to a consistent style if keep following whatever's there. I thought the policy was to always use the 'new' styles to slowly change things. Same with translations - slowly change to English.
I take it you have no further changes in progress... I'll try to get to the DOUBLE_ removal tomorrow and post up something I hope's ready for committal.
No changes in progress just this second and I'm not going to have any free time till Sunday. Transitions to dot climates are separate images not overlayed corners as there's no guarantee that overlaying would work.
Time for this to hit trunk IMHO...
There's still some work required to make the per tile climates truly functional - need to completely decouple from the old height based climates. The water level tools need to be have more intuitive rules too - as detailed above. But, that can all be worked on later; Patch is big enough as is.
Indeed once this patch is in trunk there are a few components that could be improved on easily by different people, initial climate distribution and water tools are a couple, but also bridges for example.
Why not, we just released. So now is the right time. Then it can ripen over summer (I fear).
I have end of semester, two conferences, and a lot of volunteering ahead. Ripening over the summer is more or less guaranteed, as long as we talk about graphics :)
Agreed, this looks like a good summer for ripening. I probably won't have much time for graphics until August.
My lawn and garden look nice though :)
Just move it to trunk now, we'll fix whatever comes around. And we just released, so go ahead imho.
(loving the fact that the patch was written by a pak128.Britain artist and therefore should be ready to go...!)
@kierongreen - let me know what/when to make changes, or alternatively you could upload them to sourceforge yourself if you have permissions?
Hi friends!
First of all: Many, many thanks for all your effort in this improvement!
As I would really like to see this work and include it in pak64.ho-scale, I downloaded Simutrans 112.4-6527 from the nightly page and the latest pak128.Britain for testing. But to my real shame I can't see any difference. What am I doing wrong?
For sure, it is obvious for me that I have to produce a bunch of graphics. But I am not afraid of that.
In case of pak64.ho-scale, I would like to reduce the overall height step to some 8 to 10 pixels, and the half height to 4 to 5. I am really, really curios about the result and all the new possibilities to build more realistic landscape and track/street systems. : - )
Go ahead with your great work! I love it!
Don't think I have sourceforge permissions. Just copy the latest pak128.Britain sources from this thread onto sourceforge. The only missing graphics are for maglevs.
Quote from: kierongreen on June 03, 2013, 09:53:02 PM
(...) Just copy the latest pak128.Britain sources from this thread onto sourceforge. (...)
Hm. Tried to search the 9 pages of this thread for a link to that sources. Without success.
Any hint or URL? : - )
http://forum.simutrans.com/index.php?topic=10242.msg115142#msg115142
That post has sources and compiled pak files.
And.... incorporated r6530.
A waring shows up in MSVC I guess in gcc too:
1>c:\code\simutrans\trunk\boden\wege\../../simworld.h(1654): warning C4244: '=' : conversion from 'sint16' to 'sint8', possible loss of data
What's the best option, to change the parameter of the function or making a explicit cast?
/**
* Sets water height.
* @author Kieron Green
*/
void set_water_hgt(koord k, sint16 hgt) { water_hgts[k.x + k.y * (uint32)(cached_grid_size.x)] = (hgt); }
water_hgths is a sint8 array.
Compiled and executed without problems, works with single height pak128 and with double height pak128.britain . Thank you for your work!
EDIT: I see the commit might be late for the nightly and not generate until tomorrow. I compiled it, you can download here (https://dl.dropboxusercontent.com/u/30024783/double/Simutrans.exe) for the curious. It's compiled with MSVC so it might not work on all computers since binaries seem to be pickier to distribute than mingw ones. Try installing http://www.microsoft.com/en-us/download/details.aspx?id=30679 if it doesn't work.
Or you can wait for next nightly.
No need for the sint16 there, I changed to sint8 - everybody calling this is passing a sint8 already.
GCC doesn't warn here.
I can't remember GCC ever putting up a warning about type size mismatches. A few weeks ago, I had mistakenly used the wrong type, and not a word from the compiler about it.
Thanks for adding to trunk :)
There seems to be some issues relating to loading old saved games that I'll look into later on today but I hope this particular bug was the crashing one I found a few weeks ago (which wasn't related to double heights, rather a pak file).
However one thing to be aware of is that while saved game compatibility when loading a save from versions prior to 112007 should be guaranteed for either single or double height paks there is no compatibility for versions greater or equal to 112007 (either from single to double or vice versa, at least when the double height pak has conversion factor two). This is because height scaling only happens once, when you load an old saved game.
Details on the issues?
The only thing I've noticed is the height conversion isn't applied when the demo savegame loads. But manually load it and it's ok.
Right - I've confirmed the crashing bug is still the one mentioned here (http://forum.simutrans.com/index.php?topic=11882.0) (so nothing to do with patch).
Regarding compatibility (half height pak here means a double height pak with conversion factor 2 - if you use conversion factor one you won't get these problems of course as the visual height step remains the same):
Old single height save loaded with single height pak - OK
Old single height save loaded with half height pak - OK, heights are converted automatically
New single height save loaded with single height pak - OK
New single height save loaded with half height pak - Loads but heights appear to be halved
New half height save loaded with single height pak - Loads but heights appear to be doubled
New half height save loaded with half height pak - OK
Whilst halving/doubling of heights is visual only it will make bridges look odd as there won't appear to be clearance for vehicles to pass underneath. When using half height paks building ways under bridges with height 1 is prohibited.
Is this really a problem though? Simutrans is quite permissive at allowing one to load savegames using a pak other than the one it was saved with. Up to the user to use the same pak if they want identical behaviour...
Being permissive is good. The problem comes with paks that are not converted straight away as players could be confused by changes in the landscape when/if it was finally converted.
Just a question. Does it mean that saving an old game again as old version will not work with the double height code? (So far you could still save games as 99.17.) If so, maybe one should also clean up a lot of this compability code then.
IS this also the reason, why you bumped the savegame version? (Usually, this is only done when everything is stable.)
EDIT: Saving the yoshi game under your patch as 99.17 and loading again crashes in the tunnel code.
EDIT2: Lowering a beach tile does not enlarge the beach. This should be standard behaviour with old pak, because these will have no tool to achieve this otherwise.
Also it would be great if someone would summarize the changes on a wiki page, as there are currently 14 paksets ...
The savegame version needed bumping so that maps actually using the double height feature save correctly. Otherwise the heights are corrupted on load. Such games using these new features can never be saved correctly with the old save format versions. But, an old game using an old pak should be saveable in the old versions - I get the same crash attempting it so clearly something broke...
The main reason saved game version is increased is because each tile now has a climate that needs to be saved. However the conversion code currently needs a version to decide whether or not to convert also. Alternatively we could save a flag to indicate whether the game has been converted.
By enlarging the beach do you mean the beaches generated on new maps with water and sand at the same height? This code is only run for generating new maps (or enlarging existing ones). Currently lowering/raising landscape resets surrounding tiles to default climate for that height.
Saving the yoshi game as 99.17 and reloading - does this work even before this patch? It may be that loading really old saved games is broken now?
If you have a flat beach tile at global water level, lowering the tiles next to it never generates water, even if they touch the water in one corner. Since the beach in new maps is now irregular (looking good actually) this happens frequently. Try enlarging the sea in pak 64 and you sure will come about an unexpected behaviour soon.
About he 99.17: Well it was working half a year ago, so indeed this may have been broken in between.
If you can give a link to the saved game I'll investigate further. As to lowering tiles near water - this automatically removes water from nearby tiles to try and prevent graphical glitches. Creating complex beaches as happens at map creation is possible but it really links in with a wider point - should there be default climates for each height, should there be a more complicated distribution, what should happen to climate when tile height is changed?
Saving Yoshi as 99.17, and 100.0 is broken pre this patch. - Fatals on load with "simlinemgmt - Broken Savegame". But, saving as 101.0 and up still works at r6529. This patch breaks that.
http://www.physik.tu-berlin.de/~prissi/simutrans/yoshi87-2-102.sve (http://www.physik.tu-berlin.de/~prissi/simutrans/yoshi87-2-102.sve)
Climates per tile needs to be decoupled from height levels to get any benefit IMHO (except for backwards compatibility). i.e. changing the height of a tile must not change the climate, otherwise complicated climate distributions become undone. I've been trying to adapt the rain4.m from the wind thread, and climates reverting on changing height was the first thing I noticed. The exact effect on climates from changing height will need to depend on the algorithm used to create the distribution. For rain4, I think it'll need to reapply the whole map on each height change. ughh.
Also, how hard would it be to add a couple climates? Ideally the number/names of climates would be on a per pak basis...
EDIT: updated saveversions that work.
Adding extra climates is a fair bit of work because at the moment permission bits are used in a byte. Shouldn't be impossible though. As for names well they can be translated to anything I think. Water and snow are the only fixed ones.
Changing height must to some degree affect climate, as it would look stupid to have two mountain peaks next to eachother, but only one covered with snow. That is unless the meaning of climate has changed, so that a tiles climate just defines at which level and time of year it receives snow and so on, not whether it actually has snow.
There are now two types of snow in the game - seasonal snow which rises and falls as the year progresses and overlies a base climate and permanent snow which is a climate in itself.
But there is still a progression of climates related to height. I think that is still needed (in the sense climates are at all), possibly combined with a horizontal variation in climates.
Climates now form a gradation from cold to hot and there is continuity because they are linked to height. If made independent of height or at least less dependent, I think that that continuity should be preserved: does it make sense to have tropical just close to snow?
Quote from: kierongreen on June 05, 2013, 04:38:58 PM
There are now two types of snow in the game - seasonal snow which rises and falls as the year progresses and overlies a base climate and permanent snow which is a climate in itself.
So we can now have the wrong type of snow? Excellent!
Quote from: isidoro on June 06, 2013, 12:17:17 AMdoes it make sense to have tropical just close to snow?
If snow occurs in a mountainous region next to an equatorial basin, e.g. Andes mountains next to the Amazonian basin. Yes, altitude plays a role.
Also, the probability of two climates to meet each other should be inversely proportional to the difference of temperature.
Desert x Tropical: 5/6
Desert x Mediterranean: 4/6
Desert x Temperate: 3/6
Desert x Tundra: 2/6
Desert x Alpine: 1/6
And/or, the probability of a hotter climate to occur decreases as the altitude goes higher.
Without having followed every post in this thread, it sounds like you are trying to implement something like biomes in Simutrans.
Minecraft have an excellent biome implementation. Maybe it's worth having a look to see how they implemented it?
Just a thought ;)
Quote from: Max-Max on June 06, 2013, 11:32:44 AM
Without having followed every post in this thread (...)
^^' o dear, not here. It's everywhere (http://forum.simutrans.com/index.php?topic=10835.msg113973#msg113973).
Well, that was another thread ;)
The idea of biomes has struck me too and it would be awesome if Simutrans was capable of creating maps with biomes that blend into each other nicely.
The blending is now taken care of, all that needs to be done is coding initial climate distribution. this might slow map generation down though...
Also please remember, climate are used in pak german to cluster bavarian, middle german and costal buildings together. Thus a "clustersize" for climates similar to forests is needed.
Thanks for incorporating this patch! I do not have much time at the moment to follow development.
I noticed that the structure planquadrat_t (simplan.h) now has three bytes wasted to alignment (both 32bit and 64bit builds). These bytes could be used to store water-height and grid-height (which is in karte_t simworld.h).
In addition, the back_bild_nr from grund_t could be moved to this structure as well (it is a property of the map ground - anything not on ground should not display cliffs). This would free an extra byte in grund_t, which could be used to store the extra byte from bridge grounds and water tiles. Then all grund_t have the same size, and the complete ground of a map could be allocated in one big memory block. This could speed-up karte_t::lookup_kartenboden, as the indirection to plan->get_kartenboden->check plan.data can be omitted.
Comments?
I would very much like to to this. But the different grounds treat stuff differently, especially water, fundaments and tunnels/bridgeheads? I think there is some more code magic needed until this works out. (It might indeed speed up lokkup considereably.)
Sounds good in theory! If there was spare memory it could maybe be used to do more caching of climate transitions. Or if people were wanting more climates that would need more memory also.
Here's a small patch to address a few issues with bridges reported here (http://forum.simutrans.com/index.php?topic=11982.0) (I also attached patch to that thread).
When will this patch be included into Simutrans?
It's already in. nightly builds have it, and the next release will havr it too