Hajo,
thank you for your views :-) My experience of coding is limited, so I am somewhat apprehensive about starting a major new project that requires a high degree of techincal ability - I have no doubt that Prissi's ability to write pre-emptively multi-threaded code is far greater than mine. My emphasis has been more on enhancing and re-balancing the game play and ironing out certain things that I consider to be anomalies (such as having the speed bonus based on maximum rather than average speed) rather than changing the underlying implementation.
That being the case, however, if there was someone with sufficient confidence and time to write and then debug pre-emptive multi-threading code, I could certainly consider it for inclusion. One impediment to that, however, would be problems of keeping Simutrans-Experimental in line with Simutrans-Standard's code base (presently, I regularly merge in changes to the trunk: that might be very difficult if the underlying architecture was changed too much, although should not be too much of a problem with Prissi's suggestion about extending the co-operative model).
One way around this issue would be to move towards a multi-branch, fork and re-merge development strategy for Simutrans-Standard, using Git rather than SVN, where major new features are always individually put together in a separate branch and tested in that branch, and binaries made available periodically, and then selectively re-merged back into the trunk when they are mature. That system could be extended to having separate branches for release builds and nightlies. Quite independently of any Simutrans-Experimental specific issues, I think that that approach has a great deal to recommend it. Indeed, I notice that a number of Simutrans and Simutrans-Experimental developers (Ansgar, Knightly, Gerw, Dwachs and Bernd) are already beginning to adopt this approach.
In summary, I see Simutrans-Experimental as a gameplay fork rather than as a perpetual testbed. It is better to use a multiple fork and merge system to implement test major architectural changes than use a single fork for multiple purposes. In the meantime, I am working to move Simutrans-Experimental towards maturity in its own right (and am extremely grateful to the efforts of all the bug reporters and code contributors on this forum for their invaluable assistance in that regard), and to release it independently with an automated installer for multiple platforms bundled with one or more Simutrans-Experimental fully compatible paksets.
