The International Simutrans Forum

Simutrans Extended => Simutrans-Extended development => Topic started by: jamespetts on January 21, 2009, 12:20:03 AM

Title: Simutrans Experimental [Original thread]
Post by: jamespetts on January 21, 2009, 12:20:03 AM
Archive thread - no further information will be added here. See other threads in the Simutrans-Experimental forum for more information

Introduction

As many forum regulars may be aware, I have recently developed a number of patches that are designed to have a substantial impact on gameplay. These patches have not yet been included into the trunk, quite probably because that impact has not yet been fully tested. I thought that it might be helpful if I produce a single experimental version, containing all of the various alterations that I have made to the code, for people to be able to test the gameplay impact of my modifications for themselves. I will release both the source code and a Windows binary so that people can see the modified source code all in one place, and also so that people without the wherewithal or inclination to compile from source can test (and even, if it is found to be stable enough, play with) my modified version. The experimental version is based on the latest nightly at the time of release - partly for that reason, and partly because my new features are not fully tested - it should be considered beta software and used accordingly.

I will keep this original post updated with the latest information on the progress of this experimental version as matters progress. I am also currently working with the PakBritain team, and hope for there to be a release (possibly an interim release) of a version of PakBritain that takes advantage of the extra features in this experimental version (but is also compatible with the default version) fairly soon.

Getting the necessary files

1. Source code

Simutrans-Experimental now uses a version control system ("VCS") called "Git" (as written by Linus Torvolds, no less), and no longer uses patch files (which can be hard to apply). The Simutrans-Experimental Git repository is here (http://github.com/jamespetts/simutrans-experimental/tree/master). For a tutorial on how to use Git, see here (http://nathanj.github.com/gitguide/tour.html). The standard Simutrans SVN is also mirrored on Git here (http://github.com/aburch/simutrans/tree/master). Git is compatible with Linux and Windows (and possibly also MacOS X, although I have not verified that).

It is recommended that those who wish to get the source code for Simutrans-Experimental setup a separate directory for doing so than that used for the normal source code. Anyone wishing to contribute to coding for the Experimental version is welcome to do so, using Git's very flexible branching system (which makes it far easier to merge a branch back into the trunk than is possible with SVN). So, unlike with standard Simutrans, to make an alteration to the code of Simutrans-Experimental, do not upload a patch file - fork the code in the standard Git way. Any modification that is included in Simutrans-Experimental will be included by way of re-merging the code, rather than applying a patch. Please let me know if you have forked the code so that I can merge back in any desirable new features!

2. Modified configuration files

The attached file Simutrans-experimental-config.zip contains all of the modified configuration files required for the experimental version, including:

(a) simuconf.tab:

This is my configuration file sample, needed because many of my modifications need their own configuration settings. This is an example from PakBritain-Experimental, but should be able to be modified for other paksets easily. The new features are, I hope clearly, documented.

(b) privatecar.tab:

This is a special configuration file, needed for one of the new features incorporated into this version: competition with private cars.

(c) en.tab:

These are slightly revised translation texts for the English language, as there is no specific Simutranslator entry for some of the new texts that have to be translated for the additional features. If anyone wants to produce a non-English version, please reply to this thread with the amended file attached.

(d) speedbonus.tab:

This is a modified speed bonus file for Pak128, taking into account the modified speed bonus system used in this experimental release. This may change again when the new revenue system is implemented.

3. Program files (binaries)

These are the files that will be needed if you cannot or do not want to compile Simutrans-Experimental from source. Simutrans-Experimental may well be added to the official nightly builds (albeit not as often as nightly) in the near future, but, for the time being, a Windows executable version of Simutrans-Experimental can be downloaded here (http://simutrans-germany.com/files/upload/Simutrans-Experimental.zip), and a Windows executable version of Makeobj-Experimental (for making assets that take advantage of Simutrans-Experimental's new features) can be downloaded here (http://simutrans-germany.com/files/upload/Makeobj-experimental.zip). (Note: new version)

List of modifications

Note: This list of modifications is only updated with every binary release of Simutrans-Experimental. Binary releases of Simutrans-Experimental will be less frequent than code updates on Git. For modifications to the source code on Git, see the commit comments.

I have included all of my recent patches, plus one or two patches produced recently by other regular contributors, but not included in the trunk. I have assumed that those patches have been released under the Artistic licence, and that the authors will, therefore, have no complaint about their code being included. If I am mistaken in that view, please contact me via PM and ask to have your patch removed from the experimental version.

1. Modification of speed bonus for local transport*; and

2. increase of running costs for obsolete vehicles, both explained further here (http://forum.simutrans.com/index.php?topic=980.0).

3. Modified passenger generation, including local weighting and alternative destinations, explained further here (http://forum.simutrans.com/index.php?topic=992.0).

4. Competition with private cars, as discussed further here (http://forum.simutrans.com/index.php?topic=1188.0).

5. Cornering, weight limits and tilting trains, as discussed here (http://forum.simutrans.com/index.php?topic=1157.0).

6. Way constraints (new in this version - fully implemented in the code and UI) as also discussed here (http://forum.simutrans.com/index.php?topic=1157.0).

7. Catering level (implemented in .dat files and UI only - currently has no effect on gameplay. Also, mail vehicles with a catering level above 1 are treated as "travelling post office" vehicles, but no effect on gameplay is yet coded), as also discussed  here (http://forum.simutrans.com/index.php?topic=1157.0).

8. Enhanced physics for steam locomotives.

9. Industries close down at a random point between 0 and 30 years after their retirement date. A message is displayed in the ticker when an industry closes down. Any other industries in the same chain either re-link to another supplier/consumer, or, if they cannot find one, close down themselves.

10. The origins of goods/passengers/mail are displayed with vehicles and stops (New in this version: origin data now saves).

11. Automated replacement of vehicles, by Isidoro, (updated to be compatible with way constraints) discussed here (http://forum.simutrans.com/index.php?topic=1428). (New in this version): data on replacing vehicles now saves: replacing will occur as planned when reloading from a saved game when convoys are saved as being set to be replaced.

12. More sophisticated handling of debt (including: customisable interest on debt, an option to turn off bankruptcy, and a credit limit, beyond which no further capital purchases can be made (which can be disabled)). More details on this feature here (http://forum.simutrans.com/index.php?topic=1302.msg16054#msg16054).

13. (New in this version) Accurate reversing for trains, including different types of trains taking longer to reverse: see here (http://forum.simutrans.com/index.php?topic=1302.msg17285#msg17285) for more details. (Note: this will only work with customised pakset data, made using a recent version of Makeobj-Experimental)

14. (New in this version) Variable loading time for all vehicles: see here (http://forum.simutrans.com/index.php?topic=1302.msg17437#msg17437) for more details. (Note: this will only work with customised pakset data, made using a recent version of Makeobj-Experimental)

15. (New in this version) Upgrading (rather than buying and selling) of vehicles, fully integrated with the vehicle replacing system;  see here (http://forum.simutrans.com/index.php?topic=1302.msg17437#msg17437) for more details. (Note: this will only work with customised pakset data, made using a recent version of Makeobj-Experimental)

* This will become obsolete when item no. 1 on the to do list is completed.

Please note also that the experimental version excludes a feature of some of the more recent nightlies, the revenue being based on the straight line distance between the start and end point of the whole journey, rather than for each transfer. It has been omitted because it would be difficult to integrate with the existing code, is not entirely realistic, and will be redundant once the new revenue system is in place.

Note: (New - 15th of March 2009) The save game files produced by Simutrans-Experimental are no longer compatible with save game files produced by standard Simutrans. Simutrans-Experimental can load save games from standard Simutrans, but standard Simutrans cannot load files saved by Simutrans-Experimental. This new version, however, enables data, such as the weight limits of tracks/roads, etc., the origins of goods, which vehicles are being replaced and so forth, to be saved.

To do

There are a number of further plans that I have in relation to work on this experimental version. In approximate order of priority so far:

(1) revised revenue system, with revenues based on journey times and accommodation level, not the maximum speed of vehicles;

(2) full implementation of catering and travelling post offices;

(3) a system in which labour costs (and possibly other costs) vary depending on the year;

(4) an implementation of overcrowding for passenger services;

(5) a more sophisticated means of passengers/goods choosing which route to take to travel, or whether to take their private cars as opposed to public transport, based on the new revenue model described at (1) and (possibly) the quality of services metrics being developed by Isidoro; and

(6) merge in the underground view and underground slopes patches if this has not already been included in the trunk.

Known issues

1. The sort ordering for goods in transit or at stations does not work - this is associated with origins tracking, although the reason is not entirely clear.

2. When goods from different origins have the same destination, they are not combined together in the GUI for convoys or stations, even when the mode is not set to sort by origin.

3. Interest payments are not shown in the finance history window. Fixing this requires reversioning the save game files.

Fixed bugs

15th of February 2009

1. Cornering speeds would often be incorrect when more than one vehicle was moving at once.

2. Detection of overweight vehicles became erratic when more than one vehicle was moving at once.

3. (Fixing items 1 and 2 might also have resolved occasional crashes that had not hitherto been traced or reproduced effectively).

4. Crash (assertion failure) when loading a saved game.

5. Crash (uninitialised variable) sometimes when loading saved games.

22nd of February 2009

6. Occasionally, vehicles set to be replaced automatically will not go to the depot automatically as they should.

7. Instability and unexpected behaviour when vehicles unload in a game that has been loaded from a saved game.

26th of February 2009

8. Crash (access violation) on some occasions relating to the code for detecting when vehicles are climbing hills.

15th of March 2009

10. Origin data are not saved.

11. Maximum weights on track are not set correctly when loading a saved game.

Feedback

The whole point of this experimental version is to enable people to experiment. I should be very grateful for any feedback that people have from using this experimental version, particularly as regards: (1) bugs; and (2) gameplay/balancing issues. Please, however, do not post about bugs or gameplay issues until you have verified that the bugs/issues are present only in the experimental version, and cannot be reproduced in the standard nightly (if they can, please make a stand-alone bug report in the usual way). I should also be grateful for any suggestions for improvement, although please be aware that, because I am busy with work, I may not have the time to implement even good suggestions.

Happy experimenting!
Title: Re: Simutrans Experimental
Post by: isidoro on January 21, 2009, 12:55:32 AM
My code (and my body) is free for testers...  Go ahead.
Title: Re: Simutrans Experimental
Post by: jamespetts on January 21, 2009, 08:55:38 AM
Quote from: isidoro on January 21, 2009, 12:55:32 AM
My code (and my body) is free for testers...  Go ahead.


Thank you :-)
Title: Re: Simutrans Experimental
Post by: jamespetts on January 21, 2009, 10:33:28 PM
Update: Both source and binary versions are now updated for official Nightly 2259 (21 Jan. 2009), and the configuration files are consolidated into a single .zip file for convenience and speed.

Further update: Experimental 0.2 contained a bug which would cause the game to crash whenever a vehicle reached a stop. An updated version is now available that fixes that.
Title: Re: Simutrans Experimental
Post by: jamespetts on January 24, 2009, 01:24:19 PM
New: Windows binary for Makjeobj-Experimental now available, to allow asset authors to make assets compatible with the new features in Simutrans-Experimental. See the original post for the link. Also, reference has been added in the future features list to changing labour costs, etc., over time, as well as a reference to overcrowding.
Title: Re: Simutrans Experimental
Post by: z9999 on January 25, 2009, 01:57:54 PM
Is it possible to rewrite the code for GCC safety ?
I can't compile your code on MinGW + MSYS because of too many errors, and I gave up.
Title: Re: Simutrans Experimental
Post by: jamespetts on January 25, 2009, 02:01:57 PM
Z9999,

ahh, I wasn't aware that there were errors that would be produced on some compilers but not others with this code. Can you give me an idea of what those errors are and where in the code they are to be found?
Title: Re: Simutrans Experimental
Post by: Frank on January 25, 2009, 02:11:48 PM
Quote from: jamespetts on January 21, 2009, 12:20:03 AM
...
Edit: Binary version for Windows now available here (http://simutrans-germany.com/files/upload/Simutrans-experimental.zip).
Edit 2: Binary version of Makeobj-Experimental (for compiling assets compatible with the extended features in Simutrans-Experimental) available here (http://simutrans-germany.com/files/upload/Makeobj-Experimental.zip).

pleace delete the www. from links
Title: Re: Simutrans Experimental
Post by: jamespetts on January 25, 2009, 02:25:09 PM
Quote from: Frank on January 25, 2009, 02:11:48 PM
pleace delete the www. from links

Done :-)
Title: Re: Simutrans Experimental
Post by: sojo on January 25, 2009, 07:51:27 PM
Quote5. Cornering, weight limits and tilting trains, as discussed here
I have tested the cornering. I think it looks good for trains but not so good for road-vehicles.

And i had the feeling sometimes some vehicles drive to fast. (It were citycars).
Title: Re: Simutrans Experimental
Post by: jamespetts on January 25, 2009, 08:32:35 PM
Sojo,

interesting comments about road vehicles - have you tried adjusting the values in simuconf.tab? All the various cornering settings are adjustable by waytype in simuconf.tab, so you can reduce the impact of corners just for road vehicles. If you find some values that you think are better than the default, let me know, and I'll try them out, and, if they work, include them as the default in a subsequent release. Thank you for your work!
Title: Re: Simutrans Experimental
Post by: sojo on January 25, 2009, 08:34:39 PM
I have done no changes. I have used my normal simuconf.tab without any of this settings.
Title: Re: Simutrans Experimental
Post by: jamespetts on January 25, 2009, 08:47:56 PM
Ahh - to make Simutrans-Experimental work properly, you need to use a specially adapted simuconf.tab: a copy is included in Simutrans-experimental-config.zip. The reason for this is that there are a number of Simutrans-Experimental specific settings that need to be set in simuconf.tab.
Title: Re: Simutrans Experimental
Post by: Fabio on January 26, 2009, 10:26:09 AM
and is experimental simuconf.tab back compatible with standard simutrans?
Title: Re: Simutrans Experimental
Post by: z9999 on January 26, 2009, 12:53:05 PM
You don't have MinGW, then it's okay. Don't mind, thank you.  :)
Title: Re: Simutrans Experimental
Post by: jamespetts on January 26, 2009, 05:07:11 PM
Fabio,

yes, it should be, since additional parameters in the file not supported are simply ignored.

Z9999,

what OS were you trying to compile it in? I use MSVC++ Express Edition, as recommended in the thread explaining how to compile the code. MinGW is a Windows compiler, so, if you are using Windows, you can just use MSVC++ Express Edition (free). If you are using Linux and cannot compile there, that is something that I'd need to fix.
Title: Re: Simutrans Experimental
Post by: Fabio on January 26, 2009, 05:08:10 PM
Quote from: jamespetts on January 26, 2009, 05:07:11 PM
yes, it should be, since additional parameters in the file not supported are simply ignored.

good to know! ;)
Title: Re: Simutrans Experimental
Post by: jamespetts on January 31, 2009, 07:08:43 PM
Update: Simutrans-Experimental source code is now available on Git (http://github.com/jamespetts/simutrans-experimental/tree/master): see the original post for details. The source code has also been updated since the original release, and now includes the latest rivers code as well as other recent enhancements.
Title: Re: Simutrans Experimental
Post by: wernieman on January 31, 2009, 09:38:49 PM
.....

for git you need a git-Client?
(Have you an example for the acess?)

Or can I use svn???
Title: Re: Simutrans Experimental
Post by: jamespetts on January 31, 2009, 09:54:24 PM
Yes, indeed one needs a Git client for Git (which was recommended to me over and above SVN). The process of downloading and installing the Git client for Windows is explained in this (http://nathanj.github.com/gitguide/tour.html) tutorial.
Title: Re: Simutrans Experimental
Post by: wernieman on January 31, 2009, 09:55:55 PM
Installing no Problem (Linux) but using .....

I say to you, that I make a spezial run for you experienze ... so the Server need the sources ..
Title: Re: Simutrans Experimental
Post by: jamespetts on January 31, 2009, 10:29:22 PM
Here (http://www.kernel.org/pub/software/scm/git/docs/user-manual.html)'s some information on how to use Git - but I'm not sure that I really understand your second sentence.
Title: Re: Simutrans Experimental
Post by: DirrrtyDirk on January 31, 2009, 10:31:21 PM
I read it that way, that's he's going to make a special nightly version - and for that his server needs the sources.
Title: Re: Simutrans Experimental
Post by: wernieman on January 31, 2009, 10:39:31 PM
Dirk .. you are good.....

I need the sources of the simutrans-experimental for compiling.

Have your git an anonymous access?? (Read Only)
Title: Re: Simutrans Experimental
Post by: jamespetts on January 31, 2009, 11:13:22 PM
Dirk - thank you for the translation! Yes, I hope that I've got it setup to allow anonymous access. Try here:

http://github.com/jamespetts/simutrans-experimental/tree/master
Title: Re: Simutrans Experimental
Post by: jamespetts on February 02, 2009, 11:41:47 PM
Update - new binary and features

A new release of Simutrans-Experimental is now available (updated binaries linked from the original post; updated source code on Github), with all of the revisions of the trunk up to and including r2287 (incorporating the removal of the vehicle noise at fast-forward: that has now been removed from the list of Simutrans-Experimental specific features, as well as the ever popular rivers), and a new experimental feature: enhanced steam locomotive physics.

Steam locomotive physics - in detail

In standard Simutrans, steam locomotives are treated in exactly the same way as any other locomotive, but, in reality, their performance characteristics are different (as this article explains: http://www.railway-technical.com/st-vs-de.shtml (http://www.railway-technical.com/st-vs-de.shtml)). The main noticable effect of these differences are that steam locomotives are slower to accelerate and give poorer performance on gradients than diesel or electric locomotives of the same overall power. Those differences between steam and diesel/electric traction had a marked impact on the development of railways. Firstly, it lead to early railways being constructed to avoid gradients as much as possible, even if it involved relatively tight corners, since the reduction in speed necessary to take corners was far less than the reduction in speed that a gradient would bring about; secondly, it was part of what was responsible for a strong preference on the part of railway operators to replace steam with diesel and electric traction, when the technology became mature, especially for suburban services (involving regular starting/stopping) or services in areas with steep gradients.

Simutrans-Experimental now incorporates these physical characteristics in a somewhat simplified form. The precise mechanism is largely invisible to the player, who will only notice that steam trains perform worse at low speeds than diesel/electric trains of the same overall power. This should make network design choices more interesting, as well as giving players more incentive than they currently have to use electric trains early in the game, when their maximum speed and power is low. I have tested the new physics carefully with Pak128 and Pak64, and it seems to balance about right (with the exception of the RVg 0-4-0-T in Pak128, which is now underpowered, and cannot haul more than 3 coaches without being restricted to 3kph: the problem, I suspect, is a combination of the gear being set at 0.8 and the contemporary carriages being too heavy: making the settings more favourable to low powered locomotives than they are made other locomotives perform too well). PakBritain, unfortunately, is not currently balanced well in respect of steam locomotive power, so the effect of this feature is largely unnoticeable there (some steam locomotives have a gear factor of over 3 - the Princess Coronation class accelerates like a Ferarri with or without this feature). No doubt, rebalancing will come in time.

One thing for both players and asset authors to bear in mind is that this feature works by reducing the effective power of the locomotive at lower speeds. To take account of the fact that some steam locomotives are designed to run at low speeds and others at high speeds, without having to add a tractive effort factor to all the assets in the game (which would require a great deal of work to be re-done), the system that I have implemented assumes that a locomotive with a lower maximum speed per unit of power has more of its available power at the lower end of its speed, whereas a locomotive with a higher top speed has a greater proportion of its power available at higher speeds. The practical effect of this is that more powerful steam locomotives with lower top speeds (such as, for instance, the LMS 8F and BR 9F - indeed, most locomotives with a larger number of smaller driving wheels) have better acceleration and gradient climbing abilities than their faster cousins. This is balanced against the fact, of course, that they have a lower top speed. Thus, there is, with this feature, a greater differentiation between locomotives designed for freight work and locomotives designed for passenger/mail work than there is in default Simutrans.

I should be very interested for people to test this new feature (using the binary provided; or you can compile from the sources if you prefer) and give views as to whether I have balanced it correctly. I should also be interested in thoughts on whether there are any other (relatively simple to code) ways of improving locomotive physics, preferably that (1) have a substantial, balanced and realistic economic impact on the game; and (2) do not require changes to all existing vehicle assets to make work properly. Please reply to this thread with any thoughts.
Title: Re: Simutrans Experimental
Post by: prissi on February 03, 2009, 08:20:33 AM
Simutrans has no meaningful physics, if you look into the acceleration formulars. Those would bring any Newtonian to cry in despair. Trust me, I teach them every year. I tried the "correct" formulars too, but on the Simutrans scale those simply did not look neither realistic nor nice.

Moreover the power of any engine rail is in reality not the only constrait, there is also the tracktive effort (see TTD Patch for elaborate discussion) which ultimately give the max. accelleration at low speeds, where power is in excess. Also steam engines perform worse at high spoeed, when the steam consumption rate exceeds the boiler area. A steam engine has a certain power only at a certain speed. (Also electric engines has different posers ratios. Usually electric engines can give much more power, up to 100% for short time scales than their 1h nominal power. For instanc ethe 103 can give 10300 kW peak power but is rated for 7400kW.) The only meaningful power is for diesel engines; even more since they ran more or less at constant revolutions (compared to car engines at least).

By the way, how does the japanese engines work then? THose are very weak, same for old age engines.

And Simutrans has all modes of transport and thus the formula has to fit them all and (since we are a game) must be good looking too. It even worked somehow on planes, even though it was introduced before. Since there is only a few steam trucks and apart from that only steam ships, it might be still ok.

(On a side note, However, it would be easier to discuss you changes if you showed the relevant section of the code without requiring to install git to get all code and then look in simconvoi.cc for the changes.)
Title: Re: Simutrans Experimental
Post by: jamespetts on February 03, 2009, 11:12:38 AM
Prissi,

thank you for your thoughts - it is always useful to know about the physics end of things from a physicist. I am aware that the physics in Simutrans do not try to be exactly accurate because of the nature of the game - it would be a different matter if it were a train driving simulator, of course. My intention with this change is not to have Simutrans simulate accurate physics for the sake of it, but to increase the accuracy of the physics only in so far as it has a substantial economic impact on gameplay, and steam engines accelerating from a slow speed more slowly, and having more trouble on gradients seems to be a good start.

You mention one or two other interesting facets of physics that I am wondering whether to attempt to incorporate. Firstly, the reduced efficiency of a steam engine at very high speeds; so far, I have taken the speed limit given in the vehicle file as the expression of that loss of efficiency, but do you think that the effect is significant enough that I ought also make them slower to accelerate when they are nearing their top speed by reducing the effective power when a locomotive is within, say, 10% of its maximum speed? If the reduction in power was subtle enough, and slowly phased in, that might give a good effect (and look more realistic, too, than a vehicle accelerating at a near linear rate then suddenly stopping accelerating) without having too drastic an impact on things.

I am interested also in what you have written about electrics, but I am not sure that I fully understand. Is the electric engine's ability to deliver higher power output for short periods something that might usefully have an economic impact on the game, or is it too rarely used to make a real difference?

I am also aware of the different modes of transport (although there is nothing to stop there being code to give different physics models to different modes of transport, of course, with a simple switch case on the wtype), although altering steam physics in this way ought not have an impact on other modes of transport, since (1) steam road vehicles would largely be subject to the same effect (they did not usually have gearboxes); and (2) if there was ever a problem with anomalous effects for non-trains, it would be easy to add a test in the code to see whether the vehicle is a train before applying the new formulae.

As to the code, if you set up a Git repository for Simuntrans-Experimental, you can see the new code for each individual revision by using the "visualise history" setting in Git-GUI. Did you want me to paste the relevant code into this thread for further discussion?
Title: Re: Simutrans Experimental
Post by: Spike on February 03, 2009, 11:22:11 AM
I like the idea of having different engine characteristics for the steam engines. The "power" value is often discussed, and together with the "gear" value Simutrans already is pretty detached from real world engine powers (still people want to see those numbers in the vehicle specs, otherwise they complain).

While in general I think that special cases are bad for maintainability of a program, Simutrans-Experimental seems to be the proper playground for testing such ideas, and if you get along with the maintenance of Simutrans-Experimental, despite the added complexity, it's even better.

Summary: Variation is good, realism not necessary on this level IMO.
Title: Re: Simutrans Experimental
Post by: prissi on February 03, 2009, 01:18:40 PM
SInce GIT is only available for a very limited number of platforms and the discussion can surface in half a year or so again, pasting the relevant changes ensures we are talking about the same.
Title: Re: Simutrans Experimental
Post by: jamespetts on February 08, 2009, 04:57:04 PM
Update: New version of the binary available, which now includes a system of industries retiring between 0 and 30 years (the upper number can be set in simuconf.tab) after their in-built retirement date has passed, if the player is playing with the timeline enabled. This enables pakset authors to simulate a changing world/economy, and gives players with established industry connexions later in the game a greater challenge in having to adapt to changing circumstances. Industries in the same chain as those that close down either relink to other suitable industries, or close down themselves if there are no suitable other industries.
Title: Re: Simutrans Experimental
Post by: The Hood on February 08, 2009, 05:00:36 PM
That sounds awesome.  The only problem is that I said I would draw more industries when you had done this.  Why did you have to do it so fast? :p
Title: Re: Simutrans Experimental
Post by: jamespetts on February 08, 2009, 05:01:22 PM
*** to you, too :-p
Title: Re: Simutrans Experimental
Post by: VS on February 08, 2009, 05:08:00 PM
Oh, wow. I hope the industry changes are one day ported back, because this is one of the things I was always hoping for...
Title: Re: Simutrans Experimental
Post by: jamespetts on February 08, 2009, 05:20:24 PM
VS,

I'm glad that you like it. You could always just play Simutrans-Experimental, of course ;-)
Title: Re: Simutrans Experimental
Post by: VS on February 08, 2009, 05:25:57 PM
Play? Sadly that word is not in my dictionary.
Title: Re: Simutrans Experimental
Post by: jamespetts on February 09, 2009, 11:56:02 AM
Note: I have discovered a bug in the 8th of February version that will cause the game to crash when it is saved. I have fixed the problem in my own copy of the sourcecode, and hope to upload a fixed version of the executable within a few days.
Title: Re: Simutrans Experimental
Post by: jamespetts on February 10, 2009, 12:28:33 AM
Update: The bug of the 8th of February version is fixed. Saving works once again. Also, the origins of goods/mail/passengers are displayed.
Title: Re: Simutrans Experimental
Post by: jamespetts on February 15, 2009, 08:56:03 PM
Update: I have released a new binary, including (1) Isidoro's vehicle replacement patch (adapted for Simutrans-Experimental's way constraints), as discussed here (http://forum.simutrans.com/index.php?topic=1428); and (2) a bugfix for issues relating to cornering and weight limits where, in effect, each vehicle's cornering and weight settings would contaminate settings for all others. The settings are now properly separated, so cornering and weight limits should work as designed.
Title: Re: Simutrans Experimental
Post by: z9999 on February 15, 2009, 10:04:06 PM
I don't believe someone playing with this.
Both previous version and current version can't load any savegames.
It will crash after loading any savegames.

Quote
Assertion failed!

Program: ...
File: .\vehicle\simvehikel.cc
Line: 745

Expression: ok

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts

(Press Retry to debug the application - JIT must be enabled)
Title: Re: Simutrans Experimental
Post by: jamespetts on February 15, 2009, 10:40:25 PM
z9999,

thank you very much for your bug report. Looking into this, it is very odd - the bug occurs only on a release build. With a debug build, the bug does not occur at all. The problem is, it is not easy to debug a release build because the optimisations interfere with the debugger. I will have a go at debugging it, but, in the meantime, can anyone think what the problem might be?
Title: Re: Simutrans Experimental
Post by: prissi on February 15, 2009, 10:50:04 PM
For Releasebuilt, assert should be undefined ...
Title: Re: Simutrans Experimental
Post by: gauthier on February 15, 2009, 10:50:12 PM
a bit offtopic :

I haven't followed this topic, what's exactly "Simutrans experimental" ?
Title: Re: Simutrans Experimental
Post by: jamespetts on February 15, 2009, 11:21:44 PM
Prissi,

yes, I'm aware of that, but, despite putting "NDEBUG" in "PreprocessorDefinitions=" in the .vcproj file, for some reason, asserts still seem to be on. I'm currently combing the code for any asserts with side effects.

Gauthier,

read the first post of the thread for a detailed explanation ;-) In essence, Simutrans-Experimental is a branch of Simutrans containing some revisions to gameplay and newer features not found in the trunk, either because they are too new (such as Isidoro's vehicle replacement tool), or because they change the gameplay significantly (such as a number of my economic changes; for example, having private cars compete with the player's passenger transport depending on the year).

The idea of Simutrans-Experimental is ultimately as a testbed for the addition of greater economic depth and realism to Simutrans. If, after testing, it is decided not to add the features to the trunk because those who maintain the trunk prefer a different style of gameplay, the aim is to continue to produce this branch as a variant of Simutrans with different gameplay, to appeal to those who prefer economic accuracy. Have a look at the first post in the thread for a list of current and planned changes to get a flavour of the sorts of things that are different.

Edit: I have found why all the "assert()"s were on: have a look at the following code in simdebug.h:


#ifndef simdebug_h
#define simdebug_h

// do not check assertions
//#define NDEBUG 1


// check assertions
#undef NDEBUG
//#define NDEBUG


#include <assert.h>


Whatever the compile options, debug is set to be on in any event! I still do not understand, however, why the assert is failing in substance: an assertion failure means that something is wrong somewhere, even if the error should be suppressed in a release build. Can anyone cast any light on why the value of the data itself would be different in the debug than the release build? The code is:


slist_iterator_tpl<ware_t> iter (kill_queue);
while( iter.next() ) {
total_freight -= iter.get_current().menge;
bool ok = fracht.remove(iter.get_current());
assert(ok);
}
Title: Re: Simutrans Experimental
Post by: gauthier on February 15, 2009, 11:38:34 PM
... Maybe you should do this in Simutrans experimental ?
=> http://forum.simutrans.com/index.php?topic=1523.new#new

This extension would help me very well for making my addons ...
Title: Re: Simutrans Experimental
Post by: jamespetts on February 15, 2009, 11:44:05 PM
Gauthier,

thank you for the suggestion :-) Unfortunately, I am not terribly good at things involving geometry, which your suggestion would, so I'd not be the best person to do that, even if I didn't have quite a long list of things already planned (see the first post for details). However, if somebody else were to code the patch, and it didn't look as though it was going to make it into the trunk any time soon, I'd be glad to add it to Simutrans-Experimental, if it was stable enough and, on testing, the GUI was easy to use :-)

Update: By removing the "#undef NDEBUG" line, the compiler options for debugging now work correctly. The assert failure is no longer present when loading a saved game: the binary file has now been updated. As a side effect of removing all the assert statements, the executable file is now a good many kilobytes smaller - performance should be slightly improved, too.
Title: Re: Simutrans Experimental
Post by: prissi on February 16, 2009, 09:22:29 AM
Well, probably a compiler issue with MSVC. I would anyway suggest to supply debug builds to get useful error informations. Even the normal SImutrans has assertions usually enabled, since otherwise bug reports are even harder to reproduce.
Title: Re: Simutrans Experimental
Post by: jamespetts on February 16, 2009, 11:19:54 AM
Prissi,

it's not a compiler issue - if there's a line "#undef NDEBUG" in the code, that will override the "NDEBUG" precompiler setting. Commenting out "#undef NDEBUG" removed that effect.

And I'm not sure that I agree with having all the debugging options on in a release build, increasing the possibility of assert failures (which might, but for the assertion, pass harmlessly), increasing the size of the code and reducing the performance: for code designed for playing rather than testing (i.e., release builds), the sensible setup is one that maximises performance and minimises error. Any bugs reported by users can then be reproduced by recreating the circumstances in which the bug arose in a full debug build, with the debugger on: one can just ask the users to upload a savegame to files.simutrans-germany.com.
Title: Re: Simutrans Experimental
Post by: Combuijs on February 16, 2009, 11:40:58 AM
QuoteAny bugs reported by users can then be reproduced by recreating the circumstances in which the bug arose in a full debug build, with the debugger on: one can just ask the users to upload a savegame to files.simutrans-germany.com.

Yes, but you can't ask for his computer, his operating system and the environment it is running in. Lots of bugs are caused by just that. The key for bug repair is not changing the source code but to reproduce the bug. This is often very tedious and time consuming.

To give you an idea: in the professional software package my company produces we have made a release version of ASSERT. It's by far the most efficient way to reproduce bugs. The loss of performance is neglectable these days. Causing the software to crash at the place where first things are going wrong is immensely valuable.

On the other hand, we release a "release" version, not a debug one.
Title: Re: Simutrans Experimental
Post by: HeinBloed on February 16, 2009, 01:46:28 PM
Hi,

I want to report two crashes with the latest binary (compiled on Feb 10th):

The first one happens very often when I initialize a new map (from a custom height map). It doesn't happen ALL the time though, a few times it went through and I could play the map.

The second one happened only once so far. It occured right when the vehicle you can see in the attached screenshot reached the station. Maybe it's of help for debugging that I had saved the game after the bus had already loaded some passengers. It said "from unknown" as origin then for those passengers after re-loading the game.

EDIT: screenshots are in the wrong order
Title: Re: Simutrans Experimental
Post by: jamespetts on February 16, 2009, 02:29:53 PM
Combuijs,

In the event that a bug could not be reproduced, a debug build could easily be sent to the end-user to test whether any asserts are triggered.

tttron,

thank you very much for your bug report :-) But are you sure that you have the latest version of the binary? You give the date as the 10th, but I released a new one yesterday (the 15th), which contained a number of bug fixes. If you can't get it to work with the latest version, please do let me know by replying to this thread :-)

Edit: Both of those are assertion failures, which means that you are using an older version. Incidentally, do you get these failures in the normal Simutrans? I ask because they are in areas of code not directly affected by my modifications. That does not rule out the problem being specific to Simutrans-Experimental, but it ought be investigated.
Title: Re: Simutrans Experimental
Post by: HeinBloed on February 16, 2009, 02:46:15 PM
Quote from: jamespetts on February 16, 2009, 02:29:53 PM
thank you very much for your bug report :-) But are you sure that you have the latest version of the binary? You give the date as the 10th, but I released a new one yesterday (the 15th), which contained a number of bug fixes. If you can't get it to work with the latest version, please do let me know by replying to this thread :-)

Edit: Both of those are assertion failures, which means that you are using an older version. Incidentally, do you get these failures in the normal Simutrans? I ask because they are in areas of code not directly affected by my modifications. That does not rule out the problem being specific to Simutrans-Experimental, but it ought be investigated.

Hmm are you sure you uploaded it to the server? I re-downloaded it from http://simutrans-germany.com/files/upload/Simutrans-Experimental.zip just now, but it's the same file. And no, I didn't get any of those two failures in default Simutrans 101 - didn't test any nightlies or even default 102 yet though.

Edit: Ok, the map initialization failure happens with 101, too. I hadn't tried with a custom height map (of that size) so far.

Edit 2: The map initialization failure is gone in the latest nightly, 102-2325.
Title: Re: Simutrans Experimental
Post by: jamespetts on February 16, 2009, 03:02:26 PM
Tttron,

thank you for your reply :-) Simutrans-Germany was down when I last tried it, (firstly, I could not access it at all, and then I could access it, but not delete my file) so I have uploaded the file to a temporary location, which is linked in the opening post of this thread.

Thank you for checking the map initialisation failure against 101 standard. I do merge the updates from the nightlies into Simutrans-Experimental periodically, so, if the main developers have fixed the standard version, Simutrans-Experimental should be fixed, too. Have a look at the opening post of the thread to download the new version, and see how you get along :-)
Title: Re: Simutrans Experimental
Post by: HeinBloed on February 16, 2009, 03:24:19 PM
Quote from: jamespetts on February 16, 2009, 03:02:26 PM
Simutrans-Germany was down when I last tried it, (firstly, I could not access it at all, and then I could access it, but not delete my file) so I have uploaded the file to a temporary location, which is linked in the opening post of this thread.

Ah ok, my bad I didn't check the other link (I had certainly seen your note). You should maybe rephrase the text though as it still says "and a Windows executable version of Makeobj-Experimental (for making assets that take advantage of Simutrans-Experimental's new features) can be downloaded here", where "here" points to the game binary. ;)

Edit: I can't reproduce the other crash with my savegame with the new binary. Origin is still set to "unknown" (I think you mentioned in the patch description that origins don't get saved yet), but no crash upon arrival at the station.

Edit 2: I wanted to test the new replacement feature, but it doesn't seem to work...? Either that or I'm doing something wrong. When I complete the Replace dialog (cf. screenshot), the buttons of all vehicles in the line turn red and say "Replacing", and "No load" is set, too. But then they just keep on cycling the schedule forever, driving past the depot all the time but not entering it. Is the depot meant to be added as a stop in the schedule anyway?
Title: Re: Simutrans Experimental
Post by: z9999 on February 16, 2009, 05:19:01 PM
Thank you. Now I can load Simutrans-Experimental savegames.
Another question. Is it difficult to load original simutrans games ?
Most of them will crash after loading.

For example, start pak96.comic and demo game will be loaded at first.
This game will crash soon.

Quote
Simutrans-Experimental.exe caused an Integer Divide By Zero at location 00467e13 in module Simutrans-Experimental.exe.

Registers:
eax=00000030 ebx=00000000 ecx=00000000 edx=00000000 esi=00000005 edi=0066044c
eip=00467e13 esp=0013e4f4 ebp=0013e60c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206

Call stack:
00467E13  Simutrans-Experimental.exe:00467E13
00468A4E  Simutrans-Experimental.exe:00468A4E
00465B7A  Simutrans-Experimental.exe:00465B7A
0049771B  Simutrans-Experimental.exe:0049771B
004495B9  Simutrans-Experimental.exe:004495B9
0047F15B  Simutrans-Experimental.exe:0047F15B
0047F17D  Simutrans-Experimental.exe:0047F17D
00449EE1  Simutrans-Experimental.exe:00449EE1
00450CC2  Simutrans-Experimental.exe:00450CC2
0047D00F  Simutrans-Experimental.exe:0047D00F
004718E0  Simutrans-Experimental.exe:004718E0
004318F9  Simutrans-Experimental.exe:004318F9
7C817067  kernel32.dll:7C817067  RegisterWaitForInputIdle
Title: Re: Simutrans Experimental
Post by: prissi on February 16, 2009, 08:19:25 PM
The not-replacing is due to convois never get empty, even if they pass the stations in question. I saw this too, but saw no obvious reason.
Title: Re: Simutrans Experimental
Post by: jamespetts on February 16, 2009, 09:05:49 PM
tttron,

thank you for your latest bug report - it is always most helpful to have feedback! The part of the code - the replacement of vehicles - with which you are having trouble was written by Isidoro, although I adapted it to work with some of the features of Simutrans-Experimental. Could I ask you to test with the version of the executable found here: http://simutrans-germany.com/~patches/download.php?file=sim-wingdi-replacing-r2260.zip (which is just Isidoro's original version of the vehicle replacement feature, without any of the Simutrans-Experimental additions) to see whether you still get the problem then? If you do, there is a bug with the vehicle replacement code itself, which should be reported in this (http://forum.simutrans.com/index.php?topic=1428.new;topicseen#new) thread. If not, then I will have to look into it further, since it would be my changes that would have caused the problem. If you are not able to reproduce it with Isidoro's clean version, please send me the saved game so that I can look into it.

Edit: Incidentally, thank you for pointing out the error in relation to the download links on the original post - I have edited the post now to correct the error.

Z9999,

oddly, I have been unable to reproduce this one. I tried, both with release and debug builds, loading Pak96.Comic and  letting the demonstration game run for a fair while (in fast forward mode, too), and had no problems. Is it only Pak96.Comic that gives you trouble, or do you also have problems loading saved games from, say, Pak64 or Pak128? I have not noticed any difficulty in loading saved games with the latest version of Simutrans-Experimental - certainly, there should not be any additional problems loading games saved in standard Simutrans, since I have not knowingly changed the save game format.

Prissi,

ahh, interesting. Perhaps, then, the vehicle replacement code should, when a vehicle is marked to be replaced, also mark it not to load? Or does it do that anyway? Isidoro - if you are reading - do you have any thoughts?
Title: Re: Simutrans Experimental
Post by: HeinBloed on February 16, 2009, 09:22:51 PM
Quote from: prissi on February 16, 2009, 08:19:25 PM
The not-replacing is due to convois never get empty, even if they pass the stations in question. I saw this too, but saw no obvious reason.

Before I try James' proposed executable, let me just say that the buses actually had 0 passengers.  ???

Quoteahh, interesting. Perhaps, then, the vehicle replacement code should, when a vehicle is marked to be replaced, also mark it not to load? Or does it do that anyway? Isidoro - if you are reading - do you have any thoughts?
As I said, the "No load" button gets activated when I use the replacement dialog, and it works as intended.
Title: Re: Simutrans Experimental
Post by: jamespetts on February 16, 2009, 09:30:10 PM
Hmm, perhaps Prissi's diagnosis is not correct, then. Either that or we have misunderstood what he meant. I'd be grateful if you could try Isidoro's binary, tttron, to see whether the problem is the original code or my integration.
Title: Re: Simutrans Experimental
Post by: HeinBloed on February 16, 2009, 09:32:17 PM
I will, as soon as the download server works again. ;) Getting a timeout atm.
Title: Re: Simutrans Experimental
Post by: prissi on February 16, 2009, 09:32:37 PM
Even though no-load was on it was not unloading certain passengers.
Title: Re: Simutrans Experimental
Post by: z9999 on February 16, 2009, 10:03:57 PM
Crashing is 90% of my games, include 64, 96, and 128.

I found someting. In pak96.comic demo game,it crashed the train reached a cretain track which max. weight is 74579648. See attached screenshot.
Title: Re: Simutrans Experimental
Post by: jamespetts on February 16, 2009, 10:19:33 PM
Z9999,

thank you for that information - it does indeed look as if one of my modifications has caused this (weight limits). I am not sure how, though, or why I cannot immediately reproduce it. I shall look into that.

Update: I have found the problem: in some cases, the weight limit variable was not initialised properly on loading a game, causing a crash when that variable was accessed. I have temporarily fixed the problem by setting a default value for the weight limits, but this often obliterates the true weight limits when a game is reloaded. A proper fix will involve reversioning the save game files, which I will do in due course. Thank you for spotting that problem - it is most useful! I have uploaded now a fixed version of the binary (and am about to upload the source), so do try it and let me know how you get on.
Title: Re: Simutrans Experimental
Post by: HeinBloed on February 17, 2009, 01:00:30 AM
James,

I've tested with the executable you linked earlier (http://simutrans-germany.com/~patches/download.php?file=sim-wingdi-replacing-r2260.zip) - the replacement does work with that one. Just to be sure, I started another game with your Experimental executable and the replacement still didn't work as described above. Did you try it for yourself with your executable?
Title: Re: Simutrans Experimental
Post by: isidoro on February 17, 2009, 01:22:44 AM
Quote from: jamespetts on February 16, 2009, 09:05:49 PM
Isidoro - if you are reading - do you have any thoughts?

I'm reading, James. :)  Did you adapt the seventh version of the patch?  The sixth was completely broken.

Title: Re: Simutrans Experimental
Post by: z9999 on February 17, 2009, 05:28:12 AM
Thank you. Max. weight problem was solved. It shows 999.
But still many of savegames cause crash within 1 minute after loading.
Maybe there is another problem.

Several games shows same location in error message.

Quote
Simutrans-Experimental.exe caused an Access Violation at location 0040a980 in module Simutrans-Experimental.exe Reading from location 000002a8.

Registers:
eax=0013e4e8 ebx=00000000 ecx=00000000 edx=000002a8 esi=00000046 edi=000003fc
eip=0040a980 esp=0013e4c4 ebp=0013e4c8 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206

Call stack:
0040A980  Simutrans-Experimental.exe:0040A980
00484D11  Simutrans-Experimental.exe:00484D11
004A19E5  Simutrans-Experimental.exe:004A19E5
004A357F  Simutrans-Experimental.exe:004A357F
00450986  Simutrans-Experimental.exe:00450986
00450C85  Simutrans-Experimental.exe:00450C85
0047D08F  Simutrans-Experimental.exe:0047D08F
00471960  Simutrans-Experimental.exe:00471960
00431969  Simutrans-Experimental.exe:00431969
7C817067  kernel32.dll:7C817067  RegisterWaitForInputIdle
Title: Re: Simutrans Experimental
Post by: jamespetts on February 17, 2009, 08:59:35 AM
Tttron,

thank you for testing that - I will have to integrate Isidoro's latest version of the patch and try it again.

Isidoro,

thank you for updating the patch: I cannot remember which version that I tried, except that it was the one before the latest one that you have recently posted. However, I had terrible trouble trying to get it to merge, because I use Git, whereas patch files are designed to work against SVN. Git does not seem to have a system of working with patch files. Do you think that you could use Git branches as well as SVN patches for your code modifications? There is a Git repository both for Simutrans-Experimental and normal Simutrans, and it is designed such that any single patch can effectively be made a branch, which is very easy to merge back with the trunk. PM me if you would like more information on how to set it up.

Z9999,

Hmm, that's rather odd. As I noted before, I have not had that problem myself, so reproducing it is not easy. Do you notice anything in particular happening just before the crash? Also, I have uploaded a debug build of Simutrans-Experimental, here: http://simutrans-germany.com/files/upload/Simutrans-Experimental-debug.zip . Do try that and tell me whether the problem recurs. (Note: that debug build contains an incomplete version of the next feature on which I am working, so behaviour might be different in some places, but it should not cause instability nor affect this issue).
Title: Re: Simutrans Experimental
Post by: z9999 on February 17, 2009, 09:32:25 AM
Thank you.
But I don't install MSVC, so I can't run debug version. Sorry.
Title: Re: Simutrans Experimental
Post by: jamespetts on February 17, 2009, 11:27:22 AM
Z9999,

you've tried running it and it doesn't work?
Title: Re: Simutrans Experimental
Post by: comrade on February 17, 2009, 03:59:00 PM
Hi,

firstly, thanks for making this modification. I really love the new features.

I've tried the latest version (not the debug one, it won't run for me) and I have experienced the following bug:
after loading a game, vehicles sometimes will not unload cargo they are currently carrying. They will however load new cargo on top of the old cargo, exceeding their maximum capacity.

I have attached a save with the bug (follow the train to see what I'm talking about).
Title: Re: Simutrans Experimental
Post by: jamespetts on February 17, 2009, 10:38:56 PM
Comrade,

thank you for trying Simutrans-Experimental, and thank you even more for posting a bug report :-) Feedack is very welcome indeed. Also, welcome to the forum - I notice that that was your first post.

This bug is proving a little difficult to track down, so please bear with me. I have, however, downloaded your save game, and have succeeded in reproducing the bug. The odd thing is that the bug only appears in the release build, not the debug build. That means that, either there is an assertion with a side effect (possible, but I scoured the code recently to try to remove all of those), there is some undefined behaviour being relied on somewhere that is predictable with optimisations turned off but goes wrong when optimisations are turned on, or there is some bug in the optimisation part of the compiler (unlikely but not impossible).

The most likely of those three options is the second. However, I notice that Prissi in an earlier post reported that he had the unloading bug with Isidoro's version of the code (i.e., with just the depot frame). That is a little odd, since I did not think that Isidoro's code had anything to do with freight loading , but it is not impossible that it affects freight loading somewhere. What I am going to do is download Isidoro's version of the executable and see whether I can reproduce the problem there, and report back afterwards.

Thank you again for the bug report :-)

Update: Trying the saved game with Isidoro's patch only would not work because the save game files have been reversioned in the trunk since Isidoro's initial code was written. Also, an odd bug appears with Isidiro's binary patch causing a crash to desktop whenever one uses the info tool on an industry (it might encompass more than this, but this is all that I have tested so far). I am hoping that Isidoro produces a Git-friendly version of his modification at some stage to make re-integration more easy; my view at this stage is to wait until the next version of the replacement patch is brought out, and try to re-integrate it then and see whether there are any further problems. Meanwhile, I'd be grateful if Isidoro and/or Prissi (or anyone else who's tested it and not had it crash to desktop before being able to do anything) can confirm whether the vehicle unloading patch is present in the Isidoro's version of the modified code, or whether it is unique to Simutrans-Experimental.
Title: Re: Simutrans Experimental
Post by: isidoro on February 18, 2009, 12:24:36 AM
James, I understood it the opposite way:

Quote from: tttron on February 17, 2009, 01:00:30 AM
I've tested with the executable you linked earlier (http://simutrans-germany.com/~patches/download.php?file=sim-wingdi-replacing-r2260.zip) - the replacement does work with that one. Just to be sure, I started another game with your Experimental executable and the replacement still didn't work as described above. Did you try it for yourself with your executable?

Just remember that the binary is for r2260-like games.  If tried with newer files there can be odd effects.  I'll merge with an updated version if it is decided to go to trunk.  Otherwise, I see no point in spending time on it.

I'm sorry to tell you that I will not install git.  I'm happy with svn and don't feel like learning another one.  But there is a thing I don't understand.  Patching has nothing to do with the versioning software you are using, has it?  Once you have a working copy, apply the patch, solve the failed hunks and that's all.  Nevertheless, if you encounter any problem adapting it to ST-Exp, please ask.
Title: Re: Simutrans Experimental
Post by: jamespetts on February 18, 2009, 08:34:54 AM
Isidoro,

hmm, perhaps the problem is incompatibility with the merged code, then. Although, with the binary in that link, I get a crash to desktop whenever I use the inspect tool on any factories.

As to merging with an updated version, it will go into the trunk of Simutrans-Experimental unless some currently unforeseen and irresolvable issue prevents it from doing so, so your work on this will not go unused. The patches will only work in conjunction with SVN because there needs to be some software somewhere that knows what the "base" is so that it knows which bits to change with the patch. The tool used for applying patches is Tortoise Merge, which specifically compares with the SVN base as well as the local files before merging. This is necessary so that applying the patch does not overwrite bits of the code that have been changed in comparison to the version against which you wrote the patch. There is no equivalent for Git. The difficulty will be in applying an updated patch, and working out what has changed between that and the previous patch. One thing that might work is if I use the .diff tool to compare the two patch files (the one that I used and your latest one), and then manually update in the code only those parts that have changed.
Title: Re: Simutrans Experimental
Post by: isidoro on February 18, 2009, 01:48:18 PM
When doing that with factories, the saved game is one belonging to r2260, without any patches?

Regarding the second point, when I merge I use the "patch" command, which doesn't even belong to svn.  It is as simple as a lighter.  For each chunk, it looks for context lines and insert/delete the appropriate lines.  If it can't (because the context lines have been modified by another patch), that chunk fails.  Of course that if you want to apply a new version of the patch, you must revert the old one and then apply.

In you case, perhaps the best approach is to get a fresh working copy and apply there for each new version or wait until the last version is there and do all the work then.
 
Title: Re: Simutrans Experimental
Post by: jamespetts on February 19, 2009, 08:21:40 PM
Isidoro,

it was not just on saved games that this problem occurred - it happened with new games that had never been loaded from saved files. As to waiting for the last version - any idea when that will be? ;-)
Title: Re: Simutrans Experimental
Post by: isidoro on February 20, 2009, 12:30:21 AM
It may be a defect of the crosscompiler.  I've tried the exe with wine and it gives a huge amount of production in the window information of factories.  The same patch in the Linux version works ok.  Please check with a fresh version from r2260 in trunk, patch applied and compiled in Windows.
Title: Re: Simutrans Experimental
Post by: jamespetts on February 20, 2009, 01:17:34 PM
Hmm, that really looks like it is an uninitialised variable, actually: if it crashes sometimes, gives an unexpected and very large number other times, and works other times still, then those are all the hallmarks of an uninitialised variable somewhere.

Incidentally, I have tracked down the cargo unloading bug, which is also an uninitialised variable - the problem is that, at a stop, the program would iterate through the list of all the contained cargo, checking whether it is equal to a particular item of cargo. Adding origins involved re-coding the overloaded == operator, but, because origins are not yet saved, when vehicles are reloaded, the origins would be undefined. The behaviour when calling that == operator is therefore unpredictable: sometimes it works, sometimes it produces odd results, and sometimes, I suspect, it crashes (I suspect that this might be what is causing Z9999's crashes).

I have not fixed it yet, but will do for the next version.
Title: Re: Simutrans Experimental
Post by: Spike on February 20, 2009, 01:21:21 PM
Valgrind can help to find uninitialised variables.
Title: Re: Simutrans Experimental
Post by: jamespetts on February 20, 2009, 10:56:53 PM
Hajo,

thank you for the tip - although, the difficulty is that Valgrind is only available on Linux, and I develop on Windows...
Title: Re: Simutrans Experimental
Post by: isidoro on February 21, 2009, 04:32:55 AM
I have discovered what happens.  I has nothing to do with my patch.  In simfab.cc:1257:
buf.printf("%s %li %s\n", translator::translate("Durchsatz"), get_current_production(), translator::translate("units/day"));


get_current_production() returns a sint32 and there is a %li in printf.  When crosscompiling with mingw, that produces the strange number and a buffer overflow.  When patches.simutrans-germany.com is up again, I'll upload a version with %i instead of %li for you to check.

Title: Re: Simutrans Experimental
Post by: jamespetts on February 21, 2009, 11:43:06 AM
Isidoro,

thank you - I have modified that line in my copy of the code, too. It is always good to flush the bugs out!
Title: Re: Simutrans Experimental
Post by: HeinBloed on February 21, 2009, 11:48:57 AM
I take it that buffer overflow bug most likely also caused the bug observed by me that a convoi marked for replacement never enters the depot (even though it's already empty)...? I'm looking forward to the fixed executable. :)
Title: Re: Simutrans Experimental
Post by: isidoro on February 21, 2009, 06:11:37 PM
I've just uploaded version 11.  I don't know if this is really a bug or a bad compiler/library implementation.  Should I file it for trunk?

@tttron:  the bug would only appear with my binary and if you open a factory details window.  I'd appreciate very much if anybody with Visual C++ and Windows could get r2260 from trunk, apply the patch and see if that error happens or not.

If you experience problems with the new version, please post your game and I'll try to see what happens.
Title: Re: Simutrans Experimental
Post by: jamespetts on February 21, 2009, 07:25:32 PM
Isidoro,

I have just integrated your version 11 into Simutrans-Experimental on my computer (not uploaded yet). I do not get the industry query crash. I do, however, get the bug to which tttron referred - when marked for replacing, vehicles do not enter the depot unless "go to depot" is selected. When that is selected, however, the correct behaviour re: automatically emerging or not, etc., is observed.
Title: Re: Simutrans Experimental
Post by: isidoro on February 21, 2009, 09:10:50 PM
If I understand you well, that's intended.  The button "Mark for replacement" is intended to mark replacements only.  Imagine a very complicated line with several depots.  You want to replace but to manually sent the vehicle to depot whenever it is near the desired depot.
Title: Re: Simutrans Experimental
Post by: jamespetts on February 21, 2009, 09:26:27 PM
Ahh, unfortunately, I get that behaviour when I select "full replace", not just when I select "mark for replacement". It seems to occur specifically when the convoy has no capacity, actually, rather than specifically rail vehicles: I was testing it with railway locomotives with no carriages. Adding carriages makes them go to the depot properly, although now I get an access violation in koord3d.h, which seems to result from a null pointer to a vehicle being passed in simconvoi.cc at the line:


dep->append_vehicle(self, veh, false);


Edit: I have traced the access violation to some of my own code, so do not worry about that; but the bug relating to zero capacity vehicles remains.
Title: Re: Simutrans Experimental
Post by: isidoro on February 21, 2009, 10:00:23 PM
Ok.   The alone locomotive is the good example.  Working on that... Thanks.
Title: Re: Simutrans Experimental
Post by: jamespetts on February 22, 2009, 08:37:38 PM
Update:

A new version has been uploaded, including bugfixes (see the opening post for details: the main bugs recently identified by users have, as far as I can discern, now all been fixed), and a new feature: improved debt handling. Isidoro's replacing patch is also fully updated to the latest version - thank you, Isidoro.

There are three essential features of the new system: (1) bankruptcy is now optional (and disabled by default); (2) debts accumulate interest (at a customisable rate; 10% per annum by default); and (3) there is a credit limit, beyond which players cannot buy new capital items. Interest is added monthly based on the total debt at month's end. There is not currently a graph showing historical interest payments, as this would require reversioning the save file, but this might well be added in the future. The credit limit is a varying amount, based on the player's assets and profits over the last year. The minimum (and starting) credit limit is 10,000 Simucredits. The credit limit is displayed in the finances window.

Capital expenditure can be made only within the credit limit. For example, if a player has a 100,000c bank balance and a 100,000c credit limit, the player can purchase capital items to the value of up to 200,000c. Beyond that, the player can purchase no further capital items until the cash balance or credit limit increases. Items that are placed in the map view will give an error message telling the player that the credit limit is exceeded if the player tries to purchase them in excess of the limit. Vehicles in the depot will show a new colour when the player cannot afford them: orange. (Red is still shown for vehicles that cannot be bought as part of the current convoy in any case). For the new vehicle replacement system, players can select orange items (as the resale value of the existing vehicles might enable the new ones to be bought, even if there is currently not enough in the bank), but the window will give the "That would exceed your credit limit" error message if the total net cost of the entire replacement cycle is in excess of the credit limit. The one exception to the credit limit is the remove tool: it can be used no matter how great the player's debt. This is to enable players who get into trouble to remove unprofitable parts of their network to get themselves out of the difficult.

The credit limit can optionally be disabled, reverting the game to the original behaviour. The credit limit system is also ignored in freeplay mode (although, strictly, freeplay mode is now redundant because the same effect can be had by altering the debt settings in simuconf.tab.).

There are some new simuconf.tab settings to customise each of the three features. An excerpt from the new simuconf.tab file shows the settings and the explanation for them:


# Insolvency and debt settings
#
# These settings allow what happens when the player runs out of money and goes
# into the red to be customised.
#
# "interest_rate_percent" is the annual interest rate (charged monthly) on all
# overdraft debt (i.e., on all negative account balances). It can be between 0
# and 255.
#
# "allow_bankruptsy" determines whether, when the player is deemed to have been
# insolvent for more than a certain period, the player should be declared
# bankrupt and the game over. 0 = no, 1 = yes.
#
# "allow_purchases_when_insolvent" determines whether, if the player's bank
# balance falls below the player's credit limit (shown in the finance window),
# the player will be unable to spend any new money on capital items (excluding
# bulldozing) until the player has come back within the credit limit again.
# 0 = no, 1 = yes.
#
# To revert to the behaviour of Simutrans standard, set interest_rate_percent to
# 0, set allow_bankruptsy to 1, and set allow_purchases_when_insolvent to 1.

interest_rate_percent = 10
allow_bankruptsy = 0
allow_purhcases_when_insolvent = 0


The reasoning behind this patch is that, with the current standard version of Simutrans, the handling of debt is a little too crude: players face the ostensibly extreme sanction of bankruptcy after only three months of debt (or three months of debt over a certain limit, in newer versions), but can easily bypass it by closing the "new map" window and carrying on. Meanwhile, players are free to run up as much debt as they please. That uneasy combination leads to players who have put a great deal of effort into their games but who have ended up insolvent facing a stark choice between, on the one hand, accepting the bankruptcy and losing all of their work, or, on the other hand, just closing the window and continuing; but the latter will often feel very unsatisfying. The idea of the new system is to introduce a softer but more effective disincentivisation for insolvency, by not allowing players to buy new things after they become insolvent. Players can then continue, and try to turn their transportation company around (without immediately losing all of their work), or sink into the mire of inescapable debt if they do very badly, and realise that starting again would be the best option all around. From a psychological and gameplay perspective, my view is that the new system is more satisfying. The interest is also there to introduce an element of cost to maintaining the debt: without it, there would be no point in having a separate credit limit, since the player's effective cash would be the player's actual cash plus the credit limit.

As ever, feedback (including Simutrans-Experimental specific bug reports) is always welcome.
Title: Re: Simutrans Experimental
Post by: z9999 on February 23, 2009, 05:41:34 PM
Quote from: jamespetts on February 20, 2009, 01:17:34 PM
... (I suspect that this might be what is causing Z9999's crashes).

I have not fixed it yet, but will do for the next version.

Unfortunately, new version still crashes.
But currently I don't have a time to play simutrans, so it's ok.

Quote
Simutrans-Experimental.exe caused an Access Violation at location 00401be0 in module Simutrans-Experimental.exe Reading from location 000002a8.

Registers:
eax=0013e4e8 ebx=00000000 ecx=00000000 edx=000002a8 esi=00000028 edi=00000057
eip=00401be0 esp=0013e4c4 ebp=0013e4c8 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206

Call stack:
00401BE0  Simutrans-Experimental.exe:00401BE0
00485621  Simutrans-Experimental.exe:00485621
004A24F5  Simutrans-Experimental.exe:004A24F5
004A408F  Simutrans-Experimental.exe:004A408F
00450AF6  Simutrans-Experimental.exe:00450AF6
00450DF5  Simutrans-Experimental.exe:00450DF5
0047D8BF  Simutrans-Experimental.exe:0047D8BF
00471F00  Simutrans-Experimental.exe:00471F00
00431AB9  Simutrans-Experimental.exe:00431AB9
7C817067  kernel32.dll:7C817067  RegisterWaitForInputIdle

Quote
Simutrans-Experimental.exe caused an Access Violation at location 0040924a in module Simutrans-Experimental.exe Reading from location 000002e4.

Registers:
eax=00000000 ebx=00000000 ecx=00000000 edx=00be6070 esi=0000007a edi=00000dee
eip=0040924a esp=0013e4f4 ebp=0013e4f8 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202

Call stack:
0040924A  Simutrans-Experimental.exe:0040924A
004A2361  Simutrans-Experimental.exe:004A2361
004A408F  Simutrans-Experimental.exe:004A408F
00450AF6  Simutrans-Experimental.exe:00450AF6
00450DF5  Simutrans-Experimental.exe:00450DF5
0047D8BF  Simutrans-Experimental.exe:0047D8BF
00471F00  Simutrans-Experimental.exe:00471F00
00431AB9  Simutrans-Experimental.exe:00431AB9
7C817067  kernel32.dll:7C817067  RegisterWaitForInputIdle
Title: Re: Simutrans Experimental
Post by: jamespetts on February 23, 2009, 11:43:03 PM
Z9999,

thank you for your bug report - sorry that it's still crashing. May I ask - in what circumstances does it crash? What do you do immediately before it crashes? Is this after you load a saved game, or does it also crash if you start a new game? What pakset are you using? How long after loading/starting a game does it crash? Does anything in particular happen in the game just before the crash that you have noticed?

Hopefully I can track down what is causing the problem - at least the message is clear that the problem is an access violation. Has anyone else had any problems, may I ask?
Title: Re: Simutrans Experimental
Post by: comrade on February 24, 2009, 12:47:54 AM
Hi! Thanks for the new version :)

So far it has worked fine for me, no game-breaking bugs or crashes.

Minor things I noticed:

1. Weight limit for rail tracks still resets to 999 on game load.
2. The speedbonus modification works as it should, but the "list of all goods" still shows the old speedbonus, is that intended?
Title: Re: Simutrans Experimental
Post by: jamespetts on February 24, 2009, 03:51:38 PM
Comrade,

thank you very much for your feedback - it is always much appreciated :-) The resetting track weight limit is a known limitation with the current version; changing that would require reversioning the saved game files, which I will get to, but I want to do it all at once so that I do not need to specify a large number of different saved game file versions.

As to no. 2, the table would need to be made somewhat more detailed to deal with the new system, as the speed bonus applies differentially depending on the distance travelled, which would require an overhaul of the GUI. Because I am planning on changing the revenue system entirely to abolish the speed bonus, I do not intend to make that change, because it would quickly be rendered obsolete. Thank you for spotting it, however :-) (The table is still valid in that it shows the correct speed bonus for longer distance travel).

Thank you very much for testing Simutrans-Experimental - do post again if you have any further issues or comments :-)
Title: Simutrans Experimental - screenshots
Post by: jamespetts on February 25, 2009, 10:40:04 PM
Below are some screenshots of some of the new Simutrans-Experimental features. Depicted are: (1) weight limits; (2) the new vehicle replacement tool (by Isidoro; with orange bars under the vehicles that cannot be afforded); and (3) message showing the what happens when the user tries to build things in excess of the credit limit.
Title: Re: Simutrans Experimental
Post by: Fabio on February 25, 2009, 10:46:45 PM
wow, impressive!
Title: Re: Simutrans Experimental
Post by: jamespetts on February 25, 2009, 11:36:39 PM
Thank you! Have you tested Simutrans-Experimental yet?

Edit: Of course, much of the credit for that middle screen shot goes to Isidoro...
Title: Re: Simutrans Experimental
Post by: Fabio on February 25, 2009, 11:59:02 PM
well, actually the only simutrans time i have ATM is for painting and writing dats. I test my paks in game, but only the way they look :(
but i promise that one of my first real simutrans games (in a future) will be with experimental, i really look forward to use it!
Title: Re: Simutrans Experimental
Post by: jamespetts on February 26, 2009, 12:08:53 AM
Excellent - and I shall look forward to your feedback!
Title: Re: Simutrans Experimental
Post by: z9999 on February 26, 2009, 03:43:17 AM
This is more impressive, isn't it ?  ;D
Title: Re: Simutrans Experimental
Post by: jamespetts on February 26, 2009, 08:36:14 PM
Z9999,

LOL! I take it, then, that you managed to get it to run without crashing? ;-)
Title: Re: Simutrans Experimental
Post by: jamespetts on February 26, 2009, 10:34:08 PM
Update: I have uploaded a new version to-day, (1) fixing a bug which would cause a crash to desktop in some cases; and (2) implementing the latest developments from the main Simutrans code, including the recent bugfixes and refactoring of the collection classes.

Z9999, I think that this should solve the crash that you were having with the opening screen (default save game) of Pak96.Comic. Please let me know whether it works for you.
Title: Re: Simutrans Experimental
Post by: z9999 on February 27, 2009, 06:03:29 AM
I couldn't download zip file from your site.
I downloaded it but it was empty 4.15MB file.

Can you upload the file to another site ?
I don't like such a site because of security thing. Thanks.
Title: Re: Simutrans Experimental
Post by: jamespetts on February 27, 2009, 07:41:03 AM
Z9999,

hmm, I'm not sure what the problem is. I prefer to use files.simutrans-germany.com, but it was down last night, and is still down. Can you suggest an alternative?
Title: Re: Simutrans Experimental
Post by: Dwachs on February 27, 2009, 07:50:52 AM
there are still problems with subdomains, you can use direct links as in Frank's post:

http://forum.simutrans.com/index.php?topic=1264.msg12208#msg12208 (http://forum.simutrans.com/index.php?topic=1264.msg12208#msg12208)
Title: Re: Simutrans Experimental
Post by: jamespetts on February 27, 2009, 11:44:19 PM
Dwachs,

ahh, excellent, thank you! Re-uploaded here (http://simutrans-germany.com/files/upload/Simutrans-Experimental.zip). Hope that that helps :-)
Title: Re: Simutrans Experimental
Post by: z9999 on February 28, 2009, 06:58:09 AM
Thank you, I could downloaded it.
Unfortunately result was the same, but thank you for trying it.
Title: Re: Simutrans Experimental
Post by: jamespetts on February 28, 2009, 12:07:00 PM
Z9999,

you say that the result was the same - same as what? Can you describe the problem in more detail, and, in particular, when it occurs? Are you referring to the crash when you run the game, or the zip file not unzipping properly?
Title: Re: Simutrans Experimental
Post by: Dwachs on March 06, 2009, 07:49:30 AM
as you may have noticed, in current trunk there is a feature by prissi that goods wont get routed through overcrowded stations.

Edit: I just checked your git-page. You regularly merge trunk commits in your experimental branch :)  :award:
Title: Simutrans Experimental: feature preview - reversing
Post by: jamespetts on March 09, 2009, 11:27:25 PM
I thought that I'd post here a preview of some features on which I have been working for Simutrans-Experimental. The source code for them is currently available on Git (link in the original post), but I have not yet compiled a binary as these new features need a compatible pakset for testing purposes, so users would not notice a great deal of difference.

I am currently working on a version of PakBritain, called PakBritain-Experimental, to go with Simutrans-Experimental, which will be available when I have set up enough parameters for it to be in a worthwhile state for testing. For the time being, I still encourage testing of the existing binary linked on the original page.

Reversing

The first new feature is a more sophisticated system of reversing. It is useful mostly for railway vehicles. In essence, it simulates both graphically and in simulation terms the fact that, for many trains, the locomotive needs to run around to the other end of the train, but the whole train does not turn around in the way that, for example, a road vehicle does: it just goes the other way. Likewise, some trains do not have locomotives running around at all, but can drive from both ends.

The attached screenshots show two examples. The first two are of a double headed train reaching the buffer stops and turning around: notice how the locomotives both change ends, but the carriages stay in the same order, just as in reality. The program detects that the train is double headed and acts accordingly. Similarly with steam locomotives with tenders.

The third is of an "autocoach" attached to a steam locomotive: common in rural branch-lines in the UK in the 1920s-1950s. The train can be driven either in the normal way from the locomotive at the front, or from the special cab at the rear of the train. For that reason, the locomotive does not have to uncouple and turn around at the end, and the train reverses without changing formation or direction at all. The picture shows the train travelling in reverse.

In simulation terms, whether trains have to reverse affects how long it takes them to turn around. A train, such as the autocoach example in the screen shot, that can be driven from either end can turn around very quickly. A train, as in the top example, that has a locomotive at one end and that needs to be run around to the other end before reversing turns around more slowly. A train with a steam locomotive with a tender that not only needs its locomotive to change ends, but the locomotive to turn on a turntable will turn around more slowly still.

This will make the game more fun by giving players more interesting choices, as well as by making it look more real: if players want to make their network more efficient, they will have to choose appropriate sorts of trains for the job: trains that can turn around quickly for suburban traffic, and trains with powerful locomotives for long-distance traffic (which may be more slow to turn around). As technology develops, more trains will be able to turn around more quickly. Other interesting decisions include weighing up the advantages and disadvantages of tank and tender engines (tank engines of the same power are heavier, since they cannot spread the weight into a tender, and therefore require tracks and bridges capable of higher weights, but tender engines need to use a turntable); and also the economics of long-distance multiple units: they can turn around more quickly, but, because each individual vehicle has an engine, they are less comfortable and cost more to run than locomotive hauled trains (a good middle ground is a locomotive hauled train with a driving cab at the rear - but those are not available in every era, and can be more expensive to buy).

I hope that this will add enjoyment to people's games. I should be very interested in anyone's comments.

Edit: I thought that I should add some techincal information about this feature for pakset creators.

Technical information

This feature (when used with a compatible version of Makeobj - source code available on the Simutrans-Experimental Git repository; binary not yet available, for the same reasons as above) uses two additional parameters in the .dat file:

1. can_lead_from_rear; and
2. bidirectional.

They are both boolean flags, which means that if the value is set to "0", they are considered to be false, or anything other than "0" they are considered to be true. Convention is to use "1" to denote true.

The first denotes a vehicle that, if it is at the back of a convoy, will let the convoy reverse without turning around, and go exactly backwards. This is useful for railway multiple units, or arrangements such as the autocoach pictured. In the autocoach example, only the autocoach itself need have the "can_lead_from_rear" flag set. This setting is only relevant for the rear vehicle in a convoy: it is ignored for the other vehicles. If the rear vehicle has this flag set, the fastest reverse turnaround is used.

The second denotes a vehicle that can travel in either direction without turning around. For example, an ordinary railway carriage or truck is bidirectional. A horse is not (horses cannot travel any distance walking backwards). A diesel locomotive with a cab at each end is bidrectional. A steam locomotive with a tender is not. A tank engine will usually be bidirectional, unless the tank engine is designed such as to make running in reverse impractical. (I know that tender engines do run in reverse on preserved railways, but that is far from ideal, and they cannot do that safely at anything other than the low speeds at which they operate on preserved railways). If the lead powered vehicles are bidirectional, the train will turn around more quickly than if they are not. Only bidirectional vehicles will keep their orientation when the convoy is reversing. Also, in the latest version of the code, if there is only one vehicle in the convoy, and that is bidirectional, the fastest reversing time will apply.

The whole reversing system is disapplied entirely to road and air vehicles (and kept for water-craft only because canal narrow boats might be bidirectional). The default values for both settings are false. In that state, the vehicles behave as they do in default Simutrans, with the exception of the turnaround time, which is the highest of the three, as it assumes a convoy that needs to reverse in the slowest way.

However, the delay is set from values in simuconf.tab. In the most recent version of the code, those default to 0. Thus, without a custom pakset and custom values set in simuconf.tab, the game behaves exactly in the same way as standard Simutrans: only a specially configured pakset will enable the features. Below is an extract from the simuconf.tab file that I have been using, along with full documentation of the settings, to show what can be customised:


# These settings determine how long that it takes a train-type vehicle to turn
# around when it reaches the end of the line. They do not apply to road vehicles
# or aircraft.
#
# "unit_reverse_time" refers to trains/convoys, such as multiple units, that have
# a cab at each and, and can be driven in reverse without any re-arrangement of
# the order of the vehicles. These will generally take the least time to reverse.
#
# "hauled_reverse_time" refers to trains/convoys that cannot be driven from the
# rear, so the locomotive at the front has to run around the train and attach
# to the rear, but where that locomotive can itself be driven in either direction,
# so that it does not need to turn around.
#
# "turntable_reverse_time" refers to trains/convoys that, as for the above category,
# cannot be driven from the rear, but that also require their locomotive to be turned
# around to face the other direction (such as steam locomotives with tenders) at the
# end of the journey. These will genearlly take the most time to reverse.
#
# All times are in milliseconds (1000 = 1 sec), assuming that the game is set to the
# normal speed.

unit_reverse_time=1500
hauled_reverse_time=2500
turntable_reverse_time=4000
Title: Re: Simutrans Experimental
Post by: The Hood on March 10, 2009, 01:26:17 PM
Interesting idea.  (Still not 100% sure what it all means in practice but one day I'll have a play with it and find out!).  Have fun (?!) finding appropriate settings for all of these for PakBritain-experimental though!

Oh, and what about trams?  Presumably they would have this feature enabled?   And for bidirectional vehicles that aren't symmetric (e.g. a tank engine) would they run cab first rather than boiler first when in "reverse" mode?
Title: Re: Simutrans Experimental
Post by: jamespetts on March 10, 2009, 11:17:47 PM
The Hood,

yes, indeed, trams need to be set to "bidirectional", too. To answer your question about tank engines, see the attached screenshots...
Title: Re: Simutrans Experimental
Post by: kierongreen on March 10, 2009, 11:54:22 PM
Interesting!
Title: Re: Simutrans Experimental
Post by: jamespetts on March 11, 2009, 12:03:51 AM
Just wait until I tell you about upgrading, comfort ratings and variable dwell times!
Title: Re: Simutrans Experimental
Post by: gauthier on March 11, 2009, 12:04:13 PM
A small question : are undeground slopes included in ST experimental ?

If yes, please tell me where download it :D
Title: Re: Simutrans Experimental
Post by: The Hood on March 11, 2009, 12:17:49 PM
Excellent!  All you need to do now is make it so that tender locos actually detach and then proceed to a new turntable feature and run round...  :P
Title: Re: Simutrans Experimental
Post by: Fabio on March 11, 2009, 01:49:12 PM
awesome!!!
Title: Re: Simutrans Experimental
Post by: jamespetts on March 11, 2009, 11:11:29 PM
Gauthier,

underground mode and slopes are not presently included in Simutrans-Experimental, although, if they have not made the trunk by the time that I finish the new revenue model, they will be.

The Hood,

if you'd like to learn C++ and code that, I'll add it to Simutrans-Experimental ;-)

Fabio,

thank you :-)

Upgrading

Another new feature that will be in the next version of Simutrans-Experimental is upgrading. The concept is very simple: instead of selling an old vehicle and buying a new one to replace it, one can upgrade (or refurbish or rebuild, or however one would prefer to describe it) old vehicles into better ones. Certain types of vehicle are marked as upgrades to other types, and, by using the special "upgrade" mode in either the depot window (or Isidoro's replace window), one can see which vehicles to which one can upgrade the present vehicles in a convoy. The price of upgrading can be different (usually lower) than the price of buying that sort of vehicle new. Additionally, some sorts of vehicles can only be bought as upgrades to existing types, not from new (these are shown as light purple in the depot window when "show all" is selected).

When there is a convoy selected in upgrade mode and one buys a vehicle that is an upgrade to one of the existing vehicles in the convoy, one of the suitable vehicles in the convoy is automatically replaced with the upgraded vehicle, without having to reassemble the convoy. One can keep buying upgrades until there are no more of the pre-upgraded vehicles left in the convoy. In upgrading mode, when one buys an upgrade, only the upgrade price will be shown and charged. Dark purple in upgrade mode indicates vehicles to which no vehicles in the present convoy can be upgraded. The screenshots below give an example of upgrading in progress using different types of BR Mk 1 carriage from PakBritain.

A similar system works with Isidoro's replacing system, except that whether a vehicle is upgraded from an existing vehicle or bought new is determined automatically when the convoy gets to the depot: the cheapest option will always be chosen. Also, unlike the original version of Isidoro's replacing patch, the new code will automatically re-use existing vehicles in the convoy when the upgraded type of the convoy contains the same sort of vehicles, rather than always selling the existing vehicles and buying the new ones. That means that the replacing tool can now be used to re-arrange whole sets of convoys for free.

Using upgrades, players will be able to manage their vehicle fleets in more cost-efficient ways, as well as have more interesting decisions about the merits of upgrading existing vehicles, leaving existing vehicles as they are, or purchasing new vehicles.

Technical details

To make a pakset work with this feature, there are three different possible additional settings in the vehicle's .dat file:

1. upgrade_price;

2. available_only_as_upgrade; and

3. upgrade[X] (where "X" stands for the name of a vehicle).

"upgrade_price" is the cost of the current vehicle when it is bought as an upgrade, rather than when it is bought new, expressed in 1/100ths of a Simucredit (in the same way as "cost". The default value is whatever has been set as the normal purchase price. "available_only_as_upgrade" can either be true (1) or false (0). The default value is false. When this is set to true, the vehicle cannot be purchased except by upgrading another vehicle to it. upgrade[X] (where "X" stands for the name of a vehicle) is the list of vehicles to which the current vehicle may be upgraded. Note: as with the coupling constraint values, the vehicles to which it refers must be in the same .pak file for this to work. The vehicle's name (exactly as it appears in the upgraded vehicle's name filed in the .dat file - not the translated version) is used as an identifier.

Here is an example:


cost=583000
upgrade_price=70000
...
available_only_as_upgrade=0
upgrade[0]=BR-Mk1-TO(Blue-Grey)


Loading time

Another feature in the next version of Simutrans-Experimental will be variable loading time (sometimes called "dwell time"). Currently, all load and unload operations for all kinds of vehicles take 2,000 ticks (that is: 2 seconds at default speed). In reality, different kinds of vehicles can be loaded and unloaded faster than others. For example, an old-fashioned coal truck has to be emptied by hand, whereas a modern hopper can be emptied by tipping all the coal into a bunker underneath the tracks, and can be emptied without even stopping the train. Express passenger trains tend to have small doors only at the ends of the carriages, whereas commuter trains have large doors all along the sides of the carriages: commuter trains can therefore load and unload passengers more quickly. Buses tend to load and unload faster than trains, and aircraft and ships take far longer to load and unload than buses or trains.

Different vehicles can now have different loading times. When buying a new vehicle (or upgrading an existing one), one will be able to see the loading time value in the depot window. Players will then be able to choose between faster, cheaper and/or more comfortable vehicles with longer loading times, or slower/more expensive and/or less comfortable vehicles with shorter loading times. (Comfort is a part of the new revenue system, still under development). Generally, shorter loading times are needed for shorter journeys. With this feature, players will have to match the type of vehicles used more accurately to the type of route than they do at present: no longer will it be economical to use express trains on local stopping services, or vice versa.

Technical details

Loading time is always expressed in ticks. 1 tick represents 1 millisecond (that is, 1/1000th of a second) at the default speed of 1.0. To specify a loading time in a vehicle's .dat file, add the parameter "loading_time" and the number in ticks, for example,


loading_time=2500


The default is 2,000: the same as is used in Simutrans standard. The loading time of a convoy will be the loading time of the slowest vehicle in it.
Title: Re: Simutrans Experimental
Post by: z9999 on March 12, 2009, 06:41:29 AM
One question.
In current simutrans, passenger always ride in order, from the first car.
If loading time of first car is 2000 and loading time of second car is 10000, passenger will ride on second car after 2000 ticks even if first car is empty ?
Title: Re: Simutrans Experimental
Post by: The Hood on March 12, 2009, 11:10:59 AM
Wow, both of those look like good additions for advanced gameplay.  I see one problem though - now my to-do list has just got longer (again!) :(.  I think there are lots of possibilities for using the upgrade in PakBritain Experimental, upgraded/refurbished vehicles could have more recent liveries, or there are plenty of things where there are big changes (thinking e.g SR Merchant Navy, LMS Duchess, LNER P2, LNER A1/A3 etc.).  Unfortunately I think this will have to wait til after Standard pakBritain is much more complete though...
Title: Re: Simutrans Experimental
Post by: jamespetts on March 12, 2009, 11:41:06 AM
Z9999,

as stated in the section on techincal details, the loading time of the whole convoy is the loading time of the slowest loading vehicle in that convoy.

The Hood,

ahh, sorry about the to do list... ;-) At least refurbished vehicles can be drawn in many cases by making small changes to existing ones  (rebuilt Bulleid pacifics, for instance, can use the same model as the Britania, but with the rondel style nameplates instead of the nameplates on the smoke deflectors), and some existing vehicles can be used as upgrades without any re-drawing (which I can do; likewise with the loading times, etc.).
Title: Re: Simutrans Experimental
Post by: The Hood on March 12, 2009, 12:40:31 PM
Quote from: jamespetts on March 12, 2009, 11:41:06 AM
The Hood,

ahh, sorry about the to do list... ;-) At least refurbished vehicles can be drawn in many cases by making small changes to existing ones  (rebuilt Bulleid pacifics, for instance, can use the same model as the Britania, but with the rondel style nameplates instead of the nameplates on the smoke deflectors), and some existing vehicles can be used as upgrades without any re-drawing (which I can do; likewise with the loading times, etc.).

I suggest that for your version of PakBritain-Experimental, you use a copy of existing graphics (actually a copy rather than linking to same png file) so that when I (or anyone else for that matter) gets the time to alter the graphics, then I only need to update a png file and none of the dat stuff.  BTW where are you planning on hosting pakBritain-experimental sources?
Title: Re: Simutrans Experimental
Post by: z9999 on March 12, 2009, 01:16:20 PM
Thank you. Then, it will accept loading during loading time, it's good.
Before, msp wrote a similar patch, but it didn't load during waiting time.  :(
http://forum.simutrans.com/index.php?topic=882.0
Title: Re: Simutrans Experimental
Post by: jamespetts on March 12, 2009, 01:26:29 PM
Z9999,

MSP's patch is different in function: this is just about the time that it takes to load, not extra waiting time.

The Hood,

point taken about copying graphics. I was planning to host the sources on Github, if I could get it to work - I tried to create a repository recently, but it would not work properly. I will try again in due course. If that fails, I shall have to consider other options.
Title: Re: Simutrans Experimental
Post by: The Hood on March 12, 2009, 02:35:12 PM
It would probably be a good idea to have it on sourceforge with the other sources eventually, but maybe leave that until simutrans-experimental is more established and pakBritain is more complete too.

In the fullness of time could you send me a list of all of the vehicles you want upgrade graphics for (I have my own ideas, but if you are writing dats for these anyway, I will try and provide some graphics.  this will be a long way off though!)
Title: Re: Simutrans Experimental
Post by: Fabio on March 12, 2009, 03:39:36 PM
the lading time should also depend on the amount of goods loaded: the more the longer (with a factor depending on the vehicle's specifics
Title: Re: Simutrans Experimental
Post by: jamespetts on March 12, 2009, 08:27:46 PM
The Hood,

don't worry - it'll take me a while to get around to dealing with upgrades, too - my priority at present is the revenue system, and that is likely to be quite a big job. The reason why I chose Github is that that is where the source code for Simutrans-Experimental itself is located, and it is also better at concurrent working and branching than SVN. What would be the advantage of using SVN on Sourceforge?

Fabio,

that is an interesting point, and should be reasonably easy to implement. The hardest bit would be calibrating it: currently, all vehicles load at 2,000 ticks. Would the time specified in the .dat file be a maximum, minimum or average time? And should we start from the premise that the current standard of 2,000 ticks (which would be used for all vehicles that do not have anything specified in the .dat file) is the maximum, minimum or average? How much should it be varied? Should it scale in a linear, exponential or logarithmic manner with the quantity of the goods? I should appreciate some thoughts on those matters - if something that looks workable emerges, I may well add it.
Title: Re: Simutrans Experimental
Post by: Fabio on March 12, 2009, 08:58:22 PM
i'll think about it some more.

in the meanwhile, this paper could be a useful read, maybe..

http://www.cs.bgu.ac.il/~ebachmat/managesubmit.pdf
Title: Re: Simutrans Experimental
Post by: isidoro on March 13, 2009, 12:51:09 AM
Different loading times is a nice addition, James...  I wonder if this mod can be easily tried: assign to each packet the coordinate of the tile station where it is.  Make loading time depend on the distance from that tile to the tile where the vehicle being loaded really is.

The rationale is to avoid the building of huge stations in which vehicles are unloaded on a far platform and automatically loaded on a distant one of the same huge station.
Title: Re: Simutrans Experimental
Post by: colonyan on March 13, 2009, 01:09:21 AM
Nothing new to propose but as opinion
-loading time depending on quantity(both good and passangers)
-distance between train and good at station affecting load time
I buy it.
Title: Re: Simutrans Experimental
Post by: The Hood on March 13, 2009, 09:01:35 AM
Quote from: jamespetts on March 12, 2009, 08:27:46 PM
The Hood,

don't worry - it'll take me a while to get around to dealing with upgrades, too - my priority at present is the revenue system, and that is likely to be quite a big job.

Sounds like a good plan then.  Is the revenue system going to include service quality (e.g. frequency, some notion of timings/speed/congestion, comfort, etc.)?

QuoteThe reason why I chose Github is that that is where the source code for Simutrans-Experimental itself is located, and it is also better at concurrent working and branching than SVN. What would be the advantage of using SVN on Sourceforge?

I was thinking sourceforge because (a) that's where the standard stuff is (b) more people have heard of it (c) simutrans gets publicity through it and the more downloads/stuff the better.  It would only be for the "official" experimental pakset though, if that makes sense?  Anyway, no need to do anything about it right now.

Quote
Fabio,

that is an interesting point, and should be reasonably easy to implement. The hardest bit would be calibrating it: currently, all vehicles load at 2,000 ticks. Would the time specified in the .dat file be a maximum, minimum or average time? And should we start from the premise that the current standard of 2,000 ticks (which would be used for all vehicles that do not have anything specified in the .dat file) is the maximum, minimum or average? How much should it be varied? Should it scale in a linear, exponential or logarithmic manner with the quantity of the goods? I should appreciate some thoughts on those matters - if something that looks workable emerges, I may well add it.

I would say (based on my experience of travelling in the rush hour and at other times!) that if more than a certain proportion of the train capacity alights/boards then increase loading time (probably no need for anything more complex than linear at first, see how it works).  I'd stick with current behaviour (including scope for differences between different vehicles) as a base, as there is always a minimum wait time in the station.  I guess it would be trial and error to determine at what proportion the penalty should kick in, and how much the penalty should be.
Title: Re: Simutrans Experimental
Post by: Fabio on March 13, 2009, 12:51:03 PM
I thought some more on the loading time.
There is a X min required time (could it be our 2,000 ticks?) for technical reasons (opening and closing the doors). Planes and ships should have it 4 times longer (the boarding time is always much longer). A standard vehicle could be thought having 2 doors, 2 people a time can hop on or off from each of them. I can approximate 16 people moving in another X time (16 pax in 2,000 ticks). The result is then 125 ticks per pax.
This time could be increased or decreased with a multiplier M (wider doors, low on the road/platform, etc...).

So, the formula could be:

LOADING_TICKS = MIN_TICKS + ( PAX_IN + PAX_OUT ) * TICKS_PER_PAX * MULTIPLIER

A similar formula could apply for goods too, e.g. replacing every pax with an amount of weight (e.g. 1 t, here a high multiplier would be set for older vehicles loaded by hands).

The thing Isidoro pointed out is also very true, but we need a distinction:
1) goods vehicles, planes and ships will wait to load goods coming from far tiles, busses, trams (and probably trains) won't.
Title: Re: Simutrans Experimental
Post by: isidoro on March 13, 2009, 01:04:14 PM
Yeah, it should be refined.  Something like recording the time the packet has been waiting on a station.  If long enough, we can suppose that they have moved to the right platform and will only wait the loading time.   That time would depend on the size of the station to force players not to build unrealistic giant stations.

In my QoS patch, average waiting time are already recorded for each packet.  So that would not be difficult.
Title: Re: Simutrans Experimental
Post by: The Hood on March 13, 2009, 01:47:39 PM
Quote from: fabio on March 13, 2009, 12:51:03 PM
LOADING_TICKS = MIN_TICKS + ( PAX_IN + PAX_OUT ) * TICKS_PER_PAX * MULTIPLIER

That's pretty much what I was trying to say!

EDIT: Would this calculation be for the convoy or for each carriage - obviously the more carriages, the more doors, so quicker to load the same number of people/goods...
Title: Re: Simutrans Experimental
Post by: Fabio on March 13, 2009, 02:11:49 PM
good point!

but the pax/goods are added to each single carriage, so it could be calculated for every carriage and the max would be used.

But at this point, in order to optimize the loading for pax, instead of filling the first carriage, then the second one, then the third one and so on, the procedure should split the pax on the whole carriages (e.g. a 4 carriages train boarding 20 people should add 5 people to each carriage, if there are enogh seats there).
Title: Re: Simutrans Experimental
Post by: The Hood on March 13, 2009, 02:57:05 PM
doing it by carriages is a good idea then.  But only for passengers.

Goods trains are normally loaded one vehicle at a time, so in that case the length of time to load a goods train should be dependent on the number of vehicles - maybe the sum of the loadtime for each vehicle?
Title: Re: Simutrans Experimental
Post by: Fabio on March 13, 2009, 03:21:06 PM
max for pax, sum for goods and mail.
it seems the best idea
Title: Re: Simutrans Experimental
Post by: jamespetts on March 16, 2009, 12:41:09 AM
Update: I have just uploaded a new binary version of Simutrans-Experimental, Makeobj-Experimental and the configuration files: downloadable in the usual places (see the original post in this thread for details).

New features include, as discussed above, reversing, variable dwell times, and upgrading as well as replacing, however, all of those features require a compatible pakset (made with the new version of Makeobj, using specialised parameters as described above) to work. However, it is recommended that all users of Simutrans-Experimental nonetheless upgrade to this new version, as this version has a Simutrans-Experimental specific save game file format. Thus, although games saved with Simutrans-Experimental are not now compatible with standard Simutrans saved games  (standard Simutrans games can, however, be loaded into Simutrans-Experimental), much Simutrans-Experimental specific data are saved, including weight limits, convoys being replaced, and Simutrans-Experimental specific settings.

This version also merges all of the latest nightly updates from the main Simutrans trunk, including all of the new overcrowding settings, and the new tooltips. Feedback is, as ever, welcome on this new version: please test it to make sure that it is stable.

As to all of the above comments on loading times: thank you for the detailed thoughts. Sorry for not replying sooner: I have had a very busy week-end. I shall think more on how to deal with this in a way that is simultaneously realistic, reasonably easy to code, reasonably easy to put into the .dat files, reasonably easy for players to understand (and to be represented through the GUI) and works well with the gameplay overall.

This is likely to be the last Simutrans-Experimental release before the first version of the new revenue system, currently in development, which will be based on the average speed of the line or (if the convoy is not part of a line) convoy, not the convoy's maximum speed, combined with a new comfort rating (already built into Makeobj-Experimental) for passengers. I am also considering having some sort of detection of the directness of the journey to allow the more realistic system of revenue being based on the route rather than the direct distance, but with goods/passengers not taking a route if it is absurdly indirect (more than X times the direct distance between the ultimate origin and the ultimate destination). Another possibility is to have mail and passengers pay for route distance, subject to a directness floor, and for goods to pay for the actual distance, but that may need further consideration. Any thoughts on that topic would be most welcome.

In the meantime, happy testing - do post any feedback in this thread so that I can improve it even further!
Title: Re: Simutrans Experimental
Post by: The Hood on March 16, 2009, 08:54:40 AM
Quote from: jamespetts on March 16, 2009, 12:41:09 AM
This is likely to be the last Simutrans-Experimental release before the first version of the new revenue system, currently in development, which will be based on the average speed of the line or (if the convoy is not part of a line) convoy, not the convoy's maximum speed, combined with a new comfort rating (already built into Makeobj-Experimental) for passengers. I am also considering having some sort of detection of the directness of the journey to allow the more realistic system of revenue being based on the route rather than the direct distance, but with goods/passengers not taking a route if it is absurdly indirect (more than X times the direct distance between the ultimate origin and the ultimate destination). Another possibility is to have mail and passengers pay for route distance, subject to a directness floor, and for goods to pay for the actual distance, but that may need further consideration. Any thoughts on that topic would be most welcome.

If you are calculating average speed of a convoy / route anyway for the revenue system, and you can calculate the route distance, maybe there is some scope to take a longer route as long as it is not significantly slower than the shortest distance route (using average speed for calculation purposes)?
Title: Re: Simutrans Experimental
Post by: jamespetts on March 16, 2009, 09:00:39 AM
Quote from: The Hood on March 16, 2009, 08:54:40 AM
If you are calculating average speed of a convoy / route anyway for the revenue system, and you can calculate the route distance, maybe there is some scope to take a longer route as long as it is not significantly slower than the shortest distance route (using average speed for calculation purposes)?

The plan ultimately is for goods to assess the directness of the route as well as the speed, and calculate the best route on the basis of the likely approximate journey time taking into account both directness and speed. I do not know how well that this will work in practice: it might be reduced to guessing the approximate directness of the route based on the straight line distance between all transfer stations, or alternatively, recording average directness of all journeys per line ex post facto, and calculating based on an average directness. In any event, the first task is to measure average speed and use it to calculate revenue: the system of goods choosing their route is the next step.
Title: Re: Simutrans Experimental
Post by: The Hood on March 16, 2009, 09:16:00 AM
Just a thought - goods traffic in real life virtually never cares about the journey time (except certain high value low volume goods, which probably resemble mail more in simutrans), and the only consideration is cost.  I suggest that passengers/mail consider journey time/speed in route-finding, but goods just take the cheapest route (if someone else can offer a cheaper trip, then industries will use it to cut costs, as their coal/steel/whatever doesn't usually care about spending 8 hours in transit rather than 3!).  The only possible exception to this are things like newspapers or possibly food?

The next question for goods would then be how to calculate the cost?  Seeing as no transport business would choose to operate a goods service at a loss, I suggest that the goods cost should be route-distance based (greater distance = more fuel) - but then again this probably needs a lot more thought!
Title: Re: Simutrans Experimental
Post by: jamespetts on March 16, 2009, 01:42:05 PM
The Hood,

what I had intended to do was make the revenue system use the same speed sensitivity settings as the speed bonus (some goods are more speed sensitive than others, with bulk goods, such as coal, having a 0% speed sensitivity (passengers, I think, were at 18%)), but use average rather than maximum speeds. That way, much of the existing speed bonus code could be re-used with relatively modest changes.

As to the distinct but related question of route preferences, the weighting of speed as a factor could again be used in the same way, with 0% goods not taking speed into account at all. Cost is a very difficult thing to calculate, though, as I do not think that it is possible effectively to simulate a market in Simutrans, in which the prices are set by a function of supply and demand, as neither demand nor supply are simulated in enough depth. Instead, the revenue system has to make implicit and very approximate assumptions about the elasticity of demand and the availability of alternative supply to come up with prices that are more or less right overall. It is difficult to apply the same thing to actual choices made by goods packets, though, which is why using cost is not a particularly useful measure. One possible measure of service quality s the number of transfers; another, the directness of the route. The system for choosing which route that goods take is somewhat harder than the system for determining what revenue that they should generate.
Title: Re: Simutrans Experimental [Original thread]
Post by: jamespetts on April 12, 2009, 03:43:32 PM
This thread is now locked: discussion will continue in individual threads about specific topics, to make things easier to find.