Welches programm ???

[croatia]

Hallo,

hab bisher immer SCC für den FS2002 und EOD für meine Scenerys für den FS04 benutzt und wollte fragen ob es da was neues für den SCC gibt??
EOD gefällt mir Super halt nur der SCC macht mir zu schaffen weil er ja für den FS02 ist.

hier das Project http://www.geocities.com/projectflightsimbosna/main.htm

Danke!!!

[Fleischmann]

Hallo croatia,

also ich bin noch ziemlich neu in Bereich Scenerie erstellen.
Ich benutzete EOD für Fs2002 und wollte mich dann auch FS Desgin Studio stürzen.

Ich denke das Du mit SCC - Schiratti Control Center irgendwann mit FS2004 Probleme bekommen wirst. Bei EOD ist es genauso, es macht bei normalen Grafikfarben schon Schwierigkeiten.

Ist jedenfalls bei mir so, dass mein Arbeitskollege nur weiße Texturfelder sieht, während sie bei mir bunt sind.

Thorsten

[TiAr]

Hallo Zusammen,

EOD und SCC kann man auch im FS2004 nutzen, da gibt es eigentlich kein Problem, da der FS9 auch mit SCASM kompilierte Szenerien darstellen kann. Ihr könnt also auch EOD oder SCC nutzen.

Aber: dieser Code ist nicht sehr frameratefreundlich und vor allem bei detaillierteren Objekten nicht mehr so sehr enpfehlenswert. Hier ist XML die bessere Wahl. Zumal es berechtigterweise Gerüchte gibt, dass der SCASM-Code nicht mehr wie gewohnt im FS10 nutzbar sein wird.

Also, um detaillierte Objekte zu erstellen ist FSDS2 oder Gmax die bessere Wahl. Vor allem Gmax nutzt hier den XML-Code schon sehr gut.

Um diese Objekte in eine Szenerie einzufügen, sollte man auch "umdenken". Das XML basierende SceneGenX (noch in der offenen Beta) ist der Nachfolger vom SCASM-nutzenden Airport for Windows. Informationen dafür gibt es auf www.airportforwindows.com

Gruß
Thomas

[JOBIA]

Wobei man zu SCASM gerechterweise sagen muss das SCASM immer erweitert worden ist. Mittlerweile unterstützt SCASM z.B die neue LWM3 und VTP2 Technik komplett.

Man muß ja folgendes bedenken XML ist ja auch nur Befehlscode wie SCA Code auch. Nur das SCASM ein eigener Kompiler ist und BGLCOMP.EXE der offizielle für XML.
Hingegen für VTP2 und LWM der offizielle Kompiler die BGLC.EXE ist.

Man benötigt also zwei SDK Kompiler.


Diesen umgeht SCASM schon jetzt es kann Objektcode (klar alter Code) aber auch neuen LWM und VTP Code.

Letztendlich kommt hinterher ein Bytecode bei raus, der momentan allerdings im BGLCOMP SDK nicht mehr dokumentiert ist. Ich denke es wäre für Manfred Moldenhauer kein Problem sein SCASM jederzeit so zu erweitern das er das auch kann.
Er wäre dann wie früher die eierlegende Wollmilchsau unter den Kompilern.

Fraglich ist allerdings in der Tat wie die Zukunft aussieht denn früher wurde in den SDKs immer der Bytecode dokumentiert jetzt nicht mehr. Von daher denke ich könnte es schon passieren das keiner mehr SCASM nutzt da die meisten Designtools den Weg über die offiziellen SDK Kompiler gehen.

Aber wie gesagt auch SBuilder (aktuelles Programm) nutzt Scasm und nicht BGLC.EXE von daher muss man abwarten wie sich das entwickelt.

[TiAr]

Hallo Joachin und alle Anderen,

keine Frage - SCASM ist auch heute noch prima - ich selber nutze ja noch die unterschiedlichen Kompiler- einschließlich SCASM. Nur für sehr detailliertere Objekte geht es in XML halt framerateschonender, ohne in den Code stark eingreifen zu müssen (was die wenigsten von uns Designern können). Das was Manfred Moldenhauer für uns geschaffen hat ist natürlich genial. Ich wollte das mit keinem Wort schmälern.

Ich selber bin sehr unglücklich über die momentane Entwicklung. Ich spreche hier als Szenerie-Entwickler ohne Programmierkenntnisse. Früher benötigte ich zum Erstellen von Szenerien (ohne Bildbearbeitung) genau drei Programme. Heute benötige ich mindestens 6 Programme, nur um einen einzelnen Baum mit Gmax (drehbar, mit Jahreszeiten, ohne Schatten) zu erstellen.

Die Folge ist doch klar - man sieht es an der Anzahl der Szenerien mit neuer Technik, die z.Zt. veröffentlicht werden. Es sind sehr wenige. Und viele Designer aus dem Freeware-Bereich haben mittlerweile hingeschmissen. Und der Rest fragt sich immer noch - wohin geht eigentlich die Reise?

Gruß
Thomas

[r_schon]

Hallo Thomas,

Da muß ich Dir wirklich recht geben. Die Verunsicherung ist groß.

Wahrscheinlich auch bei den Tool Entwicklern - denn ich habe lange Zeit nichts mehr Neues bei den Standard Tools gesehen, vor allem bei SCC, der im Szeneriedesign ja das Maß der Dinge ist.

Dazu kommt, daß die Meßlatte in jeder Hinsicht für Szenerien sehr hoch liegt.
Alles was man da oben drauf packt wird von den Tools nicht unterstützt und ist entsprechend mühselig.

Hoffen wir mal, daß die Tool Entwickler schnell sind, sobald die Richtiung klar ist. Ich finde auch, es reicht schon, wenn wir uns bezüglich Texturen und Objekte einen abbrechen, da brauch ich nicht noch ein mühseliges Programmieren direkt im Code oder indem ich x Progrämmchen daneben laufen habe.

Gruß
Rolf

[JOBIA]

Zu

"Nur für sehr detailliertere Objekte geht es in XML halt framerateschonender, ohne in den Code stark eingreifen zu müssen "

Das ist ja das was ich bei SCASM damit ausdrücken wollte. Es wäre vermutlich kein Problem das man SCASM dazu aufbohrt genauso framerate schonenenden Code zu produzieren. So wäre SCASM wieder das Maß der Dinge was alles kann bei guter Performance.

Ich kenne FSDesignstudio2 nicht, da ich mich weniger mit Objektdesign beschäftige (da dementsprechend auch weniger mitreden kann) aber der Byte Code (kann man ja am Header sehen ob es mit FSDS2 gemacht wurde) der hier hinten rauskommt sieht mir genauso aus wie Code den man über GMAX programmiert hat. Also auch hier performanceschonend. Warum sollte das also nicht über SCASM gehen wenn es ein Designtool gäbe welches so einen ev. noch kommenden neunen SCASM Code ausspuckt.

Schau Dir mal AFCAD2 an das beste Beispiel hierfür. Da geht es jetzt zwar weniger um Objektcode aber als Beispiel ist es geeignet. In AFCAD2 wird alles ohne BGLCOMP.EXE Kompiler umgesetzt es kommt aber hinterher der selbe BGL Code bei Runways usw. raus wie wenn man in XML definiernen und über BGLCOMP.EXE kompilieren würde.

(Offensichtlich sogar korrekter als der BGL Code über XML und BGLCOMP siehe CTD Problematik Stefan Rausch Austrian Airports der Patch)

Es geht also ohne Probleme. Mit dem SDK kann man ja auch den Byte Code der BGL konstruieren von daher muss man nicht unbedingt solche SDKs wie früher haben. Nur es ist halt jetzt etwas aufwendiger geworden. (ev. steckt da Absicht hinter)

Die Frage ist halt ob sich ein Mann wie Manfred Moldenhauer sagt muss ich das umsetzen wenn es bereits einen Kompiler gibt. Klar es wäre komfortabel da ein Designtool alles mit einem Kompiler SCASM erledigen könnte.

Nur wenn die aktuellen Tools in einigen Bereichen schon andere Kompiler nutzen, muss man dann noch Zeit für eine Aufbohrung des eigenen Kompilers verschwenden wenn ev. gar kein Designertool dahinter steht welches so einen kompletten SCASM Code nutzen würde.

Das ist jetzt genau das Problem was Rolf ansprach. Die letzte große Änderung beim SCC war das er VTP2 Code des FS2002 beherschte und als SCASM Code ausspuckte. SCASM selbst konnte schon LWM2. Im SCC wurde das nicht umgesetzt da es Äußerungen gab das es beim FS2004 etwas neues geben könnte.

Seitdem habe ich nie wieder was von SCC gehört.

Vermutlich weil AFCAD2 die wesentlichen Standard FS2004 Airportbodentechniken komfortabel erledigt. Die älteren will ja offensichtlich keiner mehr.

[Fritzbecker]

Hallo,

es scheint aber, daß sich Hr. Moldenhauer mit einer neueren Version befasst

Zitatauszug seiner Homepage www.scasm.de :


Aug/31/04 + June/13/04: I just uploaded an early SCASM beta version with some of the new FS2004 commands implemented. This version is far away from being complete and may have a lot of bugs. Also the format of some instructions may be changed in later versions. I see this version as a base for discussions.

Gruß

Fritz