(14.04.2017, 17:22)ic111 schrieb: Ja, bis zu einem gewissen Grad geht es wohl um einen Perfektionismus, den man in einem Hobbyprojekt einfach häufig realistisch nicht erfüllen kann.

Hier möchte ich gerne widersprechen. Es geht den OpenTTD-Entwicklern nicht primär um "Perfektionismus", sondern um den erhalt der Wartbarkeit. Nahezu allle bisherigen Patchpacks sind irgendwann unter der Last ihrer (zumeist unfertigen, qualitativ minderwertigen) Patches zusammengebrochen. Wenn der Entwickler selber schon kaum hinterherkommt, die im Laufe der Zeit aufkommenden Inkompatibilitäten zu behandeln, wie soll das denn sein Nachfolger tun? Und genau das soll beim "Trunk" eben nicht passieren.

Deswegen ist der Patch-Review-Prozess so konservativ angelegt. Einerseits um sicherzustellen, daß der Patch "fertig" ist, und von Leuten, die nicht an der Entwicklung beteiligt gewesen sind, gewartet werden kann, und zweitens, um zukünftige Entwicklungen nicht zu verbauen, insbesondere wenn der Autor schon längst die Community verlassen hat.

Eddi schrieb:Deswegen ist der Patch-Review-Prozess so konservativ angelegt. Einerseits um sicherzustellen, daß der Patch "fertig" ist, und von Leuten, die nicht an der Entwicklung beteiligt gewesen sind, gewartet werden kann, und zweitens, um zukünftige Entwicklungen nicht zu verbauen, insbesondere wenn der Autor schon längst die Community verlassen hat.

Es gibt Fälle in denen das genau andersherum gelaufen ist ("there's almost nothing more creative than devs finding reasons not to include patches").

Gruß
Michael

(15.04.2017, 09:44)Eddi schrieb:

(14.04.2017, 17:22)ic111 schrieb: Ja, bis zu einem gewissen Grad geht es wohl um einen Perfektionismus, den man in einem Hobbyprojekt einfach häufig realistisch nicht erfüllen kann.

Hier möchte ich gerne widersprechen. Es geht den OpenTTD-Entwicklern nicht primär um "Perfektionismus", sondern um den erhalt der Wartbarkeit.

Fragt sich halt auf welcher Ebene man von Wartbarkeit spricht. Solange es um grundlegende Designentscheidungen geht, klar, die müssen passen.

Je mehr wir aber ins Detail, in Dinge die nur lokale Auswirkungen haben, kommen, desto besser sollten meiner Meinung nach die Gründe sein, bevor man von jemandem erwartet sie nochmal über den Haufen zu werfen, obwohl es funktional eigentlich kein Problem gibt, sondern nur das Problem "jemand anderes hätte das anders gelöst".

Zitat:Nahezu allle bisherigen Patchpacks sind irgendwann unter der Last ihrer (zumeist unfertigen, qualitativ minderwertigen) Patches zusammengebrochen. Wenn der Entwickler selber schon kaum hinterherkommt, die im Laufe der Zeit aufkommenden Inkompatibilitäten zu behandeln,

Ich habe diese Patchpacks nie im Detail verfolgt, mag sein dass da tatsächlich manches qualitativ minderwertige dabei war und ist.

Aber: Solange etwas im Status "Patch" ist, bedeutet das dass Änderungen in trunk eben nicht darauf abgestimmt werden. Die unausgesprochene Erwartungshaltung ist dann einfach, dass die Leute schon fünf, oder noch mehr Jahre lang ihre Patches immer wieder nachziehen. Und dann steht man da mit seinem auf Basis einer mittlerweile umgebauten Widget-Basisklasse entwickelten Widget, wo man dann selber rausfinden darf durch was man das ersetzen muss - derjenige der in trunk die zehn Vorkommen ersetzt hat konnte das praktisch in Fließbandarbeit machen, im Patch wird sowas zur größeren Detektivarbeit.

Und wenn das dann nicht nur ein einzelnes Patch ist, sondern ein ganzes Repository voll davon, wundert mich das wenig dass das irgendwann zum Problem wird. Man kann einfach nicht endlos lange beliebig viel Code in Patches verwalten.

Deswegen sollte man alles daran setzen die Zeitspanne wo etwas als Patch lebt kurz zu halten...

Zitat:Deswegen ist der Patch-Review-Prozess so konservativ angelegt.

... und dazu würde eben ein Prozess *mit* (frühzeitiger) Kommunikation gehören. Ein Prozess bei dem halbwegs frühzeitig klar ist, was für trunk interessant (aber noch nicht reif genug) ist, und was sowieso nicht reinpasst [und wenn es genügend viel aus einer Spielstil-Ecke gibt was aus inhaltlichen Gründen in letzterer Ecke landet ist es vielleicht tatsächlich Zeit für einen entsprechenden fork].

Bezogen auf die mittlerweile in trunk befindlichen More Heightlevels hätte das z.B. heißen können, nicht nach 6 Jahren (ohne initiale Frage "hast du in den nächsten Monaten Zeit ein Review zu verarbeiten?" ==> "hatte ich nur begrenzt, weswegen dann natürlich ein Punkt bei mir unterging und nochmal zum großen Knall führte) das Review anzufangen, sondern bereits nach einem Jahr, wo der Hauptteil der Entwicklungsarbeit wohl schon getan war mal den Satz "Wir hätten gerne More Heightlevels in trunk, kannst du uns das in einen Zustand bringen der akzeptabel ist?" über sich zu bringen.

Bei meinen anderen beiden Groß-Patches kann ich bei den Fahrplänen nur vermuten dass die Änderung in der Funktionsweise von Fahrplänen wohl zu tiefgreifend ist als dass das jemand anfassen wollte, und bei den Flüssen ist der Code lokal im Generator konzentriert (abgesehen von Anpassungsarbeiten an der Generator-GUI keine Wechselwirkungen mit dem restlichen Spiel), aber eben mehrere tausend Zeilen Algorithmen, was bei einem Review wohl im "ich hätte den aber anders implementiert"-Feedback enden würde.

Aber wissen was die projektseitige Meinung dazu ist tue ich eigentlich überhaupt nichts, und das ist, gegeben dass das grundsätzliche Konzept seit langem stabil ist, da etliche Monate Arbeit drinstecken, und technische Probleme (abseits der Grundsatzfrage "wollen wir das Konzept?") wenn dann im Detail liegen schon arg wenig an Kommunikation. Das schreibe ich jetzt einfach mal so, wie andere Leute Patches bewerten.

Und mittlerweile schreibe ich das eben in einer Situation wo ich wenig Zeit für sowas habe (also mir eigentlich mindestens kurzfristig garnicht wünschen kann dass jemand sagt "wollen wir"), aber es andererseits auch schade finde dass soviel Arbeit in einem 95-Prozent-fertig-Zustand verpufft.

Zitat:Einerseits um sicherzustellen, daß der Patch "fertig" ist, und von Leuten, die nicht an der Entwicklung beteiligt gewesen sind, gewartet werden kann, und zweitens, um zukünftige Entwicklungen nicht zu verbauen, insbesondere wenn der Autor schon längst die Community verlassen hat.

... Teamarbeit kann aber auch sein, in solchen Fällen auf der Arbeit aufzubauen, anstatt die nächste Generation das Rad nochmal neu erfinden zu lassen - wenn man in Fällen wo man sagt "ist zwar nicht perfekt, aber groß andere Dinge kaputt machen kann es eigentlich auch nicht" sagt "passt schon" anstatt auf Perfektionismus zu setzen, eröffnet man anderen Leuten die Chance, die paar Ecken die eine Neuentwicklung vielleicht noch hat über ein paar kleinere Patches auszubügeln.

(15.04.2017, 15:38)ic111 schrieb: wenn man in Fällen wo man sagt "ist zwar nicht perfekt, aber groß andere Dinge kaputt machen kann es eigentlich auch nicht" sagt "passt schon" anstatt auf Perfektionismus zu setzen

Ähm, vielleicht, aber historisch gesehen ist das schon einige Male schiefgegangen. Als Beispiele wären hier zu nennen:

• Der ursprüngliche PBS Patch, der den Trunk in einem Zustand hinterließ, in dem man nicht sinnvoll ein Release machen konnte, und dessen Entfernung eine große Welle an Enttäuschung hinterließ
  
• Der "Bridges over Everything" Patch, der in den Trunk eingeführt wurde, aber der Patch-Autor daraufhin ausflippte, weil er meinte es wäre noch nicht fertig, und deswegen wieder entfernt werden mußte
  
• Der TGP Patch, der zwar irgendwie funktioniert, aber sich mittlerweile rausgestellt hat, daß er miserabel Kommentiert wurde, und keiner so richtig weiß, wie man ihn ändern soll, um einige ... Misfeatures ... auszutreiben.
  

Zitat:Und mittlerweile schreibe ich das eben in einer Situation wo ich wenig Zeit für sowas habe (also mir eigentlich mindestens kurzfristig garnicht wünschen kann dass jemand sagt "wollen wir"), aber es andererseits auch schade finde dass soviel Arbeit in einem 95-Prozent-fertig-Zustand verpufft.

Naja, das mit der Zeit geht aber auch nicht nur dir so. Auch das Developer-Feld hat sich in letzter Zeit massiv ausgedünnt... und Nachwuchs ist bei Retrospielen auch etwas schwierig.

Zitat:kann ich bei den Fahrplänen nur vermuten dass die Änderung in der Funktionsweise von Fahrplänen wohl zu tiefgreifend ist als dass das jemand anfassen wollte

Das Problem hier ist mWn ein philosophischer Konflikt, daß einerseits die Fahrplan-GUI jetzt schon total überladen ist, aber andererseits von Spielern immer wieder nachgefragte Funktionalität fehlt. Und keiner hat so richtig eine Idee, wie man beides gleichzeitig lösen kann. Das zweite Problem ist, daß derartige Patches meistens nur sehr spezielle Spielweisen im Auge haben, aber aus Sicht der Devs eine allgemeinere Lösung wichtig wäre. Ich hab mir deinen Patch aber lange nicht mehr angeschaut, weiß also nicht, wie das konkret auf dich anzuwenden wäre.

Zitat:bei den Flüssen ist der Code lokal im Generator konzentriert (abgesehen von Anpassungsarbeiten an der Generator-GUI keine Wechselwirkungen mit dem restlichen Spiel), aber eben mehrere tausend Zeilen Algorithmen, was bei einem Review wohl im "ich hätte den aber anders implementiert"-Feedback enden würde.

Den Patch kenne ich leider nicht, kann also nicht viel dazu sagen. Zwecks Generator aber sei auf das TGP-Problem verwiesen.

(15.04.2017, 16:43)Eddi schrieb:

(15.04.2017, 15:38)ic111 schrieb: wenn man in Fällen wo man sagt "ist zwar nicht perfekt, aber groß andere Dinge kaputt machen kann es eigentlich auch nicht" sagt "passt schon" anstatt auf Perfektionismus zu setzen

Ähm, vielleicht, aber historisch gesehen ist das schon einige Male schiefgegangen. Als Beispiele wären hier zu nennen:

• Der ursprüngliche PBS Patch, der den Trunk in einem Zustand hinterließ, in dem man nicht sinnvoll ein Release machen konnte, und dessen Entfernung eine große Welle an Enttäuschung hinterließ

Ich hab davon schon gelesen, und muss da die Frage stellen: Konnte man das wirklich nicht sehen, als man den commit gemacht hat? Ich meine, man muss ja nicht vom einen ins andere Extrem schwanken und plötzlich lauter Sachen committen die einem alles zerhauen.

Klar kann das eine durchaus schwierige Entscheidung sein. Aber, man wird ja mit der Zeit auch erfahrener, ich denke ich bin hier nicht der einzige der auch beruflich mit Softwareentwicklung zu tun hat, wenn man mal ein paar solche Projekte von innen gesehen hat, dann hat man irgendwann ein Gefühl dafür wo man aufpassen muss, und wo man sagen kann "vielleicht nicht optimal, aber bringt uns auch nicht um".

Ich fluche im echten Leben selber grade auch nicht schlecht über Code, den mir meine Vorgänger hinterlassen haben, der vom Design her völlig undurchsichtig ist, und den ich ersetzen / nachprogrammieren muss.

Zitat:

Der "Bridges over Everything" Patch, der in den Trunk eingeführt wurde, aber der Patch-Autor daraufhin ausflippte, weil er meinte es wäre noch nicht fertig, und deswegen wieder entfernt werden mußte

Hat man ihm das denn vorher gesagt dass er jetzt committed wird?

Zitat:

Der TGP Patch, der zwar irgendwie funktioniert, aber sich mittlerweile rausgestellt hat, daß er miserabel Kommentiert wurde, und keiner so richtig weiß, wie man ihn ändern soll, um einige ... Misfeatures ... auszutreiben.

Meine persönliche Meinung dazu ist ja, dass tgp versucht Landschaftserstellung mit einer relativ simplen mathematischen Funktion abzubilden, die zwar in manchen Fällen halbwegs brauchbare Ergebnisse liefert, aber nicht geeignet ist die ganze Komplexität von Landschaftsentstehung auch nur annähernd abzubilden.

Will sagen, mag sein das tgp auch ein Kommentierungsproblem hat (ich hab mich da bei MoreHeightlevels auch schonmal damit rumgeprügelt), aber in erster Linie hat einfach das zugrundeliegende Konzept seine Grenzen.

An der Stelle finde ich das aber nicht so dramatisch, weil wenn du sagst, wir wollen einen besseren Landschaftsgenerator, und jemand findest der ihn implementiert, dann ergänzt du einen Eintrag im entsprechenden Dropdown und bindest halt noch einen ins System ein.

Zitat:Das Problem hier ist mWn ein philosophischer Konflikt, daß einerseits die Fahrplan-GUI jetzt schon total überladen ist, aber andererseits von Spielern immer wieder nachgefragte Funktionalität fehlt. Und keiner hat so richtig eine Idee, wie man beides gleichzeitig lösen kann. Das zweite Problem ist, daß derartige Patches meistens nur sehr spezielle Spielweisen im Auge haben, aber aus Sicht der Devs eine allgemeinere Lösung wichtig wäre. Ich hab mir deinen Patch aber lange nicht mehr angeschaut, weiß also nicht, wie das konkret auf dich anzuwenden wäre.

Da müssten wir jetzt genauer spezifizieren, was besagte "nachgefragte Funktionalität" ist, um einschätzen zu können ob ich das erfülle. Die Grundidee aus meiner Sicht findet sich aber in diversen Forumseinträgen, hier und im englischen Forum; wie und ob man das auf das was andere Leute gerne hätte anwenden könnte ist natürlich Diskussionssache.

Und ja, es kann ein grundlegender Konflikt zwischen Spielstilen sein, und nachdem ich sowas ja in erster Linie implementiere weil ich es haben will wäre das auch garnicht schlimm. Die Frage für mich ist halt einfach, lohnt sich der Extraaufwand sich zu bemühen das bereit für trunk zu machen?

Zitat:

Zitat:bei den Flüssen ist der Code lokal im Generator konzentriert (abgesehen von Anpassungsarbeiten an der Generator-GUI keine Wechselwirkungen mit dem restlichen Spiel), aber eben mehrere tausend Zeilen Algorithmen, was bei einem Review wohl im "ich hätte den aber anders implementiert"-Feedback enden würde.

Den Patch kenne ich leider nicht, kann also nicht viel dazu sagen. Zwecks Generator aber sei auf das TGP-Problem verwiesen.

[/quote]

Da verweise ich auf den damaligen Eröffnungsbeitrag und den daranhängenden Thread https://www.tt-forums.net/viewtopic.php?...0#p1137719

insbesondere aber auf das dort ebenfalls verlinkte Manual
https://www.tt-forums.net/download/file.php?id=182200
wo ich den grundlegenden Algorithmus, losgelöst von den Implementierungsdetails, dokumentiert habe.
(Quelltextkommentare hab ich allerdings auch so einige getippt wenn ich mich recht erinnere)

Wobei ich zu meiner Schande gestehen muss dass da bis eben im Eröffnungsbeitrag nicht die letzte Version dranhing, die war weiter hinten...

Ich würde dir mal empfehlen, mit Peter1138 zu reden, der hatte glaub ich letztens mal durch diverse Patchpacks geschaut, was da alles übernehmenswürdig ist. Ob er damit weit gekommen ist, weiß ich nicht, aber gerade jetzt nach dem Release wäre ein guter Zeitpunkt, neue Funktionalität hinzuzufügen.

Wird eigentlich überhaupt noch was für OTTD gemacht bzw. verbessert etc.?!

Definitiv
Erst in diesem Jahr ist mit NRT ein großes Feature in die normale OpenTTD Version hinzugefügt worden

Was ist NRT wenn ich fragen darf ?

Die Möglichkeit unterschiedlicher Straßentypen. Bei den Gleisen gibt es ja schon ohne NewGRF vier Gleistypen, nun gibt es mit entsprechenden NewGRF (aber ohne Patch) auch unterschiedliche Straßentypen.

Haas schrieb:Wird eigentlich überhaupt noch was für OTTD gemacht bzw. verbessert etc.?!

Nicht wirklich.

Die verbliebenen Entwickler arbeiten in erster Linie immer noch an ihrem Auftritt (github, compiler farm, website, download tool, ...). Ansonsten bedienen sie sich bei Jonathans patchpack (JGRPP) in Bezug auf bug fixes und einige ausgewählte Erweiterungen.

Ernsthafte Fehlerbeseitigung (abseits game crashs) findet mE nicht statt, obwohl es diesbzgl eine schier unendliche Liste gibt. Bzw gab, denn es war natürlich eleganter die alten Fehlermeldungen einfach zu löschen.

Ich kann nur jedem stattdessen das JGRPP  empfehlen. In Bezug auf Fehlerbehebung ist Jonathan unübertroffen. Und auch "unter der Motorhaube" setzt seine Weiterentwicklung von OTTD Massstäbe:


https://github.com/JGRennison/OpenTTD-pa...changes.md

Fazit: nicht nur für Spieler sondern auch für grf-Entwickler gibt es im JGRPP jede Menge Verbesserungen und hilfreiche Erweiterungen auf die man in der "offiziellen" OTTD Version seit Jahren wartet.

Gruss
Michael

Hallo

(11.06.2020, 08:40)mb schrieb:

Haas schrieb:Wird eigentlich überhaupt noch was für OTTD gemacht bzw. verbessert etc.?!

Nicht wirklich.

Die verbliebenen Entwickler arbeiten in erster Linie immer noch an ihrem Auftritt (github, compiler farm, website, download tool, ...). Ansonsten bedienen sie sich bei Jonathans patchpack (JGRPP) in Bezug auf bug fixes und einige ausgewählte Erweiterungen.

Ich als JGRPP-Spieler finde es schön, dass das Entwicklerteam und JGR zusammenarbeiten, weil beide Seiten davon profitieren. Aber abseits von JGRs Patchpack gibt es auch originäre Entwicklungen der OpenTTD-Teams. Deine Aussage "nicht wirklich" ist in ihrer Kürze falsch.

(11.06.2020, 08:40)mb schrieb: Ernsthafte Fehlerbeseitigung (abseits game crashs) findet mE nicht statt, obwohl es diesbzgl eine schier unendliche Liste gibt. Bzw gab, denn es war natürlich eleganter die alten Fehlermeldungen einfach zu löschen.

Seit dem Umzug zu Github ist die Frequenz der Entwicklung nach meinem Empfinden erheblich gestiegen. Das gilt sowohl für die Fehlerbehebung (auch abseits von JGRs Beiträgen) als auch für Features (der größte Brocken der letzten Zeit ist wohl RATT). Im übrigen sind die alten Fehlermeldungen keineswegs gelöscht, wie du hier schreibst, sondern der Vollständigkeit halber auch zu Github umgezogen.

(11.06.2020, 08:40)mb schrieb: Ich kann nur jedem stattdessen das JGRPP  empfehlen. In Bezug auf Fehlerbehebung ist Jonathan unübertroffen.

Fazit: nicht nur für Spieler sondern auch für grf-Entwickler gibt es im JGRPP jede Menge Verbesserungen und hilfreiche Erweiterungen auf die man in der "offiziellen" OTTD Version seit Jahren wartet.

Dem kann ich mich jedoch vollumfänglich anschließen.

Tschö, Auge

(11.06.2020, 08:40)mb schrieb:

Haas schrieb:Wird eigentlich überhaupt noch was für OTTD gemacht bzw. verbessert etc.?!

Nicht wirklich.

würde ich in dieser Allgemeinheit nicht unterschreiben. Ja, es hat schon aktivere Zeiten gegeben. Das liegt an vielen Gründen, hauptsächlich aber daran, daß kaum noch "Nachwuchs" a la "ich hab das früher als Kind gerne gespielt, ich will mitmachen" kommt. Das ist aber der natürliche Verlauf einer Nostalgiekurve.

Zitat:Die verbliebenen Entwickler arbeiten in erster Linie immer noch an ihrem Auftritt (github, compiler farm, website, download tool, ...).

was soll denn das für ein Vorwurf sein? Jeder der sich schonmal ernsthaft mit Entwicklung auseinandergesetzt hat, sollte wissen, daß 90% der Arbeit daraus besteht, das bisher erreichte am Laufen zu halten. Darunter zählt halt auch, einen in die Jahre gekommenen Server zu ersetzen, und neue Kollaborationsmodelle auszuprobieren.

Wenn das nicht passieren würde, würde das ganze Projekt heute so brach liegen wie die Coop-Devzone.

Zitat:Ansonsten bedienen sie sich bei Jonathans patchpack (JGRPP) in Bezug auf bug fixes und einige ausgewählte Erweiterungen.

Auch das ist eine unzulässige Formulierung, denn JGR arbeitet hier aktiv mit. So läuft das halt in einigermaßen gesunden Open-Source Projekten.

Auch hier gibt es ein Gegenbeispiel, wie es nicht laufen sollte: Cirdan's Alleinunterhaltungsshow "NewMapFeatures", der sich einer solchen kooperation verweigert hat.

Zitat:Ernsthafte Fehlerbeseitigung (abseits game crashs) findet mE nicht statt, obwohl es diesbzgl eine schier unendliche Liste gibt. Bzw gab, denn es war natürlich eleganter die alten Fehlermeldungen einfach zu löschen.

Ok, das sind jetzt schon Facebook-artig unfundierte AfD-Phrasen. Die gehören hier überhaupt nicht her.

Ich finde es auch eher schade, dass so große Ziele im Original-OpenTTD anscheinend nicht mehr vorhanden sind.

Das fängt bei so banalen Sachen wie Signale auf Brücken und Tunneln an, oder die Möglichkeit, Industrieschließungs-Nachrichten nur für angefahrene Industrien anzuzeigen und geht bis zum großen Thema modulare Flughäfen wie bei Simutrans....

[quote='Fuchsi' pid='92099' dateline='1593883510'..... Signale auf Brücken und Tunneln an...
[/quote]

JGRPP (JGR Patch Pack)

Auch wir haben nun über drei Jahre mit mehreren auf einen eigenen OpenTTD-Server bis einschließlich 10.2 gespielt.

Seit heute "lernen" wir die vorzüge vom Jgrpp (0.35.0), erst einmal ohne NewGrfs bis alle Mitspieler die Version aufgespielt haben. Aber bis jetzt ist die freude über den Wechsel zu jgrpp sehr groß.

was mir am meisten zusagt..
Sharing von Schienen, Depot, sogar Flughäfen und
Signale in Tunnel und auf Brücken.

Lg.
PS: und die Updates, wenn Fehler bekannt wurden, kommen fixer.

Hallo

(21.07.2020, 19:59)CheNeroX schrieb: Seit heute "lernen" wir die vorzüge vom Jgrpp (0.35.0), erst einmal ohne NewGrfs bis alle Mitspieler die Version aufgespielt haben. Aber bis jetzt ist die freude über den Wechsel zu jgrpp sehr groß.

Kompiliert ihr selbst oder benutzt ihr alle fertige Binaries? Ich selbst habe nämlich nach anfänglichen Schwierigkeiten JGRPP 0.35.0 unter Ubuntu 18.04 ohne Fehlermeldungen kompilieren können, kann das Kompilat aber nicht zum Programmstart bewegen.

(21.07.2020, 19:59)CheNeroX schrieb: PS: und die Updates, wenn Fehler bekannt wurden, kommen fixer.

Naja, das liegt einerseits daran, dass sich JGR echt gut um die bei ihm verfügbaren Patches kümmert und andererseits, dass er halt eine neue Version bereitstellt, sobald er das für richtig hält. Bei OpenTTD gibt es einmal im Jahr ein Major-Release und Minor-Releases, wenn sich genug Fixes angesammelt haben (wenn jetzt nicht gerade ein Showstopper das Spiel unbenutzbar macht). Das passiert relativ selten. Ich spiele selbst ausschließlich JGRPP (wegen der oben beschriebenen Probleme immer noch 0.34.4), weiß aber, dass es das Patchpack ohne das Basisspiel nicht gäbe. und soweit ich das beobachte, profitieren beide Stränge voneinander (was ich sehr angenehm finde).

Tschö, Auge

Wie immer bei Kompilierproblemen gilt: Probiere erstmal, das unmodifizierte Spiel zu kompilieren.

(22.07.2020, 08:28)Eddi schrieb: Wie immer bei Kompilierproblemen gilt: Probiere erstmal, das unmodifizierte Spiel zu kompilieren.

JGRPP, zumindest 0.34, habe ich für Linux als absoluter Laie ohne Probleme compilieren können. (Allerdings läuft das neuerdings mit "Cmake…", da habe ich es noch nicht wieder probiert.)
Beim Versuch die gleiche Version für WIN zu compilieren bin ich kläglich gescheitert, trotz ausführlichster Anleitung auf openttd.org.

Kann so oder so laufen

Vielleicht schaffen wir es ja, hier immer eine passende Win-Linux Kombi vorzuhalten (Linux für meinen Raspberry-Pi - Server, Win für den Laptop mit dem ich spiele)

Ich halte nichts von Patchpacks. Und was so spielerische Neuheiten bei OTTD betrifft, hab ich da schon länger nichts bahnbrechendes gesehen. Schade eigentlich.