factory: expand_* / *_boost

[prissi]

BItte? Nahezu alles ist abwärtskompatibel, keines der neuen Features muss genutzt werden. Lasst mal die Kirche im Dorf.

Auf der anderen Seite schreien dir Nutzer ...

[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.

[Dwachs]

Aber nur wenn Programmierer und Grafikset-Entwickler zusammen arbeiten, dann haben auch die Nutzer was davon.

[...]

Kommunikation ist was schönes, aber bei Simutrans ein Fremdwort.

Da hast du natuerlich recht. Da kannst du aber gerne bei dir selber anfangen. Quasi jeder dritte Post ist pures Rumgemotze. Soviel zum Thema 'Zusammenarbeit'.

[BR84]

Gut prissi da geh ich mit.

Frag mich allerdings ob es das Ziel ist eine software am start zu haben, deren Funktionen nicht oder nur teilweise genutzt werden.
So wie sich das nach deiner Antwort darstellt ist es ja alles nicht so schlimm und die PakSet's können einstweilen einen älteren Funktions- und Programmierstand nutzen, da (fast) alles abwärtskompatibel ist.
Würde bedeuten das Programm schiesst immer weit voraus - die Sets hängen hinterher.
(je weniger (verständlich) dokumentiert wird, desto weiter hängen sie nach)

Kann doch nicht ernsthaft das Ziel sein - oder verwechsel ich da grundsätzlich was?

[Wurzelgnom]

Aber nur wenn Programmierer und Grafikset-Entwickler zusammen arbeiten, dann haben auch die Nutzer was davon.

[...]

Kommunikation ist was schönes, aber bei Simutrans ein Fremdwort.

Da hast du natuerlich recht. Da kannst du aber gerne bei dir selber anfangen. Quasi jeder dritte Post ist pures Rumgemotze. Soviel zum Thema 'Zusammenarbeit'.

Klar, Frust von 6 Jahren und immer wieder ignorirte fragen trotz des Spruchs "Wer was wissen will kann Fragen und Dwachs antwortet auch".

Die Wertigkeit der Parameterzahlen wurde immer noch nicht beantwortet. Scheiß rumgewarte über Tage, Wochen und Monate, so was kotzt mich halt immer mehr an.

Der erste Post mit Fragen stammt vom Donnerstag, 9. Oktober 2014, 22:44 und erst jetzt nach wiederholter Nachfrage gabs mal ne Antwort dazu. Wobei die auch nicht vollständig ist.

Viele Versprechen/Willensbekundungen ohne Ergebnisse, in dem fast 10 Jahren seit ich bei Simutrans dabei bin.

Und wenns Dir halt nicht mehr passt mein Auftreten, dann schaff doch mal Fakten und schmeiß mich aus dem Forum.

Und Tatsache ist, die Informationen werden immer weniger die hier ankommen. Geht schon so weit, das man in einem deutschen Forum englich können muss, weil einfach der Engliche Text aus dem int. Forum rüber kopiert wird. Wenn denn überhaupt, siehe Ankündigung zur 112.3.
Die Ankündigungen sind schon seit Jahren ein Witz.

Oder noch besser, übernimm doch einfach das pak64.german und release Ostern ne aktuelle Version für Simutrans 120.x.x ( Dateien kannste von prissi bekommen ). Aber dann bitte schön mit dem vollen 100% Funktionsumfang der 120er Version. Und garantiert Fehlerfrei, denn Du weist ja über alles Bescheid, im Gegensatz zu den meisten anderen.

[prissi]

Die meisten Funktionen sind in einem oder dem anderen Pakset benutzt. Aber im Prinzip kann Simutrans immer noch mit einem pak für Version 102.2.2 benutzt werden (pak 96HD zum Beispiel).

Und wenn Simutrans schon zu viele schlecht dokumentierte Neuerungen hat, was ist dann bitte mit der Experimental-Version ... ?

Wenn jemand die Änderung nicht gefällt, dann muss es ja nicht gemacht werden. Auch gibt es paks (pak96.comic) die schon länger kein Update mehr gesehen haben und trotzdem noch funktionieren.

Wie soll denn auch sonst Weiterentwicklung funktionieren? Ein Paksetentwickler (ja auch Frank) wünscht sich was, es wird eingebaut, und dann liegt der Ball halt wieder bei Pakset. Oder ein Spieler schlägt was vor. Oder ein Programmierer will was ausprobieren.

Ja und manche Sachen werden halt von Leuten eingebracht (wie die just_in_time 2 Geschichte), die nicht so tief im Projekt stehen. Die hier auch gar nicht mitlesen, weil sie z.B. Brasilianer sind (wo Simutrans sehr verbreitet ist). Oder Japaner. Und ich bin dann zuständig Sachen, die ich nicht programmiert habe, die ich kaum getestet habe, die ich nicht verwende zu dokumentieren?

Es ist OpenSource. Das heisst nicht nur, dass man umsonst Programmierer bekommt ...

[Flemmbrav]

Was bräuchte man denn überhaupt für eine Art Dokumentation?
Würde es nicht für die Meisten (Paksetentwicklern) völlig ausreichen, wenn man bei "Paksetrelevanten" ADD und CHQ -s in einen separaten (das ist ganz wichtig, damit man nicht lange suchen muss, sondern auch findet, was man braucht) Log schreibt, was diese tun/verändern, und wie man diese anspricht?
Das müsste meiner Meinung nach nicht einmal mehr schön ausformuliert, sondern einfach kurz und knapp, im simpelsten english, so dass es jeder lesen kann.
zb.:
https://github.com/aburch/simutrans/comm...dfd6e3ba5c
=>

Code:

ADD
New building type 'dock'.
Similar to harbour, but on flat ground.
parameter => "type=dock"

Fast genau so, wie zur Zeit. Zumindest in diesem Fall war es für mich leichter als leicht das wichtige herauszubekommen.
Aber wenn zb. "more precise city growth calculation" [Link] das einzige ist, was man über einen Commit herausfindet, ist das echt ärgerlich, und schreckt mich auch total ab weiter zu gucken, woran gebastelt wird, da zumindest ich keine Chance mehr habe, einen Überblick zu bekommen. In diesem Fall könnte (rein hypothetisch) dies durchaus auch bedeuten, dass ich neue Möglichkeiten zum Einstellen bekäme, als auch, dass meine bisherigen Einstellungen verfälscht werden, und damit die Paksetbalance gleich mit.

Wenn man ein aufgeräumtes Log hätte, wäre für Pakersteller dann eigentlich nur noch wichtig, ab welcher Revision das ganze testbar ist,
bzw. wie sie herausfinden, ob die Funktion schon unterstützt wird, und damit, ob der Fehler bei ihnen, oder an der fehlenden Unterstützung seitens der genutzten Simutransversion liegt.

Was meint ihr? wäre das eine Lösung?
Der Aufwand für die Programmierer dürfte nicht allzu hoch sein, und mit einer Suchfunktion wäre er auch für Paksetentwickler als Nachschlagwerk nutzbar.
Vielleicht schafft man das sogar, diesen log automatisch zu schreiben, oder die derzeitigen Commits so sortierbar zu machen, dass man nur die für Paksetentwickler relevanten angezeigt bekommt.

[Valdore]

Warum denn ein pak.german mit allen Funktionen der 120.0.1 bis Ostern?
Das pak.german funktioniert mit der aktuellen V wunderbar,und die halben Höhen/irgendwelche anderen das Spiel Ansich nicht wirklich weiter beeinflussende Funktionen müssen ja nicht sofort hinzugefügt werden.viel wichtiger ist,dass man lieber erstmal alles grafische vervollständigt und dabei nicht wählerisch bleibt("och,nehmen wir mal den MVG-C ins Set der aber kaum was nützt aber die anderen Fahrzeuge von Dogstar lieber nicht obwohl sie das größere Problem Timeline lösen würden")

Fakt ist

-das pakset ist fast tot (ohne mich hätte es keinen MVG-C gegeben,den hat Flemm gemacht weil ich die Front nicht machen konnte)
-nicht jeder Schnickschnack sollte benötigt werden
-Man kann auch eine Paksetversion nur mit neuen Grafiken machen (!)
-Man kann auch eine Paksetversion einzig und allein mit Fehlerkorrekturen machen.

Meine Fahrzeuge mögen vielleicht unausbalanciert sein,aber ich habe seit spätestens der letzten "Version" meines Noch-AddOns der U-Bahnen meine Sourcen dabei.und die waren immer dabei. Ich weiß nicht wo du keine Sourcen gesehen hast,Frank.

Der Link zu den Bahnen


@Flemm
Ich finde deine Idee Sehr gut :thumbup:

[Leartin]

Ist halt schon doof, wenn auf der einen Seite Leute rummaulen, weil sie mit der Fülle an Funktionen nicht klarkommen, und auf der anderen Seite sich manche kaum mehr trauen ihre Ideen vorzuschlagen, um nicht zuuu lästig zu sein.
Denn kaum was wird direkt vom Spieler an die Programmierer gewünscht, der Spieler an sich will eher was vom Paksetautor.

Ein Beispiel: Kürzlich gabs folgende Meldung zum Pak192.comic im Internationalen:

I like playing around 1995, although much before 1951 and the industries seem to look out of place and are few in type.

Die Beschwerde lautet, dass Industrien grafisch nicht zu der Zeit passen, in der sie entstehen. Das liegt daran, dass es bisher nur eine Grafik je Industrie gibt, welche so gestaltet ist, dass sie zu den späteren Jahren passt. Wäre es anders, mit Industriegrafiken die perfekt ins Jahr 1900 passen, so würde sich das Problem einfach nur umkehren, und statt zu modernen Fabriken in frühen Jahren hat man dann zu alte Fabriken in späten Jahren.
Als Paksetautor kann ich den Wunsch des Spielers also nicht erfüllen, zumindest nicht ohne woanders Abstriche zu machen. Gibt also zwei Möglichkeiten:
1.) Die "Schuld" von mir weisen und behaupten, dass Simutrans es eben nicht kann und es deshalb nicht geht.
2.) Die entsprechenden Vorschläge im Fundus der Extension Requests rauszusuchen (denn da gibts sicher schon was), und das ganze Thema mal wieder aufwärmen (sofern es kein eindeutiges Nein gab) oder eben einen neuen Vorschlag einbringen, wenn man kreativ genug ist, auch eine Umsetzungsmethode vorschlagen zu können.
Zweiteres werde ich bestimmt irgendwann noch machen

Auch, wenn man sich das Extension Requests Forum durchliest findet man im Grunde zwei Dinge:
1) Pakset-Entwickler, die auf irgendeine technische Limitierung stießen, aufgrund derer sie nicht umsetzen konnten, was sie wollten, und deshalb darum bitten, diese technische Limitierung aufzuheben.
2) Requests von Spielern, welche sich direkt auf die Spielsteuerung beziehen und daher für Pakset-Entwickler nicht von Bedeutung.
Man merkt jedenfalls sehr deutlich, dass die Spieler kaum was vorschlagen, das viel Arbeit für Pakentwickler bedeutet, das sind die Pakentwickler selber. Auf der vordersten Seite ist da so ein Typ namens Leartin besonders lästig :.



Dass viele Paksets viele Funktionen nicht nutzen liegt nicht etwa daran, dass es nutzlose Funktionen gibt, sondern eher daran, dass nicht jedem jede Funktion gefällt. Möglichkeiten bedeuten nicht, dass man alles machen muss, sondern nur, dass man das machen kann, was man machen will. Wäre man verrückt genug, wirklich alle Möglichkeiten nutzen zu wollen, wäre bereits das erstellen eines einzelnen einkacheligen Gebäudes eine Tortur - momentan wären da 8 Rotationen und 5 Jahreszeiten fällig, die Möglichkeit zum Frontimage lässt sich gut mit der Möglichkeit zur Animation kombinieren, und natürlich wäre es 4 Kacheln hoch - weils möglich ist. In Summe 160 Background Images und 120 Front Images (bei einer 3-Frame-Animation), ich glaube, kein vernünftiger Mensch würde sich 280 Grafiken pro Gebäude antun - aber es ist möglich.
Genauso verhält es sich mit vielen anderen Funktionen. Speedbonus, halbe Höhen, Beladungszeiten, Menühintergrundgrafiken, 5 Jahreszeiten für Gebäude, oder überhaupt erstmal Wintergrafik - all das kann man machen, muss man aber nicht. Simutrans nimmt mehr und mehr den Charakter einer Transportsimulationsengine an, deren Paksets die eigentlichen Spiele sind, und entfernt sich von der Vorstellung eines Spiels mit unterschiedlichen Grafikmöglichkeiten. Und wenn nun jemand daherkommt und eine Funktion programmiert, mit der der Spieler in Städten "vorplanen" kann, ob dort Industrie, Kommerz, Wohnungen oder Sehenswürdigkeiten entstehen, so ist diese Funktion recht nutzlos für eine Transportsimulation - aber zugleich auch nicht schädlich und zumindest im Karteneditor nützlich (Man baue Feldwege, verschiedene Stadtzonen, und erhöhe dann die Einwohnerzahl...) - Der Punkt ist, jeder sieht in Simutrans etwas anderes. Das fängt schon damit an, dass manche glauben es sei kein Spiel sondern eine Simulation, während andere kaum was simulieren sondern nur spielen. Manche glauben, ein Haus sei ein Haus, während andere behaupten jede Kachel sei ein paar hundert Meter zum Quadrat, und die Häuser nur symbolisch. Was wäre da passender, als prinzipiell alle Meinungen zuzulassen und die Programmierung für alle voranzutreiben, während die genaue Spielweise von den Paksets gesteuert wird?

Aber ja, man kann auch einfach meckern, was alles nicht passt, anstatt das Problem in einer Extension Request darzulegen und Lösungsvorschläge zu unterbreiten. (Nicht Englisch sprechen zu können ist dabei sicher das größte Problem, allerdings ein Problem des Individuums. Im Internationalen Forum gibt es 9 verschiedene Fremdsprachenforen und 2 Verlinkungen, der Simutranslator verfügt über 34 Sprachen. Entwicklungssprache ist englisch, deutsch hat keine Sonderstellung.)

[NNW]

Simutrans nimmt mehr und mehr den Charakter einer Transportsimulationsengine an, deren Paksets die eigentlichen Spiele sind, und entfernt sich von der Vorstellung eines Spiels mit unterschiedlichen Grafikmöglichkeiten.

Und ich finde dass ist gut so. ST hat eine Langzeitmotivation, die mir bei anderen =>meist kommerziellen0<= Projekten bisher immer völlig gefehlt hat. Einmal durchspielen, CD ins Regal stellen und vergessen.

Es ist OpenSource. Das heisst nicht nur, dass man umsonst Programmierer bekommt ...

Da hast du was wahres gesagt. Deswegen finde Ich, dass man einem geschenkten Gaul nicht ständig in den Rachen Glotzen sollte.

Würde es nicht für die Meisten (Paksetentwicklern) völlig ausreichen, wenn man bei "Paksetrelevanten" ADD und CHQ -s in einen separaten (das ist ganz wichtig, damit man nicht lange suchen muss, sondern auch findet, was man braucht) Log schreibt, was diese tun/verändern, und wie man diese anspricht?

Dass sollte man unterstreichen. Wenn man sich relativ schnell einen Reim auf die neuen/geänderten Parameter machen kann in dem man in die Changelogs guckt , dann kann man auch mit Trial & Error schnell zum Ziel kommen und braucht nicht auf eine Antwort der Programmierer warten, bzw. diese gar nicht erst Fragen.
Das deutschsprachige Wiki hängt ja leider dem englischen hinterher, weil sich bisher keiner aufraffen konnte, die englischen Beschreibungen ins deutsche zu übertragen. Wenn es nicht nur so in Arbeit ausarten würde....