Slowly returning: priorities and opportnities to help

[jamespetts]

Introduction

As many Simutransians will know, I have been largely absent for about a year, with the exception of some weeks over the Christmas period where I made some good progress on way renewal and other related matters. I have been extremely preoccupied with moving house, which has taken far longer than I expected, and I ended up living with my parents for many months whilst my house was refurbished. Whilst it is not quite complete (I am missing curtains and stair carpet, amongst other things), I am now somewhat settled and able to spend a little time on Simutrans-Experimental again.

Priorities

There is a very large backlog of work outstanding, and I only have a little free time each week, so I have to prioritise. The most important thing guiding my thinking on the release schedule is that I do not think it worthwhile to release another major version that is not ready to have its pakset properly balanced, as most of the game is in the balance. The priority (aside from critical bug fixes and completing currently incomplete work) must be features that are either necessary or highly desirable to ensure that the balancing will work and be a practical thing to achieve and thereafter adjust. Given the length of the below list and the complexity of the things on it, I am afraid that this task may take some considerable time (i.e., years) even if I can dedicate a goodly amount of time to this regularly for the foreseeable future, unless I have some substantial assistance in (for which I should be very grateful).

The new desync bug
The highest priority at present, I think, must be the desync bug reported in this thread, which is confirmed. Unfortunately, this sort of bug is fantastically difficult to find and fix, and may take many months of work to track it down (as has happened in the past).

Any help to find the source of this would be very helpful: even people with no knowledge of or interest in coding can help a great deal by some scientific play-testing: see this post for details on how: please reply to that thread to discuss this issue.

The old desync bug
Even the current release version, 11.35, has a desync bug, which is known to be associated with connecting towns to an electricity supply. This will also need to be fixed as a matter of some priority: because it has been narrowed down, it should be slightly easier to fix than the new bug, but will still be very difficult. Any techincal assistance in fixing this would be very, very much appreciated.

Signalling
After fixing the desync bugs, I need to finish the railway signalling project that I started over the Christmas period, which is a fairly substantial task in itself. This needs to be done as the work is currently half-finished, and the signalling system in this state makes little sense. This will also involve redrawing most of the Pak128.Britain-Ex signals as well as adding a lot of new ones, and some existing work will have to be redone following a recent(ish) bug fix.

Help either in coding (a fairly experienced coder or better will be needed here) or in producing signal graphics (some basic/moderate Blender/Simutrans graphics knowledge would be helpful) would be appreciated in this respect.

Town/city growth
This is a major topic: town growth needs to be substantially re-engineered so as to take into account local transport quality. This will be a very significant advance in realism. This is necessary now because the passenger generation system and some ancillary changes has broken the existing town growth system, and hugely excessive and fundamentally unbalanced town growth seriously blighted the most recent online game on the Bridgewater-Brunel server. There area already some elements of the new system in place, particularly those measuring local transport quality in the new passenger generation system (indeed, earlier versions of these exist in the current release version, showing statistics for local transport quality).

Some very detailed discussion about this topic can be found on this thread: please discuss the details of this topic there. I have also had feedback a few months ago to the effect that, because of the presence of essentially random factors in real life as to where certain buildings are built, an element of randomness should be retained in where buildings are constructed, which seems to me a reasonable and sensible suggestion and which I intend to implement. This will, however, take a very long time to implement because it is such a radical change.

Help with this feature can come from experienced coders working on the town growth code, or from anyone with or without any knowledge/understanding of coding prepared to give some consideration to the topics raised in the discussion thread.

This will also need to involve fixing this bug, which has been reported more than once.

Balancing tools
Tools, built into the code, to make balancing (and thereafter rebalancing/adjusting the balance) much easier than at present have been under consideration for some time. In essence, these would allow whole categories of things (e.g., all diesel powered buses' per km cost) to have their costs increased/decreased at once, rather than having to edit hundreds of .dat files each time. In principle, this is not too hard to implement, but quite how to do it (e.g., what categories to have) needs some thought.

Closely connected to this is a mechanism for simulating inflation. This should not be too difficult technically (but might take a little time to set up all the various structures and systems), but very careful thought will have to be given to how to make this work: do we start with the existing prices, and try to back-calculate, for example, what proportion of a steam railway locomotive's per km running cost is coal and what proportion labour, or do we replace the per km running cost entirely with a coal factor and a repairs factor?

Help to code these features from a moderately experienced coder or better would be very much appreciated, as would any reasonably well considered thoughts as to how, conceptually, to achieve the inflation factoring efficiently.

Convoy based features
This is a complex area for the reasons discussed here (and possibly elsewhere). The current replacing system does not work for legacy vehicles and so cannot be used to cascade, and can be chaotic and frustrating to use. Clarity is needed in precisely what each in-game vehicle represents if the costs of vehicles are properly to be balanced. Set against that is the need not to make the game too fiddly, awkward or complicated. Some serious work in this respect will be needed before the game can balance, but it is not clear to me yet whether full convoy re-combination will be necessary for balancing.

Help in the form of coding from an experienced coder or contribution to this discussion would be most welcome.

Other bugs
I see that  there have been some other bugs reported in the forum during my absence. I will have to look into those and determine whether I can reproduce them, whether I can fix them easily and, if not, how important that they are before deciding how to proceed in respect of them.

How to help
I imagine that at least some of those reading this thread would be as keen to see a well balanced new version of Simutrans-Experimental with bugs fixed and the features described above finished at least almost as much as I should. Those who have coding experience in C++ have innumerable opportunities to assist, and any such assistance will be invaluable in greatly reducing the lead time before the next version is released.

Those without knowledge of coding can also help, however, by testing (as many already do, as the large number of helpful bug reports attest); both general testing (reporting bugs that arise in normal playing) and specific testing (testing with the aim of narrowing down the source of specific bugs as in the new desync bug) are very much appreciated.

On a more abstract level, contributing to discussions such as this or this is very helpful.

Miscellany

For a more comprehensive overview of the currently outstanding coding projects, see here.

I also anticipate possibly spending some time in between the somewhat challenging projects outlined above doing a little not so critical work on Pak128.Britain-Ex for relaxation purposes, which is likely to include things that can/will be incorporated into the Standard version of that pakset, too.

If anyone would like to help in any way on any of the projects, please contact me, either by PM or by posting in the forum (in one of the threads to which I refer above, if appropriate).

Edit: Collaboration

Incidentally, I should welcome anybody who would wish to collaborate more generally on Simutrans-Experimental with me, sharing both some element of the general maintenance work and of the ability to control and shape the future development of Simutrans-Experimental. It is no more than an accident of history that this has historically been a one man band project, albeit with some extremely helpful and substantial contributions ad hoc from people such as Knightly, Bernd Gabriel and Neroden, as well as others; the project could benefit from having some more in the way of leadership as well as work. Anyone interested in such collaboration, please contact me by private message.

[Jando]

First of all thanks, James, for your continuous work on this project. Your work already has given me many hours of enjoyment, and I can only offer my thanks in return. Really good to hear that you're settled and hopefully comfortable again!

As to the priorities: 

1. Getting the current release into a playable state again. The current release has game-breaking bugs (notably: http://forum.simutrans.com/index.php?topic=13725.0 and http://forum.simutrans.com/index.php?topic=14417.0). I experienced them myself in the single-player game and cannot comment on the desync issues in the multi-player game. It's a matter of choice (i.e. your choice!) whether time should be spend on fixing these bugs for a new "intermediate" release (with no "new" features) or whether the current version of Experimental gets abandoned. In case it gets abandoned I would advise to clearly state that the current release is broken, so that new players know what they're getting.

2. Make a clear cut, abandon the current version and start with your new development plans, like Signalling, Town Growth and other features you have in mind. How many of these features should be addressed (and in what order) depends mainly on a simple decision about the time-frame. That's again your choice. Introducing many new features will mean that a new, playable release is still some time away, cutting the work into smaller chunks means that a playable version can be released earlier. 

As for help:
Sadly I have no experience with coding in C++, my last coding experience is from many, many years ago when C++ wasn't even invented yet and I never made the transition from procedural to object-oriented programming. Yes, I'm showing my age here. I'm however more than willing to help in testing, not only in general testing but also in targeted testing if you can want to deal with certain issues.

Btw, if you want save-games of a small map where the mentioned two bugs are easily re-produced, by now I reliably can re-produce the bugs on any small map. Just say and I'll upload them.

[Junna]

First of all thanks, James, for your continuous work on this project. Your work already has given me many hours of enjoyment, and I can only offer my thanks in return. Really good to hear that you're settled and hopefully comfortable again!

As to the priorities: 

1. Getting the current release into a playable state again. The current release has game-breaking bugs (notably: http://forum.simutrans.com/index.php?topic=13725.0 and http://forum.simutrans.com/index.php?topic=14417.0). I experienced them myself in the single-player game and cannot comment on the desync issues in the multi-player game. It's a matter of choice (i.e. your choice!) whether time should be spend on fixing these bugs for a new "intermediate" release (with no "new" features) or whether the current version of Experimental gets abandoned. In case it gets abandoned I would advise to clearly state that the current release is broken, so that new players know what they're getting.

I think those are already fixed in the current development version?

[jamespetts]

Before C++ was even invented? Goodness me - I believe that I was a toddler, if that, when C++ was invented in the early 1980s. I remember procedural programming in BBC Basic when I was a nipper - OO is much, much better, although C++ can be painful at times (the manual memory management in particular can introduce bugs that are fantastically difficult to trace and very easy to create).

I am reluctant to re-fix things in the current release that are already fixed in the latest development code, as the ultimate priority is to get to a point where I can release a version that I can then use to balance the pakset (Pak128.Britain-Ex), as, without balance, there is only half a game anyway.

Any testing would be appreciated, although I realise that this may be difficult if you are not able to compile from source.

[Jando]

Before C++ was even invented? Goodness me - I believe that I was a toddler, if that, when C++ was invented in the early 1980s. I remember procedural programming in BBC Basic when I was a nipper - OO is much, much better, although C++ can be painful at times (the manual memory management in particular can introduce bugs that are fantastically difficult to trace and very easy to create).

I am reluctant to re-fix things in the current release that are already fixed in the latest development code, as the ultimate priority is to get to a point where I can release a version that I can then use to balance the pakset (Pak128.Britain-Ex), as, without balance, there is only half a game anyway.

Any testing would be appreciated, although I realise that this may be difficult if you are not able to compile from source.

I well understand your reluctance to change the current release, James, and as I said, it's your choice to make anyway. Perhaps you might edit the post announcing the release then, so that people at least know that it's currently not in a working state. I'll have to look into how to compile the sources, it's at least 20 years ago that I last used a compiler.

[jamespetts]

May I suggest this thread for information as to how to go about compiling Simutrans-Experimental? I have added reference in the release post to there being known bugs.

[Jando]

Thanks, James, had seen the thread. I'm on Linux here, thus that won't work. Ah well, no big deal, I'll just wait.

Thanks again for your work on this project!

[jamespetts]

Ahh, I see, Linux. Do you know compilation in Linux in general? Which bit are you stuck with?

[Vladki]

I have compiled experimental (stable and devel) without problems. Maybe you just miss some libraries (libsomething-dev packages). Anyway I can share linux executables if you wish.

[killwater]

These are great news!

[zook2]

Great news indeed, and looking forward to the next version!

[Jando]

I have compiled experimental (stable and devel) without problems. Maybe you just miss some libraries (libsomething-dev packages). Anyway I can share linux executables if you wish.

Well, that would be most appreciated, Vladki. I have not made any progress with compiling myself, I just don't know enough about the Linux setup. Thus if you could upload the executable somewhere (perhaps http://files.simutrans-germany.com/) that would be great.

I can run the Windows executable as well, at least the current 11.35 release runs well on the Linux WINE windows emulator.

[jamespetts]

I have pushed a few fixes which might conceivably fix the electricity in cities desync issue: would anyone care to test this?