I do not know about adding a tool the the game menus.. although it would be nice! I was more thinking about modifying the savegame file to set the sealevel one level lower, making your bridge, then editing the savegame again to restore the sea level. It would depend mostly on how hard the game engine would be to add sea level changes.
A lot, I think. Some are purely cosmetic: making your game look "pretty." Others are gameplay issues: Let's say you have a thriving transportation company operating in a large city. Planning and logistics becomes a nightmare. So you decide to build an underground subway network to move goods (and people and mail) about. Ideally, you would like to just demolish one tile (one of the already existing stations) and turn it into an entrance to the underground network.
As it is, you'll have to demolish not just the one tile, but at least one or more others nearby so you can modify the land for a slope, plus you'll have to allocate land for the exit somewhere nearby, even if you intend to demolish it afterwords. All of this costs a lot more money than simply creating a single tile entrance. (And you know how the accountants back at corporate HQ are about allocating the budget.. )
It would also simplify the construction of such a network. No need to modify several tiles of land, only to demolish them afterwords, etc.
Not necessarily.. I cannot see the ability being added to the game engine itself.. but I might be able to figure out a work-around based on an idea from another post: If we could temporarily lower the sea level, build the pathway/bridge, then raise the sea level back up, the game engine should happily draw it correctly. Of course, I am ****uming a lot about how the game engine operates.. if it just draws the tiles and graphics according to what the map says is there, without any checking for sea level, etc, it can be done.
Ahh, OK. Thanks.. I must not have pressed the control key fully when I tried it before. :/
Anyhow.. What I was suggesting was have tunnel entrance/exits be just that.. not place a whole section of tunnel between two of them. Then (if the road/rail/etc tools were enabled) we could create pathways that wander where ever, cross where ever, etc.
EDIT: It might even make possible underground entrances that go down into flat land tiles, rather than always requiring a slope to build the tunnel.
OK The first tile under the bridge needs to be a land tile with a pathway (if I delete the bridge, that tile reverts to the pathway, road or rail, accordingly). What you want to do is enable the game to build a pathway one tile into water, so you can start a bridge (without all the ugliness that raising land/creating artificial slopes causes).
I think that would be very nice to have.. allowing bridges at the waters edge to start rising _into_ the water instead of forcing a slope before the water. But I cannot see it being added: Tiles at sea level are always water, while land is one level above sea level. The only time you'll have the situation of building a bridge at the waters edge then, is when you have a tunnel at the edge, because you'll _always_ have a slope at the edge, never a flat land tile.
You need to use the tunnel tool (the same one you create the entrances - or complete straight tunnels - with) not rail or road tools.
The tunnel tool just gives a "no suitable ground" error. The only thing I can seem to do is build a straight tunnel, then use the tunnel tool to create a side spur. But I cannot delete one of the tunnel ends afterwords, or it deletes the side spur, too.
Anyhow, I am thinking I may have a technical issue on my end more suitable for the help forum, so let's not hijack this thread!
I downloaded http://downloads.sourceforge.net/simutrans/simuwin-sdl-101-0.zip last week -- So whichever one that is. It does not allow underground crossings, and when I switch to underground mode, the pathways toolsbars change to allow only stations, signals, etc. No road or rail.
What, you cannot read the tone of his font!? :O (Sorry, couldn't help myself )
In terms of realism.. tunnel crossings and intersections are very dangerous due to limited visibility, and generally a very bad idea.
But in terms of game playability.. because this is a game and only _simulates_ a portion of reality, and as such, cannot do some things that can be done in reality (multi-level tunnels, for example), I agree that pathways should be allowed to intersect/cross underground. We can always pretend that one pathway is just on a lower level than the other..
Actually, I have wondered why we cannot simply lay pathways underground, allowing tunnels which curve slightly and do not match up to exits on a straight line. (That is, why can't we place a tunnel entrance, go underground and lay the road/rail to another point, and then place the exit?) An example of such a tunnel is the Fort McHenry Tunnel (http://www.roadstothefuture.com/Fort_McHenry_Tunnel.html) in Baltimore, Maryland, USA, which carries highway I-95 traffic under the harbour, and curves the entire length.
I might just do that.. But like the developers, I'd like to know if there's even enough real _interest_ in such a patch before committing my time and effort to it.. or even a better way to go about doing it..
Perhaps I can. But I, too, have a family and a job, and a lot less investment or incentive in the game to improve it at this point. Plus, there is a development forum for those who wish to join development and write code. I would thusly ****ume the extension requests forum is for those who wish to request an extension and discuss them more fully.
So, I would kindly ask that you post something useful to the discussion, rather than a curt "do it yourself" type reply. Do you (or others) like the idea? Would you find it useful? Are there any technical issues you can foresee that I have missed? Is there something you think might improve the suggestion and make it even better for the game? Would it detract from the game? Et cetera.
Perhaps, once these questions are answered, I'll have the incentive and motivation to start learning the code and try..
Yes, you can save games in XML format.. However.. a newly created 512x512 map, immediately saved as XML is 109+ megabytes on my system. It also has every last detail of the game data, of which 99% is probably useless to the purposes I am proposing. Further complicating things, the data is not self-documenting, so extracting the data wanted would require enough code that I would just devote the time to writing a new game rather than a tool to extend and enrich SimuTrans.
Extracting the data from a binary save file might be easier, if the save file format is clear and well-documented/well-structured.
But ultimately, the game already has code to extract most if not all of the desired data.. the same code that puts it on the game screen could be modified to dump it to a file instead. (Without having seen the source code, I do not know how difficult such mods would be.. but if it's too difficult, then maybe the code needs to be re-written anyhow!)
Add an option to export/dump various bits of game data into one or more simple file formats (comma/tab separated, xml, etc) for easy import into external tools (such as spreadsheets, etc.)
Of course, only export/dump data which makes sense and can be useful in writing external tools to aid gameplay, logistics planning, etc. Things like the current list of goods prices, costs (and availability at the time of data dump/export) of new vehicles, station locations (and possibly distances between? Or maybe node lists for pathways..), lists of vehicles in operation/storage, industries, lines, financial data, etc.
Basically, I started looking for game data tables to put into a spreadsheet to help me plan convoy configurations and line planning. But much of the game data is specific to each game, it's pak, and other settings, so there are no 'universal' tables.
Personally, I do not think converting to "MPH" alone is such a good idea.. What I think would be a good idea is to simply internationalize the UI the same way it's done for languages. Internally, the game/code/cpu/whatever does not care if 1+1 is in miles or kilometres or martian zilwiks. All the game codes cares about is that 1+1 equals 2, whatever the type of units.
In truth, when I write software that I know is bound for an international market, I follow a few simple rules:
1) All input is converted into "standard units". That is, regardless of the input units, be it imperial or metric, I convert it on input into whatever unit makes the _code_ easier to write and maintain. For example, in financial software, I convert dollars, pounds, yen, etc., into FU's ("financial units"), which are roughly USD$1.00 to 10000000FU (which is large enough that converting back to almost any other world currency won't cause significant rounding errors.)
2) All internal calculations are done in the internal standard units. There are few, if any, conversions done in calculations, IF the internal/standard units are well chosen. Using FU's for example, since FU's are accurate to several decimal places no matter which currency is used for input or output, I generally do not have to worry about any conversions, rounding errors, etc. (For a game like this, though, scaling things like the maps may be a good idea. However, that really is not a "conversion" so much as a "scaling factor", which is not much different to calculate for drawing than it is to calculate the zoom level.)
3) All output is sent to functions which convert the internal standard units into whatever units are specified by the system locale, or a user defined locale, which are then output to the UI.
Doing it this way allows the software to run regardless of locale settings, and if done right, can even allow the user to set up custom conversions.. Image SimuTrans with the Mars pak using [hypothetical] Martian units, or a space pak version where the playing field is many light years of space between star systems.. Much like people have modding other games to their favorite genres. Such a game would have far more appeal to more people!
Of course, this would not be a trivial or minor project as far as code is concerned. It would require a lot of codework, and therefore would need to be an ongoing project. But I think it would be worth it in the long run: Once the input/output routines are in place, and the UI updated, the game becomes infinitely flexible. It might also make maintaining the code much easier, since the I/O conversions free the game engine from needing to worry about many different units--all code can be written using simple internal units that best fit the needs of the code.
Is it possible?...
Mine work just fine. 
)