factory: expand_* / *_boost

[Wurzelgnom]

..., keines der neuen Features muss genutzt werden. ...

Na klar, werde ich dich wieder dran erinnern wenn Du auf bestimmte Funktionen verweist die man aber nicht nutzen möchte.

Entweder weil man sie schlicht nicht nützlich findet oder eben gar nicht richtig versteht.

... Auf der anderen Seite schreien dir Nutzer ...

Klar tun sie das und werden es immer tun.

Nur hat Simutrans nun mal diese Zweiteilung von Programm und Grafikset.

Und ihr hört eben mehr auf die Nutzer statt auf die, die die Funktionen auch in die Grafiksets einpflegen müssen.

Aber nur wenn Programmierer und Grafikset-Entwickler zusammen arbeiten, dann haben auch die Nutzer was davon. Und davon scheint man immer weiter sich zu entfernen.
Bzw. kann man nur noch Grafikset-Entwickler sein, wenn man den Programmcode lesen und verstehen kann.

Und wie bitte schön sollen Außenstehende etwas Dokumentieren wenn sie gar nicht nachvollziehen können wie was funktioniert?

Kommunikation ist was schönes, aber bei Simutrans ein Fremdwort.
Also auch wenn es schwer fällt, weniger programmieren und öfters Funktionen ausführlicher erklären. Das Ergebnis ist dann, das Funktionen auch genutzt werden und nicht nur eingebaut wurden und vor sich hin gammeln.

Und ich befürworte es immer noch, das Versionen länger gepflegt werden sollten. Gerade dann, wenn größere Umbauten stattfinden.
Bei Software-Projekten gibt es nicht um sonst Entwicklungs- und Release-Zweige.
Für Release-Zweige würde sich SF anbieten. Statt eben die Zip mit den Code hoch zu laden einfach ins dortige SVN als Zweig einstellen. Dann wäre der Code unabhängig und es können sogar andere die es wollen die betreffende Version weiter pflegen und mit Bugfixen versorgen. Je nach Änderungen ( Menge oder schwere des Problems ) hin und wieder mal compilieren und hochladen. Die originale Revisionsnummer kann man je fest reinschreiben und die SF-Revisionsnummer dann dahinter.

Und es wird immer an zu vielen Stellen gleichzeitig rum gebaut finde ich.