Neuerungen, Pakentwicklung?

[Paco_m]

Andererseits wird auf Diagonalstrecken pro Streckenlänge mehr Raum verbraucht.
Bin mir gar nicht sicher, wo da spielerisch der Schwerpunkt liegt, oder geht es hier nur um ein optisches Problem ?

Optisch und wenn ich das richtig in Erinnerung habe auch vom Balancing her weil die Diagonalstrecken im pak.german aufgrund der größeren Länge mehr Gewinn einbringen (zählen wie 2 normale Kacheln)

[partyschreck]

Mehr Gewinn müssen sie ja bringen, schließlich ist der Weg kürzer.
Wenn es unverhältnismäßig zu viel Gewinn ist, sollte man es ändern.
Wenn die Züge nur etwas schneller sind, halte ich es für einen adäquaten Ausgleich für den Raumnachteil.
Was mich am Spiel eher aufregt, sind die Probleme diagonaler Verbindungsstrassen zwischen den Städten.
Es gibt fast nichts, was mich derart aufregt, wie hier ständig aufpassen zu müssen, dass man da Haltestellen bauen kann, wenn die Stadt sich den Raum erobert. Im Grunde ist es sinnvoll die sofort abzureißen und durch Schachbrettmuster zu ersetzen.

Diagonales Bauen ist in Simutrans grundsätzlich stark benachteiligt (Steigungen, Städte, Raum). Ich würde auf jeden Fall aufpassen, eine Schachbrettbauweise nicht noch stärker zu begünstigen. Etwas höhere Gewinne können hier durchaus auch akzeptabel sein.

[prissi]

Eine diagonale Strecke braucht genauso viele Kacheln wie eine gerade mit rechtwinkliger Kurve: Probiere es aus. Nur sind mit dem jetzigen pak64.german die Zuege auf der Diagonalen deutlich schneller.

[partyschreck]

Ist mir schon klar, dass es genausoviele Kacheln sind.
Ist aber trotzdem so, dass im Spiel viel Raum verloren geht, vor allem durch den Wechsel zwischen den Abschnitten.
Wenn man im Stadtbereich Gleise verlegt, merkt man das deutlich.
Ich merke beim Spielen mit pak64german oft, wie ich da hin- und hergerissen bin zwischen verschiedenen Bauweisen.

[Wurzelgnom]

Das ist eine Frage der Geschwindigkeit. OpenTTD hat heute noch eine falsche Geschwindigkeit in der Diagonale. Daher sind dort die Zuege viel schneller und muessen so laenger erscheinen. Sollen die Zuege gleich schnell sein (so wie in den meisten Simutrans paks), damit ZUege auf gleicher Streckenlaenge gleich lange brauchen (gleiche Anzahl Kurven und Steigungen vorausgesetzt), dann muss man als Diagonalenlaenge Wurzel2 der Laenge in OpenTTD nehmen (oder der jetzigen aus pak64.german) Daher habe ich die Diagonalen der Fahrzeuge gekuerzt.

Da ist mit 100.0 dazugekommen, wenn ich mich nicht irre.

Klar erst machst Du die langen Ansichten und nach der Umstellung des Sets auf die langen Ansichten kürzt Du die wieder ein. Gab ja keine klare Aussage was wann wie wo gemacht wird.

Meine Ansicht dazu, unnütze Arbeit die man bei richtiger Planung vermeiden hätte können.

Aber Simutrans und Planung ist utopisches Wunschdenken. Und Setverwalter haben schlicht gar kein Mitspracherecht. Die Programmierer machen was sie wollen ohne Rücksicht auf die Setentwicklung.

Und heulen danach noch rum das die Sets vieles nicht nutzen. Warum nutzen sies nicht, weil sie sich ja nie sicher sein können, das es grundlegend geändert oder gar wieder entfernt wird. Beispiele sind dafür eben die Fahrzeuglängen und auch die Gebäude mit freien Feldern. pak64.german hat beides genutzt und ist mächtig auf die Nase gefallen. Genau so alle Klimazonen auf jeder Ebene, macht die grafische Abstimmung der Höhenlagen ( pak64.german, pak128.german ) praktisch zu Nichte.

Ach ja, variables Startkapital ( seit 102.2.2 ). Könnte sein das das auch vom pak64.german als einzigem Set genutzt wird.

Frag mich wie es zBsp gehen soll, das ein großflächiges Objekt für Flachland nun im Bergland gebaut werden soll. Oder eben nicht, weil eben kein Bauplatz gefunden wird. Klar pak64 verwendet Industrien mit max 4 Feldern. Andere Sets haben aber Industrien mit bis zu 20 Feldern oder mehr drin.

Nur weil etwas machbar ist/erscheint muss es nicht sinnvoll sein.

Und andere Projekte führen nicht umsonst verschiedene Entwicklungszweige bis zu einem bestimmten Reifegrad, bevor es in den Release-Zweig übernommen wird. Darüber sollte man mal reden, größere Sachen in eigenen Codezweigen reifen zu lassen, statt alles zusammen zu mischen nach der Mentalität "friss oder stirb" ( Entwickler Grafiksets wie Spielerseite ). Aber die Programmierer haben ja immer Recht, da sie am längeren Hebel sitzen ( was sie auch ausnutzen ).

[Valdore]

Also ich persönlich wäre auch dafür,dass nicht so viel neus programmiert wird,was sinnlos ist.sinnvoller wäre z.B. eine Abtrennung von Stromzufuhr varianten.Mit dieser könnte man dann alle Narrowgauge-Fahrzeuge des pak.german in das Eisenbahnmenü in einem neuem Unterfenster
( Passagierzüge ; Loks ; Elektrotraktion ; Metro/S-U-Bahn ; Waggons ) unterbringen.
einen solchen Parameter habe ich auch schon eperimentell in meine pak192.comic-Stromschienen eingebracht.

Code:

#####Vielen Dank an Flemmbrav,der mir die Sourcen dafür gegeben hat :)####
#####Vielen Dank an Flemmbrav und PTM,die die Grafik und die Dat erstellt haben####

obj=way-object
waytype=track
own_waytype=electrified_track
name=Stromschiene 1902
copyright=Flemmbrav & PappeTeeMaster
intro_year=1902
cost=1000
maintenance=195
topspeed=50
icon=> track/Track_Stromschiene_1902.3.0
cursor=track/Track_Stromschiene_1902.3.1


#electric_system_type=third_rail


BackImage[EW]=track/Track_Stromschiene_1902.0.0
BackImage[E]=track/Track_Stromschiene_1902.0.1

...