.dass man dem Boden, der eine Stufe unter der Schneegrenze ist, via newgrf eine neue Grafik zuweist? Wenn ich ja diese Textur generell ersetze, werden ja gleich all diese Grafiken ersetzt, ich will aber nur die ersetzen, die unmittelbar unterhalb der Schneegrenze sind!
Ich hab noch nicht soviel Ahnung von newgrf, hab das Wiki mal ein bisschen überflogen, da hab ich zwar auch ne variable für die Schneegrenze gefunden, ich weiss nicht, ob das eventuell dafür zu gebrauchen ist, ich hatte eher das Gefühl, dass das nur für die flexible Schneegrenze ist (jahresrhytmus[/i]).

Also einfache Frage: geht das?

Zur verdeutlichung noch ein Bild:
   
die rotumkreisten flächen sind gemeint (natürlich in den verschiedenen Perspektiven), wenns mit der blau umkreisten Fläche auch noch möglich ist (die ja schliesslich zwei Stufen niedriger ist), wärs ganz toll

Addi schrieb:[.]Also einfache Frage: geht das?

Einfache Antwort: nein.

Gruß
Michael

Was stört dich denn an dem Übergang?

Schade, hab ich mir schon fast gedacht.

Mich stört vorallem, dass wie bei meinem Bild das unterste schneebedeckte Feld dieses zwar noch schneebedeckt ist, die danebenliegenden Felder, die zur hälfte ja noch auf selber höhe sind, aber schneefrei sind.
Und ich hätte generell gerne einen sanfteren Übergang gemacht, würde doch besser aussehen
Denn bei jedem teilschneebedecktem Feld ist ja eigentlich schon zu 100% definiert, welchen "schneebedeckungsgrad" die vier Felder daneben haben, so gesehen sollte es ja kein grosses Problem sein. Da das jetzt nicht geht müsste ich einfach einfach ein eine Stufe wegnehmen, dann bringt man zwar keinen soo sanften Übergang hin als anders, aber geht ja trotzdem.
(und die Anfrage zu Planquadrat stimmt dann halt bei dem einen Feld ohne Neigung nicht mehr.)

Also, ich verstehe immer weniger was du überhaupt willst.

Denn im Prinzip ist das was du anscheinend willst:

Addi schrieb:ich hätte generell gerne einen sanfteren Übergang gemacht, würde doch besser aussehen

ja bereits in TTD enthalten: statt nur einem "harten" Übergang (Schnee/nicht Schnee) hat TTD vier verschiedene Stufen der Schneebedeckung im Angebot.

Und bzgl deines anderen Wunsches:

Zitat:Mich stört vorallem, dass wie bei meinem Bild das unterste schneebedeckte Feld dieses zwar noch schneebedeckt ist, die danebenliegenden Felder, die zur hälfte ja noch auf selber höhe sind, aber schneefrei sind.

Lassen sich diese Felder bzgl ihrer Höhe - und also auch der Höhe der Schneegrenze - nicht unterscheiden, denn bei beiden liegt die nördliche Ecke auf der gleichen Höhe. Und nur die ist entscheidend.

Und wenn man noch eine zusätzliche (tiefere) Reihe von Schneefeldern einführen würde wäre das Problem für diese ja genauso!

Ich weiss nicht warum dir der jetzige Mechanismus missfällt:

   

Gruß
Michael

mb schrieb:ja bereits in TTD enthalten: statt nur einem "harten" Übergang (Schnee/nicht Schnee) hat TTD vier verschiedene Stufen der Schneebedeckung im Angebot.

Ja, aber wie du bereits selber gesagt hast, sind es vier Stufen. Ich hätte gerne eihen stufenlosen Übergang (siehe Bild Nummer 1)
Warum ich die darunterliegende Stufe auch noch schneebedecken wollte, sieht man in Bild 2.
   

mb schrieb:Lassen sich diese Felder bzgl ihrer Höhe - und also auch der Höhe der Schneegrenze - nicht unterscheiden, denn bei beiden liegt die nördliche Ecke auf der gleichen Höhe. Und nur die ist entscheidend.

Wenn die nördliche Ecke entscheidens ist, müsste das Feld in meinem Bild doch schneebedeckt sein, denn die liegen ja auf selber höhe, beim Schnee ist aber die unterste (nicht die südlichste) Ecke entscheidend.
Oder wie hast du das gemeint?


[edit] sehe grade, dass TTDPatch das anders handhabt als OpenTTD, da orientiert sich die Schneehöhe an der obersten (nicht nördlichsten) Ecke (es sei denn, das Feld erstrecket sich über zwei höhen, Wie das Feld bei meinem Bild 1)

Addi schrieb:[mb]> ja bereits in TTD enthalten: statt nur einem "harten" Übergang (Schnee/nicht Schnee) hat TTD vier verschiedene Stufen der Schneebedeckung im Angebot.

Ja, aber wie du bereits selber gesagt hast, sind es vier Stufen. Ich hätte gerne eihen stufenlosen Übergang (siehe Bild Nummer 1)

Jaaaa. Aber dein Vorschlag wäre ja lediglich eine tile-Reihe, während TTD den "stufenlosen" Übergang ja auf vier tile-Reihen verbreitert. Und die sind dynmisch (verändern sich über die Zeit) während dein Vorschlag statisch wäre.

Zudem wäre dein Vorschlag schwierig umzusetzen: du müsstest ja pro Tile verschiedene "Übergänge" anbieten, denn abhängig von (den Höhen) den Nachbartiles wäre dein Übergang ja verschieden. Und dass liesse sich gar nicht einbauen, denn TTD überprüft ja die Nachbartiles überhaupt nicht. Deshalb sind ja zB auch keine Geländeeinschnitte möglich. Jedes Tile wird lediglich anhand der Koordinaten seiner nördlichen Ecke ausgewählt und dargestellt.

Bei TTD sind übrigens (leider) nur die Landschaftstiles dynamisch, während man bei Gebäuden und Schienen den harten Übergang Schnee/ nicht Schnee anhand der Schneelinie sehr gut sehen kann. Andererseits müsste man sonst statt einem Schneesprite pro Gebäude vier verschiedene haben, d.h. das wäre doch ein ordentlicher Mehraufwand.

Gruß
Michael

Nein, mein Vorschlag würde natürlich auch alle Reihen ausnutzen! Es hat ja drei "Zwischenstufen", die erste Zwischenstufe wäre ein sanfter Übergang von Gras zu 1/3 schneebedekt, die zweite Zwischenstufe wäre ein sanfter Übergang von 1/3 zu 2/3 schneebedeckt und die dritte Zwischenstufe wäre ein sanfter Übergang von 2/3 schneebedeckt zum Schnee! Und warum wäre das statisch? Wenn ich das grf einfach so code, dass es heisst "grf #1 in blabla.grf ersetzt grf #xyz in trg1r.grf", dann müsste das doch mitgehen? Oder ist ein so simples grf etwa nicht möglich?
Die Idee, das Feld das unter der schneegrenze ist auch zu ersetzen, habe ich nach deinem Nein gleich wieder verworfen, das hätte nur einen noch sanfteren übergang ermöglicht.

Und nein, ich muss eben nicht pro Feld verschiedene Übergänge anbieten! Das ist ja das, was ich mit "bei jedem teilschneebedecktem Feld ist ja eigentlich schon zu 100% definiert . " gemeint habe!
Nennen wir z.b. die drei oben beschriebenen Übergänge mal Übergang 1 2 und 3. jedes teilschneebedeckte Feld hat an den vier Rändern je einen dieser Übergänge, sofern es nicht eben ist. Hat ein Feld an einer Seite z.B. Übergang 3, dann muss das angrenzende Feld an dieser Stelle auch Übergang 3 haben! Man müsste also nur dieses Feld an dieser stelle entsprechend zeichnen.

Addi schrieb:Nein, mein Vorschlag würde natürlich auch alle Reihen ausnutzen! Es hat ja drei "Zwischenstufen" [.]

Ah! Noch komplizierter .

Zitat:Wenn ich das grf einfach so code, dass es heisst "grf #1 in blabla.grf ersetzt grf #xyz in trg1r.grf", dann müsste das doch mitgehen? Oder ist ein so simples grf etwa nicht möglich?

Doch. Sehr leicht sogar (action0A).

Zitat:Hat ein Feld an einer Seite z.B. Übergang 3, dann muss das angrenzende Feld an dieser Stelle auch Übergang 3 haben! Man müsste also nur dieses Feld an dieser stelle entsprechend zeichnen.

Und das ist eben nicht möglich, da die Nachbarfelder nicht abgeprüft werden.

Gruß
Michael

Zitat:Ah! Noch komplizierter .

Nein, schöner!


Warum Nachbarfeld abpfüfen? Das ist doch gar nicht nötig! Ich hab extra für dich ein Bild mit lustigen bunten Linien als Erklärung gezeichnet:
   
weisse Linie = Gras
rote Linie = Übergang 1
violette Linie = 1/3 Schnee
blaue Linie = Übergang 2
grüne Linie = 2/3 Schnee
gelbe Linie = Übergang 3
schwarze Linie= Schnee

jetzt muss ich mir nur noch ein Feld herauspicken, wie zum Beispiel Feld 1, und ich weiss genau, wie die angrenzenden Felder an dieser Stelle aussehen werden und man muss es nur noch entsprechend zeichnen. Probleme kann es einzig beim Feld 2 geben, da eine Seite da sowohl Übergang 1 als auch Gras bedeuten kann, aber durch etwas geschicktes Zeichnen kann man das sicher vertuschen, da der Übergang 1 ja sowieso ziemlich "grasig" ist.
Aber das ist nur der Fall, wenn da gerade ein Grasfeld angrenzt, dass sich über 3 Höhenlagen erstreckt, wie grad in dem Beispiel, beim Schnee kann dieses Problem nicht auftauchen!

Sooo, hab jetzt mal das grf erstellt

Download gibts auf meiner Seite: http://www.ttdx.250x.com/grf.htm

Screenshot:
   

(klappt doch, mb )

Gut gelungen!

Hab ne neue Version gemacht, die ein paar bugs fixt und für OpenTTD wird nicht mehr ne extra Version benötigt.

schöne Arbeit!

Addi, hast fein jemacht.

Moin Addi,

kommt da auch noch eine Version für das gemäßigte Klima raus? Da sieht der Schnee ja immernoch so hässlich aus.

Ja, hab ich auch noch vor.

Allerdings hab ich noch ne kleine Frage zu Action7:
mit der Variable 9D kann man ja TTDPatch oder OpenTTD angeben, aber warum müssen das laut Wiki vier Bytes sein? Der Wert kann ja nur 0 oder 1 betragen, da würde ein Byte doch locker ausreichen! hat das irgendeinen Grund?

Und noch was: Momentan steht bei mir die Zeile
das funzt zwar auch wunderbar, aber müsste man nicht eigentlich 01 00 00 00 anstatt 00 00 00 01 schreiben? Ich bin mir da jetzt unsicher, da es zwar geht, meiner Meinung nach aber falsch ist.

[edit] und noch ne Frage: muss in der allerersten Zeile, wo steht wie viele Zeilen die grf hat, die Zeile null mitgerechnet werden?

Du gibst doch die 4 Bytes vor. 9D 04 (<variable> <varsize> [amount of bytes to compare])

Geht das auch wenn Du die Zeile so schreibst:

60 * 5 07 9D 01 01 06

2. Frage (eine Vermutung.)
Warum 00 00 00 01? Weil dort nicht EIN Wert übergeben wird, der müsste in Little Endian gewandelt werden, sonder weil Parameter bzw. 4 Einzelwerte übergeben werden?

Addi schrieb:müsste man nicht eigentlich 01 00 00 00 anstatt 00 00 00 01 schreiben?

http://wiki.ttdpatch.net/tiki-index.php?page=Action7 schrieb:9D D TTD Platform, 0=TTDPatch, 1=OpenTTD

Es wird ein double word als Parameter erwartet ("D") und der Wert "0" steht für TTDPatch. Vermutlich wird nicht "1" als OTTD gewertet sondern ganz einfach "!=0" und sowohl "01 00 00 00" als auch "00 00 00 01" sind != 0.

Gruß
Michael

aber in der Wiki steht als Wert für Var07/09 Byte, nicht DWord *grübel*