http://wiki.omnibussimulator.de/omsiwikineu.de/api.php?action=feedcontributions&feedformat=atom&user=Janniboy 2026-06-02T17:53:21Z Benutzerbeiträge MediaWiki 1.31.0 http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=OMSI_Addon_Tester_(OAT)&diff=708 2012-09-10T14:36:15Z

<p>Janniboy: </p> <hr /> <div>== Gründung und Zielsetzung ==<br /> <br /> Die OMSI Addon Tester - kurz &quot;OAT&quot; - sind ein Zusammenschluss von Mitgliedern aus dem offiziellen OMSI-Forum.<br /> Gegründet wurde die OAT am 30. April 2011 durch die OMSI-Forenmitglieder Yufa, dem Leiter der OAT, Felix01 und Janniboy, die tatkräftig das [http://www.oat-online.de/forum/index.php Forum] und die [http://www.oat-online.de/ Website] der OAT warten und instandhalten ([http://omnibussimulator.forumieren.com/t4415-prufung-neuer-maps Link zum Gründungsthread im Forum]).<br /> <br /> Die OAT hat es sich zum Ziel gesetzt, kostenlose OMSI-Addons von Privatpersonen sachlich und objektiv zu bewerten.<br /> Damit soll einerseits interessierten Benutzern bereits vor dem Download ein allgemeiner in das Addon gegeben werden; andererseits soll so dazu beigetragen werden, dass sich die Qualität von OMSI-Addons mit der Zeit steigert.<br /> <br /> All das fasst die OAT in einem Statement-Satz zusammen:<br /> ''&quot;Wir möchten die Autoren aktiv dabei unterstützen, ihre Addons zu perfektionieren.&quot;''<br /> <br /> Alle Mitarbeiter der OAT arbeiten ehrenamtlich, jeder kann sich bewerben. Die derzeitigen Addon-Tester sind weiter unten gelistet. Welche Kriterien ein Addon-Tester erfüllen sollte und was von ihm erwartet wird, kann [http://oat-online.de/info_bewerben.php hier] nachgelesen werden.<br /> <br /> <br /> == Weitere Geschichte ==<br /> <br /> Nachdem die OAT einige Monate nach der Gründung ihre Dynamik und Geschwindigkeit bei der Abarbeitung der Testberichte verlor und sich die Zahl der nicht getesteten Addons drastisch erhöhte, berief man im Februar 2012 den User pBuch im neuen Posten als &quot;Manager für Testberichte&quot;, welcher die bisherigen Grundsätze der OAT grundlegend reformierte und somit ein völlig neues internes System zur besseren Kommunikation und Interaktion zwischen den Testern schuf. Damit war und ist er immer noch eine wichtige Stütze der OAT-Testersparte und testet selbst neben Verwaltungsaufgaben aktiv Addons.<br /> <br /> Am 30. April 2012 konnte die OAT mit neuer Motivation und aktiven Testern ihr einjähriges Bestehen als seriöse Testervereinigung feiern. Sie testet auch mehrere Monate nach ihrem ersten Geburtstag mit hoher Effektivität und Geschwindigkeit und großer Motivation die Addons von Privatentwicklern.<br /> <br /> <br /> == Testverfahren und Bewertung ==<br /> <br /> Interessierte Addon-Entwickler können ihr Addon direkt über das [http://oat-online.de/einsenden.php Online-Formular] einsenden.<br /> <br /> [[Datei:OATIconExplanation.jpg‎|300px|thumb|right|Das OAT-Testsiegel]]Die OAT veröffentlicht den jeweiligen Testbericht nach der Testphase auf der offiziellen Website [http://www.oat-online.de www.oat-online.de]. Daraus gehen zum Einen die Einzelwertungen, zum anderen die wichtigsten Punkte (Positiv- und Negativlisten) sowie die Gesamtpunktzahl des Addons hervor. Bei allen Tests soll größtmögliche Transparenz walten. Daher wurden auf der Website außerdem Leitfäden und Empfehlungen veröffentlicht. Nach der Meinung der OAT sind die dort genannten Kriterien elementar für das &quot;in den Grundsätzen perfekte Addon&quot;, und sie sind zugleich auch die Bewertungsmaßstäbe für die Testphasen.<br /> <br /> Die maximal erreichbare Punktzahl beträgt für alle Einsendungen 100 Punkte. Je nach Art des Addons werden die Kriterien verschieden gewählt und teilweise auch gewichtet, um den vielfältigen Anforderungen gerecht zu werden. Die erreichte Punktzahl wird im OAT-Testsiegel (siehe Beispielbild) dargestellt. Mit diesem Siegel kann der Entwickler des Addons überall für sein Addon &quot;werben&quot; und somit zeigen, dass er sich um Qualität bemüht.<br /> <br /> <br /> == Verwaltungsteam und Tester ==<br /> <br /> * Yufa - ''Leitung der OAT''<br /> * Felix - ''Forenadministration, Webhosting''<br /> * Janniboy - ''Gestaltung, Programmierung, Betreuung der Website (Webmaster)''<br /> * pBuch - ''Manager für Testberichte''<br /> <br /> <br /> Über eineinhalb Jahre haben sich auch die Gesichter der Addon-Testersparte verändert. Die derzeitigen Tester sind:<br /> <br /> * Dario<br /> * LH458<br /> * Sascha<br /> * Stefan_112<br /> * VDL<br /> <br /> <br /> == Weitere Dienstleistungen ==<br /> <br /> === OAT-Chat (wiedereröffnet) ===<br /> <br /> Nach einiger Zeit der Abschaltung aufgrund erhöhter Serverauslastung bietet die OAT unter der URL [http://www.oat-online.de/forum/chat/ oat-online.de/forum/chat/] nun wieder einen Chat für Mitglieder der OMSI-Community an.<br /> <br /> === OAT-Forum ===<br /> <br /> Die OAT stellt ein Forum bereit, wo über Testberichte und über die OAT diskutiert werden kann. Es ist unter [http://oat-online.de/forum/ www.oat-online.de/forum/] zu finden.<br /> <br /> == Weblinks ==<br /> <br /> * [http://www.oat-online.de www.oat-online.de]<br /> <br /> [[Kategorie:Anschlussprojekte]]<br /> <br /> [[en:OMSI Addon Testers (OAT)]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=OMSI_Addon_Tester_(OAT)&diff=707 2012-09-10T14:35:53Z

<p>Janniboy: /* Verwaltungsteam und Tester */</p> <hr /> <div>== Gründung und Zielsetzung ==<br /> <br /> Die OMSI Addon Tester - kurz &quot;OAT&quot; - sind ein Zusammenschluss von Mitgliedern aus dem offiziellen OMSI-Forum.<br /> Gegründet wurde die OAT am 30. April 2011 durch die OMSI-Forenmitglieder Yufa, dem Leiter der OAT, Felix01 und Janniboy, die tatkräftig das [http://www.oat-online.de/forum/index.php Forum] und die [http://www.oat-online.de/ Website] der OAT warten und instandhalten ([http://omnibussimulator.forumieren.com/t4415-prufung-neuer-maps Link zum Gründungsthread im Forum]).<br /> <br /> Die OAT hat es sich zum Ziel gesetzt, kostenlose OMSI-Addons von Privatpersonen sachlich und objektiv zu bewerten.<br /> Damit soll einerseits interessierten Benutzern bereits vor dem Download ein allgemeiner in das Addon gegeben werden; andererseits soll so dazu beigetragen werden, dass sich die Qualität von OMSI-Addons mit der Zeit steigert.<br /> <br /> All das fasst die OAT in einem Statement-Satz zusammen:<br /> ''&quot;Wir möchten die Autoren aktiv dabei unterstützen, ihre Addons zu perfektionieren.&quot;''<br /> <br /> Alle Mitarbeiter der OAT arbeiten ehrenamtlich, jeder kann sich bewerben. Die derzeitigen Addon-Tester sind weiter unten gelistet. Welche Kriterien ein Addon-Tester erfüllen sollte und was von ihm erwartet wird, kann [http://oat-online.de/info_bewerben.php hier] nachgelesen werden.<br /> <br /> <br /> == Weitere Geschichte ==<br /> <br /> Nachdem die OAT einige Monate nach der Gründung ihre Dynamik und Geschwindigkeit bei der Abarbeitung der Testberichte verlor und sich die Zahl der nicht getesteten Addons drastisch erhöhte, berief man im Februar 2012 den User pBuch im neuen Posten als &quot;Manager für Testberichte&quot;, welcher die bisherigen Grundsätze der OAT grundlegend reformierte und somit ein völlig neues internes System zur besseren Kommunikation und Interaktion zwischen den Testern schuf. Damit war und ist er immer noch eine wichtige Stütze der OAT-Testersparte und testet selbst neben Verwaltungsaufgaben aktiv Addons.<br /> <br /> Am 30. April 2012 konnte die OAT mit neuer Motivation und aktiven Testern ihr einjähriges Bestehen als seriöse Testervereinigung feiern. Sie testet auch mehrere Monate nach ihrem ersten Geburtstag mit hoher Effektivität und Geschwindigkeit und großer Motivation die Addons von Privatentwicklern.<br /> <br /> <br /> == Testverfahren und Bewertung ==<br /> <br /> Interessierte Addon-Entwickler können ihr Addon direkt über das [http://oat-online.de/einsenden.php Online-Formular] einsenden.<br /> <br /> [[Datei:OATIconExplanation.jpg‎|300px|thumb|right|Das OAT-Testsiegel]]Die OAT veröffentlicht den jeweiligen Testbericht nach der Testphase auf der offiziellen Website [http://www.oat-online.de www.oat-online.de]. Daraus gehen zum Einen die Einzelwertungen, zum anderen die wichtigsten Punkte (Positiv- und Negativlisten) sowie die Gesamtpunktzahl des Addons hervor. Bei allen Tests soll größtmögliche Transparenz walten. Daher wurden auf der Website außerdem Leitfäden und Empfehlungen veröffentlicht. Nach der Meinung der OAT sind die dort genannten Kriterien elementar für das &quot;in den Grundsätzen perfekte Addon&quot;, und sie sind zugleich auch die Bewertungsmaßstäbe für die Testphasen.<br /> <br /> Die maximal erreichbare Punktzahl beträgt für alle Einsendungen 100 Punkte. Je nach Art des Addons werden die Kriterien verschieden gewählt und teilweise auch gewichtet, um den vielfältigen Anforderungen gerecht zu werden. Die erreichte Punktzahl wird im OAT-Testsiegel (siehe Beispielbild) dargestellt. Mit diesem Siegel kann der Entwickler des Addons überall für sein Addon &quot;werben&quot; und somit zeigen, dass er sich um Qualität bemüht.<br /> <br /> <br /> == Verwaltungsteam und Tester ==<br /> <br /> * Yufa - ''Leitung der OAT''<br /> * Felix - ''Forenadministration, Webhosting''<br /> * Janniboy - ''Gestaltung, Programmierung, Betreuung der Website (Webmaster)''<br /> * pBuch - ''Manager für Testberichte''<br /> <br /> <br /> Über eineinhalb Jahre haben sich auch die Gesichter der Addon-Testersparte verändert. Die derzeitigen Tester sind:<br /> <br /> * Dario<br /> * LH458<br /> * Sascha<br /> * Stefan_112<br /> * VDL<br /> <br /> == Weitere Dienstleistungen ==<br /> <br /> === OAT-Chat (wiedereröffnet) ===<br /> <br /> Nach einiger Zeit der Abschaltung aufgrund erhöhter Serverauslastung bietet die OAT unter der URL [http://www.oat-online.de/forum/chat/ oat-online.de/forum/chat/] nun wieder einen Chat für Mitglieder der OMSI-Community an.<br /> <br /> === OAT-Forum ===<br /> <br /> Die OAT stellt ein Forum bereit, wo über Testberichte und über die OAT diskutiert werden kann. Es ist unter [http://oat-online.de/forum/ www.oat-online.de/forum/] zu finden.<br /> <br /> == Weblinks ==<br /> <br /> * [http://www.oat-online.de www.oat-online.de]<br /> <br /> [[Kategorie:Anschlussprojekte]]<br /> <br /> [[en:OMSI Addon Testers (OAT)]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=OMSI_Addon_Tester_(OAT)&diff=706 2012-09-10T14:35:43Z

<p>Janniboy: Absatz-/Formatkorrektur</p> <hr /> <div>== Gründung und Zielsetzung ==<br /> <br /> Die OMSI Addon Tester - kurz &quot;OAT&quot; - sind ein Zusammenschluss von Mitgliedern aus dem offiziellen OMSI-Forum.<br /> Gegründet wurde die OAT am 30. April 2011 durch die OMSI-Forenmitglieder Yufa, dem Leiter der OAT, Felix01 und Janniboy, die tatkräftig das [http://www.oat-online.de/forum/index.php Forum] und die [http://www.oat-online.de/ Website] der OAT warten und instandhalten ([http://omnibussimulator.forumieren.com/t4415-prufung-neuer-maps Link zum Gründungsthread im Forum]).<br /> <br /> Die OAT hat es sich zum Ziel gesetzt, kostenlose OMSI-Addons von Privatpersonen sachlich und objektiv zu bewerten.<br /> Damit soll einerseits interessierten Benutzern bereits vor dem Download ein allgemeiner in das Addon gegeben werden; andererseits soll so dazu beigetragen werden, dass sich die Qualität von OMSI-Addons mit der Zeit steigert.<br /> <br /> All das fasst die OAT in einem Statement-Satz zusammen:<br /> ''&quot;Wir möchten die Autoren aktiv dabei unterstützen, ihre Addons zu perfektionieren.&quot;''<br /> <br /> Alle Mitarbeiter der OAT arbeiten ehrenamtlich, jeder kann sich bewerben. Die derzeitigen Addon-Tester sind weiter unten gelistet. Welche Kriterien ein Addon-Tester erfüllen sollte und was von ihm erwartet wird, kann [http://oat-online.de/info_bewerben.php hier] nachgelesen werden.<br /> <br /> <br /> == Weitere Geschichte ==<br /> <br /> Nachdem die OAT einige Monate nach der Gründung ihre Dynamik und Geschwindigkeit bei der Abarbeitung der Testberichte verlor und sich die Zahl der nicht getesteten Addons drastisch erhöhte, berief man im Februar 2012 den User pBuch im neuen Posten als &quot;Manager für Testberichte&quot;, welcher die bisherigen Grundsätze der OAT grundlegend reformierte und somit ein völlig neues internes System zur besseren Kommunikation und Interaktion zwischen den Testern schuf. Damit war und ist er immer noch eine wichtige Stütze der OAT-Testersparte und testet selbst neben Verwaltungsaufgaben aktiv Addons.<br /> <br /> Am 30. April 2012 konnte die OAT mit neuer Motivation und aktiven Testern ihr einjähriges Bestehen als seriöse Testervereinigung feiern. Sie testet auch mehrere Monate nach ihrem ersten Geburtstag mit hoher Effektivität und Geschwindigkeit und großer Motivation die Addons von Privatentwicklern.<br /> <br /> <br /> == Testverfahren und Bewertung ==<br /> <br /> Interessierte Addon-Entwickler können ihr Addon direkt über das [http://oat-online.de/einsenden.php Online-Formular] einsenden.<br /> <br /> [[Datei:OATIconExplanation.jpg‎|300px|thumb|right|Das OAT-Testsiegel]]Die OAT veröffentlicht den jeweiligen Testbericht nach der Testphase auf der offiziellen Website [http://www.oat-online.de www.oat-online.de]. Daraus gehen zum Einen die Einzelwertungen, zum anderen die wichtigsten Punkte (Positiv- und Negativlisten) sowie die Gesamtpunktzahl des Addons hervor. Bei allen Tests soll größtmögliche Transparenz walten. Daher wurden auf der Website außerdem Leitfäden und Empfehlungen veröffentlicht. Nach der Meinung der OAT sind die dort genannten Kriterien elementar für das &quot;in den Grundsätzen perfekte Addon&quot;, und sie sind zugleich auch die Bewertungsmaßstäbe für die Testphasen.<br /> <br /> Die maximal erreichbare Punktzahl beträgt für alle Einsendungen 100 Punkte. Je nach Art des Addons werden die Kriterien verschieden gewählt und teilweise auch gewichtet, um den vielfältigen Anforderungen gerecht zu werden. Die erreichte Punktzahl wird im OAT-Testsiegel (siehe Beispielbild) dargestellt. Mit diesem Siegel kann der Entwickler des Addons überall für sein Addon &quot;werben&quot; und somit zeigen, dass er sich um Qualität bemüht.<br /> <br /> <br /> == Verwaltungsteam und Tester ==<br /> <br /> * Yufa - ''Leitung der OAT''<br /> * Felix - ''Forenadministration, Webhosting''<br /> * Janniboy - ''Gestaltung, Programmierung, Betreuung der Website (Webmaster)''<br /> * pBuch - ''Manager für Testberichte<br /> ''<br /> <br /> Über eineinhalb Jahre haben sich auch die Gesichter der Addon-Testersparte verändert. Die derzeitigen Tester sind:<br /> <br /> * Dario<br /> * LH458<br /> * Sascha<br /> * Stefan_112<br /> * VDL<br /> <br /> == Weitere Dienstleistungen ==<br /> <br /> === OAT-Chat (wiedereröffnet) ===<br /> <br /> Nach einiger Zeit der Abschaltung aufgrund erhöhter Serverauslastung bietet die OAT unter der URL [http://www.oat-online.de/forum/chat/ oat-online.de/forum/chat/] nun wieder einen Chat für Mitglieder der OMSI-Community an.<br /> <br /> === OAT-Forum ===<br /> <br /> Die OAT stellt ein Forum bereit, wo über Testberichte und über die OAT diskutiert werden kann. Es ist unter [http://oat-online.de/forum/ www.oat-online.de/forum/] zu finden.<br /> <br /> == Weblinks ==<br /> <br /> * [http://www.oat-online.de www.oat-online.de]<br /> <br /> [[Kategorie:Anschlussprojekte]]<br /> <br /> [[en:OMSI Addon Testers (OAT)]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=OMSI_Addon_Tester_(OAT)&diff=705 2012-09-10T14:35:04Z

<p>Janniboy: Neue Passage &quot;Verwaltungsteam und Tester&quot;</p> <hr /> <div>== Gründung und Zielsetzung ==<br /> <br /> Die OMSI Addon Tester - kurz &quot;OAT&quot; - sind ein Zusammenschluss von Mitgliedern aus dem offiziellen OMSI-Forum.<br /> Gegründet wurde die OAT am 30. April 2011 durch die OMSI-Forenmitglieder Yufa, dem Leiter der OAT, Felix01 und Janniboy, die tatkräftig das [http://www.oat-online.de/forum/index.php Forum] und die [http://www.oat-online.de/ Website] der OAT warten und instandhalten ([http://omnibussimulator.forumieren.com/t4415-prufung-neuer-maps Link zum Gründungsthread im Forum]).<br /> <br /> Die OAT hat es sich zum Ziel gesetzt, kostenlose OMSI-Addons von Privatpersonen sachlich und objektiv zu bewerten.<br /> Damit soll einerseits interessierten Benutzern bereits vor dem Download ein allgemeiner in das Addon gegeben werden; andererseits soll so dazu beigetragen werden, dass sich die Qualität von OMSI-Addons mit der Zeit steigert.<br /> <br /> All das fasst die OAT in einem Statement-Satz zusammen:<br /> ''&quot;Wir möchten die Autoren aktiv dabei unterstützen, ihre Addons zu perfektionieren.&quot;''<br /> <br /> Alle Mitarbeiter der OAT arbeiten ehrenamtlich, jeder kann sich bewerben. Die derzeitigen Addon-Tester sind weiter unten gelistet. Welche Kriterien ein Addon-Tester erfüllen sollte und was von ihm erwartet wird, kann [http://oat-online.de/info_bewerben.php hier] nachgelesen werden.<br /> <br /> <br /> == Weitere Geschichte ==<br /> <br /> Nachdem die OAT einige Monate nach der Gründung ihre Dynamik und Geschwindigkeit bei der Abarbeitung der Testberichte verlor und sich die Zahl der nicht getesteten Addons drastisch erhöhte, berief man im Februar 2012 den User pBuch im neuen Posten als &quot;Manager für Testberichte&quot;, welcher die bisherigen Grundsätze der OAT grundlegend reformierte und somit ein völlig neues internes System zur besseren Kommunikation und Interaktion zwischen den Testern schuf. Damit war und ist er immer noch eine wichtige Stütze der OAT-Testersparte und testet selbst neben Verwaltungsaufgaben aktiv Addons.<br /> <br /> Am 30. April 2012 konnte die OAT mit neuer Motivation und aktiven Testern ihr einjähriges Bestehen als seriöse Testervereinigung feiern. Sie testet auch mehrere Monate nach ihrem ersten Geburtstag mit hoher Effektivität und Geschwindigkeit und großer Motivation die Addons von Privatentwicklern.<br /> <br /> <br /> == Testverfahren und Bewertung ==<br /> <br /> Interessierte Addon-Entwickler können ihr Addon direkt über das [http://oat-online.de/einsenden.php Online-Formular] einsenden.<br /> <br /> [[Datei:OATIconExplanation.jpg‎|300px|thumb|right|Das OAT-Testsiegel]]Die OAT veröffentlicht den jeweiligen Testbericht nach der Testphase auf der offiziellen Website [http://www.oat-online.de www.oat-online.de]. Daraus gehen zum Einen die Einzelwertungen, zum anderen die wichtigsten Punkte (Positiv- und Negativlisten) sowie die Gesamtpunktzahl des Addons hervor. Bei allen Tests soll größtmögliche Transparenz walten. Daher wurden auf der Website außerdem Leitfäden und Empfehlungen veröffentlicht. Nach der Meinung der OAT sind die dort genannten Kriterien elementar für das &quot;in den Grundsätzen perfekte Addon&quot;, und sie sind zugleich auch die Bewertungsmaßstäbe für die Testphasen.<br /> <br /> Die maximal erreichbare Punktzahl beträgt für alle Einsendungen 100 Punkte. Je nach Art des Addons werden die Kriterien verschieden gewählt und teilweise auch gewichtet, um den vielfältigen Anforderungen gerecht zu werden. Die erreichte Punktzahl wird im OAT-Testsiegel (siehe Beispielbild) dargestellt. Mit diesem Siegel kann der Entwickler des Addons überall für sein Addon &quot;werben&quot; und somit zeigen, dass er sich um Qualität bemüht.<br /> <br /> <br /> == Verwaltungsteam und Tester ==<br /> <br /> * '''Yufa''' - Leitung der OAT<br /> * '''Felix''' - Forenadministration, Webhosting<br /> * '''Janniboy''' - Gestaltung, Programmierung, Betreuung der Website (Webmaster)<br /> * '''pBuch''' - Manager für Testberichte<br /> <br /> Über eineinhalb Jahre haben sich auch die Gesichter der Addon-Testersparte verändert. Die derzeitigen Tester sind:<br /> <br /> * Dario<br /> * LH458<br /> * Sascha<br /> * Stefan_112<br /> * VDL<br /> <br /> <br /> == Weitere Dienstleistungen ==<br /> <br /> === OAT-Chat (wiedereröffnet) ===<br /> <br /> Nach einiger Zeit der Abschaltung aufgrund erhöhter Serverauslastung bietet die OAT unter der URL [http://www.oat-online.de/forum/chat/ oat-online.de/forum/chat/] nun wieder einen Chat für Mitglieder der OMSI-Community an.<br /> <br /> === OAT-Forum ===<br /> <br /> Die OAT stellt ein Forum bereit, wo über Testberichte und über die OAT diskutiert werden kann. Es ist unter [http://oat-online.de/forum/ www.oat-online.de/forum/] zu finden.<br /> <br /> == Weblinks ==<br /> <br /> * [http://www.oat-online.de www.oat-online.de]<br /> <br /> [[Kategorie:Anschlussprojekte]]<br /> <br /> [[en:OMSI Addon Testers (OAT)]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=OMSI_Addon_Tester_(OAT)&diff=704 2012-09-10T14:31:40Z

<p>Janniboy: Kleine Fehlerkorrekturen / Ergänzungen</p> <hr /> <div>== Gründung und Zielsetzung ==<br /> <br /> Die OMSI Addon Tester - kurz &quot;OAT&quot; - sind ein Zusammenschluss von Mitgliedern aus dem offiziellen OMSI-Forum.<br /> Gegründet wurde die OAT am 30. April 2011 durch die OMSI-Forenmitglieder Yufa, dem Leiter der OAT, Felix01 und Janniboy, die tatkräftig das [http://www.oat-online.de/forum/index.php Forum] und die [http://www.oat-online.de/ Website] der OAT warten und instandhalten ([http://omnibussimulator.forumieren.com/t4415-prufung-neuer-maps Link zum Gründungsthread im Forum]).<br /> <br /> Die OAT hat es sich zum Ziel gesetzt, kostenlose OMSI-Addons von Privatpersonen sachlich und objektiv zu bewerten.<br /> Damit soll einerseits interessierten Benutzern bereits vor dem Download ein allgemeiner in das Addon gegeben werden; andererseits soll so dazu beigetragen werden, dass sich die Qualität von OMSI-Addons mit der Zeit steigert.<br /> <br /> All das fasst die OAT in einem Statement-Satz zusammen:<br /> ''&quot;Wir möchten die Autoren aktiv dabei unterstützen, ihre Addons zu perfektionieren.&quot;''<br /> <br /> Alle Mitarbeiter der OAT arbeiten ehrenamtlich, jeder kann sich bewerben. Die derzeitigen Addon-Tester sind weiter unten gelistet. Welche Kriterien ein Addon-Tester erfüllen sollte und was von ihm erwartet wird, kann [http://oat-online.de/info_bewerben.php hier] nachgelesen werden.<br /> <br /> == Weitere Geschichte ==<br /> <br /> Nachdem die OAT einige Monate nach der Gründung ihre Dynamik und Geschwindigkeit bei der Abarbeitung der Testberichte verlor und sich die Zahl der nicht getesteten Addons drastisch erhöhte, berief man im Februar 2012 den User pBuch im neuen Posten als &quot;Manager für Testberichte&quot;, welcher die bisherigen Grundsätze der OAT grundlegend reformierte und somit ein völlig neues internes System zur besseren Kommunikation und Interaktion zwischen den Testern schuf. Damit war und ist er immer noch eine wichtige Stütze der OAT-Testersparte und testet selbst neben Verwaltungsaufgaben aktiv Addons.<br /> <br /> Am 30. April 2012 konnte die OAT mit neuer Motivation und aktiven Testern ihr einjähriges Bestehen als seriöse Testervereinigung feiern. Sie testet auch mehrere Monate nach ihrem ersten Geburtstag mit hoher Effektivität und Geschwindigkeit und großer Motivation die Addons von Privatentwicklern.<br /> <br /> == Testverfahren und Bewertung ==<br /> <br /> Interessierte Addon-Entwickler können ihr Addon direkt über das [http://oat-online.de/einsenden.php Online-Formular] einsenden.<br /> <br /> [[Datei:OATIconExplanation.jpg‎|300px|thumb|right|Das OAT-Testsiegel]]Die OAT veröffentlicht den jeweiligen Testbericht nach der Testphase auf der offiziellen Website [http://www.oat-online.de www.oat-online.de]. Daraus gehen zum Einen die Einzelwertungen, zum anderen die wichtigsten Punkte (Positiv- und Negativlisten) sowie die Gesamtpunktzahl des Addons hervor. Bei allen Tests soll größtmögliche Transparenz walten. Daher wurden auf der Website außerdem Leitfäden und Empfehlungen veröffentlicht. Nach der Meinung der OAT sind die dort genannten Kriterien elementar für das &quot;in den Grundsätzen perfekte Addon&quot;, und sie sind zugleich auch die Bewertungsmaßstäbe für die Testphasen.<br /> <br /> Die maximal erreichbare Punktzahl beträgt für alle Einsendungen 100 Punkte. Je nach Art des Addons werden die Kriterien verschieden gewählt und teilweise auch gewichtet, um den vielfältigen Anforderungen gerecht zu werden. Die erreichte Punktzahl wird im OAT-Testsiegel (siehe Beispielbild) dargestellt. Mit diesem Siegel kann der Entwickler des Addons überall für sein Addon &quot;werben&quot; und somit zeigen, dass er sich um Qualität bemüht.<br /> <br /> == Weitere Dienstleistungen ==<br /> <br /> === OAT-Chat (wiedereröffnet) ===<br /> <br /> Nach einiger Zeit der Abschaltung aufgrund erhöhter Serverauslastung bietet die OAT unter der URL [http://www.oat-online.de/forum/chat/ oat-online.de/forum/chat/] nun wieder einen Chat für Mitglieder der OMSI-Community an.<br /> <br /> === OAT-Forum ===<br /> <br /> Die OAT stellt ein Forum bereit, wo über Testberichte und über die OAT diskutiert werden kann. Es ist unter [http://oat-online.de/forum/ www.oat-online.de/forum/] zu finden.<br /> <br /> == Weblinks ==<br /> <br /> * [http://www.oat-online.de www.oat-online.de]<br /> <br /> [[Kategorie:Anschlussprojekte]]<br /> <br /> [[en:OMSI Addon Testers (OAT)]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=OMSI_Addon_Tester_(OAT)&diff=703 2012-09-10T14:29:59Z

<p>Janniboy: Neue Passage &quot;Weitere Geschichte&quot;</p> <hr /> <div>== Gründung und Zielsetzung ==<br /> <br /> Die OMSI Addon Tester - kurz &quot;OAT&quot; - sind ein Zusammenschluss von Mitgliedern aus dem offiziellen OMSI-Forum.<br /> Gegründet wurde die OAT am 30. April 2011 durch die OMSI-Forenmitglieder Yufa, dem Leiter der OAT, Felix01 und Janniboy, die tatkräftig das [http://www.oat-online.de/forum/index.php Forum] und die [http://www.oat-online.de/ Website] der OAT warten und instandhalten ([http://omnibussimulator.forumieren.com/t4415-prufung-neuer-maps Link zum Gründungsthread im Forum]).<br /> <br /> Die OAT hat es sich zum Ziel gesetzt, kostenlose OMSI-Addons von Privatpersonen sachlich und objektiv zu bewerten.<br /> Damit soll einerseits interessierten Benutzern bereits vor dem Download ein allgemeiner in das Addon gegeben werden; andererseits soll so dazu beigetragen werden, dass sich die Qualität von OMSI-Addons mit der Zeit steigert.<br /> <br /> All das fasst die OAT in einem Statement-Satz zusammen:<br /> ''&quot;Wir möchten die Autoren aktiv dabei unterstützen, ihre Addons zu perfektionieren.&quot;''<br /> <br /> Alle Mitarbeiter der OAT arbeiten ehrenamtlich, jeder kann sich bewerben. Die derzeitigen Addon-Tester sind weiter unten gelistet. Welche Kriterien ein Addon-Tester erfüllen sollte und was von ihm erwartet wird, kann [http://oat-online.de/info_bewerben.php hier] nachgelesen werden.<br /> <br /> == Weitere Geschichte ==<br /> <br /> Nachdem die OAT einige Monate nach der Gründung ihre Dynamik und Geschwindigkeit bei der Abarbeitung der Testberichte verlor und sich die Zahl der nicht getesteten Addons drastisch erhöhte, berief man im Februar 2012 den User pBuch im neuen Posten als &quot;Manager für Testberichte&quot;, welcher die bisherigen Grundsätze der OAT grundlegend reformierte und somit ein völlig neues internes System zur besseren Kommunikation und Interaktion zwischen den Testern schuf. Damit war und ist er immer noch eine wichtige Stütze der OAT-Testersparte und testet selbst neben Verwaltungsaufgaben aktiv Addons.<br /> <br /> Am 30. April 2012 konnte die OAT mit neuer Motivation und aktiven Testern ihr einjähriges Bestehen als seriöse Testervereinigung feiern. Sie testet auch mehrere Monate nach ihrem ersten Geburtstag mit hoher Effektivität und Geschwindigkeit und großer Motivation die Addons von Privatentwicklern.<br /> <br /> == Testverfahren und Bewertung ==<br /> <br /> Interessierte Addon-Entwickler können ihr Addon direkt über das [http://oat-online.de/einsenden.php Online-Formular] einsenden.<br /> <br /> [[Datei:OATIconExplanation.jpg‎|300px|thumb|right|Das OAT-Testsiegel]]Die OAT veröffentlicht den jeweiligen Testbericht nach der Testphase auf der offiziellen Website [http://www.oat-online.de www.oat-online.de]. Daraus gehen zum Einen die Einzelwertungen, zum anderen die wichtigsten Punkte (Positiv- und Negativlisten) sowie die Gesamtpunktzahl des Addons hervor. Bei allen Tests soll größtmögliche Transparenz walten. Daher wurden auf der Website außerdem Leitfäden und Empfehlungen veröffentlicht. Nach der Meinung der OAT sind die dort genannten Kriterien elementar für &quot;das perfekte Addon&quot;, und sie sind zugleich auch die Bewertungsmaßstäbe für Testsphasen.<br /> <br /> Die maximal erreichbare Punktzahl beträgt für alle Einsendungen 100 Punkte. Je nach Art des Addons werden die Kriterien verschieden gewählt und teilweise auch gewichtet, um den vielfältigen Anforderungen gerecht zu werden. Die erreichte Punktzahl wird im OAT-Testsiegel (siehe Beispielbild) dargestellt. Mit diesem Siegel kann der Entwickler des Addons überall für sein Addon &quot;werben&quot; und somit zeigen, dass er sich um Qualität bemüht.<br /> <br /> == Weitere Dienstleistungen ==<br /> <br /> === OAT-Chat (wiedereröffnet) ===<br /> <br /> Nach einiger Zeit der Abschaltung aufgrund erhöhter Serverauslastung bietet die OAT unter der URL [http://www.oat-online.de/forum/chat/ oat-online.de/forum/chat/] nun wieder einen Chat für Mitglieder der OMSI-Community an.<br /> <br /> === OAT-Forum ===<br /> <br /> Die OAT stellt ein Forum bereit, wo über Testberichte und über die OAT diskutiert werden kann. Es ist unter [http://oat-online.de/forum/ www.oat-online.de/forum/] zu finden.<br /> <br /> == Weblinks ==<br /> <br /> * [http://www.oat-online.de www.oat-online.de]<br /> <br /> [[Kategorie:Anschlussprojekte]]<br /> <br /> [[en:OMSI Addon Testers (OAT)]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=OMSI_Addon_Tester_(OAT)&diff=702 2012-09-10T14:26:33Z

<p>Janniboy: Klammern korrigiert</p> <hr /> <div>== Gründung und Zielsetzung ==<br /> <br /> Die OMSI Addon Tester - kurz &quot;OAT&quot; - sind ein Zusammenschluss von Mitgliedern aus dem offiziellen OMSI-Forum.<br /> Gegründet wurde die OAT am 30. April 2011 durch die OMSI-Forenmitglieder Yufa, dem Leiter der OAT, Felix01 und Janniboy, die tatkräftig das [http://www.oat-online.de/forum/index.php Forum] und die [http://www.oat-online.de/ Website] der OAT warten und instandhalten ([http://omnibussimulator.forumieren.com/t4415-prufung-neuer-maps Link zum Gründungsthread im Forum]).<br /> <br /> Die OAT hat es sich zum Ziel gesetzt, kostenlose OMSI-Addons von Privatpersonen sachlich und objektiv zu bewerten.<br /> Damit soll einerseits interessierten Benutzern bereits vor dem Download ein allgemeiner in das Addon gegeben werden; andererseits soll so dazu beigetragen werden, dass sich die Qualität von OMSI-Addons mit der Zeit steigert.<br /> <br /> All das fasst die OAT in einem Statement-Satz zusammen:<br /> ''&quot;Wir möchten die Autoren aktiv dabei unterstützen, ihre Addons zu perfektionieren.&quot;''<br /> <br /> Alle Mitarbeiter der OAT arbeiten ehrenamtlich, jeder kann sich bewerben. Die derzeitigen Addon-Tester sind weiter unten gelistet. Welche Kriterien ein Addon-Tester erfüllen sollte und was von ihm erwartet wird, kann [http://oat-online.de/info_bewerben.php hier] nachgelesen werden.<br /> <br /> == Testverfahren und Bewertung ==<br /> <br /> Interessierte Addon-Entwickler können ihr Addon direkt über das [http://oat-online.de/einsenden.php Online-Formular] einsenden.<br /> <br /> [[Datei:OATIconExplanation.jpg‎|300px|thumb|right|Das OAT-Testsiegel]]Die OAT veröffentlicht den jeweiligen Testbericht nach der Testphase auf der offiziellen Website [http://www.oat-online.de www.oat-online.de]. Daraus gehen zum Einen die Einzelwertungen, zum anderen die wichtigsten Punkte (Positiv- und Negativlisten) sowie die Gesamtpunktzahl des Addons hervor. Bei allen Tests soll größtmögliche Transparenz walten. Daher wurden auf der Website außerdem Leitfäden und Empfehlungen veröffentlicht. Nach der Meinung der OAT sind die dort genannten Kriterien elementar für &quot;das perfekte Addon&quot;, und sie sind zugleich auch die Bewertungsmaßstäbe für Testsphasen.<br /> <br /> Die maximal erreichbare Punktzahl beträgt für alle Einsendungen 100 Punkte. Je nach Art des Addons werden die Kriterien verschieden gewählt und teilweise auch gewichtet, um den vielfältigen Anforderungen gerecht zu werden. Die erreichte Punktzahl wird im OAT-Testsiegel (siehe Beispielbild) dargestellt. Mit diesem Siegel kann der Entwickler des Addons überall für sein Addon &quot;werben&quot; und somit zeigen, dass er sich um Qualität bemüht.<br /> <br /> == Weitere Dienstleistungen ==<br /> <br /> === OAT-Chat (wiedereröffnet) ===<br /> <br /> Nach einiger Zeit der Abschaltung aufgrund erhöhter Serverauslastung bietet die OAT unter der URL [http://www.oat-online.de/forum/chat/ oat-online.de/forum/chat/] nun wieder einen Chat für Mitglieder der OMSI-Community an.<br /> <br /> === OAT-Forum ===<br /> <br /> Die OAT stellt ein Forum bereit, wo über Testberichte und über die OAT diskutiert werden kann. Es ist unter [http://oat-online.de/forum/ www.oat-online.de/forum/] zu finden.<br /> <br /> == Weblinks ==<br /> <br /> * [http://www.oat-online.de www.oat-online.de]<br /> <br /> [[Kategorie:Anschlussprojekte]]<br /> <br /> [[en:OMSI Addon Testers (OAT)]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=OMSI_Addon_Tester_(OAT)&diff=701 2012-09-10T14:25:53Z

<p>Janniboy: Aktualisierung / Anpassung an heutige Tatsachen</p> <hr /> <div>== Gründung und Zielsetzung ==<br /> <br /> Die OMSI Addon Tester - kurz &quot;OAT&quot; - sind ein Zusammenschluss von Mitgliedern aus dem offiziellen OMSI-Forum.<br /> Gegründet wurde die OAT am 30. April 2011 durch die OMSI-Forenmitglieder Yufa, dem Leiter der OAT, Felix01 und Janniboy, die tatkräftig das ([http://www.oat-online.de/forum/index.php Forum]) und die ([http://www.oat-online.de/ Website]) der OAT warten und instandhalten ([http://omnibussimulator.forumieren.com/t4415-prufung-neuer-maps Link zum Gründungsthread im Forum]).<br /> <br /> Die OAT hat es sich zum Ziel gesetzt, kostenlose OMSI-Addons von Privatpersonen sachlich und objektiv zu bewerten.<br /> Damit soll einerseits interessierten Benutzern bereits vor dem Download ein allgemeiner in das Addon gegeben werden; andererseits soll so dazu beigetragen werden, dass sich die Qualität von OMSI-Addons mit der Zeit steigert.<br /> <br /> All das fasst die OAT in einem Statement-Satz zusammen:<br /> ''&quot;Wir möchten die Autoren aktiv dabei unterstützen, ihre Addons zu perfektionieren.&quot;''<br /> <br /> Alle Mitarbeiter der OAT arbeiten ehrenamtlich, jeder kann sich bewerben. Die derzeitigen Addon-Tester sind weiter unten gelistet. Welche Kriterien ein Addon-Tester erfüllen sollte und was von ihm erwartet wird, kann [http://oat-online.de/info_bewerben.php hier] nachgelesen werden.<br /> <br /> == Testverfahren und Bewertung ==<br /> <br /> Interessierte Addon-Entwickler können ihr Addon direkt über das [http://oat-online.de/einsenden.php Online-Formular] einsenden.<br /> <br /> [[Datei:OATIconExplanation.jpg‎|300px|thumb|right|Das OAT-Testsiegel]]Die OAT veröffentlicht den jeweiligen Testbericht nach der Testphase auf der offiziellen Website [http://www.oat-online.de www.oat-online.de]. Daraus gehen zum Einen die Einzelwertungen, zum anderen die wichtigsten Punkte (Positiv- und Negativlisten) sowie die Gesamtpunktzahl des Addons hervor. Bei allen Tests soll größtmögliche Transparenz walten. Daher wurden auf der Website außerdem Leitfäden und Empfehlungen veröffentlicht. Nach der Meinung der OAT sind die dort genannten Kriterien elementar für &quot;das perfekte Addon&quot;, und sie sind zugleich auch die Bewertungsmaßstäbe für Testsphasen.<br /> <br /> Die maximal erreichbare Punktzahl beträgt für alle Einsendungen 100 Punkte. Je nach Art des Addons werden die Kriterien verschieden gewählt und teilweise auch gewichtet, um den vielfältigen Anforderungen gerecht zu werden. Die erreichte Punktzahl wird im OAT-Testsiegel (siehe Beispielbild) dargestellt. Mit diesem Siegel kann der Entwickler des Addons überall für sein Addon &quot;werben&quot; und somit zeigen, dass er sich um Qualität bemüht.<br /> <br /> == Weitere Dienstleistungen ==<br /> <br /> === OAT-Chat (wiedereröffnet) ===<br /> <br /> Nach einiger Zeit der Abschaltung aufgrund erhöhter Serverauslastung bietet die OAT unter der URL [http://www.oat-online.de/forum/chat/ oat-online.de/forum/chat/] nun wieder einen Chat für Mitglieder der OMSI-Community an.<br /> <br /> === OAT-Forum ===<br /> <br /> Die OAT stellt ein Forum bereit, wo über Testberichte und über die OAT diskutiert werden kann. Es ist unter [http://oat-online.de/forum/ www.oat-online.de/forum/] zu finden.<br /> <br /> == Weblinks ==<br /> <br /> * [http://www.oat-online.de www.oat-online.de]<br /> <br /> [[Kategorie:Anschlussprojekte]]<br /> <br /> [[en:OMSI Addon Testers (OAT)]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=OMSI_Addon_Tester_(OAT)&diff=673 2012-08-15T18:27:00Z

<p>Janniboy: OAT-Chat wieder aktiviert</p> <hr /> <div>== Gründung und Zielsetzung ==<br /> <br /> Die OMSI Addon Tester - kurz &quot;OAT&quot; - sind ein Zusammenschluss von Mitgliedern aus dem offiziellen OMSI-Forum.<br /> Gegründet wurde die OAT am 30. April 2011 durch die OMSI-Forenmitglieder Yufa, Felix01 und Janniboy ([http://omnibussimulator.forumieren.com/t4415-prufung-neuer-maps Link zum Thread]).<br /> <br /> Die OAT ([http://www.oat-online.de www.oat-online.de]) hat es sich zum Ziel gesetzt, kostenlose OMSI-Addons von Privatpersonen sachlich und objektiv zu bewerten.<br /> Damit soll einerseits interessierten Benutzern bereits vor dem Download ein Einblick darin geben werden, was sie mit dem Addon erwartet; andererseits soll so dazu beigetragen werden, dass sich die Qualität von OMSI-Addons mit der Zeit steigert.<br /> <br /> All das fasst die OAT in einem Statement-Satz zusammen:<br /> ''&quot;Wir möchten die Autoren aktiv dabei unterstützen, ihre Addons zu perfektionieren.&quot;''<br /> <br /> Alle Mitarbeiter der OAT arbeiten ehrenamtlich, jeder kann sich bewerben. Welche Kriterien ein Addon-Tester erfüllen sollte und was von ihm erwartet wird, kann [http://oat-online.de/info_bewerben.php hier] nachgelesen werden.<br /> <br /> == Testverfahren und Bewertung ==<br /> <br /> Interessierte Addon-Entwickler können ihr Addon direkt über das [http://oat-online.de/einsenden.php Online-Formular] einsenden.<br /> <br /> [[Datei:OATIconExplanation.jpg‎|300px|thumb|right|Das OAT-Testsiegel]]Die OAT veröffentlicht den jeweiligen Testbericht nach der Testphase auf der offiziellen Website [http://www.oat-online.de www.oat-online.de]. Daraus gehen zum Einen die Einzelwertungen, zum anderen die wichtigsten Punkte (Positiv- und Negativlisten) sowie die Gesamtpunktzahl des Addons hervor. Bei allen Tests soll größtmögliche Transparenz walten. Daher wurden auf der Website außerdem Leitfäden und Empfehlungen veröffentlicht. Nach der Meinung der OAT sind die dort genannten Kriterien elementar für &quot;das perfekte Addon&quot;, und sie sind zugleich auch die Bewertungsmaßstäbe für Testsphasen.<br /> <br /> Die maximal erreichbare Punktzahl beträgt für alle Einsendungen 100 Punkte. Je nach Art des Addons werden die Kriterien verschieden gewählt und teilweise auch gewichtet, um den vielfältigen Anforderungen gerecht zu werden. Die erreichte Punktzahl wird im OAT-Testsiegel (siehe Beispielbild) dargestellt. Mit diesem Siegel kann der Entwickler des Addons überall für sein Addon &quot;werben&quot; und somit zeigen, dass er sich um Qualität bemüht.<br /> <br /> == Weitere Dienstleistungen ==<br /> <br /> === OAT-Chat (wiedereröffnet) ===<br /> <br /> Nach einiger Zeit der Abschaltung aufgrund erhöhter Serverauslastung bietet die OAT unter der URL [http://www.oat-online.de/forum/chat/ oat-online.de/forum/chat/] nun wieder einen Chat für Mitglieder der OMSI-Community an.<br /> <br /> === OAT-Forum ===<br /> <br /> Die OAT stellt ein Forum bereit, wo über Testberichte und über die OAT diskutiert werden kann. Es ist unter [http://oat-online.de/forum/ www.oat-online.de/forum/] zu finden.<br /> <br /> == Weblinks ==<br /> <br /> * [http://www.oat-online.de www.oat-online.de]<br /> <br /> [[Kategorie:Anschlussprojekte]]<br /> <br /> [[en:OMSI Addon Testers (OAT)]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Script:_Ein_Haltewunsch-Summer&diff=291 2011-10-04T15:23:48Z

<p>Janniboy: Rechtschreibfehler ausgebessert</p> <hr /> <div>Ich selbst habe erst vor zwei Tagen begonnen, mich mit dem OMSI-Skriptsystem näher auseinanderzusetzen, als die Dokumentation hier in der OMSI-Wiki erschien. Ich habe sogleich begonnen, ein bisschen zu experimentieren, um mir die Skriptsprache selber ein wenig beizubringen. Als eines der ersten Projekte ist ein Haltewunsch-Summer herausgekommen.<br /> <br /> Mir ist bewusst, dass dies skripttechnisch kein &quot;Wunderwerk&quot; ist - aber ich denke, für den Einsteiger ist es das ideale Projekt, denn es zeigt die Verwendung von Macros, Soundtriggern usw., ist aber gleichzeitig nicht sonderlich umfangreich. Ich entschied mich daher, hier ein Tutorial zu verfassen, um einigen Skriptern den Einstieg zu erleichtern.<br /> <br /> <br /> == Wie fangen wir an? ==<br /> <br /> <br /> === Bedingungen für das Abspielen des Sounds ===<br /> <br /> Am Anfang müssen wir uns natürlich fragen, was wir überhaupt umsetzen wollen. Ich mache jetzt mal eine Art &quot;Monolog-Brainstorming&quot;.<br /> <br /> Wir wollen, dass ein Summer ertönt, wenn die Haltewunsch-Lampe beim Fahrer angeht. Allerdings soll dies nur einmal geschehen und nicht jedes Mal, wenn ein Fahrgast den Stopknopf drückt. Des Weiteren wollen wir den Ton nicht hören, wenn wir den Kinderwagenschalter umlegen (dies ist ja auch eine Art Stopknopf). Wenn die Türen offen sind, soll der Sound ebenfalls nicht abgespielt werden.<br /> <br /> Außerdem ist es so, dass die Fahrgäste beim Aussteigen in OMSI permanent den Stopknopf drücken (bzw. über das Trittbrett laufen), denn so weiß OMSI, dass die hintere Tür noch nicht geschlossen werden darf! Wenn wir dies nicht berücksichtigen würden, würde ein Dauerton erklingen, wenn Leute aussteigen - eine der Stolperfallen, auf die ich gestoßen bin.<br /> <br /> Also kurz und knapp, welche Bedingungen für das Abspielen des Summers soll OMSI prüfen, wenn ein Haltewunsch registriert wird?<br /> <br /> * Es hat noch keiner vorher den Stopknopf gedrückt, es liegt also noch kein Haltewunsch vor.<br /> * Alle Türen müssen geschlossen sein.<br /> * Es wurde entweder ein normaler Stopknopf oder ein Stopknopf an der Tür gedrückt, der Kinderwagenschalter aber wird ignoriert.<br /> <br /> Jetzt wissen wir, was wir umsetzen wollen - aber noch nicht, wie wir das denn machen.<br /> <br /> <br /> === Was brauchen wir? ===<br /> <br /> Okay, die Abspielbedingungen sind geklärt. Spätestens jetzt sollte man sich den Artikel [[Scriptsystem]] genauer ansehen - ich werde die meisten Informationen, die hier benötigt werden, aber nochmal erläutern.<br /> <br /> Um die Übersicht zu wahren, werden wir eine '''neue Skriptdatei für dieses Projekt anlegen'''. Skriptdateien haben die Endung *.osc. Diese Datei wird den Code enthalten, der überprüft, ob der Sound abgespielt werden darf und falls ja, den Sound auch tatsächlich abspielt.<br /> <br /> Des Weiteren müssen wir für jeden Bus, der diesen Summer abspielen soll, die Skriptdatei '''in der jeweiligen *.bus-Datei registrieren'''. Die BUS-Datei enthält alle grundlegenden Informationen zum Bus und darüber hinaus auch die Verweise auf Variablenlisten, Skripts usw. - hier müssen wir OMSI also sagen, wo sich die neue Skriptdatei befindet.<br /> <br /> Außerdem müssen wir noch den '''abzuspielenden Sound definieren'''. Dies geschieht in der Soundkonfigurationsdatei (Endung *.cfg) jedes betroffenen Busses.<br /> <br /> Damit haben wir uns einen Überblick verschafft. Wir benötigen also:<br /> <br /> * Eine neue Skriptdatei mit dem Code zum Abspielen des Sounds<br /> * Ändern der *.bus-Datei, um die neue Skriptdatei bei OMSI anzumelden<br /> * Ändern der Soundkonfigurationsdatei (*.cfg), um den abzuspielenden Sound zu definieren<br /> <br /> Jetzt haben wir unser ganzes Handwerkszeug beisammen, und im nächsten Schritt geht's Stück für Stück an die Umsetzung.<br /> <br /> <br /> == Die Umsetzung ==<br /> <br /> <br /> === Den Sound dem Bus hinzufügen ===<br /> <br /> Die Datei &quot;sound_XXX.cfg&quot; im Unterverzeichnis &quot;Sound&quot; eines Bustyps enthält alle Sounds, die für den jeweiligen Bus verwendet werden. Hier müssen wir also unseren Sound auch hinzufügen, damit OMSI ihn erkennt.<br /> <br /> Kopiere als erstes den Summer-Sound (eine WAV-Datei) in das Unterverzeichnis &quot;Sound&quot; zu den anderen Sounddateien. Der Dateiname sollte natürlich aussagekräftig sein, wir wählen in diesem Fall einfach &quot;summer.wav&quot;.<br /> <br /> <br /> Jetzt öffne die &quot;sound_XXX.cfg&quot; des gewünschten Busses. Ich nehme als Beispiel den D92, das geht aber mit jedem anderen Bus auch. In diesem Fall öffne ich also die &quot;sound_D92.cfg&quot;.<br /> <br /> Scrolle bis ans Ende der Datei und füge folgenden Code hinzu, im Anschluss wird er erläutert:<br /> <br /> &lt;pre&gt;<br /> [sound]<br /> summer.wav<br /> 0.6<br /> <br /> <br /> [3d]<br /> -0.65<br /> 5.35<br /> 1.6<br /> 0.5<br /> <br /> [trigger]<br /> haltewunsch_summer<br /> &lt;/pre&gt;<br /> <br /> Nach dem Schlüsselwort [sound] folgt der Dateiname (ggf. anpassen!) und die Lautstärke (von 0 bis 1). Mit der Lautstärke musst du je nach Lautstärke der Sounddatei ein wenig experimentieren, bis der Summer laut/leise genug ist.<br /> <br /> Das Schlüsselwort [3d] definiert die Position des Sounds. Mit dem dargestellten Code befindet er sich direkt im Cockpit. Im Heck des Busses nimmt man den Summer also kaum noch wahr.<br /> <br /> Das letzte Schlüsselwort [trigger] ist extrem wichtig: Mit diesem Trigger wird später der Sound abgespielt, der Name sollte also eindeutig gewählt sein! Im Beispiel &quot;haltewunsch_summer&quot;.<br /> <br /> Speichere die Datei und OMSI weiß, dass der neue Sound existiert, aber noch nicht, wann und wie er abgespielt werden soll - das kommt im nächsten Schritt.<br /> <br /> <br /> === Die neue Skriptdatei anlegen ===<br /> <br /> Die eigene Skriptdatei enthält den Code, der ausgeführt wird, wenn ein Fahrgast den Haltewunschknopf drückt. Zwar hätte man diese Routine auch direkt in die anderen Skripte schreiben können, aber so wird das System klarer verständlich und man trennt zudem &quot;Eigenproduktion&quot; und &quot;Originalproduktion&quot;.<br /> <br /> Öffne also den Windows-Editor (Notepad), um die neue Datei zu erstellen. Füge folgenden Code ein, er wird wiederum im Anschluss erläutert.<br /> <br /> &lt;pre&gt;<br /> 'Spielt einen Summer-Ton ab, wenn ein Haltewunschknopf gedrückt wird.<br /> <br /> {macro:summer_abspielen}<br /> <br /> (L.L.haltewunsch) 1 = !<br /> (L.L.door_0) 0.1 &lt; &amp;&amp;<br /> (L.L.door_1) 0.1 &lt; &amp;&amp;<br /> (L.L.door_2) 0.1 &lt; &amp;&amp;<br /> {if}<br /> (T.L.haltewunsch_summer) <br /> {endif}<br /> <br /> {end}<br /> &lt;/pre&gt;<br /> <br /> Zuerst definieren wir den Namen der Prozedur, in OMSI heißen diese Prozeduren einfach &quot;Macros&quot;. Später kann man dieses Macro an geeigneter Stelle aufrufen und so den Code immer dann ausführen, wenn er benötigt wird. Hierzu empfehle ich noch diese Lektüre: [[Scriptsystem#Einstiegs-_und_Ausstiegspunkte.2C_Makros_und_Trigger|Einstiegs- und Ausstiegspunkte, Makros und Trigger ]]<br /> <br /> Alles, was also zwischen {macro:...} und {end} steht, wird immer durchlaufen, wenn das Macro aufgerufen wird. Jetzt zur Erläuterung des enthaltenen Codes.<br /> <br /> <br /> Der Code besteht eigentlich nur aus einer IF-Anweisung und dem Abspielen des Sounds, falls die Bedingungen alle zutreffen. Der Einfachheit halber werde ich die Zeilen einzeln erläutern.<br /> <br /> &lt;pre&gt;<br /> (L.L.haltewunsch) 1 = !<br /> &lt;/pre&gt;<br /> Wenn ein Haltewunsch registriert wurde, wird die Variable &quot;haltewunsch&quot; auf 1 gesetzt, sonst ist sie 0. Man kann also einfach abfragen, ob die Variable ungleich 1 ist, denn der Sound soll ja nur abgespielt werden, wenn die Haltewunschlampe noch nicht leuchtet. Der Code &quot;(L.L.haltewunsch) 1 =&quot; würde also TRUE zurückgeben, wenn schon ein Haltewunsch existiert, das Gegenteil wollen wir aber erreichen. &quot;!&quot; ist in OMSI die Verneinung, sie kehrt also TRUE zu FALSE um und umgekehrt.<br /> Das bedeutet für uns, die Bedingung ist dann wahr, wenn noch kein Haltewunsch vorliegt - genau das, was wir erreichen wollen.<br /> <br /> &lt;pre&gt;<br /> (L.L.door_0) 0.1 &lt; &amp;&amp;<br /> (L.L.door_1) 0.1 &lt; &amp;&amp;<br /> (L.L.door_2) 0.1 &lt; &amp;&amp;<br /> &lt;/pre&gt;<br /> <br /> Hier prüfen wir einfach, ob alle Türen geschlossen sind. Ob eine Tür offen ist, wird über die Variable &quot;door_X&quot; festgelegt. 0 bedeutet &quot;ganz geschlossen&quot;, 1 dagegen &quot;ganz geöffnet&quot;. Wir wollen nicht so streng sein und sagen: Für uns ist die Tür schon zu, wenn sie nur 10% geöffnet ist (das entspricht ja 0.1). <br /> Die &quot;&amp;&amp;&quot; bedeuten &quot;AND&quot;, d.h. damit die IF-Anweisung ausgeführt wird, müssen ALLE Bedingungen TRUE sein.<br /> <br /> &lt;pre&gt;<br /> (T.L.haltewunsch_summer)<br /> &lt;/pre&gt;<br /> Dieser Befehl schließlich führt den Soundtrigger &quot;haltewunsch_summer&quot; aus. Dieser Name entspricht dem, den wir vorhin in der Soundkonfigurationsdatei unter [trigger] angegeben haben. OMSI spielt den Sound einfach jedes Mal ab, wenn dieser Trigger augerufen wird.<br /> <br /> So weit so gut, das Skript steht. Speichere es jetzt z.B. als &quot;summer.osc&quot; ab - OMSI kann es jetzt aber noch nicht finden. Damit OMSI weiß, wo es sich befindet, müssen wir im folgenden Schritt noch eine Kleinigkeit ändern.<br /> <br /> <br /> === Die Skriptdatei dem Bus hinzufügen ===<br /> <br /> Welche Skripts ein Bus verwendet, wird in der entsprechenden *.bus-Datei des Busses festgelegt. Damit OMSI also das oben definierte Makro überhaupt finden kann, öffnen wir jetzt die entsprechende *.bus-Datei mit dem Editor. Beim D92 wäre das logischerweise die &quot;MAN_D92.bus&quot;.<br /> <br /> Wir scrollen nun herunter bis zum Abschnitt [script]. Hier folgen zunächst die Zahl der von OMSI zu lesenden Zeilen und dann die relativen Pfade zu den Skriptdateien. Wir fügen unsere Skriptdatei hinten an und erhöhen die auszulesende Zeilenzahl um 1, sodass es etwa so aussehen sollte:<br /> <br /> &lt;pre&gt;[script]<br /> 24<br /> script\man_D92_main.osc<br /> script\man_D86_main_AI.osc<br /> script\collision.osc<br /> script\cockpit.osc<br /> script\antrieb.osc<br /> script\engine.osc<br /> script\elec.osc<br /> script\bremse.osc<br /> script\auspuff.osc<br /> script\lights.osc<br /> script\door.osc<br /> script\wiper.osc<br /> script\klappern.osc<br /> script\forcefeedback.osc<br /> script\rain.osc<br /> script\dirt.osc<br /> script\sound_volume.osc<br /> script\heizung.osc<br /> script\IBIS-2.osc<br /> script\matrix_D.osc<br /> script\wimpel.osc<br /> script\cashdesk.osc<br /> script\ticketprinter.osc<br /> script\summer.osc&lt;/pre&gt;<br /> <br /> Falls schon vorhergehend Modifikation installiert worden sein sollten, kann die Liste natürlich variieren. Wichtig ist nur, penibel genau auf die korrekte Zeilenanzahl zu achten.<br /> <br /> Damit haben wir das Gröbste geschafft und können kurz durchatmen ;-)<br /> Was jetzt noch fehlt, ist, dass OMSI dieses Makro an den geeigneten Stellen aufruft - also immer dann, wenn ein Haltewunsch von OMSI bemerkt wird. Das kommt im vierten und letzten Schritt an die Reihe.<br /> <br /> === Das Makro an geeigneter Stelle aufrufen ===<br /> <br /> Der Code für den Haltewunsch steht bei den mitgelieferten Doppeldeckern in der Skriptdatei &quot;door.osc&quot;. Für den OMSI-Türmod funktioniert die Anleitung genauso, dort müssen eben entsprechend die anderen Dateien bearbeitet werden.<br /> <br /> Öffne also die &quot;door.osc&quot; und suche die Sektion ''{trigger:int_haltewunsch}''. Hier müssen wir unser oben definiertes Macro aufrufen.<br /> <br /> Dieser Trigger wird von OMSI aufgerufen, wenn ein Fahrgast den Stopknof drückt. Direkt unter dieser Zeile fügen wir also den Macroaufruf ein, sodass die ganze Sektion so aussieht:<br /> <br /> &lt;pre&gt;<br /> {trigger:int_haltewunsch}<br /> <br /> (M.L.summer_abspielen)<br /> 1 (S.L.haltewunsch)<br /> <br /> {end}<br /> &lt;/pre&gt;<br /> <br /> Wir rufen einfach zuerst das oben selbst geschriebene Macro auf, und danach setzt OMSI die Variable &quot;haltewunsch&quot; auf 1. Würden wir die umgekehrte Reihenfolge wählen, wäre die 1. Bedingung innerhalb des Macros (s.o.) immer FALSE und der Sound würde nie abgespielt!<br /> <br /> Den gleichen Makroaufruf fügst du auch unter ''{trigger:door_haltewunsch}'' ein - dieser Trigger repräsentiert die Tür-Stopknöpfe bzw. das Trittbrett an der hinteren Tür. Und falls gewünscht, kannst du den Code darunter auch für den Kinderwagenschalter einfügen. Wie das geht, kannst du selbst ausprobieren - nur ein Tipp: ''(T.L.ev_kippschalter_ein)'' spielt den Sound ab, der das Einschalten des Kinderwagenschalters repräsentiert. Irgendwo dort sollte also der Macroaufruf stehen ;)<br /> <br /> <br /> Speichere die Änderungen dann noch ab und probiere das Ergebnis aus - es sollte funktionieren.<br /> <br /> Viel Spaß beim weiteren Erkunden der Skriptsprache ;-)<br /> <br /> <br /> [[Kategorie:Tutorials für Addon-Entwickler]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Script:_Ein_Haltewunsch-Summer&diff=290 2011-10-04T15:23:00Z

<p>Janniboy: *.bus-Registrierung hinzugefügt</p> <hr /> <div>Ich selbst habe erst vor zwei Tagen begonnen, mich mit dem OMSI-Skriptsystem näher auseinanderzusetzen, als die Dokumentation hier in der OMSI-Wiki erschien. Ich habe sogleich begonnen, ein bisschen zu experimentieren, um mir die Skriptsprache selber ein wenig beizubringen. Als eines der ersten Projekte ist ein Haltewunsch-Summer herausgekommen.<br /> <br /> Mir ist bewusst, dass dies skripttechnisch kein &quot;Wunderwerk&quot; ist - aber ich denke, für den Einsteiger ist es das ideale Projekt, denn es zeigt die Verwendung von Macros, Soundtriggern usw., ist aber gleichzeitig nicht sonderlich umfangreich. Ich entschied mich daher, hier ein Tutorial zu verfassen, um einigen Skriptern den Einstieg zu erleichtern.<br /> <br /> <br /> == Wie fangen wir an? ==<br /> <br /> <br /> === Bedingungen für das Abspielen des Sounds ===<br /> <br /> Am Anfang müssen wir uns natürlich fragen, was wir überhaupt umsetzen wollen. Ich mache jetzt mal eine Art &quot;Monolog-Brainstorming&quot;.<br /> <br /> Wir wollen, dass ein Summer ertönt, wenn die Haltewunsch-Lampe beim Fahrer angeht. Allerdings soll dies nur einmal geschehen und nicht jedes Mal, wenn ein Fahrgast den Stopknopf drückt. Des Weiteren wollen wir den Ton nicht hören, wenn wir den Kinderwagenschalter umlegen (dies ist ja auch eine Art Stopknopf). Wenn die Türen offen sind, soll der Sound ebenfalls nicht abgespielt werden.<br /> <br /> Außerdem ist es so, dass die Fahrgäste beim Aussteigen in OMSI permanent den Stopknopf drücken (bzw. über das Trittbrett laufen), denn so weiß OMSI, dass die hintere Tür noch nicht geschlossen werden darf! Wenn wir dies nicht berücksichtigen würden, würde ein Dauerton erklingen, wenn Leute aussteigen - eine der Stolperfallen, auf die ich gestoßen bin.<br /> <br /> Also kurz und knapp, welche Bedingungen für das Abspielen des Summers soll OMSI prüfen, wenn ein Haltewunsch registriert wird?<br /> <br /> * Es hat noch keiner vorher den Stopknopf gedrückt, es liegt also noch kein Haltewunsch vor.<br /> * Alle Türen müssen geschlossen sein.<br /> * Es wurde entweder ein normaler Stopknopf oder ein Stopknopf an der Tür gedrückt, der Kinderwagenschalter aber wird ignoriert.<br /> <br /> Jetzt wissen wir, was wir umsetzen wollen - aber noch nicht, wie wir das denn machen.<br /> <br /> <br /> === Was brauchen wir? ===<br /> <br /> Okay, die Abspielbedingungen sind geklärt. Spätestens jetzt sollte man sich den Artikel [[Scriptsystem]] genauer ansehen - ich werde die meisten Informationen, die hier benötigt werden, aber nochmal erläutern.<br /> <br /> Um die Übersicht zu wahren, werden wir eine '''neue Skriptdatei für dieses Projekt anlegen'''. Skriptdateien haben die Endung *.osc. Diese Datei wird den Code enthalten, der überprüft, ob der Sound abgespielt werden darf und falls ja, den Sound auch tatsächlich abspielt.<br /> <br /> Des Weiteren müssen wir für jeden Bus, der diesen Summer abspielen soll, die Skriptdatei '''in der jeweiligen *.bus-Datei registrieren'''. Die BUS-Datei enthält alle grundlegenden Informationen zum Bus und darüber hinaus auch die Verweise auf Variablenlisten, Skripts usw. - hier müssen wir OMSI also sagen, wo sich die neue Skriptdatei befindet.<br /> <br /> Außerdem müssen wir noch den '''abzuspielenden Sound definieren'''. Dies geschieht in der Soundkonfigurationsdatei (Endung *.cfg) jedes betroffenen Busses.<br /> <br /> Damit haben wir uns einen Überblick verschafft. Wir benötigen also:<br /> <br /> * Eine neue Skriptdatei mit dem Code zum Abspielen des Sounds<br /> * Ändern der *.bus-Datei, um die neue Skriptdatei bei OMSI anzumelden<br /> * Ändern der Soundkonfigurationsdatei (*.cfg), um den abzuspielenden Sound zu definieren<br /> <br /> Jetzt haben wir unser ganzes Handwerkszeug beisammen, und im nächsten Schritt geht's Stück für Stück an die Umsetzung.<br /> <br /> <br /> == Die Umsetzung ==<br /> <br /> <br /> === Den Sound dem Bus hinzufügen ===<br /> <br /> Die Datei &quot;sound_XXX.cfg&quot; im Unterverzeichnis &quot;Sound&quot; eines Bustyps enthält alle Sounds, die für den jeweiligen Bus verwendet werden. Hier müssen wir also unseren Sound auch hinzufügen, damit OMSI ihn erkennt.<br /> <br /> Kopiere als erstes den Summer-Sound (eine WAV-Datei) in das Unterverzeichnis &quot;Sound&quot; zu den anderen Sounddateien. Der Dateiname sollte natürlich aussagekräftig sein, wir wählen in diesem Fall einfach &quot;summer.wav&quot;.<br /> <br /> <br /> Jetzt öffne die &quot;sound_XXX.cfg&quot; des gewünschten Busses. Ich nehme als Beispiel den D92, das geht aber mit jedem anderen Bus auch. In diesem Fall öffne ich also die &quot;sound_D92.cfg&quot;.<br /> <br /> Scrolle bis ans Ende der Datei und füge folgenden Code hinzu, im Anschluss wird er erläutert:<br /> <br /> &lt;pre&gt;<br /> [sound]<br /> summer.wav<br /> 0.6<br /> <br /> <br /> [3d]<br /> -0.65<br /> 5.35<br /> 1.6<br /> 0.5<br /> <br /> [trigger]<br /> haltewunsch_summer<br /> &lt;/pre&gt;<br /> <br /> Nach dem Schlüsselwort [sound] folgt der Dateiname (ggf. anpassen!) und die Lautstärke (von 0 bis 1). Mit der Lautstärke musst du je nach Lautstärke der Sounddatei ein wenig experimentieren, bis der Summer laut/leise genug ist.<br /> <br /> Das Schlüsselwort [3d] definiert die Position des Sounds. Mit dem dargestellten Code befindet er sich direkt im Cockpit. Im Heck des Busses nimmt man den Summer also kaum noch wahr.<br /> <br /> Das letzte Schlüsselwort [trigger] ist extrem wichtig: Mit diesem Trigger wird später der Sound abgespielt, der Name sollte also eindeutig gewählt sein! Im Beispiel &quot;haltewunsch_summer&quot;.<br /> <br /> Speichere die Datei und OMSI weiß, dass der neue Sound existiert, aber noch nicht, wann und wie er abgespielt werden soll - das kommt im nächsten Schritt.<br /> <br /> <br /> === Die neue Skriptdatei anlegen ===<br /> <br /> Die eigene Skriptdatei enthält den Code, der ausgeführt wird, wenn ein Fahrgast den Haltewunschknopf drückt. Zwar hätte man diese Routine auch direkt in die anderen Skripte schreiben können, aber so wird das System klarer verständlich und man trennt zudem &quot;Eigenproduktion&quot; und &quot;Originalproduktion&quot;.<br /> <br /> Öffne also den Windows-Editor (Notepad), um die neue Datei zu erstellen. Füge folgenden Code ein, er wird wiederum im Anschluss erläutert.<br /> <br /> &lt;pre&gt;<br /> 'Spielt einen Summer-Ton ab, wenn ein Haltewunschknopf gedrückt wird.<br /> <br /> {macro:summer_abspielen}<br /> <br /> (L.L.haltewunsch) 1 = !<br /> (L.L.door_0) 0.1 &lt; &amp;&amp;<br /> (L.L.door_1) 0.1 &lt; &amp;&amp;<br /> (L.L.door_2) 0.1 &lt; &amp;&amp;<br /> {if}<br /> (T.L.haltewunsch_summer) <br /> {endif}<br /> <br /> {end}<br /> &lt;/pre&gt;<br /> <br /> Zuerst definieren wir den Namen der Prozedur, in OMSI heißen diese Prozeduren einfach &quot;Macros&quot;. Später kann man dieses Macro an geeigneter Stelle aufrufen und so den Code immer dann ausführen, wenn er benötigt wird. Hierzu empfehle ich noch diese Lektüre: [[Scriptsystem#Einstiegs-_und_Ausstiegspunkte.2C_Makros_und_Trigger|Einstiegs- und Ausstiegspunkte, Makros und Trigger ]]<br /> <br /> Alles, was also zwischen {macro:...} und {end} steht, wird immer durchlaufen, wenn das Macro aufgerufen wird. Jetzt zur Erläuterung des enthaltenen Codes.<br /> <br /> <br /> Der Code besteht eigentlich nur aus einer IF-Anweisung und dem Abspielen des Sounds, falls die Bedingungen alle zutreffen. Der Einfachheit halber werde ich die Zeilen einzeln erläutern.<br /> <br /> &lt;pre&gt;<br /> (L.L.haltewunsch) 1 = !<br /> &lt;/pre&gt;<br /> Wenn ein Haltewunsch registriert wurde, wird die Variable &quot;haltewunsch&quot; auf 1 gesetzt, sonst ist sie 0. Man kann also einfach abfragen, ob die Variable ungleich 1 ist, denn der Sound soll ja nur abgespielt werden, wenn die Haltewunschlampe noch nicht leuchtet. Der Code &quot;(L.L.haltewunsch) 1 =&quot; würde also TRUE zurückgeben, wenn schon ein Haltewunsch existiert, das Gegenteil wollen wir aber erreichen. &quot;!&quot; ist in OMSI die Verneinung, sie kehrt also TRUE zu FALSE um und umgekehrt.<br /> Das bedeutet für uns, die Bedingung ist dann wahr, wenn noch kein Haltewunsch vorliegt - genau das, was wir erreichen wollen.<br /> <br /> &lt;pre&gt;<br /> (L.L.door_0) 0.1 &lt; &amp;&amp;<br /> (L.L.door_1) 0.1 &lt; &amp;&amp;<br /> (L.L.door_2) 0.1 &lt; &amp;&amp;<br /> &lt;/pre&gt;<br /> <br /> Hier prüfen wir einfach, ob alle Türen geschlossen sind. Ob eine Tür offen ist, wird über die Variable &quot;door_X&quot; festgelegt. 0 bedeutet &quot;ganz geschlossen&quot;, 1 dagegen &quot;ganz geöffnet&quot;. Wir wollen nicht so streng sein und sagen: Für uns ist die Tür schon zu, wenn sie nur 10% geöffnet ist (das entspricht ja 0.1). <br /> Die &quot;&amp;&amp;&quot; bedeuten &quot;AND&quot;, d.h. damit die IF-Anweisung ausgeführt wird, müssen ALLE Bedingungen TRUE sein.<br /> <br /> &lt;pre&gt;<br /> (T.L.haltewunsch_summer)<br /> &lt;/pre&gt;<br /> Dieser Befehl schließlich führt den Soundtrigger &quot;haltewunsch_summer&quot; aus. Dieser Name entspricht dem, den wir vorhin in der Soundkonfigurationsdatei unter [trigger] angegeben haben. OMSI spielt den Sound einfach jedes Mal ab, wenn dieser Trigger augerufen wird.<br /> <br /> So weit so gut, das Skript steht. Speichere es jetzt z.B. als &quot;summer.osc&quot; ab - OMSI kann es jetzt aber noch nicht finden. Damit OMSI weiß, wo es sich befindet, müssen wir im folgenden Schritt noch eine Kleinigkeit ändern.<br /> <br /> <br /> === Die Skriptdatei dem Bus hinzufügen ===<br /> <br /> Welche Skripts ein Bus verwendet, wird in der entsprechenden *.bus-Datei des Busses festgelegt. Damit OMSI also das oben definierte Makro überhaupt finden kann, öffnen wir jetzt die entsprechende *.bus-Datei mit dem Editor. Beim D92 wäre das logischerweise die &quot;MAN_D92.bus&quot;.<br /> <br /> Wir scrollen nun herunter bis zum Abschnitt [script]. Hier folgen zunächst die Zahl der von OMSI zu lesenden Zeilen und dann die relativen Pfade zu den Skriptdateien. Wir fügen unsere Skriptdatei hinten an und erhöhen die auszulesende Zeilenzahl um 1, sodass es etwa so aussehen sollte:<br /> <br /> &lt;pre&gt;[script]<br /> 24<br /> script\man_D92_main.osc<br /> script\man_D86_main_AI.osc<br /> script\collision.osc<br /> script\cockpit.osc<br /> script\antrieb.osc<br /> script\engine.osc<br /> script\elec.osc<br /> script\bremse.osc<br /> script\auspuff.osc<br /> script\lights.osc<br /> script\door.osc<br /> script\wiper.osc<br /> script\klappern.osc<br /> script\forcefeedback.osc<br /> script\rain.osc<br /> script\dirt.osc<br /> script\sound_volume.osc<br /> script\heizung.osc<br /> script\IBIS-2.osc<br /> script\matrix_D.osc<br /> script\wimpel.osc<br /> script\cashdesk.osc<br /> script\ticketprinter.osc<br /> script\summer.osc&lt;/pre&gt;<br /> <br /> Falls schon verhergehend Modifikation installiert worden sein sollten, kann die Liste natürlich variieren. Wichtig ist nur, penibel genau auf die korrekte Zeilenanzahl zu achten.<br /> <br /> Damit haben wir das Gröbste geschafft und können kurz durchatmen ;-)<br /> Was jetzt noch fehlt, ist, dass OMSI dieses Makro an den geeigneten Stellen aufruft - also immer dann, wenn ein Haltewunsch von OMSI bemerkt wird. Das kommt im vierten und letzten Schritt an die Reihe.<br /> <br /> <br /> === Das Makro an geeigneter Stelle aufrufen ===<br /> <br /> Der Code für den Haltewunsch steht bei den mitgelieferten Doppeldeckern in der Skriptdatei &quot;door.osc&quot;. Für den OMSI-Türmod funktioniert die Anleitung genauso, dort müssen eben entsprechend die anderen Dateien bearbeitet werden.<br /> <br /> Öffne also die &quot;door.osc&quot; und suche die Sektion ''{trigger:int_haltewunsch}''. Hier müssen wir unser oben definiertes Macro aufrufen.<br /> <br /> Dieser Trigger wird von OMSI aufgerufen, wenn ein Fahrgast den Stopknof drückt. Direkt unter dieser Zeile fügen wir also den Macroaufruf ein, sodass die ganze Sektion so aussieht:<br /> <br /> &lt;pre&gt;<br /> {trigger:int_haltewunsch}<br /> <br /> (M.L.summer_abspielen)<br /> 1 (S.L.haltewunsch)<br /> <br /> {end}<br /> &lt;/pre&gt;<br /> <br /> Wir rufen einfach zuerst das oben selbst geschriebene Macro auf, und danach setzt OMSI die Variable &quot;haltewunsch&quot; auf 1. Würden wir die umgekehrte Reihenfolge wählen, wäre die 1. Bedingung innerhalb des Macros (s.o.) immer FALSE und der Sound würde nie abgespielt!<br /> <br /> Den gleichen Makroaufruf fügst du auch unter ''{trigger:door_haltewunsch}'' ein - dieser Trigger repräsentiert die Tür-Stopknöpfe bzw. das Trittbrett an der hinteren Tür. Und falls gewünscht, kannst du den Code darunter auch für den Kinderwagenschalter einfügen. Wie das geht, kannst du selbst ausprobieren - nur ein Tipp: ''(T.L.ev_kippschalter_ein)'' spielt den Sound ab, der das Einschalten des Kinderwagenschalters repräsentiert. Irgendwo dort sollte also der Macroaufruf stehen ;)<br /> <br /> <br /> Speichere die Änderungen dann noch ab und probiere das Ergebnis aus - es sollte funktionieren.<br /> <br /> Viel Spaß beim weiteren Erkunden der Skriptsprache ;-)<br /> <br /> <br /> [[Kategorie:Tutorials für Addon-Entwickler]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Script:_Ein_Haltewunsch-Summer&diff=274 2011-09-17T13:04:04Z

<p>Janniboy: Kategorie korrigiert</p> <hr /> <div>Ich selbst habe erst vor zwei Tagen begonnen, mich mit dem OMSI-Skriptsystem näher auseinanderzusetzen, als die Dokumentation hier in der OMSI-Wiki erschien. Ich habe sogleich begonnen, ein bisschen zu experimentieren, um mir die Skriptsprache selber ein wenig beizubringen. Als eines der ersten Projekte ist ein Haltewunsch-Summer herausgekommen.<br /> <br /> Mir ist bewusst, dass dies skripttechnisch kein &quot;Wunderwerk&quot; ist - aber ich denke, für den Einsteiger ist es das ideale Projekt, denn es zeigt die Verwendung von Macros, Soundtriggern usw., ist aber gleichzeitig nicht sonderlich umfangreich. Ich entschied mich daher, hier ein Tutorial zu verfassen, um einigen Skriptern den Einstieg zu erleichtern.<br /> <br /> <br /> == Wie fangen wir an? ==<br /> <br /> <br /> === Bedingungen für das Abspielen des Sounds ===<br /> <br /> Am Anfang müssen wir uns natürlich fragen, was wir überhaupt umsetzen wollen. Ich mache jetzt mal eine Art &quot;Monolog-Brainstorming&quot;.<br /> <br /> Wir wollen, dass ein Summer ertönt, wenn die Haltewunsch-Lampe beim Fahrer angeht. Allerdings soll dies nur einmal geschehen und nicht jedes Mal, wenn ein Fahrgast den Stopknopf drückt. Des Weiteren wollen wir den Ton nicht hören, wenn wir den Kinderwagenschalter umlegen (dies ist ja auch eine Art Stopknopf). Wenn die Türen offen sind, soll der Sound ebenfalls nicht abgespielt werden.<br /> <br /> Außerdem ist es so, dass die Fahrgäste beim Aussteigen in OMSI permanent den Stopknopf drücken (bzw. über das Trittbrett laufen), denn so weiß OMSI, dass die hintere Tür noch nicht geschlossen werden darf! Wenn wir dies nicht berücksichtigen würden, würde ein Dauerton erklingen, wenn Leute aussteigen - eine der Stolperfallen, auf die ich gestoßen bin.<br /> <br /> Also kurz und knapp, welche Bedingungen für das Abspielen des Summers soll OMSI prüfen, wenn ein Haltewunsch registriert wird?<br /> <br /> * Es hat noch keiner vorher den Stopknopf gedrückt, es liegt also noch kein Haltewunsch vor.<br /> * Alle Türen müssen geschlossen sein.<br /> * Es wurde entweder ein normaler Stopknopf oder ein Stopknopf an der Tür gedrückt, der Kinderwagenschalter aber wird ignoriert.<br /> <br /> Jetzt wissen wir, was wir umsetzen wollen - aber noch nicht, wie wir das denn machen.<br /> <br /> <br /> === Was brauchen wir? ===<br /> <br /> Okay, die Abspielbedingungen sind geklärt. Spätestens jetzt sollte man sich den Artikel [[Scriptsystem]] genauer ansehen - ich werde die meisten Informationen, die hier benötigt werden, aber nochmal erläutern.<br /> <br /> Um die Übersicht zu wahren, werden wir eine '''neue Skriptdatei für dieses Projekt anlegen'''. Skriptdateien haben die Endung *.osc. Diese Datei wird den Code enthalten, der überprüft, ob der Sound abgespielt werden darf und falls ja, den Sound auch tatsächlich abspielt.<br /> <br /> Des Weiteren müssen wir für jeden Bus, der diesen Summer abspielen soll, die Skriptdatei '''in der jeweiligen *.bus-Datei registrieren'''. Die BUS-Datei enthält alle grundlegenden Informationen zum Bus und darüber hinaus auch die Verweise auf Variablenlisten, Skripts usw. - hier müssen wir OMSI also sagen, wo sich die neue Skriptdatei befindet.<br /> <br /> Außerdem müssen wir noch den '''abzuspielenden Sound definieren'''. Dies geschieht in der Soundkonfigurationsdatei (Endung *.cfg) jedes betroffenen Busses.<br /> <br /> Damit haben wir uns einen Überblick verschafft. Wir benötigen also:<br /> <br /> * Eine neue Skriptdatei mit dem Code zum Abspielen des Sounds<br /> * Ändern der *.bus-Datei, um die neue Skriptdatei bei OMSI anzumelden<br /> * Ändern der Soundkonfigurationsdatei (*.cfg), um den abzuspielenden Sound zu definieren<br /> <br /> Jetzt haben wir unser ganzes Handwerkszeug beisammen, und im nächsten Schritt geht's Stück für Stück an die Umsetzung.<br /> <br /> <br /> == Die Umsetzung ==<br /> <br /> <br /> === Den Sound dem Bus hinzufügen ===<br /> <br /> Die Datei &quot;sound_XXX.cfg&quot; im Unterverzeichnis &quot;Sound&quot; eines Bustyps enthält alle Sounds, die für den jeweiligen Bus verwendet werden. Hier müssen wir also unseren Sound auch hinzufügen, damit OMSI ihn erkennt.<br /> <br /> Kopiere als erstes den Summer-Sound (eine WAV-Datei) in das Unterverzeichnis &quot;Sound&quot; zu den anderen Sounddateien. Der Dateiname sollte natürlich aussagekräftig sein, wir wählen in diesem Fall einfach &quot;summer.wav&quot;.<br /> <br /> <br /> Jetzt öffne die &quot;sound_XXX.cfg&quot; des gewünschten Busses. Ich nehme als Beispiel den D92, das geht aber mit jedem anderen Bus auch. In diesem Fall öffne ich also die &quot;sound_D92.cfg&quot;.<br /> <br /> Scrolle bis ans Ende der Datei und füge folgenden Code hinzu, im Anschluss wird er erläutert:<br /> <br /> &lt;pre&gt;<br /> [sound]<br /> summer.wav<br /> 0.6<br /> <br /> <br /> [3d]<br /> -0.65<br /> 5.35<br /> 1.6<br /> 0.5<br /> <br /> [trigger]<br /> haltewunsch_summer<br /> &lt;/pre&gt;<br /> <br /> Nach dem Schlüsselwort [sound] folgt der Dateiname (ggf. anpassen!) und die Lautstärke (von 0 bis 1). Mit der Lautstärke musst du je nach Lautstärke der Sounddatei ein wenig experimentieren, bis der Summer laut/leise genug ist.<br /> <br /> Das Schlüsselwort [3d] definiert die Position des Sounds. Mit dem dargestellten Code befindet er sich direkt im Cockpit. Im Heck des Busses nimmt man den Summer also kaum noch wahr.<br /> <br /> Das letzte Schlüsselwort [trigger] ist extrem wichtig: Mit diesem Trigger wird später der Sound abgespielt, der Name sollte also eindeutig gewählt sein! Im Beispiel &quot;haltewunsch_summer&quot;.<br /> <br /> Speichere die Datei und OMSI weiß, dass der neue Sound existiert, aber noch nicht, wann und wie er abgespielt werden soll - das kommt im nächsten Schritt.<br /> <br /> <br /> === Die neue Skriptdatei anlegen ===<br /> <br /> Die eigene Skriptdatei enthält den Code, der ausgeführt wird, wenn ein Fahrgast den Haltewunschknopf drückt. Zwar hätte man diese Routine auch direkt in die anderen Skripte schreiben können, aber so wird das System klarer verständlich und man trennt zudem &quot;Eigenproduktion&quot; und &quot;Originalproduktion&quot;.<br /> <br /> Öffne also den Windows-Editor (Notepad), um die neue Datei zu erstellen. Füge folgenden Code ein, er wird wiederum im Anschluss erläutert.<br /> <br /> &lt;pre&gt;<br /> 'Spielt einen Summer-Ton ab, wenn ein Haltewunschknopf gedrückt wird.<br /> <br /> {macro:summer_abspielen}<br /> <br /> (L.L.haltewunsch) 1 = !<br /> (L.L.door_0) 0.1 &lt; &amp;&amp;<br /> (L.L.door_1) 0.1 &lt; &amp;&amp;<br /> (L.L.door_2) 0.1 &lt; &amp;&amp;<br /> {if}<br /> (T.L.haltewunsch_summer) <br /> {endif}<br /> <br /> {end}<br /> &lt;/pre&gt;<br /> <br /> Zuerst definieren wir den Namen der Prozedur, in OMSI heißen diese Prozeduren einfach &quot;Macros&quot;. Später kann man dieses Macro an geeigneter Stelle aufrufen und so den Code immer dann ausführen, wenn er benötigt wird. Hierzu empfehle ich noch diese Lektüre: [[Scriptsystem#Einstiegs-_und_Ausstiegspunkte.2C_Makros_und_Trigger|Einstiegs- und Ausstiegspunkte, Makros und Trigger ]]<br /> <br /> Alles, was also zwischen {macro:...} und {end} steht, wird immer durchlaufen, wenn das Macro aufgerufen wird. Jetzt zur Erläuterung des enthaltenen Codes.<br /> <br /> <br /> Der Code besteht eigentlich nur aus einer IF-Anweisung und dem Abspielen des Sounds, falls die Bedingungen alle zutreffen. Der Einfachheit halber werde ich die Zeilen einzeln erläutern.<br /> <br /> &lt;pre&gt;<br /> (L.L.haltewunsch) 1 = !<br /> &lt;/pre&gt;<br /> Wenn ein Haltewunsch registriert wurde, wird die Variable &quot;haltewunsch&quot; auf 1 gesetzt, sonst ist sie 0. Man kann also einfach abfragen, ob die Variable ungleich 1 ist, denn der Sound soll ja nur abgespielt werden, wenn die Haltewunschlampe noch nicht leuchtet. Der Code &quot;(L.L.haltewunsch) 1 =&quot; würde also TRUE zurückgeben, wenn schon ein Haltewunsch existiert, das Gegenteil wollen wir aber erreichen. &quot;!&quot; ist in OMSI die Verneinung, sie kehrt also TRUE zu FALSE um und umgekehrt.<br /> Das bedeutet für uns, die Bedingung ist dann wahr, wenn noch kein Haltewunsch vorliegt - genau das, was wir erreichen wollen.<br /> <br /> &lt;pre&gt;<br /> (L.L.door_0) 0.1 &lt; &amp;&amp;<br /> (L.L.door_1) 0.1 &lt; &amp;&amp;<br /> (L.L.door_2) 0.1 &lt; &amp;&amp;<br /> &lt;/pre&gt;<br /> <br /> Hier prüfen wir einfach, ob alle Türen geschlossen sind. Ob eine Tür offen ist, wird über die Variable &quot;door_X&quot; festgelegt. 0 bedeutet &quot;ganz geschlossen&quot;, 1 dagegen &quot;ganz geöffnet&quot;. Wir wollen nicht so streng sein und sagen: Für uns ist die Tür schon zu, wenn sie nur 10% geöffnet ist (das entspricht ja 0.1). <br /> Die &quot;&amp;&amp;&quot; bedeuten &quot;AND&quot;, d.h. damit die IF-Anweisung ausgeführt wird, müssen ALLE Bedingungen TRUE sein.<br /> <br /> &lt;pre&gt;<br /> (T.L.haltewunsch_summer)<br /> &lt;/pre&gt;<br /> Dieser Befehl schließlich führt den Soundtrigger &quot;haltewunsch_summer&quot; aus. Dieser Name entspricht dem, den wir vorhin in der Soundkonfigurationsdatei unter [trigger] angegeben haben. OMSI spielt den Sound einfach jedes Mal ab, wenn dieser Trigger augerufen wird.<br /> <br /> <br /> Damit haben wir das Gröbste geschafft und können kurz durchatmen ;-)<br /> Was jetzt noch fehlt, ist, dass OMSI dieses Makro an den geeigneten Stellen aufruft - also immer dann, wenn ein Haltewunsch von OMSI bemerkt wird. Das kommt im dritten und letzten Schritt an die Reihe.<br /> <br /> <br /> === Das Makro an geeigneter Stelle aufrufen ===<br /> <br /> Der Code für den Haltewunsch steht bei den mitgelieferten Doppeldeckern in der Skriptdatei &quot;door.osc&quot;. Für den OMSI-Türmod funktioniert die Anleitung genauso, dort müssen eben entsprechend die anderen Dateien bearbeitet werden.<br /> <br /> Öffne also die &quot;door.osc&quot; und suche die Sektion ''{trigger:int_haltewunsch}''. Hier müssen wir unser oben definiertes Macro aufrufen.<br /> <br /> Dieser Trigger wird von OMSI aufgerufen, wenn ein Fahrgast den Stopknof drückt. Direkt unter dieser Zeile fügen wir also den Macroaufruf ein, sodass die ganze Sektion so aussieht:<br /> <br /> &lt;pre&gt;<br /> {trigger:int_haltewunsch}<br /> <br /> (M.L.summer_abspielen)<br /> 1 (S.L.haltewunsch)<br /> <br /> {end}<br /> &lt;/pre&gt;<br /> <br /> Wir rufen einfach zuerst das oben selbst geschriebene Macro auf, und danach setzt OMSI die Variable &quot;haltewunsch&quot; auf 1. Würden wir die umgekehrte Reihenfolge wählen, wäre die 1. Bedingung innerhalb des Macros (s.o.) immer FALSE und der Sound würde nie abgespielt!<br /> <br /> Den gleichen Makroaufruf fügst du auch unter ''{trigger:door_haltewunsch}'' ein - dieser Trigger repräsentiert die Tür-Stopknöpfe bzw. das Trittbrett an der hinteren Tür. Und falls gewünscht, kannst du den Code darunter auch für den Kinderwagenschalter einfügen. Wie das geht, kannst du selbst ausprobieren - nur ein Tipp: ''(T.L.ev_kippschalter_ein)'' spielt den Sound ab, der das Einschalten des Kinderwagenschalters repräsentiert. Irgendwo dort sollte also der Macroaufruf stehen ;)<br /> <br /> <br /> Speichere die Änderungen dann noch ab und probiere das Ergebnis aus - es sollte funktionieren.<br /> <br /> Viel Spaß beim weiteren Erkunden der Skriptsprache ;-)<br /> <br /> <br /> [[Kategorie:Tutorials für Addon-Entwickler]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Script:_Ein_Haltewunsch-Summer&diff=272 2011-09-17T13:02:10Z

<p>Janniboy: hat „Tutorial: Ein Haltewunsch-Summer“ nach „Script: Ein Haltewunsch-Summer“ verschoben</p> <hr /> <div>Ich selbst habe erst vor zwei Tagen begonnen, mich mit dem OMSI-Skriptsystem näher auseinanderzusetzen, als die Dokumentation hier in der OMSI-Wiki erschien. Ich habe sogleich begonnen, ein bisschen zu experimentieren, um mir die Skriptsprache selber ein wenig beizubringen. Als eines der ersten Projekte ist ein Haltewunsch-Summer herausgekommen.<br /> <br /> Mir ist bewusst, dass dies skripttechnisch kein &quot;Wunderwerk&quot; ist - aber ich denke, für den Einsteiger ist es das ideale Projekt, denn es zeigt die Verwendung von Macros, Soundtriggern usw., ist aber gleichzeitig nicht sonderlich umfangreich. Ich entschied mich daher, hier ein Tutorial zu verfassen, um einigen Skriptern den Einstieg zu erleichtern.<br /> <br /> <br /> == Wie fangen wir an? ==<br /> <br /> <br /> === Bedingungen für das Abspielen des Sounds ===<br /> <br /> Am Anfang müssen wir uns natürlich fragen, was wir überhaupt umsetzen wollen. Ich mache jetzt mal eine Art &quot;Monolog-Brainstorming&quot;.<br /> <br /> Wir wollen, dass ein Summer ertönt, wenn die Haltewunsch-Lampe beim Fahrer angeht. Allerdings soll dies nur einmal geschehen und nicht jedes Mal, wenn ein Fahrgast den Stopknopf drückt. Des Weiteren wollen wir den Ton nicht hören, wenn wir den Kinderwagenschalter umlegen (dies ist ja auch eine Art Stopknopf). Wenn die Türen offen sind, soll der Sound ebenfalls nicht abgespielt werden.<br /> <br /> Außerdem ist es so, dass die Fahrgäste beim Aussteigen in OMSI permanent den Stopknopf drücken (bzw. über das Trittbrett laufen), denn so weiß OMSI, dass die hintere Tür noch nicht geschlossen werden darf! Wenn wir dies nicht berücksichtigen würden, würde ein Dauerton erklingen, wenn Leute aussteigen - eine der Stolperfallen, auf die ich gestoßen bin.<br /> <br /> Also kurz und knapp, welche Bedingungen für das Abspielen des Summers soll OMSI prüfen, wenn ein Haltewunsch registriert wird?<br /> <br /> * Es hat noch keiner vorher den Stopknopf gedrückt, es liegt also noch kein Haltewunsch vor.<br /> * Alle Türen müssen geschlossen sein.<br /> * Es wurde entweder ein normaler Stopknopf oder ein Stopknopf an der Tür gedrückt, der Kinderwagenschalter aber wird ignoriert.<br /> <br /> Jetzt wissen wir, was wir umsetzen wollen - aber noch nicht, wie wir das denn machen.<br /> <br /> <br /> === Was brauchen wir? ===<br /> <br /> Okay, die Abspielbedingungen sind geklärt. Spätestens jetzt sollte man sich den Artikel [[Scriptsystem]] genauer ansehen - ich werde die meisten Informationen, die hier benötigt werden, aber nochmal erläutern.<br /> <br /> Um die Übersicht zu wahren, werden wir eine '''neue Skriptdatei für dieses Projekt anlegen'''. Skriptdateien haben die Endung *.osc. Diese Datei wird den Code enthalten, der überprüft, ob der Sound abgespielt werden darf und falls ja, den Sound auch tatsächlich abspielt.<br /> <br /> Des Weiteren müssen wir für jeden Bus, der diesen Summer abspielen soll, die Skriptdatei '''in der jeweiligen *.bus-Datei registrieren'''. Die BUS-Datei enthält alle grundlegenden Informationen zum Bus und darüber hinaus auch die Verweise auf Variablenlisten, Skripts usw. - hier müssen wir OMSI also sagen, wo sich die neue Skriptdatei befindet.<br /> <br /> Außerdem müssen wir noch den '''abzuspielenden Sound definieren'''. Dies geschieht in der Soundkonfigurationsdatei (Endung *.cfg) jedes betroffenen Busses.<br /> <br /> Damit haben wir uns einen Überblick verschafft. Wir benötigen also:<br /> <br /> * Eine neue Skriptdatei mit dem Code zum Abspielen des Sounds<br /> * Ändern der *.bus-Datei, um die neue Skriptdatei bei OMSI anzumelden<br /> * Ändern der Soundkonfigurationsdatei (*.cfg), um den abzuspielenden Sound zu definieren<br /> <br /> Jetzt haben wir unser ganzes Handwerkszeug beisammen, und im nächsten Schritt geht's Stück für Stück an die Umsetzung.<br /> <br /> <br /> == Die Umsetzung ==<br /> <br /> <br /> === Den Sound dem Bus hinzufügen ===<br /> <br /> Die Datei &quot;sound_XXX.cfg&quot; im Unterverzeichnis &quot;Sound&quot; eines Bustyps enthält alle Sounds, die für den jeweiligen Bus verwendet werden. Hier müssen wir also unseren Sound auch hinzufügen, damit OMSI ihn erkennt.<br /> <br /> Kopiere als erstes den Summer-Sound (eine WAV-Datei) in das Unterverzeichnis &quot;Sound&quot; zu den anderen Sounddateien. Der Dateiname sollte natürlich aussagekräftig sein, wir wählen in diesem Fall einfach &quot;summer.wav&quot;.<br /> <br /> <br /> Jetzt öffne die &quot;sound_XXX.cfg&quot; des gewünschten Busses. Ich nehme als Beispiel den D92, das geht aber mit jedem anderen Bus auch. In diesem Fall öffne ich also die &quot;sound_D92.cfg&quot;.<br /> <br /> Scrolle bis ans Ende der Datei und füge folgenden Code hinzu, im Anschluss wird er erläutert:<br /> <br /> &lt;pre&gt;<br /> [sound]<br /> summer.wav<br /> 0.6<br /> <br /> <br /> [3d]<br /> -0.65<br /> 5.35<br /> 1.6<br /> 0.5<br /> <br /> [trigger]<br /> haltewunsch_summer<br /> &lt;/pre&gt;<br /> <br /> Nach dem Schlüsselwort [sound] folgt der Dateiname (ggf. anpassen!) und die Lautstärke (von 0 bis 1). Mit der Lautstärke musst du je nach Lautstärke der Sounddatei ein wenig experimentieren, bis der Summer laut/leise genug ist.<br /> <br /> Das Schlüsselwort [3d] definiert die Position des Sounds. Mit dem dargestellten Code befindet er sich direkt im Cockpit. Im Heck des Busses nimmt man den Summer also kaum noch wahr.<br /> <br /> Das letzte Schlüsselwort [trigger] ist extrem wichtig: Mit diesem Trigger wird später der Sound abgespielt, der Name sollte also eindeutig gewählt sein! Im Beispiel &quot;haltewunsch_summer&quot;.<br /> <br /> Speichere die Datei und OMSI weiß, dass der neue Sound existiert, aber noch nicht, wann und wie er abgespielt werden soll - das kommt im nächsten Schritt.<br /> <br /> <br /> === Die neue Skriptdatei anlegen ===<br /> <br /> Die eigene Skriptdatei enthält den Code, der ausgeführt wird, wenn ein Fahrgast den Haltewunschknopf drückt. Zwar hätte man diese Routine auch direkt in die anderen Skripte schreiben können, aber so wird das System klarer verständlich und man trennt zudem &quot;Eigenproduktion&quot; und &quot;Originalproduktion&quot;.<br /> <br /> Öffne also den Windows-Editor (Notepad), um die neue Datei zu erstellen. Füge folgenden Code ein, er wird wiederum im Anschluss erläutert.<br /> <br /> &lt;pre&gt;<br /> 'Spielt einen Summer-Ton ab, wenn ein Haltewunschknopf gedrückt wird.<br /> <br /> {macro:summer_abspielen}<br /> <br /> (L.L.haltewunsch) 1 = !<br /> (L.L.door_0) 0.1 &lt; &amp;&amp;<br /> (L.L.door_1) 0.1 &lt; &amp;&amp;<br /> (L.L.door_2) 0.1 &lt; &amp;&amp;<br /> {if}<br /> (T.L.haltewunsch_summer) <br /> {endif}<br /> <br /> {end}<br /> &lt;/pre&gt;<br /> <br /> Zuerst definieren wir den Namen der Prozedur, in OMSI heißen diese Prozeduren einfach &quot;Macros&quot;. Später kann man dieses Macro an geeigneter Stelle aufrufen und so den Code immer dann ausführen, wenn er benötigt wird. Hierzu empfehle ich noch diese Lektüre: [[Scriptsystem#Einstiegs-_und_Ausstiegspunkte.2C_Makros_und_Trigger|Einstiegs- und Ausstiegspunkte, Makros und Trigger ]]<br /> <br /> Alles, was also zwischen {macro:...} und {end} steht, wird immer durchlaufen, wenn das Macro aufgerufen wird. Jetzt zur Erläuterung des enthaltenen Codes.<br /> <br /> <br /> Der Code besteht eigentlich nur aus einer IF-Anweisung und dem Abspielen des Sounds, falls die Bedingungen alle zutreffen. Der Einfachheit halber werde ich die Zeilen einzeln erläutern.<br /> <br /> &lt;pre&gt;<br /> (L.L.haltewunsch) 1 = !<br /> &lt;/pre&gt;<br /> Wenn ein Haltewunsch registriert wurde, wird die Variable &quot;haltewunsch&quot; auf 1 gesetzt, sonst ist sie 0. Man kann also einfach abfragen, ob die Variable ungleich 1 ist, denn der Sound soll ja nur abgespielt werden, wenn die Haltewunschlampe noch nicht leuchtet. Der Code &quot;(L.L.haltewunsch) 1 =&quot; würde also TRUE zurückgeben, wenn schon ein Haltewunsch existiert, das Gegenteil wollen wir aber erreichen. &quot;!&quot; ist in OMSI die Verneinung, sie kehrt also TRUE zu FALSE um und umgekehrt.<br /> Das bedeutet für uns, die Bedingung ist dann wahr, wenn noch kein Haltewunsch vorliegt - genau das, was wir erreichen wollen.<br /> <br /> &lt;pre&gt;<br /> (L.L.door_0) 0.1 &lt; &amp;&amp;<br /> (L.L.door_1) 0.1 &lt; &amp;&amp;<br /> (L.L.door_2) 0.1 &lt; &amp;&amp;<br /> &lt;/pre&gt;<br /> <br /> Hier prüfen wir einfach, ob alle Türen geschlossen sind. Ob eine Tür offen ist, wird über die Variable &quot;door_X&quot; festgelegt. 0 bedeutet &quot;ganz geschlossen&quot;, 1 dagegen &quot;ganz geöffnet&quot;. Wir wollen nicht so streng sein und sagen: Für uns ist die Tür schon zu, wenn sie nur 10% geöffnet ist (das entspricht ja 0.1). <br /> Die &quot;&amp;&amp;&quot; bedeuten &quot;AND&quot;, d.h. damit die IF-Anweisung ausgeführt wird, müssen ALLE Bedingungen TRUE sein.<br /> <br /> &lt;pre&gt;<br /> (T.L.haltewunsch_summer)<br /> &lt;/pre&gt;<br /> Dieser Befehl schließlich führt den Soundtrigger &quot;haltewunsch_summer&quot; aus. Dieser Name entspricht dem, den wir vorhin in der Soundkonfigurationsdatei unter [trigger] angegeben haben. OMSI spielt den Sound einfach jedes Mal ab, wenn dieser Trigger augerufen wird.<br /> <br /> <br /> Damit haben wir das Gröbste geschafft und können kurz durchatmen ;-)<br /> Was jetzt noch fehlt, ist, dass OMSI dieses Makro an den geeigneten Stellen aufruft - also immer dann, wenn ein Haltewunsch von OMSI bemerkt wird. Das kommt im dritten und letzten Schritt an die Reihe.<br /> <br /> <br /> === Das Makro an geeigneter Stelle aufrufen ===<br /> <br /> Der Code für den Haltewunsch steht bei den mitgelieferten Doppeldeckern in der Skriptdatei &quot;door.osc&quot;. Für den OMSI-Türmod funktioniert die Anleitung genauso, dort müssen eben entsprechend die anderen Dateien bearbeitet werden.<br /> <br /> Öffne also die &quot;door.osc&quot; und suche die Sektion ''{trigger:int_haltewunsch}''. Hier müssen wir unser oben definiertes Macro aufrufen.<br /> <br /> Dieser Trigger wird von OMSI aufgerufen, wenn ein Fahrgast den Stopknof drückt. Direkt unter dieser Zeile fügen wir also den Macroaufruf ein, sodass die ganze Sektion so aussieht:<br /> <br /> &lt;pre&gt;<br /> {trigger:int_haltewunsch}<br /> <br /> (M.L.summer_abspielen)<br /> 1 (S.L.haltewunsch)<br /> <br /> {end}<br /> &lt;/pre&gt;<br /> <br /> Wir rufen einfach zuerst das oben selbst geschriebene Macro auf, und danach setzt OMSI die Variable &quot;haltewunsch&quot; auf 1. Würden wir die umgekehrte Reihenfolge wählen, wäre die 1. Bedingung innerhalb des Macros (s.o.) immer FALSE und der Sound würde nie abgespielt!<br /> <br /> Den gleichen Makroaufruf fügst du auch unter ''{trigger:door_haltewunsch}'' ein - dieser Trigger repräsentiert die Tür-Stopknöpfe bzw. das Trittbrett an der hinteren Tür. Und falls gewünscht, kannst du den Code darunter auch für den Kinderwagenschalter einfügen. Wie das geht, kannst du selbst ausprobieren - nur ein Tipp: ''(T.L.ev_kippschalter_ein)'' spielt den Sound ab, der das Einschalten des Kinderwagenschalters repräsentiert. Irgendwo dort sollte also der Macroaufruf stehen ;)<br /> <br /> <br /> Speichere die Änderungen dann noch ab und probiere das Ergebnis aus - es sollte funktionieren.<br /> <br /> Viel Spaß beim weiteren Erkunden der Skriptsprache ;-)<br /> <br /> <br /> [[Kategorie:Tutorials]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Tutorial:_Ein_Haltewunsch-Summer&diff=273 2011-09-17T13:02:10Z

<p>Janniboy: hat „Tutorial: Ein Haltewunsch-Summer“ nach „Script: Ein Haltewunsch-Summer“ verschoben</p> <hr /> <div>#WEITERLEITUNG [[Script: Ein Haltewunsch-Summer]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Script:_Ein_Haltewunsch-Summer&diff=271 2011-09-17T13:01:08Z

<p>Janniboy: Kategorie geändert</p> <hr /> <div>Ich selbst habe erst vor zwei Tagen begonnen, mich mit dem OMSI-Skriptsystem näher auseinanderzusetzen, als die Dokumentation hier in der OMSI-Wiki erschien. Ich habe sogleich begonnen, ein bisschen zu experimentieren, um mir die Skriptsprache selber ein wenig beizubringen. Als eines der ersten Projekte ist ein Haltewunsch-Summer herausgekommen.<br /> <br /> Mir ist bewusst, dass dies skripttechnisch kein &quot;Wunderwerk&quot; ist - aber ich denke, für den Einsteiger ist es das ideale Projekt, denn es zeigt die Verwendung von Macros, Soundtriggern usw., ist aber gleichzeitig nicht sonderlich umfangreich. Ich entschied mich daher, hier ein Tutorial zu verfassen, um einigen Skriptern den Einstieg zu erleichtern.<br /> <br /> <br /> == Wie fangen wir an? ==<br /> <br /> <br /> === Bedingungen für das Abspielen des Sounds ===<br /> <br /> Am Anfang müssen wir uns natürlich fragen, was wir überhaupt umsetzen wollen. Ich mache jetzt mal eine Art &quot;Monolog-Brainstorming&quot;.<br /> <br /> Wir wollen, dass ein Summer ertönt, wenn die Haltewunsch-Lampe beim Fahrer angeht. Allerdings soll dies nur einmal geschehen und nicht jedes Mal, wenn ein Fahrgast den Stopknopf drückt. Des Weiteren wollen wir den Ton nicht hören, wenn wir den Kinderwagenschalter umlegen (dies ist ja auch eine Art Stopknopf). Wenn die Türen offen sind, soll der Sound ebenfalls nicht abgespielt werden.<br /> <br /> Außerdem ist es so, dass die Fahrgäste beim Aussteigen in OMSI permanent den Stopknopf drücken (bzw. über das Trittbrett laufen), denn so weiß OMSI, dass die hintere Tür noch nicht geschlossen werden darf! Wenn wir dies nicht berücksichtigen würden, würde ein Dauerton erklingen, wenn Leute aussteigen - eine der Stolperfallen, auf die ich gestoßen bin.<br /> <br /> Also kurz und knapp, welche Bedingungen für das Abspielen des Summers soll OMSI prüfen, wenn ein Haltewunsch registriert wird?<br /> <br /> * Es hat noch keiner vorher den Stopknopf gedrückt, es liegt also noch kein Haltewunsch vor.<br /> * Alle Türen müssen geschlossen sein.<br /> * Es wurde entweder ein normaler Stopknopf oder ein Stopknopf an der Tür gedrückt, der Kinderwagenschalter aber wird ignoriert.<br /> <br /> Jetzt wissen wir, was wir umsetzen wollen - aber noch nicht, wie wir das denn machen.<br /> <br /> <br /> === Was brauchen wir? ===<br /> <br /> Okay, die Abspielbedingungen sind geklärt. Spätestens jetzt sollte man sich den Artikel [[Scriptsystem]] genauer ansehen - ich werde die meisten Informationen, die hier benötigt werden, aber nochmal erläutern.<br /> <br /> Um die Übersicht zu wahren, werden wir eine '''neue Skriptdatei für dieses Projekt anlegen'''. Skriptdateien haben die Endung *.osc. Diese Datei wird den Code enthalten, der überprüft, ob der Sound abgespielt werden darf und falls ja, den Sound auch tatsächlich abspielt.<br /> <br /> Des Weiteren müssen wir für jeden Bus, der diesen Summer abspielen soll, die Skriptdatei '''in der jeweiligen *.bus-Datei registrieren'''. Die BUS-Datei enthält alle grundlegenden Informationen zum Bus und darüber hinaus auch die Verweise auf Variablenlisten, Skripts usw. - hier müssen wir OMSI also sagen, wo sich die neue Skriptdatei befindet.<br /> <br /> Außerdem müssen wir noch den '''abzuspielenden Sound definieren'''. Dies geschieht in der Soundkonfigurationsdatei (Endung *.cfg) jedes betroffenen Busses.<br /> <br /> Damit haben wir uns einen Überblick verschafft. Wir benötigen also:<br /> <br /> * Eine neue Skriptdatei mit dem Code zum Abspielen des Sounds<br /> * Ändern der *.bus-Datei, um die neue Skriptdatei bei OMSI anzumelden<br /> * Ändern der Soundkonfigurationsdatei (*.cfg), um den abzuspielenden Sound zu definieren<br /> <br /> Jetzt haben wir unser ganzes Handwerkszeug beisammen, und im nächsten Schritt geht's Stück für Stück an die Umsetzung.<br /> <br /> <br /> == Die Umsetzung ==<br /> <br /> <br /> === Den Sound dem Bus hinzufügen ===<br /> <br /> Die Datei &quot;sound_XXX.cfg&quot; im Unterverzeichnis &quot;Sound&quot; eines Bustyps enthält alle Sounds, die für den jeweiligen Bus verwendet werden. Hier müssen wir also unseren Sound auch hinzufügen, damit OMSI ihn erkennt.<br /> <br /> Kopiere als erstes den Summer-Sound (eine WAV-Datei) in das Unterverzeichnis &quot;Sound&quot; zu den anderen Sounddateien. Der Dateiname sollte natürlich aussagekräftig sein, wir wählen in diesem Fall einfach &quot;summer.wav&quot;.<br /> <br /> <br /> Jetzt öffne die &quot;sound_XXX.cfg&quot; des gewünschten Busses. Ich nehme als Beispiel den D92, das geht aber mit jedem anderen Bus auch. In diesem Fall öffne ich also die &quot;sound_D92.cfg&quot;.<br /> <br /> Scrolle bis ans Ende der Datei und füge folgenden Code hinzu, im Anschluss wird er erläutert:<br /> <br /> &lt;pre&gt;<br /> [sound]<br /> summer.wav<br /> 0.6<br /> <br /> <br /> [3d]<br /> -0.65<br /> 5.35<br /> 1.6<br /> 0.5<br /> <br /> [trigger]<br /> haltewunsch_summer<br /> &lt;/pre&gt;<br /> <br /> Nach dem Schlüsselwort [sound] folgt der Dateiname (ggf. anpassen!) und die Lautstärke (von 0 bis 1). Mit der Lautstärke musst du je nach Lautstärke der Sounddatei ein wenig experimentieren, bis der Summer laut/leise genug ist.<br /> <br /> Das Schlüsselwort [3d] definiert die Position des Sounds. Mit dem dargestellten Code befindet er sich direkt im Cockpit. Im Heck des Busses nimmt man den Summer also kaum noch wahr.<br /> <br /> Das letzte Schlüsselwort [trigger] ist extrem wichtig: Mit diesem Trigger wird später der Sound abgespielt, der Name sollte also eindeutig gewählt sein! Im Beispiel &quot;haltewunsch_summer&quot;.<br /> <br /> Speichere die Datei und OMSI weiß, dass der neue Sound existiert, aber noch nicht, wann und wie er abgespielt werden soll - das kommt im nächsten Schritt.<br /> <br /> <br /> === Die neue Skriptdatei anlegen ===<br /> <br /> Die eigene Skriptdatei enthält den Code, der ausgeführt wird, wenn ein Fahrgast den Haltewunschknopf drückt. Zwar hätte man diese Routine auch direkt in die anderen Skripte schreiben können, aber so wird das System klarer verständlich und man trennt zudem &quot;Eigenproduktion&quot; und &quot;Originalproduktion&quot;.<br /> <br /> Öffne also den Windows-Editor (Notepad), um die neue Datei zu erstellen. Füge folgenden Code ein, er wird wiederum im Anschluss erläutert.<br /> <br /> &lt;pre&gt;<br /> 'Spielt einen Summer-Ton ab, wenn ein Haltewunschknopf gedrückt wird.<br /> <br /> {macro:summer_abspielen}<br /> <br /> (L.L.haltewunsch) 1 = !<br /> (L.L.door_0) 0.1 &lt; &amp;&amp;<br /> (L.L.door_1) 0.1 &lt; &amp;&amp;<br /> (L.L.door_2) 0.1 &lt; &amp;&amp;<br /> {if}<br /> (T.L.haltewunsch_summer) <br /> {endif}<br /> <br /> {end}<br /> &lt;/pre&gt;<br /> <br /> Zuerst definieren wir den Namen der Prozedur, in OMSI heißen diese Prozeduren einfach &quot;Macros&quot;. Später kann man dieses Macro an geeigneter Stelle aufrufen und so den Code immer dann ausführen, wenn er benötigt wird. Hierzu empfehle ich noch diese Lektüre: [[Scriptsystem#Einstiegs-_und_Ausstiegspunkte.2C_Makros_und_Trigger|Einstiegs- und Ausstiegspunkte, Makros und Trigger ]]<br /> <br /> Alles, was also zwischen {macro:...} und {end} steht, wird immer durchlaufen, wenn das Macro aufgerufen wird. Jetzt zur Erläuterung des enthaltenen Codes.<br /> <br /> <br /> Der Code besteht eigentlich nur aus einer IF-Anweisung und dem Abspielen des Sounds, falls die Bedingungen alle zutreffen. Der Einfachheit halber werde ich die Zeilen einzeln erläutern.<br /> <br /> &lt;pre&gt;<br /> (L.L.haltewunsch) 1 = !<br /> &lt;/pre&gt;<br /> Wenn ein Haltewunsch registriert wurde, wird die Variable &quot;haltewunsch&quot; auf 1 gesetzt, sonst ist sie 0. Man kann also einfach abfragen, ob die Variable ungleich 1 ist, denn der Sound soll ja nur abgespielt werden, wenn die Haltewunschlampe noch nicht leuchtet. Der Code &quot;(L.L.haltewunsch) 1 =&quot; würde also TRUE zurückgeben, wenn schon ein Haltewunsch existiert, das Gegenteil wollen wir aber erreichen. &quot;!&quot; ist in OMSI die Verneinung, sie kehrt also TRUE zu FALSE um und umgekehrt.<br /> Das bedeutet für uns, die Bedingung ist dann wahr, wenn noch kein Haltewunsch vorliegt - genau das, was wir erreichen wollen.<br /> <br /> &lt;pre&gt;<br /> (L.L.door_0) 0.1 &lt; &amp;&amp;<br /> (L.L.door_1) 0.1 &lt; &amp;&amp;<br /> (L.L.door_2) 0.1 &lt; &amp;&amp;<br /> &lt;/pre&gt;<br /> <br /> Hier prüfen wir einfach, ob alle Türen geschlossen sind. Ob eine Tür offen ist, wird über die Variable &quot;door_X&quot; festgelegt. 0 bedeutet &quot;ganz geschlossen&quot;, 1 dagegen &quot;ganz geöffnet&quot;. Wir wollen nicht so streng sein und sagen: Für uns ist die Tür schon zu, wenn sie nur 10% geöffnet ist (das entspricht ja 0.1). <br /> Die &quot;&amp;&amp;&quot; bedeuten &quot;AND&quot;, d.h. damit die IF-Anweisung ausgeführt wird, müssen ALLE Bedingungen TRUE sein.<br /> <br /> &lt;pre&gt;<br /> (T.L.haltewunsch_summer)<br /> &lt;/pre&gt;<br /> Dieser Befehl schließlich führt den Soundtrigger &quot;haltewunsch_summer&quot; aus. Dieser Name entspricht dem, den wir vorhin in der Soundkonfigurationsdatei unter [trigger] angegeben haben. OMSI spielt den Sound einfach jedes Mal ab, wenn dieser Trigger augerufen wird.<br /> <br /> <br /> Damit haben wir das Gröbste geschafft und können kurz durchatmen ;-)<br /> Was jetzt noch fehlt, ist, dass OMSI dieses Makro an den geeigneten Stellen aufruft - also immer dann, wenn ein Haltewunsch von OMSI bemerkt wird. Das kommt im dritten und letzten Schritt an die Reihe.<br /> <br /> <br /> === Das Makro an geeigneter Stelle aufrufen ===<br /> <br /> Der Code für den Haltewunsch steht bei den mitgelieferten Doppeldeckern in der Skriptdatei &quot;door.osc&quot;. Für den OMSI-Türmod funktioniert die Anleitung genauso, dort müssen eben entsprechend die anderen Dateien bearbeitet werden.<br /> <br /> Öffne also die &quot;door.osc&quot; und suche die Sektion ''{trigger:int_haltewunsch}''. Hier müssen wir unser oben definiertes Macro aufrufen.<br /> <br /> Dieser Trigger wird von OMSI aufgerufen, wenn ein Fahrgast den Stopknof drückt. Direkt unter dieser Zeile fügen wir also den Macroaufruf ein, sodass die ganze Sektion so aussieht:<br /> <br /> &lt;pre&gt;<br /> {trigger:int_haltewunsch}<br /> <br /> (M.L.summer_abspielen)<br /> 1 (S.L.haltewunsch)<br /> <br /> {end}<br /> &lt;/pre&gt;<br /> <br /> Wir rufen einfach zuerst das oben selbst geschriebene Macro auf, und danach setzt OMSI die Variable &quot;haltewunsch&quot; auf 1. Würden wir die umgekehrte Reihenfolge wählen, wäre die 1. Bedingung innerhalb des Macros (s.o.) immer FALSE und der Sound würde nie abgespielt!<br /> <br /> Den gleichen Makroaufruf fügst du auch unter ''{trigger:door_haltewunsch}'' ein - dieser Trigger repräsentiert die Tür-Stopknöpfe bzw. das Trittbrett an der hinteren Tür. Und falls gewünscht, kannst du den Code darunter auch für den Kinderwagenschalter einfügen. Wie das geht, kannst du selbst ausprobieren - nur ein Tipp: ''(T.L.ev_kippschalter_ein)'' spielt den Sound ab, der das Einschalten des Kinderwagenschalters repräsentiert. Irgendwo dort sollte also der Macroaufruf stehen ;)<br /> <br /> <br /> Speichere die Änderungen dann noch ab und probiere das Ergebnis aus - es sollte funktionieren.<br /> <br /> Viel Spaß beim weiteren Erkunden der Skriptsprache ;-)<br /> <br /> <br /> [[Kategorie:Tutorials]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Script:_Ein_Haltewunsch-Summer&diff=267 2011-09-17T09:17:41Z

<p>Janniboy: /* Die Umsetzung */</p> <hr /> <div>Ich selbst habe erst vor zwei Tagen begonnen, mich mit dem OMSI-Skriptsystem näher auseinanderzusetzen, als die Dokumentation hier in der OMSI-Wiki erschien. Ich habe sogleich begonnen, ein bisschen zu experimentieren, um mir die Skriptsprache selber ein wenig beizubringen. Als eines der ersten Projekte ist ein Haltewunsch-Summer herausgekommen.<br /> <br /> Mir ist bewusst, dass dies skripttechnisch kein &quot;Wunderwerk&quot; ist - aber ich denke, für den Einsteiger ist es das ideale Projekt, denn es zeigt die Verwendung von Macros, Soundtriggern usw., ist aber gleichzeitig nicht sonderlich umfangreich. Ich entschied mich daher, hier ein Tutorial zu verfassen, um einigen Skriptern den Einstieg zu erleichtern.<br /> <br /> <br /> == Wie fangen wir an? ==<br /> <br /> <br /> === Bedingungen für das Abspielen des Sounds ===<br /> <br /> Am Anfang müssen wir uns natürlich fragen, was wir überhaupt umsetzen wollen. Ich mache jetzt mal eine Art &quot;Monolog-Brainstorming&quot;.<br /> <br /> Wir wollen, dass ein Summer ertönt, wenn die Haltewunsch-Lampe beim Fahrer angeht. Allerdings soll dies nur einmal geschehen und nicht jedes Mal, wenn ein Fahrgast den Stopknopf drückt. Des Weiteren wollen wir den Ton nicht hören, wenn wir den Kinderwagenschalter umlegen (dies ist ja auch eine Art Stopknopf). Wenn die Türen offen sind, soll der Sound ebenfalls nicht abgespielt werden.<br /> <br /> Außerdem ist es so, dass die Fahrgäste beim Aussteigen in OMSI permanent den Stopknopf drücken (bzw. über das Trittbrett laufen), denn so weiß OMSI, dass die hintere Tür noch nicht geschlossen werden darf! Wenn wir dies nicht berücksichtigen würden, würde ein Dauerton erklingen, wenn Leute aussteigen - eine der Stolperfallen, auf die ich gestoßen bin.<br /> <br /> Also kurz und knapp, welche Bedingungen für das Abspielen des Summers soll OMSI prüfen, wenn ein Haltewunsch registriert wird?<br /> <br /> * Es hat noch keiner vorher den Stopknopf gedrückt, es liegt also noch kein Haltewunsch vor.<br /> * Alle Türen müssen geschlossen sein.<br /> * Es wurde entweder ein normaler Stopknopf oder ein Stopknopf an der Tür gedrückt, der Kinderwagenschalter aber wird ignoriert.<br /> <br /> Jetzt wissen wir, was wir umsetzen wollen - aber noch nicht, wie wir das denn machen.<br /> <br /> <br /> === Was brauchen wir? ===<br /> <br /> Okay, die Abspielbedingungen sind geklärt. Spätestens jetzt sollte man sich den Artikel [[Scriptsystem]] genauer ansehen - ich werde die meisten Informationen, die hier benötigt werden, aber nochmal erläutern.<br /> <br /> Um die Übersicht zu wahren, werden wir eine '''neue Skriptdatei für dieses Projekt anlegen'''. Skriptdateien haben die Endung *.osc. Diese Datei wird den Code enthalten, der überprüft, ob der Sound abgespielt werden darf und falls ja, den Sound auch tatsächlich abspielt.<br /> <br /> Des Weiteren müssen wir für jeden Bus, der diesen Summer abspielen soll, die Skriptdatei '''in der jeweiligen *.bus-Datei registrieren'''. Die BUS-Datei enthält alle grundlegenden Informationen zum Bus und darüber hinaus auch die Verweise auf Variablenlisten, Skripts usw. - hier müssen wir OMSI also sagen, wo sich die neue Skriptdatei befindet.<br /> <br /> Außerdem müssen wir noch den '''abzuspielenden Sound definieren'''. Dies geschieht in der Soundkonfigurationsdatei (Endung *.cfg) jedes betroffenen Busses.<br /> <br /> Damit haben wir uns einen Überblick verschafft. Wir benötigen also:<br /> <br /> * Eine neue Skriptdatei mit dem Code zum Abspielen des Sounds<br /> * Ändern der *.bus-Datei, um die neue Skriptdatei bei OMSI anzumelden<br /> * Ändern der Soundkonfigurationsdatei (*.cfg), um den abzuspielenden Sound zu definieren<br /> <br /> Jetzt haben wir unser ganzes Handwerkszeug beisammen, und im nächsten Schritt geht's Stück für Stück an die Umsetzung.<br /> <br /> <br /> == Die Umsetzung ==<br /> <br /> <br /> === Den Sound dem Bus hinzufügen ===<br /> <br /> Die Datei &quot;sound_XXX.cfg&quot; im Unterverzeichnis &quot;Sound&quot; eines Bustyps enthält alle Sounds, die für den jeweiligen Bus verwendet werden. Hier müssen wir also unseren Sound auch hinzufügen, damit OMSI ihn erkennt.<br /> <br /> Kopiere als erstes den Summer-Sound (eine WAV-Datei) in das Unterverzeichnis &quot;Sound&quot; zu den anderen Sounddateien. Der Dateiname sollte natürlich aussagekräftig sein, wir wählen in diesem Fall einfach &quot;summer.wav&quot;.<br /> <br /> <br /> Jetzt öffne die &quot;sound_XXX.cfg&quot; des gewünschten Busses. Ich nehme als Beispiel den D92, das geht aber mit jedem anderen Bus auch. In diesem Fall öffne ich also die &quot;sound_D92.cfg&quot;.<br /> <br /> Scrolle bis ans Ende der Datei und füge folgenden Code hinzu, im Anschluss wird er erläutert:<br /> <br /> &lt;pre&gt;<br /> [sound]<br /> summer.wav<br /> 0.6<br /> <br /> <br /> [3d]<br /> -0.65<br /> 5.35<br /> 1.6<br /> 0.5<br /> <br /> [trigger]<br /> haltewunsch_summer<br /> &lt;/pre&gt;<br /> <br /> Nach dem Schlüsselwort [sound] folgt der Dateiname (ggf. anpassen!) und die Lautstärke (von 0 bis 1). Mit der Lautstärke musst du je nach Lautstärke der Sounddatei ein wenig experimentieren, bis der Summer laut/leise genug ist.<br /> <br /> Das Schlüsselwort [3d] definiert die Position des Sounds. Mit dem dargestellten Code befindet er sich direkt im Cockpit. Im Heck des Busses nimmt man den Summer also kaum noch wahr.<br /> <br /> Das letzte Schlüsselwort [trigger] ist extrem wichtig: Mit diesem Trigger wird später der Sound abgespielt, der Name sollte also eindeutig gewählt sein! Im Beispiel &quot;haltewunsch_summer&quot;.<br /> <br /> Speichere die Datei und OMSI weiß, dass der neue Sound existiert, aber noch nicht, wann und wie er abgespielt werden soll - das kommt im nächsten Schritt.<br /> <br /> <br /> === Die neue Skriptdatei anlegen ===<br /> <br /> Die eigene Skriptdatei enthält den Code, der ausgeführt wird, wenn ein Fahrgast den Haltewunschknopf drückt. Zwar hätte man diese Routine auch direkt in die anderen Skripte schreiben können, aber so wird das System klarer verständlich und man trennt zudem &quot;Eigenproduktion&quot; und &quot;Originalproduktion&quot;.<br /> <br /> Öffne also den Windows-Editor (Notepad), um die neue Datei zu erstellen. Füge folgenden Code ein, er wird wiederum im Anschluss erläutert.<br /> <br /> &lt;pre&gt;<br /> 'Spielt einen Summer-Ton ab, wenn ein Haltewunschknopf gedrückt wird.<br /> <br /> {macro:summer_abspielen}<br /> <br /> (L.L.haltewunsch) 1 = !<br /> (L.L.door_0) 0.1 &lt; &amp;&amp;<br /> (L.L.door_1) 0.1 &lt; &amp;&amp;<br /> (L.L.door_2) 0.1 &lt; &amp;&amp;<br /> {if}<br /> (T.L.haltewunsch_summer) <br /> {endif}<br /> <br /> {end}<br /> &lt;/pre&gt;<br /> <br /> Zuerst definieren wir den Namen der Prozedur, in OMSI heißen diese Prozeduren einfach &quot;Macros&quot;. Später kann man dieses Macro an geeigneter Stelle aufrufen und so den Code immer dann ausführen, wenn er benötigt wird. Hierzu empfehle ich noch diese Lektüre: [[Scriptsystem#Einstiegs-_und_Ausstiegspunkte.2C_Makros_und_Trigger|Einstiegs- und Ausstiegspunkte, Makros und Trigger ]]<br /> <br /> Alles, was also zwischen {macro:...} und {end} steht, wird immer durchlaufen, wenn das Macro aufgerufen wird. Jetzt zur Erläuterung des enthaltenen Codes.<br /> <br /> <br /> Der Code besteht eigentlich nur aus einer IF-Anweisung und dem Abspielen des Sounds, falls die Bedingungen alle zutreffen. Der Einfachheit halber werde ich die Zeilen einzeln erläutern.<br /> <br /> &lt;pre&gt;<br /> (L.L.haltewunsch) 1 = !<br /> &lt;/pre&gt;<br /> Wenn ein Haltewunsch registriert wurde, wird die Variable &quot;haltewunsch&quot; auf 1 gesetzt, sonst ist sie 0. Man kann also einfach abfragen, ob die Variable ungleich 1 ist, denn der Sound soll ja nur abgespielt werden, wenn die Haltewunschlampe noch nicht leuchtet. Der Code &quot;(L.L.haltewunsch) 1 =&quot; würde also TRUE zurückgeben, wenn schon ein Haltewunsch existiert, das Gegenteil wollen wir aber erreichen. &quot;!&quot; ist in OMSI die Verneinung, sie kehrt also TRUE zu FALSE um und umgekehrt.<br /> Das bedeutet für uns, die Bedingung ist dann wahr, wenn noch kein Haltewunsch vorliegt - genau das, was wir erreichen wollen.<br /> <br /> &lt;pre&gt;<br /> (L.L.door_0) 0.1 &lt; &amp;&amp;<br /> (L.L.door_1) 0.1 &lt; &amp;&amp;<br /> (L.L.door_2) 0.1 &lt; &amp;&amp;<br /> &lt;/pre&gt;<br /> <br /> Hier prüfen wir einfach, ob alle Türen geschlossen sind. Ob eine Tür offen ist, wird über die Variable &quot;door_X&quot; festgelegt. 0 bedeutet &quot;ganz geschlossen&quot;, 1 dagegen &quot;ganz geöffnet&quot;. Wir wollen nicht so streng sein und sagen: Für uns ist die Tür schon zu, wenn sie nur 10% geöffnet ist (das entspricht ja 0.1). <br /> Die &quot;&amp;&amp;&quot; bedeuten &quot;AND&quot;, d.h. damit die IF-Anweisung ausgeführt wird, müssen ALLE Bedingungen TRUE sein.<br /> <br /> &lt;pre&gt;<br /> (T.L.haltewunsch_summer)<br /> &lt;/pre&gt;<br /> Dieser Befehl schließlich führt den Soundtrigger &quot;haltewunsch_summer&quot; aus. Dieser Name entspricht dem, den wir vorhin in der Soundkonfigurationsdatei unter [trigger] angegeben haben. OMSI spielt den Sound einfach jedes Mal ab, wenn dieser Trigger augerufen wird.<br /> <br /> <br /> Damit haben wir das Gröbste geschafft und können kurz durchatmen ;-)<br /> Was jetzt noch fehlt, ist, dass OMSI dieses Makro an den geeigneten Stellen aufruft - also immer dann, wenn ein Haltewunsch von OMSI bemerkt wird. Das kommt im dritten und letzten Schritt an die Reihe.<br /> <br /> <br /> === Das Makro an geeigneter Stelle aufrufen ===<br /> <br /> Der Code für den Haltewunsch steht bei den mitgelieferten Doppeldeckern in der Skriptdatei &quot;door.osc&quot;. Für den OMSI-Türmod funktioniert die Anleitung genauso, dort müssen eben entsprechend die anderen Dateien bearbeitet werden.<br /> <br /> Öffne also die &quot;door.osc&quot; und suche die Sektion ''{trigger:int_haltewunsch}''. Hier müssen wir unser oben definiertes Macro aufrufen.<br /> <br /> Dieser Trigger wird von OMSI aufgerufen, wenn ein Fahrgast den Stopknof drückt. Direkt unter dieser Zeile fügen wir also den Macroaufruf ein, sodass die ganze Sektion so aussieht:<br /> <br /> &lt;pre&gt;<br /> {trigger:int_haltewunsch}<br /> <br /> (M.L.summer_abspielen)<br /> 1 (S.L.haltewunsch)<br /> <br /> {end}<br /> &lt;/pre&gt;<br /> <br /> Wir rufen einfach zuerst das oben selbst geschriebene Macro auf, und danach setzt OMSI die Variable &quot;haltewunsch&quot; auf 1. Würden wir die umgekehrte Reihenfolge wählen, wäre die 1. Bedingung innerhalb des Macros (s.o.) immer FALSE und der Sound würde nie abgespielt!<br /> <br /> Den gleichen Makroaufruf fügst du auch unter ''{trigger:door_haltewunsch}'' ein - dieser Trigger repräsentiert die Tür-Stopknöpfe bzw. das Trittbrett an der hinteren Tür. Und falls gewünscht, kannst du den Code darunter auch für den Kinderwagenschalter einfügen. Wie das geht, kannst du selbst ausprobieren - nur ein Tipp: ''(T.L.ev_kippschalter_ein)'' spielt den Sound ab, der das Einschalten des Kinderwagenschalters repräsentiert. Irgendwo dort sollte also der Macroaufruf stehen ;)<br /> <br /> <br /> Speichere die Änderungen dann noch ab und probiere das Ergebnis aus - es sollte funktionieren.<br /> <br /> Viel Spaß beim weiteren Erkunden der Skriptsprache ;-)<br /> <br /> <br /> [[Kategorie:Nachschlagewerk für Addon-Entwickler]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Script:_Ein_Haltewunsch-Summer&diff=266 2011-09-17T09:16:49Z

<p>Janniboy: Fettdruck geändert</p> <hr /> <div>Ich selbst habe erst vor zwei Tagen begonnen, mich mit dem OMSI-Skriptsystem näher auseinanderzusetzen, als die Dokumentation hier in der OMSI-Wiki erschien. Ich habe sogleich begonnen, ein bisschen zu experimentieren, um mir die Skriptsprache selber ein wenig beizubringen. Als eines der ersten Projekte ist ein Haltewunsch-Summer herausgekommen.<br /> <br /> Mir ist bewusst, dass dies skripttechnisch kein &quot;Wunderwerk&quot; ist - aber ich denke, für den Einsteiger ist es das ideale Projekt, denn es zeigt die Verwendung von Macros, Soundtriggern usw., ist aber gleichzeitig nicht sonderlich umfangreich. Ich entschied mich daher, hier ein Tutorial zu verfassen, um einigen Skriptern den Einstieg zu erleichtern.<br /> <br /> <br /> == Wie fangen wir an? ==<br /> <br /> <br /> === Bedingungen für das Abspielen des Sounds ===<br /> <br /> Am Anfang müssen wir uns natürlich fragen, was wir überhaupt umsetzen wollen. Ich mache jetzt mal eine Art &quot;Monolog-Brainstorming&quot;.<br /> <br /> Wir wollen, dass ein Summer ertönt, wenn die Haltewunsch-Lampe beim Fahrer angeht. Allerdings soll dies nur einmal geschehen und nicht jedes Mal, wenn ein Fahrgast den Stopknopf drückt. Des Weiteren wollen wir den Ton nicht hören, wenn wir den Kinderwagenschalter umlegen (dies ist ja auch eine Art Stopknopf). Wenn die Türen offen sind, soll der Sound ebenfalls nicht abgespielt werden.<br /> <br /> Außerdem ist es so, dass die Fahrgäste beim Aussteigen in OMSI permanent den Stopknopf drücken (bzw. über das Trittbrett laufen), denn so weiß OMSI, dass die hintere Tür noch nicht geschlossen werden darf! Wenn wir dies nicht berücksichtigen würden, würde ein Dauerton erklingen, wenn Leute aussteigen - eine der Stolperfallen, auf die ich gestoßen bin.<br /> <br /> Also kurz und knapp, welche Bedingungen für das Abspielen des Summers soll OMSI prüfen, wenn ein Haltewunsch registriert wird?<br /> <br /> * Es hat noch keiner vorher den Stopknopf gedrückt, es liegt also noch kein Haltewunsch vor.<br /> * Alle Türen müssen geschlossen sein.<br /> * Es wurde entweder ein normaler Stopknopf oder ein Stopknopf an der Tür gedrückt, der Kinderwagenschalter aber wird ignoriert.<br /> <br /> Jetzt wissen wir, was wir umsetzen wollen - aber noch nicht, wie wir das denn machen.<br /> <br /> <br /> === Was brauchen wir? ===<br /> <br /> Okay, die Abspielbedingungen sind geklärt. Spätestens jetzt sollte man sich den Artikel [[Scriptsystem]] genauer ansehen - ich werde die meisten Informationen, die hier benötigt werden, aber nochmal erläutern.<br /> <br /> Um die Übersicht zu wahren, werden wir eine '''neue Skriptdatei für dieses Projekt anlegen'''. Skriptdateien haben die Endung *.osc. Diese Datei wird den Code enthalten, der überprüft, ob der Sound abgespielt werden darf und falls ja, den Sound auch tatsächlich abspielt.<br /> <br /> Des Weiteren müssen wir für jeden Bus, der diesen Summer abspielen soll, die Skriptdatei '''in der jeweiligen *.bus-Datei registrieren'''. Die BUS-Datei enthält alle grundlegenden Informationen zum Bus und darüber hinaus auch die Verweise auf Variablenlisten, Skripts usw. - hier müssen wir OMSI also sagen, wo sich die neue Skriptdatei befindet.<br /> <br /> Außerdem müssen wir noch den '''abzuspielenden Sound definieren'''. Dies geschieht in der Soundkonfigurationsdatei (Endung *.cfg) jedes betroffenen Busses.<br /> <br /> Damit haben wir uns einen Überblick verschafft. Wir benötigen also:<br /> <br /> * Eine neue Skriptdatei mit dem Code zum Abspielen des Sounds<br /> * Ändern der *.bus-Datei, um die neue Skriptdatei bei OMSI anzumelden<br /> * Ändern der Soundkonfigurationsdatei (*.cfg), um den abzuspielenden Sound zu definieren<br /> <br /> Jetzt haben wir unser ganzes Handwerkszeug beisammen, und im nächsten Schritt geht's Stück für Stück an die Umsetzung.<br /> <br /> == Die Umsetzung ==<br /> <br /> <br /> === Den Sound dem Bus hinzufügen ===<br /> <br /> Die Datei &quot;sound_XXX.cfg&quot; im Unterverzeichnis &quot;Sound&quot; eines Bustyps enthält alle Sounds, die für den jeweiligen Bus verwendet werden. Hier müssen wir also unseren Sound auch hinzufügen, damit OMSI ihn erkennt.<br /> <br /> Kopiere als erstes den Summer-Sound (eine WAV-Datei) in das Unterverzeichnis &quot;Sound&quot; zu den anderen Sounddateien. Der Dateiname sollte natürlich aussagekräftig sein, wir wählen in diesem Fall einfach &quot;summer.wav&quot;.<br /> <br /> <br /> Jetzt öffne die &quot;sound_XXX.cfg&quot; des gewünschten Busses. Ich nehme als Beispiel den D92, das geht aber mit jedem anderen Bus auch. In diesem Fall öffne ich also die &quot;sound_D92.cfg&quot;.<br /> <br /> Scrolle bis ans Ende der Datei und füge folgenden Code hinzu, im Anschluss wird er erläutert:<br /> <br /> &lt;pre&gt;<br /> [sound]<br /> summer.wav<br /> 0.6<br /> <br /> <br /> [3d]<br /> -0.65<br /> 5.35<br /> 1.6<br /> 0.5<br /> <br /> [trigger]<br /> haltewunsch_summer<br /> &lt;/pre&gt;<br /> <br /> Nach dem Schlüsselwort [sound] folgt der Dateiname (ggf. anpassen!) und die Lautstärke (von 0 bis 1). Mit der Lautstärke musst du je nach Lautstärke der Sounddatei ein wenig experimentieren, bis der Summer laut/leise genug ist.<br /> <br /> Das Schlüsselwort [3d] definiert die Position des Sounds. Mit dem dargestellten Code befindet er sich direkt im Cockpit. Im Heck des Busses nimmt man den Summer also kaum noch wahr.<br /> <br /> Das letzte Schlüsselwort [trigger] ist extrem wichtig: Mit diesem Trigger wird später der Sound abgespielt, der Name sollte also eindeutig gewählt sein! Im Beispiel &quot;haltewunsch_summer&quot;.<br /> <br /> Speichere die Datei und OMSI weiß, dass der neue Sound existiert, aber noch nicht, wann und wie er abgespielt werden soll - das kommt im nächsten Schritt.<br /> <br /> <br /> === Die neue Skriptdatei anlegen ===<br /> <br /> Die eigene Skriptdatei enthält den Code, der ausgeführt wird, wenn ein Fahrgast den Haltewunschknopf drückt. Zwar hätte man diese Routine auch direkt in die anderen Skripte schreiben können, aber so wird das System klarer verständlich und man trennt zudem &quot;Eigenproduktion&quot; und &quot;Originalproduktion&quot;.<br /> <br /> Öffne also den Windows-Editor (Notepad), um die neue Datei zu erstellen. Füge folgenden Code ein, er wird wiederum im Anschluss erläutert.<br /> <br /> &lt;pre&gt;<br /> 'Spielt einen Summer-Ton ab, wenn ein Haltewunschknopf gedrückt wird.<br /> <br /> {macro:summer_abspielen}<br /> <br /> (L.L.haltewunsch) 1 = !<br /> (L.L.door_0) 0.1 &lt; &amp;&amp;<br /> (L.L.door_1) 0.1 &lt; &amp;&amp;<br /> (L.L.door_2) 0.1 &lt; &amp;&amp;<br /> {if}<br /> (T.L.haltewunsch_summer) <br /> {endif}<br /> <br /> {end}<br /> &lt;/pre&gt;<br /> <br /> Zuerst definieren wir den Namen der Prozedur, in OMSI heißen diese Prozeduren einfach &quot;Macros&quot;. Später kann man dieses Macro an geeigneter Stelle aufrufen und so den Code immer dann ausführen, wenn er benötigt wird. Hierzu empfehle ich noch diese Lektüre: [[Scriptsystem#Einstiegs-_und_Ausstiegspunkte.2C_Makros_und_Trigger|Einstiegs- und Ausstiegspunkte, Makros und Trigger ]]<br /> <br /> Alles, was also zwischen {macro:...} und {end} steht, wird immer durchlaufen, wenn das Macro aufgerufen wird. Jetzt zur Erläuterung des enthaltenen Codes.<br /> <br /> <br /> Der Code besteht eigentlich nur aus einer IF-Anweisung und dem Abspielen des Sounds, falls die Bedingungen alle zutreffen. Der Einfachheit halber werde ich die Zeilen einzeln erläutern.<br /> <br /> &lt;pre&gt;<br /> (L.L.haltewunsch) 1 = !<br /> &lt;/pre&gt;<br /> Wenn ein Haltewunsch registriert wurde, wird die Variable &quot;haltewunsch&quot; auf 1 gesetzt, sonst ist sie 0. Man kann also einfach abfragen, ob die Variable ungleich 1 ist, denn der Sound soll ja nur abgespielt werden, wenn die Haltewunschlampe noch nicht leuchtet. Der Code &quot;(L.L.haltewunsch) 1 =&quot; würde also TRUE zurückgeben, wenn schon ein Haltewunsch existiert, das Gegenteil wollen wir aber erreichen. &quot;!&quot; ist in OMSI die Verneinung, sie kehrt also TRUE zu FALSE um und umgekehrt.<br /> Das bedeutet für uns, die Bedingung ist dann wahr, wenn noch kein Haltewunsch vorliegt - genau das, was wir erreichen wollen.<br /> <br /> &lt;pre&gt;<br /> (L.L.door_0) 0.1 &lt; &amp;&amp;<br /> (L.L.door_1) 0.1 &lt; &amp;&amp;<br /> (L.L.door_2) 0.1 &lt; &amp;&amp;<br /> &lt;/pre&gt;<br /> <br /> Hier prüfen wir einfach, ob alle Türen geschlossen sind. Ob eine Tür offen ist, wird über die Variable &quot;door_X&quot; festgelegt. 0 bedeutet &quot;ganz geschlossen&quot;, 1 dagegen &quot;ganz geöffnet&quot;. Wir wollen nicht so streng sein und sagen: Für uns ist die Tür schon zu, wenn sie nur 10% geöffnet ist (das entspricht ja 0.1). <br /> Die &quot;&amp;&amp;&quot; bedeuten &quot;AND&quot;, d.h. damit die IF-Anweisung ausgeführt wird, müssen ALLE Bedingungen TRUE sein.<br /> <br /> &lt;pre&gt;<br /> (T.L.haltewunsch_summer)<br /> &lt;/pre&gt;<br /> Dieser Befehl schließlich führt den Soundtrigger &quot;haltewunsch_summer&quot; aus. Dieser Name entspricht dem, den wir vorhin in der Soundkonfigurationsdatei unter [trigger] angegeben haben. OMSI spielt den Sound einfach jedes Mal ab, wenn dieser Trigger augerufen wird.<br /> <br /> <br /> Damit haben wir das Gröbste geschafft und können kurz durchatmen ;-)<br /> Was jetzt noch fehlt, ist, dass OMSI dieses Makro an den geeigneten Stellen aufruft - also immer dann, wenn ein Haltewunsch von OMSI bemerkt wird. Das kommt im dritten und letzten Schritt an die Reihe.<br /> <br /> <br /> === Das Makro an geeigneter Stelle aufrufen ===<br /> <br /> Der Code für den Haltewunsch steht bei den mitgelieferten Doppeldeckern in der Skriptdatei &quot;door.osc&quot;. Für den OMSI-Türmod funktioniert die Anleitung genauso, dort müssen eben entsprechend die anderen Dateien bearbeitet werden.<br /> <br /> Öffne also die &quot;door.osc&quot; und suche die Sektion ''{trigger:int_haltewunsch}''. Hier müssen wir unser oben definiertes Macro aufrufen.<br /> <br /> Dieser Trigger wird von OMSI aufgerufen, wenn ein Fahrgast den Stopknof drückt. Direkt unter dieser Zeile fügen wir also den Macroaufruf ein, sodass die ganze Sektion so aussieht:<br /> <br /> &lt;pre&gt;<br /> {trigger:int_haltewunsch}<br /> <br /> (M.L.summer_abspielen)<br /> 1 (S.L.haltewunsch)<br /> <br /> {end}<br /> &lt;/pre&gt;<br /> <br /> Wir rufen einfach zuerst das oben selbst geschriebene Macro auf, und danach setzt OMSI die Variable &quot;haltewunsch&quot; auf 1. Würden wir die umgekehrte Reihenfolge wählen, wäre die 1. Bedingung innerhalb des Macros (s.o.) immer FALSE und der Sound würde nie abgespielt!<br /> <br /> Den gleichen Makroaufruf fügst du auch unter ''{trigger:door_haltewunsch}'' ein - dieser Trigger repräsentiert die Tür-Stopknöpfe bzw. das Trittbrett an der hinteren Tür. Und falls gewünscht, kannst du den Code darunter auch für den Kinderwagenschalter einfügen. Wie das geht, kannst du selbst ausprobieren - nur ein Tipp: ''(T.L.ev_kippschalter_ein)'' spielt den Sound ab, der das Einschalten des Kinderwagenschalters repräsentiert. Irgendwo dort sollte also der Macroaufruf stehen ;)<br /> <br /> <br /> Speichere die Änderungen dann noch ab und probiere das Ergebnis aus - es sollte funktionieren.<br /> <br /> Viel Spaß beim weiteren Erkunden der Skriptsprache ;-)<br /> <br /> <br /> [[Kategorie:Nachschlagewerk für Addon-Entwickler]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Script:_Ein_Haltewunsch-Summer&diff=265 2011-09-17T09:11:08Z

<p>Janniboy: Die Seite wurde neu angelegt: „Ich selbst habe erst vor zwei Tagen begonnen, mich mit dem OMSI-Skriptsystem näher auseinanderzusetzen, als die Dokumentation hier in der OMSI-Wiki erschien. Ich…“</p> <hr /> <div>Ich selbst habe erst vor zwei Tagen begonnen, mich mit dem OMSI-Skriptsystem näher auseinanderzusetzen, als die Dokumentation hier in der OMSI-Wiki erschien. Ich habe sogleich begonnen, ein bisschen zu experimentieren, um mir die Skriptsprache selber ein wenig beizubringen. Als eines der ersten Projekte ist ein Haltewunsch-Summer herausgekommen.<br /> <br /> Mir ist bewusst, dass dies skripttechnisch kein &quot;Wunderwerk&quot; ist - aber ich denke, für den Einsteiger ist es das ideale Projekt, denn es zeigt die Verwendung von Macros, Soundtriggern usw., ist aber gleichzeitig nicht sonderlich umfangreich. Ich entschied mich daher, hier ein Tutorial zu verfassen, um einigen Skriptern den Einstieg zu erleichtern.<br /> <br /> <br /> == Wie fangen wir an? ==<br /> <br /> <br /> === Bedingungen für das Abspielen des Sounds ===<br /> <br /> Am Anfang müssen wir uns natürlich fragen, was wir überhaupt umsetzen wollen. Ich mache jetzt mal eine Art &quot;Monolog-Brainstorming&quot;.<br /> <br /> Wir wollen, dass ein Summer ertönt, wenn die Haltewunsch-Lampe beim Fahrer angeht. Allerdings soll dies nur einmal geschehen und nicht jedes Mal, wenn ein Fahrgast den Stopknopf drückt. Des Weiteren wollen wir den Ton nicht hören, wenn wir den Kinderwagenschalter umlegen (dies ist ja auch eine Art Stopknopf). Wenn die Türen offen sind, soll der Sound ebenfalls nicht abgespielt werden.<br /> <br /> Außerdem ist es so, dass die Fahrgäste beim Aussteigen in OMSI permanent den Stopknopf drücken (bzw. über das Trittbrett laufen), denn so weiß OMSI, dass die hintere Tür noch nicht geschlossen werden darf! Wenn wir dies nicht berücksichtigen würden, würde ein Dauerton erklingen, wenn Leute aussteigen - eine der Stolperfallen, auf die ich gestoßen bin.<br /> <br /> Also kurz und knapp, welche Bedingungen für das Abspielen des Summers soll OMSI prüfen, wenn ein Haltewunsch registriert wird?<br /> <br /> * Es hat noch keiner vorher den Stopknopf gedrückt, es liegt also noch kein Haltewunsch vor.<br /> * Alle Türen müssen geschlossen sein.<br /> * Es wurde entweder ein normaler Stopknopf oder ein Stopknopf an der Tür gedrückt, der Kinderwagenschalter aber wird ignoriert.<br /> <br /> Jetzt wissen wir, was wir umsetzen wollen - aber noch nicht, wie wir das denn machen.<br /> <br /> <br /> === Was brauchen wir? ===<br /> <br /> Okay, die Abspielbedingungen sind geklärt. Spätestens jetzt sollte man sich den Artikel [[Scriptsystem]] genauer ansehen - ich werde die meisten Informationen, die hier benötigt werden, aber nochmal erläutern.<br /> <br /> Um die Übersicht zu wahren, werden wir eine '''neue Skriptdatei für dieses Projekt anlegen'''. Skriptdateien haben die Endung *.osc. Diese Datei wird den Code enthalten, der überprüft, ob der Sound abgespielt werden darf und falls ja, den Sound auch tatsächlich abspielt.<br /> <br /> Des Weiteren müssen wir für jeden Bus, der diesen Summer abspielen soll, die Skriptdatei '''in der jeweiligen *.bus-Datei registrieren'''. Die BUS-Datei enthält alle grundlegenden Informationen zum Bus und darüber hinaus auch die Verweise auf Variablenlisten, Skripts usw. - hier müssen wir OMSI also sagen, wo sich die neue Skriptdatei befindet.<br /> <br /> Außerdem müssen wir noch den abzuspielenden Sound definieren. Dies geschieht in der Soundkonfigurationsdatei (Endung *.cfg) jedes betroffenen Busses.<br /> <br /> Damit haben wir uns einen Überblick verschafft. Wir benötigen also:<br /> <br /> * Eine neue Skriptdatei mit dem Code zum Abspielen des Sounds<br /> * Ändern der *.bus-Datei, um die neue Skriptdatei bei OMSI anzumelden<br /> * Ändern der Soundkonfigurationsdatei (*.cfg), um den abzuspielenden Sound zu definieren<br /> <br /> Jetzt haben wir unser ganzes Handwerkszeug beisammen, und im nächsten Schritt geht's Stück für Stück an die Umsetzung.<br /> <br /> <br /> == Die Umsetzung ==<br /> <br /> <br /> === Den Sound dem Bus hinzufügen ===<br /> <br /> Die Datei &quot;sound_XXX.cfg&quot; im Unterverzeichnis &quot;Sound&quot; eines Bustyps enthält alle Sounds, die für den jeweiligen Bus verwendet werden. Hier müssen wir also unseren Sound auch hinzufügen, damit OMSI ihn erkennt.<br /> <br /> Kopiere als erstes den Summer-Sound (eine WAV-Datei) in das Unterverzeichnis &quot;Sound&quot; zu den anderen Sounddateien. Der Dateiname sollte natürlich aussagekräftig sein, wir wählen in diesem Fall einfach &quot;summer.wav&quot;.<br /> <br /> <br /> Jetzt öffne die &quot;sound_XXX.cfg&quot; des gewünschten Busses. Ich nehme als Beispiel den D92, das geht aber mit jedem anderen Bus auch. In diesem Fall öffne ich also die &quot;sound_D92.cfg&quot;.<br /> <br /> Scrolle bis ans Ende der Datei und füge folgenden Code hinzu, im Anschluss wird er erläutert:<br /> <br /> &lt;pre&gt;<br /> [sound]<br /> summer.wav<br /> 0.6<br /> <br /> <br /> [3d]<br /> -0.65<br /> 5.35<br /> 1.6<br /> 0.5<br /> <br /> [trigger]<br /> haltewunsch_summer<br /> &lt;/pre&gt;<br /> <br /> Nach dem Schlüsselwort [sound] folgt der Dateiname (ggf. anpassen!) und die Lautstärke (von 0 bis 1). Mit der Lautstärke musst du je nach Lautstärke der Sounddatei ein wenig experimentieren, bis der Summer laut/leise genug ist.<br /> <br /> Das Schlüsselwort [3d] definiert die Position des Sounds. Mit dem dargestellten Code befindet er sich direkt im Cockpit. Im Heck des Busses nimmt man den Summer also kaum noch wahr.<br /> <br /> Das letzte Schlüsselwort [trigger] ist extrem wichtig: Mit diesem Trigger wird später der Sound abgespielt, der Name sollte also eindeutig gewählt sein! Im Beispiel &quot;haltewunsch_summer&quot;.<br /> <br /> Speichere die Datei und OMSI weiß, dass der neue Sound existiert, aber noch nicht, wann und wie er abgespielt werden soll - das kommt im nächsten Schritt.<br /> <br /> <br /> === Die neue Skriptdatei anlegen ===<br /> <br /> Die eigene Skriptdatei enthält den Code, der ausgeführt wird, wenn ein Fahrgast den Haltewunschknopf drückt. Zwar hätte man diese Routine auch direkt in die anderen Skripte schreiben können, aber so wird das System klarer verständlich und man trennt zudem &quot;Eigenproduktion&quot; und &quot;Originalproduktion&quot;.<br /> <br /> Öffne also den Windows-Editor (Notepad), um die neue Datei zu erstellen. Füge folgenden Code ein, er wird wiederum im Anschluss erläutert.<br /> <br /> &lt;pre&gt;<br /> 'Spielt einen Summer-Ton ab, wenn ein Haltewunschknopf gedrückt wird.<br /> <br /> {macro:summer_abspielen}<br /> <br /> (L.L.haltewunsch) 1 = !<br /> (L.L.door_0) 0.1 &lt; &amp;&amp;<br /> (L.L.door_1) 0.1 &lt; &amp;&amp;<br /> (L.L.door_2) 0.1 &lt; &amp;&amp;<br /> {if}<br /> (T.L.haltewunsch_summer) <br /> {endif}<br /> <br /> {end}<br /> &lt;/pre&gt;<br /> <br /> Zuerst definieren wir den Namen der Prozedur, in OMSI heißen diese Prozeduren einfach &quot;Macros&quot;. Später kann man dieses Macro an geeigneter Stelle aufrufen und so den Code immer dann ausführen, wenn er benötigt wird. Hierzu empfehle ich noch diese Lektüre: [[Scriptsystem#Einstiegs-_und_Ausstiegspunkte.2C_Makros_und_Trigger|Einstiegs- und Ausstiegspunkte, Makros und Trigger ]]<br /> <br /> Alles, was also zwischen {macro:...} und {end} steht, wird immer durchlaufen, wenn das Macro aufgerufen wird. Jetzt zur Erläuterung des enthaltenen Codes.<br /> <br /> <br /> Der Code besteht eigentlich nur aus einer IF-Anweisung und dem Abspielen des Sounds, falls die Bedingungen alle zutreffen. Der Einfachheit halber werde ich die Zeilen einzeln erläutern.<br /> <br /> &lt;pre&gt;<br /> (L.L.haltewunsch) 1 = !<br /> &lt;/pre&gt;<br /> Wenn ein Haltewunsch registriert wurde, wird die Variable &quot;haltewunsch&quot; auf 1 gesetzt, sonst ist sie 0. Man kann also einfach abfragen, ob die Variable ungleich 1 ist, denn der Sound soll ja nur abgespielt werden, wenn die Haltewunschlampe noch nicht leuchtet. Der Code &quot;(L.L.haltewunsch) 1 =&quot; würde also TRUE zurückgeben, wenn schon ein Haltewunsch existiert, das Gegenteil wollen wir aber erreichen. &quot;!&quot; ist in OMSI die Verneinung, sie kehrt also TRUE zu FALSE um und umgekehrt.<br /> Das bedeutet für uns, die Bedingung ist dann wahr, wenn noch kein Haltewunsch vorliegt - genau das, was wir erreichen wollen.<br /> <br /> &lt;pre&gt;<br /> (L.L.door_0) 0.1 &lt; &amp;&amp;<br /> (L.L.door_1) 0.1 &lt; &amp;&amp;<br /> (L.L.door_2) 0.1 &lt; &amp;&amp;<br /> &lt;/pre&gt;<br /> <br /> Hier prüfen wir einfach, ob alle Türen geschlossen sind. Ob eine Tür offen ist, wird über die Variable &quot;door_X&quot; festgelegt. 0 bedeutet &quot;ganz geschlossen&quot;, 1 dagegen &quot;ganz geöffnet&quot;. Wir wollen nicht so streng sein und sagen: Für uns ist die Tür schon zu, wenn sie nur 10% geöffnet ist (das entspricht ja 0.1). <br /> Die &quot;&amp;&amp;&quot; bedeuten &quot;AND&quot;, d.h. damit die IF-Anweisung ausgeführt wird, müssen ALLE Bedingungen TRUE sein.<br /> <br /> &lt;pre&gt;<br /> (T.L.haltewunsch_summer)<br /> &lt;/pre&gt;<br /> Dieser Befehl schließlich führt den Soundtrigger &quot;haltewunsch_summer&quot; aus. Dieser Name entspricht dem, den wir vorhin in der Soundkonfigurationsdatei unter [trigger] angegeben haben. OMSI spielt den Sound einfach jedes Mal ab, wenn dieser Trigger augerufen wird.<br /> <br /> <br /> Damit haben wir das Gröbste geschafft und können kurz durchatmen ;-)<br /> Was jetzt noch fehlt, ist, dass OMSI dieses Makro an den geeigneten Stellen aufruft - also immer dann, wenn ein Haltewunsch von OMSI bemerkt wird. Das kommt im dritten und letzten Schritt an die Reihe.<br /> <br /> <br /> === Das Makro an geeigneter Stelle aufrufen ===<br /> <br /> Der Code für den Haltewunsch steht bei den mitgelieferten Doppeldeckern in der Skriptdatei &quot;door.osc&quot;. Für den OMSI-Türmod funktioniert die Anleitung genauso, dort müssen eben entsprechend die anderen Dateien bearbeitet werden.<br /> <br /> Öffne also die &quot;door.osc&quot; und suche die Sektion ''{trigger:int_haltewunsch}''. Hier müssen wir unser oben definiertes Macro aufrufen.<br /> <br /> Dieser Trigger wird von OMSI aufgerufen, wenn ein Fahrgast den Stopknof drückt. Direkt unter dieser Zeile fügen wir also den Macroaufruf ein, sodass die ganze Sektion so aussieht:<br /> <br /> &lt;pre&gt;<br /> {trigger:int_haltewunsch}<br /> <br /> (M.L.summer_abspielen)<br /> 1 (S.L.haltewunsch)<br /> <br /> {end}<br /> &lt;/pre&gt;<br /> <br /> Wir rufen einfach zuerst das oben selbst geschriebene Macro auf, und danach setzt OMSI die Variable &quot;haltewunsch&quot; auf 1. Würden wir die umgekehrte Reihenfolge wählen, wäre die 1. Bedingung innerhalb des Macros (s.o.) immer FALSE und der Sound würde nie abgespielt!<br /> <br /> Den gleichen Makroaufruf fügst du auch unter ''{trigger:door_haltewunsch}'' ein - dieser Trigger repräsentiert die Tür-Stopknöpfe bzw. das Trittbrett an der hinteren Tür. Und falls gewünscht, kannst du den Code darunter auch für den Kinderwagenschalter einfügen. Wie das geht, kannst du selbst ausprobieren - nur ein Tipp: ''(T.L.ev_kippschalter_ein)'' spielt den Sound ab, der das Einschalten des Kinderwagenschalters repräsentiert. Irgendwo dort sollte also der Macroaufruf stehen ;)<br /> <br /> <br /> Speichere die Änderungen dann noch ab und probiere das Ergebnis aus - es sollte funktionieren.<br /> <br /> Viel Spaß beim weiteren Erkunden der Skriptsprache ;-)<br /> <br /> <br /> [[Kategorie:Nachschlagewerk für Addon-Entwickler]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=OMSI_Addon_Tester_(OAT)&diff=166 2011-09-14T06:50:10Z

<p>Janniboy: Grammatik-Fehler korrigiert</p> <hr /> <div>== Gründung und Zielsetzung ==<br /> <br /> Die OMSI Addon Tester - kurz &quot;OAT&quot; - sind ein Zusammenschluss von Mitgliedern aus dem offiziellen OMSI-Forum.<br /> Gegründet wurde die OAT am 30. April 2011 durch die OMSI-Forenmitglieder Yufa, Felix01 und Janniboy ([http://omnibussimulator.forumieren.com/t4415p60-prufung-neuer-maps Link zum Thread]).<br /> <br /> Die OAT ([http://www.oat-online.de www.oat-online.de]) hat es sich zum Ziel gesetzt, kostenlose OMSI-Addons von Privatpersonen sachlich und objektiv zu bewerten.<br /> Damit soll einerseits interessierten Benutzern bereits vor dem Download ein Einblick darin geben werden, was sie mit dem Addon erwartet; andererseits soll so dazu beigetragen werden, dass sich die Qualität von OMSI-Addons mit der Zeit steigert.<br /> <br /> All das fasst die OAT in einem Statement-Satz zusammen:<br /> ''&quot;Wir möchten die Autoren aktiv dabei unterstützen, ihre Addons zu perfektionieren.&quot;''<br /> <br /> Alle Mitarbeiter der OAT arbeiten ehrenamtlich, jeder kann sich bewerben. Welche Kriterien ein Addon-Tester erfüllen sollte und was von ihm erwartet wird, kann [http://oat-online.de/info_bewerben.php hier] nachgelesen werden.<br /> <br /> == Testverfahren und Bewertung ==<br /> <br /> Interessierte Addon-Entwickler können ihr Addon direkt über das [http://oat-online.de/einsenden.php Online-Formular] einsenden.<br /> <br /> [[Datei:OATIconExplanation.jpg‎|right|Erklärung zum OAT-Testsiegel]]Die OAT veröffentlicht den jeweiligen Testbericht nach der Testphase auf der offiziellen Website [http://www.oat-online.de www.oat-online.de]. Daraus gehen zum Einen die Einzelwertungen, zum anderen die wichtigsten Punkte (Positiv- und Negativlisten) sowie die Gesamtpunktzahl des Addons hervor. Bei allen Tests soll größtmögliche Transparenz walten. Daher wurden auf der Website außerdem Leitfäden und Empfehlungen veröffentlicht. Nach der Meinung der OAT sind die dort genannten Kriterien elementar für &quot;das perfekte Addon&quot;, und sie sind zugleich auch die Bewertungsmaßstäbe für Testsphasen.<br /> <br /> Die maximal erreichbare Punktzahl beträgt für alle Einsendungen 100 Punkte. Je nach Art des Addons werden die Kriterien verschieden gewählt und teilweise auch gewichtet, um den vielfältigen Anforderungen gerecht zu werden. Die erreichte Punktzahl wird im OAT-Testsiegel (siehe Beispielbild) dargestellt. Mit diesem Siegel kann der Entwickler des Addons überall für sein Addon &quot;werben&quot; und somit zeigen, dass er sich um Qualität bemüht.<br /> <br /> == Weblinks ==<br /> [http://www.oat-online.de www.oat-online.de]<br /> <br /> [[Kategorie:Anschlussprojekte]]<br /> <br /> [[en:OMSI Addon Testers (OAT)]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Hauptseite&diff=165 2011-09-13T19:17:12Z

<p>Janniboy: AM-Artikelprojekt aus der ToDo-Liste ausgetragen</p> <hr /> <div>&lt;font style=&quot;font-size:1.2em;&quot;&gt;<br /> '''Herzlich willkommen auf der deutschen Version von OMSIWiki!'''<br /> <br /> Hier geht's direkt zu einer der Hauptkategorien:<br /> <br /> * [[:Kategorie:Busfahren in OMSI|Busfahren in OMSI]]<br /> * Entwicklung von Addons:<br /> ** [[:Kategorie:Nachschlagewerk für Addon-Entwickler|Nachschlagewerk]]<br /> ** [[:Kategorie:Tutorials für Addon-Entwickler|Tutorials]]<br /> ** [[:Kategorie:Tipps und Tricks für Addon-Entwickler|Tipps und Tricks]]<br /> * [[:Kategorie:Anschlussprojekte|Anschlussprojekte (z.B. Addon-Manager, OAT)]]<br /> * [[:Kategorie:Addon-Präsentationen|Addon-Präsentationen]]<br /> * [[:Kategorie:Hintergrundinformationen|Hintergrundinformationen]]<br /> <br /> '''Achtung: Vor dem Verfassen eigener Beiträge bitte zuerst die Regeln lesen!''' Weiter unten gibt es noch eine Ultra-Kurzanleitung für Neulinge.<br /> <br /> ''Aktuell in Arbeit:''<br /> &lt;/font&gt;<br /> <br /> * ''&lt; Geplante Artikel hier eintragen &gt;''<br /> <br /> <br /> <br /> ----<br /> <br /> == Idee ==<br /> <br /> Wir Entwickler von OMSI haben OMSIWiki eingerichtet, um eine bessere Plattform für alle Arten von Informationen rund um OMSI zu erhalten. Folgende Themengebiete sind von uns vorläufig vorgesehen:<br /> <br /> * Präsentation von Hintergrundinformationen über das Addon-Design von unserer Seite (Objekt- und Fahrzeugbar, Soundengine, Scriptengine usw.)<br /> * Tipps und Tricks oder auch ganze Tutorials von Usern z.B. zum Erstellen von Repaints oder Mapbau würden unsere Kernthemen abrunden. Entweder als Ergänzung unserer oder als weiterreichende Artikel.<br /> * Die Bedienung von OMSI und insbesondere der Busse könnte ein weiterer Themenkomplex sein. Zwar gibt es natürlich ein Handbuch für OMSI, dennoch gibt es vieleicht die eine oder andere Sache, die ausführlicher erklärt werden soll. Hier werden wir uns allerdings etwas zurückhalten.<br /> * Weiterhin könnten hier bewährte Anschlussprojekte zu OMSI präsentiert werden, z.B. OAT oder der Addon-Manager. Höchstwahrscheinlich werden die zugehörigen Artikel dann von den Leitern oder treuesten Fans dieser Projekte geschrieben, wir werden uns hier ebenfalls zurückhalten.<br /> * Ähnlich hierzu haben wir nichts gegen eine hochqualitative Präsentation von komplexen Addons; denkbar wäre hier z.B. die Bedienungsanleitung eines Addon-Busses oder die Beschreibung und Hinweise für die Fahrt durch eine Addon-Karte mit Fahrplänen und/oder Karten. Wo wir hier allerdings die Grenze setzen, steht noch nicht fest. Insbesondere sollen hier keine &quot;Mini-Artikel&quot; entstehen, wo nur ein Screenshot von einem Repaint und ein Download-Link präsentiert wird!<br /> * Selbstverständlich dürfen hier auch gerne Hintergrundinformationen zu unserer Strecke oder unseren Bussen oder aber zu Addons gegeben werden (wie sah Spandau in der Realität 1989 aus? Wie wurde damals in Berlin Bus gefahren?). Es sollte sich aber um abgeschlossene und ernsthaft geschriebene Artikel handeln und es sollte definitiv ein Bezug zu OMSI vorhanden sein! Also keine schnell hingeschriebenen Tagesberichte von irgendeinem Busunternehmen, was keiner kennt und was auch nicht in OMSI mindestens als Addon simuliert werden kann.<br /> <br /> == Regeln ==<br /> <br /> === Ist das Thema hier erwünscht? ===<br /> <br /> Der Idee von OMSIWiki entsprechend sollte jeder Artikel letztlich in eine der oben genannten Kategorien passen!<br /> <br /> === &quot;Goldene Regel&quot; ===<br /> <br /> Zunächst die '''&quot;goldene Regel&quot;''': Bevor ein Artikel verfasst oder geändert wird, sollte stets geschaut werden, ob sich an den Regeln etwas geändert hat! Gerade in der Anfangszeit wird es sicher vorkommen, dass sich Regeln ändern oder neue hinzukommen.<br /> <br /> === Erwünscht ===<br /> <br /> * Wenn ihr einen kleinen oder großen Fehler entdeckt (auch in einem unserer Artikel!), dann darf ihn jeder korrigieren! Aber nur, wenn ihr euch dabei auch sicher seid.<br /> * Ihr findet einen Artikel z.B. im Addon-Handbuch zu trocken? Dann dürft ihr gerne ein kleines Beispiel ergänzen! Von mir weiß ich z.B., dass die Anschauung und Klarheit leidet, wenn ich viele und lange Texte schreibe!<br /> * Ihr findet einen Fachbegriff, der nicht erklärt wird? Wenn es ein bisher nicht erklärter Begriff von OMSI ist, dürft ihr gerne einen Artikel anfertigen und ihn mit dem Fachbegriff verlinken; handelt es sich um einen allgemeinen Fachbegriff, dann reicht meist ein externer Link zu einem entsprechenden Artikel z.B. in der Wikipedia aus.<br /> * Um zu vermeiden, dass euch bereits jemand anderes &quot;dazwischen funkt&quot;, obwohl euer Artikel noch gar nicht fertig ist, ergänzt bitte hierzu oben den Hinweis: &quot;''Hinweis: Dieser Artikel befindet sich noch im Aufbau!''&quot;. Dadurch wird auch vermieden, dass der unter Umständen erst halbfertige Artikel schon von jemandem übersetzt wird, sodass nach Fertigstellung der deutschen Version die englische noch unvollständig ist.<br /> * Wenn euer Artikel auch ein englischsprachiges Pendant hat, dann verknüpft ihn bitte! Ein Blick ans Ende des Quelltextes ''dieser'' Seite zeigt euch, wie das geht! Hat er jedoch ''kein'' Pendant und muss demnach in der englischen OMSIWiki noch angelegt werden, so wäre ein Hinweis ganz oben nicht schlecht: &quot;''Hinweis: Dieser Artikel wurde noch nicht ins Englische übersetzt!''&quot; oder &quot;''Hinweis: Die englische Version muss noch aktualisiert werden!''&quot;<br /> * Wenn ihr Spaß am Übersetzen habt, dann könnt ihr eine sehr wertvolle Hilfe für OMSIWiki sein! Wenn ihr einen dieser Hinweise entdeckt, scheut euch nicht, den Artikel in die englische OMSIWiki einzupflegen! Ihr solltet danach aber den Original-Autor informieren (damit er die Gelegenheit hat, einmal drüber zu schauen) und dann natürlich die beidseitige Verlinkung mit der deutschen Seite vornehmen und den Hinweis entfernen.<br /> <br /> === Unerwünscht ===<br /> <br /> * '''Ganz wichtig: Der Name des Artikels muss wohlüberlegt gewählt werden, weil man den nicht mal eben ändern kann! Wer hier grob fahrlässig schlampt, fliegt raus!'''<br /> * Schlechter Schreibstil! Was im Chat normal ist und im Forum zwangsweise geduldet wird, ist hier tabu: Bitte gebt euch etwas Mühe, wenn ihr hier einen Artikel verfasst!<br /> * Werbung für unbekannte, kleine Projekte, Foren, virtuelle Gesellschaften etc. Der Sinn von OMSIWiki ist nicht die Werbung für Projekte! Es soll eine Informationsplattform sein!<br /> <br /> Hier dazu was Passendes zum schmunzeln: [http://meta.wikimedia.org/wiki/Wikipedia_Anti-Regeln Wikipedia-Anti-Regeln]<br /> <br /> === Absprachen ===<br /> <br /> * Vor Beginn der Arbeit bitte oben bei &quot;Aktuell in Arbeit&quot; eine Zeile mit der geplanten Arbeit und eurer Signatur ergänzen. Nach Fertigstellung diesen wieder entfernen. Sollte jedoch dann gar kein Punkt mehr übrigbleiben, dann ein &quot; * ''Nichts'' &quot; stehen lassen.<br /> * Wenn ihr größere Korrekturen an unseren Artikeln vornehmt, wär es natürlich gut, wenn ihr uns zumindest nachher darüber informiert, damit wir den Überblick behalten.<br /> * Bevor ein neuer Artikel verfasst wird, kann es nicht schaden, kurz eine E-Mail an uns Administratoren zu schicken mit euren Planungen.<br /> * Das Einführen neuer Kategorien hat grundstätzlich in Absprache mit den Administratoren zu geschehen.<br /> <br /> * Beachtet auch die Möglichkeit, mit den Autoren auf der Diskussionsseite zu diskutieren! Wie der &quot;Quellcode&quot; einer Diskussionsseite aussieht, seht ihr hier: [[Diskussion:OMSI_Addon_Tester_(OAT)]]. Und nicht vergessen: Die Signatur könnt ihr automatisch erzeugen mit &lt;nowiki&gt;--~~~~&lt;/nowiki&gt;!<br /> <br /> === Multilingualität ===<br /> <br /> OMSIWiki ist zweisprachig ausgelegt: Englisch und Deutsch. Wie beim großen Vorbild, der Wikipedia, können die Artikel beider Sprachen miteinander verbunden werden. Dies erfolgt auch auf selbem Wege wie bei Wikipedia. Selbstverständlich ist es erstrebenswert, beide Teile der OMSIWiki auf gleichem Stand zu halten - auch wenn das natürlich praktisch nie ganz der Fall sein kann.<br /> <br /> === Zugriff ===<br /> <br /> Im Gegensatz zur Wikipedia müsst ihr angemeldet sein, um hier Schreibzugriff zu erhalten. Ich denke, dies ist nicht zu viel verlangt und hilft uns eine gewisse Kontrolle über das Verfassen von Artikeln zu behalten.<br /> <br /> == Ultra-Kurzhandbuch ==<br /> <br /> Ein paar Hinweise für Neulinge, die sich davor scheuen, das ganze Handbuch zu lesen. Wie &quot;baut&quot; man einen OMSIWiki-Artikel?<br /> <br /> * Signatur: Gibt's überm Editor-Fenster einen Button, sonst &lt;nowiki&gt;--~~~~&lt;/nowiki&gt;.<br /> * Anlegen einer neuen Seite: Nachdem ihr im Forum oder uns Bescheid gegeben habt, gebt ihr den ''wohlüberlegten'' Titel der neuen Seite ins ''Suche''-Feld ein. Es erscheint dann der Vorschlag, ob man diese Seite enlegen möchte? Ein &quot;ja&quot; führt dich dann zum leeren Editorfenster.<br /> * Eine sinnvolle Gliederung kann folgendermaßen erstellt werden:<br /> == Hauptüberschrift ==<br /> === Subüberschrift ===<br /> ==== Sub-Sub-Überschrift ==== usw.<br /> * Aufzählungen wie diese werden folgendermaßen durchgeführt:<br /> * Aufzählungspunkt<br /> * Aufzählungspunkt<br /> ** Sub-Aufzählungspunkt<br /> * Ein # statt einem * führt zu numerierten Aufzählungen.<br /> * Fett- und Kursivschreibung wird mittels Apostrophen markiert:<br /> &lt;pre&gt;<br /> ''Kursiv''<br /> '''Fett'''<br /> &lt;/pre&gt;<br /> * Die Zuweisung einer Kategorie (im Beispiel der Kategorie &quot;Busfahren in OMSI&quot;) erfolgt ganz am Ende des Artikels mit &lt;nowiki&gt;[[Kategorie:Busfahren in OMSI]]&lt;/nowiki&gt;.<br /> <br /> Weitere Informationen: [http://meta.wikimedia.org/wiki/Hilfe:Handbuch?uselang=de meta.wikimedia.org/wiki/Hilfe:Handbuch]<br /> <br /> == Historie ==<br /> <br /> * 8. September 2011 - Marcel Kuhnt: Einrichten der deutschen OMSIWiki und Verlinkung mit der englischen.<br /> * 13. September 2011 - Marcel Kuhnt: OMSIWiki öffentlich angekündigt.<br /> <br /> == Links rund ums Thema OMSI ==<br /> <br /> * [http://www.omnibussimulator.de www.omnibussimulator.de] - offizielle Seite von OMSI, dem Omnibussimulator<br /> * [http://omnibussimulator.forumieren.com omnibussimulator.forumieren.com] - offizielles OMSI-Forum<br /> <br /> == Sonstiges ==<br /> <br /> [[Technische Informationen zum MediaWiki]]<br /> <br /> [[en:Main Page]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=OMSI_Addon_Manager&diff=164 2011-09-13T19:15:16Z

<p>Janniboy: Verlinkung zur Kategorie hinzugefügt</p> <hr /> <div>== Konzept und Entwicklung ==<br /> <br /> [[Datei: Am logo.png|left]]Ursprünglich war nur eine Art &quot;Update-Erinnerer&quot; für OMSI-Addons gedacht, doch daraus entstand während der Entwicklungsphase schnell eine Software, die die Installation, Verwaltung und Entfernung von OMSI-Addons gerade für Einsteiger erleichtert: Der OMSI Addon Manager, oder auch kurz: AM.<br /> <br /> Am 20. Mai wurde die Version 1.0 nach einem längeren Betatest für die Öffentlichkeit freigegeben. Mit der Zeit kamen mit höheren Versionsnummern auch neue Funktionen hinzu: Einige Erweiterungen in der Skriptsprache erhielten Einzug, ein Benutzerzähler für die Addon-Entwickler, diverse Sicherheitsfeatures und eine automatische Prüfung auf zusätzlich benötigte Addons sind einige Beispiele.<br /> <br /> Die letzte Version 1.2.3 wurde am 31. Juli veröffentlicht und kann im [http://forum.aerosoft.com/index.php?/files/file/820-omsi-addon-manager/ Aerosoft-Downloadcenter] heruntergeladen werden.<br /> <br /> <br /> == Für die Benutzer ==<br /> <br /> [[Datei: AM screen.jpg|miniatur|right|Benutzeroberfläche des Addon Managers (V1.0)]]Für die Benutzer des Addon Managers ergeben sich einige Vereinfachungen, wenn Addons über diese Software installiert werden. In den folgenden Abschnitten werden diese Features kurz zusammengefasst.<br /> <br /> === Ein Addon herunterladen und installieren ===<br /> <br /> Ein AM-kompatibles Addon wird in einer Datei mit der Endung *.ams heruntergeladen. Bei einigen Filehostern ist der Upload von *.ams nicht gestattet, da die Dateiendung unbekannt ist. Teilweise kann es also nötig sein, die *.ams-Datei erst aus einem anderen Archiv zu extrahieren.<br /> <br /> Der AM enthält ein integriertes Downloadcenter, über das der Benutzer die Kategorien nach interessanten Addons durchstöbern kann. Klickt er dort auf den Download-Button, wird er direkt zur Website weitergeleitet, die das Addon anbietet.<br /> <br /> Per Doppelklick auf die heruntergeladene AMS-Datei startet der Addon Importer (er ist Teil des AM), der den Benutzer durch den Installationsvorgang führt. Eventuell müssen Readme-Bedingungen akzeptiert werden. Bei einigen Addons können zudem zusätzliche Optionen gewählt werden, die ebenfalls installiert werden sollen.<br /> <br /> Wenn der Addon-Entwickler dies vorgesehen hat, wird der Benutzer nach der Installation auch informiert, falls weitere Addons benötigt werden, die noch nicht installiert sind.<br /> <br /> Anschließend ist das Addon fertig installiert und sollte einwandfrei funktionieren.<br /> <br /> === Updates für Addons ===<br /> <br /> Je nach Konfiguration informiert der AM den Benutzer beim Systemstart mit einem Hinweisfenster in der rechten unteren Bildschirmecke, wenn Updates für OMSI-Addons verfügbar sind. Der Benutzer muss dann nur noch den Download-Button anklicken und gelangt zur Download-Website. Ab dort gleicht die Installationsroutine dem Vorgang, der im vorigen Abschnitt beschrieben wurde.<br /> <br /> === Addon deinstallieren ===<br /> <br /> Die allermeisten Addons kann man auch per Mausklick wieder deinstallieren, wenn man das Interesse verloren hat oder nicht zufrieden ist. Es gilt aber zu beachten, dass der Addon-Entwickler dafür sorgt, dass diese Entfernung funktioniert. Bei Problemen ist daher im Regelfall der Autor des Addons zu benachrichtigen.<br /> <br /> === Weitere Features ===<br /> <br /> Einige kleinere Features wurden noch nicht erwähnt. Beispielsweise können alle User dem Addon-Entwickler ihr Feedback schicken (wenn dieser es gestattet hat), indem sie unter &quot;Meine installierten Addons&quot; beim betreffenden Addon auf &quot;Feedback senden!&quot; klicken. Des Weiteren kann in den Einstellungen das Autostart- und Benachrichtigungsverhalten des AM gesteuert werden. Zu guter Letzt lässt sich auch der Pfad zu OMSI verändern für den Fall, dass man entweder mehrere OMSI-Installationen hat oder der Pfad irrtümlicherweise nicht richtig erkannt wurde.<br /> <br /> <br /> == Für die Entwickler ==<br /> <br /> Auch für die Entwickler bieten sich einige Vorteile, wenn sie ihre Addons auch über den AM anbieten. Es wird jedoch immer empfohlen, auch eine konventionelle Installationsvariante bereitzustellen, da es auch Benutzer gibt, die den AM nicht nutzen möchten - ihnen soll deswegen aber kein Addon vorenthalten werden!<br /> Falls ein Addon-Entwickler keinen Standard-Download anbietet, kann die AMS-Datei auch in *.zip umbenannt werden. Je nach Komplexität des Addons muss man dann beim Entpacken allerdings vorsichtig sein mit der Ordnerstruktur!<br /> <br /> Im Folgenden wird in Kürze erläutert, wie ein Entwickler sein Addon kompatibel zum AM machen kann.<br /> <br /> === Als Entwickler registrieren ===<br /> <br /> Zu aller erst muss sich jeder interessierte Entwickler im [http://www.jan-kiesewalter.de/am_developer/ AM Developer Access] kostenlos registrieren. Er erhält dadurch Zugriff auf alle Administrationsfunktionen, die für den Betrieb mit AM benötigt werden, sowie auf die deutsche und englische Dokumentation. <br /> Die sollte er sich selbstverständlich erst einmal durchlesen.<br /> <br /> === Addon registrieren ===<br /> <br /> Damit der Addon Manager jedes Addon weltweit einwandfrei erkennt, muss der Entwickler sein Addon zunächst im Developer Access registrieren. Details hierfür können in Kapitel 1 der Dokumentation gefunden werden.<br /> <br /> Er erhält daraufhin eine eindeutige ID, mit der sein Addon identifiziert werden kann. Zugleich werden hier Informationen wie die neueste Verionsnummer, das Vorschaubildchen, die zugeordnete Kategorie im Downloadcenter oder die Beschreibung festgelegt.<br /> <br /> === AMS-Datei packen und veröffentlichen ===<br /> <br /> [[Datei: Am icon small.png|right|miniatur|Kleines Icon (64x64)]][[Datei: Am icon gross.png|right|miniatur|Großes Icon (250x64)]]Der nächste logische Schritt ist die Erstellung der AMS-Datei. Dafür muss das sogenannten &quot;Import-Skript&quot; geschrieben werden, es ist eine einfache Textdatei und kann mit jedem beliebigen Editor bearbeitet werden. Eine Vorlage hierfür befindet sich im Programmverzeichnis des AM. Dieses Skript wird beim Buildvorgang in die AMS-Datei integriert und ermöglicht so die Steuerung der Addon-bezogenen Funktionen auf dem Ziel-PC. Festgelegt werden hier unter anderem die ID (s.o.), die Versionsnummer, die Readme-Texte und die Deinstallationsroutine. Es gibt noch viele weitere Möglichkeiten wie das Öffnen einer Website nach dem Import oder das Anzeigen wichtiger Hinweise, die mindestens 10 Sekunden für den Benutzer sichtbar bleiben, bevor er sie &quot;wegklicken&quot; kann.<br /> <br /> Nach dem Skript müssen die Addon-Dateien und die Skriptdatei in eine AMS-Datei vereint werden. Dabei hilft der &quot;AMS Builder&quot;, der beim AM standardmäßig mitinstalliert wird. Ist die AMS-Datei gepackt, kann sie hochgeladen und den Benutzern somit zugänglich gemacht werden.<br /> <br /> Dem Addon-Entwickler ist es nun gestattet, mit einem der offizielle Kompatibilitätslogos zu zeigen, dass er sein Addon für den AM fit gemacht hat. Dabei stehen zwei Varianten zur Verfügung, eine kleine (64x64) und eine erweiterte (250x64). Beide sind rechts abgebildet.<br /> <br /> ''HINWEIS: Emil hat ein sehr schönes und leicht verständliches Tutorial erstellt zum Thema &quot;Wie mache ich ein Addon für den Addon Manager?&quot; (siehe Weblinks). Jedem Einsteiger empfehle ich die Lektüre!''<br /> <br /> === Ein Update bereitstellen ===<br /> <br /> Bisher bedeutete die Nutzung des AM vor allem Zusatzarbeit für den Entwickler. Doch spätestens beim Updatevorgang zeigt sich, warum sich die Mühe in der Regel lohnt.<br /> Zunächst wird die neue AMS mit neuer Versionsnummer gepackt, wie im vorigen Abschnitt beschrieben. Nach dem Upload wird im Developer Access die Versionsnummer geändert.<br /> <br /> Ab nun werden alle User weltweit beim nächsten Start des AM informiert, dass die aktuelle Addon-Version veraltet ist und eine neue zum Download bereitsteht. So erfahren alle User direkt von der neuen Version, nicht mehr oder weniger durch &quot;Zufall&quot;. Fehler können so effektiv, schnell und weitreichend beseitigt werden.<br /> <br /> === Hilfe für Entwickler ===<br /> <br /> Falls nach dem Lesen der Dokumentation noch Fragen offenbleiben sollten, können Addon-Entwickler ihre Fragen jederzeit im &quot;Internal Help Forum&quot; des Developer Access posten. Andere Addon-Autoren und ich (Entwickler des AM) helfen gerne weiter.<br /> <br /> <br /> == Weblinks ==<br /> <br /> * [http://forum.aerosoft.com/index.php?/files/file/820-omsi-addon-manager/ AM-Download bei Aerosoft]<br /> * [http://www.jan-kiesewalter.de/am_developer/ Developer-Access für Addon-Entwickler]<br /> * [http://omnibussimulator.forumieren.com/t5367-tut-wie-mache-ich-ein-addon-fur-den-addon-manager Tutorial von Emil: &quot;Wie mache ich ein Addon für den Addon Manager?&quot;]<br /> <br /> <br /> [[Kategorie:Anschlussprojekte]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=OMSI_Addon_Manager&diff=163 2011-09-13T19:12:57Z

<p>Janniboy: Die Seite wurde neu angelegt: „== Konzept und Entwicklung == leftUrsprünglich war nur eine Art &quot;Update-Erinnerer&quot; für OMSI-Addons gedacht, doch daraus entstand währen…“</p> <hr /> <div>== Konzept und Entwicklung ==<br /> <br /> [[Datei: Am logo.png|left]]Ursprünglich war nur eine Art &quot;Update-Erinnerer&quot; für OMSI-Addons gedacht, doch daraus entstand während der Entwicklungsphase schnell eine Software, die die Installation, Verwaltung und Entfernung von OMSI-Addons gerade für Einsteiger erleichtert: Der OMSI Addon Manager, oder auch kurz: AM.<br /> <br /> Am 20. Mai wurde die Version 1.0 nach einem längeren Betatest für die Öffentlichkeit freigegeben. Mit der Zeit kamen mit höheren Versionsnummern auch neue Funktionen hinzu: Einige Erweiterungen in der Skriptsprache erhielten Einzug, ein Benutzerzähler für die Addon-Entwickler, diverse Sicherheitsfeatures und eine automatische Prüfung auf zusätzlich benötigte Addons sind einige Beispiele.<br /> <br /> Die letzte Version 1.2.3 wurde am 31. Juli veröffentlicht und kann im [http://forum.aerosoft.com/index.php?/files/file/820-omsi-addon-manager/ Aerosoft-Downloadcenter] heruntergeladen werden.<br /> <br /> <br /> == Für die Benutzer ==<br /> <br /> [[Datei: AM screen.jpg|miniatur|right|Benutzeroberfläche des Addon Managers (V1.0)]]Für die Benutzer des Addon Managers ergeben sich einige Vereinfachungen, wenn Addons über diese Software installiert werden. In den folgenden Abschnitten werden diese Features kurz zusammengefasst.<br /> <br /> === Ein Addon herunterladen und installieren ===<br /> <br /> Ein AM-kompatibles Addon wird in einer Datei mit der Endung *.ams heruntergeladen. Bei einigen Filehostern ist der Upload von *.ams nicht gestattet, da die Dateiendung unbekannt ist. Teilweise kann es also nötig sein, die *.ams-Datei erst aus einem anderen Archiv zu extrahieren.<br /> <br /> Der AM enthält ein integriertes Downloadcenter, über das der Benutzer die Kategorien nach interessanten Addons durchstöbern kann. Klickt er dort auf den Download-Button, wird er direkt zur Website weitergeleitet, die das Addon anbietet.<br /> <br /> Per Doppelklick auf die heruntergeladene AMS-Datei startet der Addon Importer (er ist Teil des AM), der den Benutzer durch den Installationsvorgang führt. Eventuell müssen Readme-Bedingungen akzeptiert werden. Bei einigen Addons können zudem zusätzliche Optionen gewählt werden, die ebenfalls installiert werden sollen.<br /> <br /> Wenn der Addon-Entwickler dies vorgesehen hat, wird der Benutzer nach der Installation auch informiert, falls weitere Addons benötigt werden, die noch nicht installiert sind.<br /> <br /> Anschließend ist das Addon fertig installiert und sollte einwandfrei funktionieren.<br /> <br /> === Updates für Addons ===<br /> <br /> Je nach Konfiguration informiert der AM den Benutzer beim Systemstart mit einem Hinweisfenster in der rechten unteren Bildschirmecke, wenn Updates für OMSI-Addons verfügbar sind. Der Benutzer muss dann nur noch den Download-Button anklicken und gelangt zur Download-Website. Ab dort gleicht die Installationsroutine dem Vorgang, der im vorigen Abschnitt beschrieben wurde.<br /> <br /> === Addon deinstallieren ===<br /> <br /> Die allermeisten Addons kann man auch per Mausklick wieder deinstallieren, wenn man das Interesse verloren hat oder nicht zufrieden ist. Es gilt aber zu beachten, dass der Addon-Entwickler dafür sorgt, dass diese Entfernung funktioniert. Bei Problemen ist daher im Regelfall der Autor des Addons zu benachrichtigen.<br /> <br /> === Weitere Features ===<br /> <br /> Einige kleinere Features wurden noch nicht erwähnt. Beispielsweise können alle User dem Addon-Entwickler ihr Feedback schicken (wenn dieser es gestattet hat), indem sie unter &quot;Meine installierten Addons&quot; beim betreffenden Addon auf &quot;Feedback senden!&quot; klicken. Des Weiteren kann in den Einstellungen das Autostart- und Benachrichtigungsverhalten des AM gesteuert werden. Zu guter Letzt lässt sich auch der Pfad zu OMSI verändern für den Fall, dass man entweder mehrere OMSI-Installationen hat oder der Pfad irrtümlicherweise nicht richtig erkannt wurde.<br /> <br /> <br /> == Für die Entwickler ==<br /> <br /> Auch für die Entwickler bieten sich einige Vorteile, wenn sie ihre Addons auch über den AM anbieten. Es wird jedoch immer empfohlen, auch eine konventionelle Installationsvariante bereitzustellen, da es auch Benutzer gibt, die den AM nicht nutzen möchten - ihnen soll deswegen aber kein Addon vorenthalten werden!<br /> Falls ein Addon-Entwickler keinen Standard-Download anbietet, kann die AMS-Datei auch in *.zip umbenannt werden. Je nach Komplexität des Addons muss man dann beim Entpacken allerdings vorsichtig sein mit der Ordnerstruktur!<br /> <br /> Im Folgenden wird in Kürze erläutert, wie ein Entwickler sein Addon kompatibel zum AM machen kann.<br /> <br /> === Als Entwickler registrieren ===<br /> <br /> Zu aller erst muss sich jeder interessierte Entwickler im [http://www.jan-kiesewalter.de/am_developer/ AM Developer Access] kostenlos registrieren. Er erhält dadurch Zugriff auf alle Administrationsfunktionen, die für den Betrieb mit AM benötigt werden, sowie auf die deutsche und englische Dokumentation. <br /> Die sollte er sich selbstverständlich erst einmal durchlesen.<br /> <br /> === Addon registrieren ===<br /> <br /> Damit der Addon Manager jedes Addon weltweit einwandfrei erkennt, muss der Entwickler sein Addon zunächst im Developer Access registrieren. Details hierfür können in Kapitel 1 der Dokumentation gefunden werden.<br /> <br /> Er erhält daraufhin eine eindeutige ID, mit der sein Addon identifiziert werden kann. Zugleich werden hier Informationen wie die neueste Verionsnummer, das Vorschaubildchen, die zugeordnete Kategorie im Downloadcenter oder die Beschreibung festgelegt.<br /> <br /> === AMS-Datei packen und veröffentlichen ===<br /> <br /> [[Datei: Am icon small.png|right|miniatur|Kleines Icon (64x64)]][[Datei: Am icon gross.png|right|miniatur|Großes Icon (250x64)]]Der nächste logische Schritt ist die Erstellung der AMS-Datei. Dafür muss das sogenannten &quot;Import-Skript&quot; geschrieben werden, es ist eine einfache Textdatei und kann mit jedem beliebigen Editor bearbeitet werden. Eine Vorlage hierfür befindet sich im Programmverzeichnis des AM. Dieses Skript wird beim Buildvorgang in die AMS-Datei integriert und ermöglicht so die Steuerung der Addon-bezogenen Funktionen auf dem Ziel-PC. Festgelegt werden hier unter anderem die ID (s.o.), die Versionsnummer, die Readme-Texte und die Deinstallationsroutine. Es gibt noch viele weitere Möglichkeiten wie das Öffnen einer Website nach dem Import oder das Anzeigen wichtiger Hinweise, die mindestens 10 Sekunden für den Benutzer sichtbar bleiben, bevor er sie &quot;wegklicken&quot; kann.<br /> <br /> Nach dem Skript müssen die Addon-Dateien und die Skriptdatei in eine AMS-Datei vereint werden. Dabei hilft der &quot;AMS Builder&quot;, der beim AM standardmäßig mitinstalliert wird. Ist die AMS-Datei gepackt, kann sie hochgeladen und den Benutzern somit zugänglich gemacht werden.<br /> <br /> Dem Addon-Entwickler ist es nun gestattet, mit einem der offizielle Kompatibilitätslogos zu zeigen, dass er sein Addon für den AM fit gemacht hat. Dabei stehen zwei Varianten zur Verfügung, eine kleine (64x64) und eine erweiterte (250x64). Beide sind rechts abgebildet.<br /> <br /> ''HINWEIS: Emil hat ein sehr schönes und leicht verständliches Tutorial erstellt zum Thema &quot;Wie mache ich ein Addon für den Addon Manager?&quot; (siehe Weblinks). Jedem Einsteiger empfehle ich die Lektüre!''<br /> <br /> === Ein Update bereitstellen ===<br /> <br /> Bisher bedeutete die Nutzung des AM vor allem Zusatzarbeit für den Entwickler. Doch spätestens beim Updatevorgang zeigt sich, warum sich die Mühe in der Regel lohnt.<br /> Zunächst wird die neue AMS mit neuer Versionsnummer gepackt, wie im vorigen Abschnitt beschrieben. Nach dem Upload wird im Developer Access die Versionsnummer geändert.<br /> <br /> Ab nun werden alle User weltweit beim nächsten Start des AM informiert, dass die aktuelle Addon-Version veraltet ist und eine neue zum Download bereitsteht. So erfahren alle User direkt von der neuen Version, nicht mehr oder weniger durch &quot;Zufall&quot;. Fehler können so effektiv, schnell und weitreichend beseitigt werden.<br /> <br /> === Hilfe für Entwickler ===<br /> <br /> Falls nach dem Lesen der Dokumentation noch Fragen offenbleiben sollten, können Addon-Entwickler ihre Fragen jederzeit im &quot;Internal Help Forum&quot; des Developer Access posten. Andere Addon-Autoren und ich (Entwickler des AM) helfen gerne weiter.<br /> <br /> <br /> == Weblinks ==<br /> <br /> * [http://forum.aerosoft.com/index.php?/files/file/820-omsi-addon-manager/ AM-Download bei Aerosoft]<br /> * [http://www.jan-kiesewalter.de/am_developer/ Developer-Access für Addon-Entwickler]<br /> * [http://omnibussimulator.forumieren.com/t5367-tut-wie-mache-ich-ein-addon-fur-den-addon-manager Tutorial von Emil: &quot;Wie mache ich ein Addon für den Addon Manager?&quot;]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Datei:Am_icon_gross.png&diff=162 2011-09-13T19:11:18Z

<p>Janniboy: Quelle: Jan Kiesewalter (Urheber)</p> <hr /> <div>Quelle: Jan Kiesewalter (Urheber)</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Datei:Am_icon_small.png&diff=161 2011-09-13T19:10:21Z

<p>Janniboy: Quelle: Jan Kiesewalter (Urheber)</p> <hr /> <div>Quelle: Jan Kiesewalter (Urheber)</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Datei:Am_logo.png&diff=160 2011-09-13T19:07:35Z

<p>Janniboy: Quelle: Jan Kiesewalter (Urheber)</p> <hr /> <div>Quelle: Jan Kiesewalter (Urheber)</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Datei:AM_screen.jpg&diff=159 2011-09-13T19:05:04Z

<p>Janniboy: Quelle: Jan Kiesewalter (Urheber)</p> <hr /> <div>Quelle: Jan Kiesewalter (Urheber)</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Hauptseite&diff=157 2011-09-13T13:24:42Z

<p>Janniboy: AM-Artikel zu &quot;In Arbeit&quot; hinzugefügt</p> <hr /> <div>&lt;font style=&quot;font-size:1.2em;&quot;&gt;<br /> '''Herzlich willkommen auf der deutschen Version von OMSIWiki!'''<br /> <br /> Hier geht's direkt zu einer der Hauptkategorien:<br /> <br /> * [[:Kategorie:Busfahren in OMSI|Busfahren in OMSI]]<br /> * Entwicklung von Addons:<br /> ** [[:Kategorie:Nachschlagewerk für Addon-Entwickler|Nachschlagewerk]]<br /> ** [[:Kategorie:Tutorials für Addon-Entwickler|Tutorials]]<br /> ** [[:Kategorie:Tipps und Tricks für Addon-Entwickler|Tipps und Tricks]]<br /> * [[:Kategorie:Anschlussprojekte|Anschlussprojekte (z.B. Addon-Manager, OAT)]]<br /> * [[:Kategorie:Addon-Präsentationen|Addon-Präsentationen]]<br /> * [[:Kategorie:Hintergrundinformationen|Hintergrundinformationen]]<br /> <br /> '''Achtung: Vor dem Verfassen eigener Beiträge bitte zuerst die Regeln lesen!''' Weiter unten gibt es noch eine Ultra-Kurzanleitung für Neulinge.<br /> <br /> ''Aktuell in Arbeit:''<br /> &lt;/font&gt;<br /> <br /> * ''Allgemeiner Artikel zum Addon-Manager (erstmal DE), später evtl. noch zur AM-Skriptsprache --[[Benutzer:Janniboy|Janniboy]] 15:24, 13. Sep. 2011 (MEST)''<br /> <br /> <br /> <br /> ----<br /> <br /> == Idee ==<br /> <br /> Wir Entwickler von OMSI haben OMSIWiki eingerichtet, um eine bessere Plattform für alle Arten von Informationen rund um OMSI zu erhalten. Folgende Themengebiete sind von uns vorläufig vorgesehen:<br /> <br /> * Präsentation von Hintergrundinformationen über das Addon-Design von unserer Seite (Objekt- und Fahrzeugbar, Soundengine, Scriptengine usw.)<br /> * Tipps und Tricks oder auch ganze Tutorials von Usern z.B. zum Erstellen von Repaints oder Mapbau würden unsere Kernthemen abrunden. Entweder als Ergänzung unserer oder als weiterreichende Artikel.<br /> * Die Bedienung von OMSI und insbesondere der Busse könnte ein weiterer Themenkomplex sein. Zwar gibt es natürlich ein Handbuch für OMSI, dennoch gibt es vieleicht die eine oder andere Sache, die ausführlicher erklärt werden soll. Hier werden wir uns allerdings etwas zurückhalten.<br /> * Weiterhin könnten hier bewährte Anschlussprojekte zu OMSI präsentiert werden, z.B. OAT oder der Addon-Manager. Höchstwahrscheinlich werden die zugehörigen Artikel dann von den Leitern oder treuesten Fans dieser Projekte geschrieben, wir werden uns hier ebenfalls zurückhalten.<br /> * Ähnlich hierzu haben wir nichts gegen eine hochqualitative Präsentation von komplexen Addons; denkbar wäre hier z.B. die Bedienungsanleitung eines Addon-Busses oder die Beschreibung und Hinweise für die Fahrt durch eine Addon-Karte mit Fahrplänen und/oder Karten. Wo wir hier allerdings die Grenze setzen, steht noch nicht fest. Insbesondere sollen hier keine &quot;Mini-Artikel&quot; entstehen, wo nur ein Screenshot von einem Repaint und ein Download-Link präsentiert wird!<br /> * Selbstverständlich dürfen hier auch gerne Hintergrundinformationen zu unserer Strecke oder unseren Bussen oder aber zu Addons gegeben werden (wie sah Spandau in der Realität 1989 aus? Wie wurde damals in Berlin Bus gefahren?). Es sollte sich aber um abgeschlossene und ernsthaft geschriebene Artikel handeln und es sollte definitiv ein Bezug zu OMSI vorhanden sein! Also keine schnell hingeschriebenen Tagesberichte von irgendeinem Busunternehmen, was keiner kennt und was auch nicht in OMSI mindestens als Addon simuliert werden kann.<br /> <br /> == Regeln ==<br /> <br /> === Ist das Thema hier erwünscht? ===<br /> <br /> Der Idee von OMSIWiki entsprechend sollte jeder Artikel letztlich in eine der oben genannten Kategorien passen!<br /> <br /> === &quot;Goldene Regel&quot; ===<br /> <br /> Zunächst die '''&quot;goldene Regel&quot;''': Bevor ein Artikel verfasst oder geändert wird, sollte stets geschaut werden, ob sich an den Regeln etwas geändert hat! Gerade in der Anfangszeit wird es sicher vorkommen, dass sich Regeln ändern oder neue hinzukommen.<br /> <br /> === Erwünscht ===<br /> <br /> * Wenn ihr einen kleinen oder großen Fehler entdeckt (auch in einem unserer Artikel!), dann darf ihn jeder korrigieren! Aber nur, wenn ihr euch dabei auch sicher seid.<br /> * Ihr findet einen Artikel z.B. im Addon-Handbuch zu trocken? Dann dürft ihr gerne ein kleines Beispiel ergänzen! Von mir weiß ich z.B., dass die Anschauung und Klarheit leidet, wenn ich viele und lange Texte schreibe!<br /> * Ihr findet einen Fachbegriff, der nicht erklärt wird? Wenn es ein bisher nicht erklärter Begriff von OMSI ist, dürft ihr gerne einen Artikel anfertigen und ihn mit dem Fachbegriff verlinken; handelt es sich um einen allgemeinen Fachbegriff, dann reicht meist ein externer Link zu einem entsprechenden Artikel z.B. in der Wikipedia aus.<br /> * Um zu vermeiden, dass euch bereits jemand anderes &quot;dazwischen funkt&quot;, obwohl euer Artikel noch gar nicht fertig ist, ergänzt bitte hierzu oben den Hinweis: &quot;''Hinweis: Dieser Artikel befindet sich noch im Aufbau!''&quot;. Dadurch wird auch vermieden, dass der unter Umständen erst halbfertige Artikel schon von jemandem übersetzt wird, sodass nach Fertigstellung der deutschen Version die englische noch unvollständig ist.<br /> * Wenn euer Artikel auch ein englischsprachiges Pendant hat, dann verknüpft ihn bitte! Ein Blick ans Ende des Quelltextes ''dieser'' Seite zeigt euch, wie das geht! Hat er jedoch ''kein'' Pendant und muss demnach in der englischen OMSIWiki noch angelegt werden, so wäre ein Hinweis ganz oben nicht schlecht: &quot;''Hinweis: Dieser Artikel wurde noch nicht ins Englische übersetzt!''&quot; oder &quot;''Hinweis: Die englische Version muss noch aktualisiert werden!''&quot;<br /> * Wenn ihr Spaß am Übersetzen habt, dann könnt ihr eine sehr wertvolle Hilfe für OMSIWiki sein! Wenn ihr einen dieser Hinweise entdeckt, scheut euch nicht, den Artikel in die englische OMSIWiki einzupflegen! Ihr solltet danach aber den Original-Autor informieren (damit er die Gelegenheit hat, einmal drüber zu schauen) und dann natürlich die beidseitige Verlinkung mit der deutschen Seite vornehmen und den Hinweis entfernen.<br /> <br /> === Unerwünscht ===<br /> <br /> * '''Ganz wichtig: Der Name des Artikels muss wohlüberlegt gewählt werden, weil man den nicht mal eben ändern kann! Wer hier grob fahrlässig schlampt, fliegt raus!'''<br /> * Schlechter Schreibstil! Was im Chat normal ist und im Forum zwangsweise geduldet wird, ist hier tabu: Bitte gebt euch etwas Mühe, wenn ihr hier einen Artikel verfasst!<br /> * Werbung für unbekannte, kleine Projekte, Foren, virtuelle Gesellschaften etc. Der Sinn von OMSIWiki ist nicht die Werbung für Projekte! Es soll eine Informationsplattform sein!<br /> <br /> Hier dazu was Passendes zum schmunzeln: [http://meta.wikimedia.org/wiki/Wikipedia_Anti-Regeln Wikipedia-Anti-Regeln]<br /> <br /> === Absprachen ===<br /> <br /> * Vor Beginn der Arbeit bitte oben bei &quot;Aktuell in Arbeit&quot; eine Zeile mit der geplanten Arbeit und eurer Signatur ergänzen. Nach Fertigstellung diesen wieder entfernen. Sollte jedoch dann gar kein Punkt mehr übrigbleiben, dann ein &quot; * ''Nichts'' &quot; stehen lassen.<br /> * Wenn ihr größere Korrekturen an unseren Artikeln vornehmt, wär es natürlich gut, wenn ihr uns zumindest nachher darüber informiert, damit wir den Überblick behalten.<br /> * Bevor ein neuer Artikel verfasst wird, kann es nicht schaden, kurz eine E-Mail an uns Administratoren zu schicken mit euren Planungen.<br /> * Das Einführen neuer Kategorien hat grundstätzlich in Absprache mit den Administratoren zu geschehen.<br /> <br /> * Beachtet auch die Möglichkeit, mit den Autoren auf der Diskussionsseite zu diskutieren! Wie der &quot;Quellcode&quot; einer Diskussionsseite aussieht, seht ihr hier: [[Diskussion:OMSI_Addon_Tester_(OAT)]]. Und nicht vergessen: Die Signatur könnt ihr automatisch erzeugen mit &lt;nowiki&gt;--~~~~&lt;/nowiki&gt;!<br /> <br /> === Multilingualität ===<br /> <br /> OMSIWiki ist zweisprachig ausgelegt: Englisch und Deutsch. Wie beim großen Vorbild, der Wikipedia, können die Artikel beider Sprachen miteinander verbunden werden. Dies erfolgt auch auf selbem Wege wie bei Wikipedia. Selbstverständlich ist es erstrebenswert, beide Teile der OMSIWiki auf gleichem Stand zu halten - auch wenn das natürlich praktisch nie ganz der Fall sein kann.<br /> <br /> === Zugriff ===<br /> <br /> Im Gegensatz zur Wikipedia müsst ihr angemeldet sein, um hier Schreibzugriff zu erhalten. Ich denke, dies ist nicht zu viel verlangt und hilft uns eine gewisse Kontrolle über das Verfassen von Artikeln zu behalten.<br /> <br /> == Ultra-Kurzhandbuch ==<br /> <br /> Ein paar Hinweise für Neulinge, die sich davor scheuen, das ganze Handbuch zu lesen. Wie &quot;baut&quot; man einen OMSIWiki-Artikel?<br /> <br /> * Signatur: Gibt's überm Editor-Fenster einen Button, sonst &lt;nowiki&gt;--~~~~&lt;/nowiki&gt;.<br /> * Anlegen einer neuen Seite: Nachdem ihr im Forum oder uns Bescheid gegeben habt, gebt ihr den ''wohlüberlegten'' Titel der neuen Seite ins ''Suche''-Feld ein. Es erscheint dann der Vorschlag, ob man diese Seite enlegen möchte? Ein &quot;ja&quot; führt dich dann zum leeren Editorfenster.<br /> * Eine sinnvolle Gliederung kann folgendermaßen erstellt werden:<br /> == Hauptüberschrift ==<br /> === Subüberschrift ===<br /> ==== Sub-Sub-Überschrift ==== usw.<br /> * Aufzählungen wie diese werden folgendermaßen durchgeführt:<br /> * Aufzählungspunkt<br /> * Aufzählungspunkt<br /> ** Sub-Aufzählungspunkt<br /> * Ein # statt einem * führt zu numerierten Aufzählungen.<br /> * Fett- und Kursivschreibung wird mittels Apostrophen markiert:<br /> &lt;pre&gt;<br /> ''Kursiv''<br /> '''Fett'''<br /> &lt;/pre&gt;<br /> * Die Zuweisung einer Kategorie (im Beispiel der Kategorie &quot;Busfahren in OMSI&quot;) erfolgt ganz am Ende des Artikels mit &lt;nowiki&gt;[[Kategorie:Busfahren in OMSI]]&lt;/nowiki&gt;.<br /> <br /> Weitere Informationen: [http://meta.wikimedia.org/wiki/Hilfe:Handbuch?uselang=de meta.wikimedia.org/wiki/Hilfe:Handbuch]<br /> <br /> == Historie ==<br /> <br /> * 8. September 2011 - Marcel Kuhnt: Einrichten der deutschen OMSIWiki und Verlinkung mit der englischen.<br /> <br /> == Links rund ums Thema OMSI ==<br /> <br /> * [http://www.omnibussimulator.de www.omnibussimulator.de] - offizielle Seite von OMSI, dem Omnibussimulator<br /> * [http://omnibussimulator.forumieren.com omnibussimulator.forumieren.com] - offizielles OMSI-Forum<br /> <br /> == Sonstiges ==<br /> <br /> [[Technische Informationen zum MediaWiki]]<br /> <br /> [[en:Main Page]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Diskussion:OMSI_Addon_Tester_(OAT)&diff=152 2011-09-13T06:22:39Z

<p>Janniboy: </p> <hr /> <div>Hi Janniboy! Ich fand die alte Gliederung besser; mein Hinweis im OMSI-Forum war ganz allgemeiner Natur. Schließlich sind &quot;Gründung&quot; und &quot;Bewertungsverfahren&quot; doch durchaus gleichberechtigte Punkte... --[[Benutzer:Marcel Kuhnt|Marcel Kuhnt]] 23:39, 12. Sep. 2011 (MEST) Achja: wenn du hierzu was schreibst, ist es üblich, mit Doppelpunkten einzurücken, also etwa so:<br /> :ach, haste ja schon angepasst... --[[Benutzer:Marcel Kuhnt|Marcel Kuhnt]] 23:42, 12. Sep. 2011 (MEST)<br /> ::Jap, sind ja alle gleichberechtigt?! Hier hat sich zeitlich wohl was überschnitten :D --[[Benutzer:Janniboy|Janniboy]] 23:44, 12. Sep. 2011 (MEST)<br /> :::Ja, schon. Aber es wird wie im Forum gemeldet, wenn eine gleichzeitige Editierung geschieht. Hatte ich auch heute mit dir vorhin das erste Mal! ;) Hab aber &quot;nachgegeben&quot;, sodass du also nix gemerkt haben dürftest...--[[Benutzer:Marcel Kuhnt|Marcel Kuhnt]] 23:55, 12. Sep. 2011 (MEST)<br /> ::::Jaja, der Klügere gibt nach... nech? Ich hab davon jedenfalls nix mitbekommen. Dann schau ich mal, ob ich in naher Zukunft auch noch einen AM-Artikel hinbekomme - diesmal aber an der *richtigen* Stelle. --[[Benutzer:Janniboy|Janniboy]] 08:22, 13. Sep. 2011 (MEST)</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Diskussion:OMSI_Addon_Tester_(OAT)&diff=144 2011-09-12T21:44:10Z

<p>Janniboy: </p> <hr /> <div>Hi Janniboy! Ich fand die alte Gliederung besser; mein Hinweis im OMSI-Forum war ganz allgemeiner Natur. Schließlich sind &quot;Gründung&quot; und &quot;Bewertungsverfahren&quot; doch durchaus gleichberechtigte Punkte... --[[Benutzer:Marcel Kuhnt|Marcel Kuhnt]] 23:39, 12. Sep. 2011 (MEST) Achja: wenn du hierzu was schreibst, ist es üblich, mit Doppelpunkten einzurücken, also etwa so:<br /> :bla (übrigens erzeugt &lt;nowiki&gt;--~~~~&lt;/nowiki&gt; den automatischen Benutzernamen mit Zeitstempel. Gibts auch einen Button für.<br /> ::bla<br /> :::bla (kann nach Lesen gelöscht werden...)<br /> ::::ach, haste ja schon angepasst... --[[Benutzer:Marcel Kuhnt|Marcel Kuhnt]] 23:42, 12. Sep. 2011 (MEST)<br /> :::::Jap, sind ja alle gleichberechtigt?! Hier hat sich zeitlich wohl was überschnitten :D --[[Benutzer:Janniboy|Janniboy]] 23:44, 12. Sep. 2011 (MEST)</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=OMSI_Addon_Tester_(OAT)&diff=142 2011-09-12T21:42:26Z

<p>Janniboy: Überschrift angepasst</p> <hr /> <div>== Gründung und Zielsetzung ==<br /> <br /> Die OMSI Addon Tester - kurz &quot;OAT&quot; - sind ein Zusammenschluss von Mitgliedern aus dem offiziellen OMSI-Forum.<br /> Gegründet wurde die OAT am 30. April 2011 durch die OMSI-Forenmitglieder Yufa, Felix01 und Janniboy ([http://omnibussimulator.forumieren.com/t4415p60-prufung-neuer-maps Link zum Thread]).<br /> <br /> Die OAT ([http://www.oat-online.de www.oat-online.de]) hat es sich zum Ziel gesetzt, kostenlose OMSI-Addons von Privatpersonen sachlich und objektiv zu bewerten.<br /> Damit soll einerseits interessierten Benutzern bereits vor dem Download ein Einblick darin geben werden, was sie mit dem Addon erwartet; andererseits soll so dazu beigetragen werden, dass sich die Qualität von OMSI-Addons mit der Zeit steigert.<br /> <br /> All das fasst die OAT in einem Statement-Satz zusammen:<br /> ''&quot;Wir möchten die Autoren aktiv dabei unterstützen, ihre Addons zu perfektionieren.&quot;''<br /> <br /> Alle Mitarbeiter der OAT arbeiten ehrenamtlich, jeder kann sich bewerben. Welche Kriterien ein Addon-Tester erfüllen sollte und was von ihm erwartet wird, kann [http://oat-online.de/info_bewerben.php hier] nachgelesen werden.<br /> <br /> == Testverfahren und Bewertung ==<br /> <br /> Interessierte Addon-Entwickler können ihr Addon direkt über das [http://oat-online.de/einsenden.php Online-Formular] einsenden.<br /> <br /> [[Datei:OATIconExplanation.jpg‎|right|Erklärung zum OAT-Testsiegel]]Die OAT veröffentlicht den jeweiligen Testbericht nach der Testphase auf der offiziellen Website [http://www.oat-online.de www.oat-online.de]. Daraus gehen zum Einen die Einzelwertungen, zum anderen die wichtigsten Punkte (Positiv- und Negativlisten) sowie die Gesamtpunktzahl des Addons hervor. Bei allen Tests soll größtmögliche Transparenz walten. Daher veröffentlichen wurden auf der Website außerdem Leitfäden und Empfehlungen veröffentlicht. Nach der Meinung der OAT sind die dort genannten Kriterien elementar für &quot;das perfekte Addon&quot;, und sie sind zugleich auch die Bewertungsmaßstäbe für Testsphasen.<br /> <br /> Die maximal erreichbare Punktzahl beträgt für alle Einsendungen 100 Punkte. Je nach Art des Addons werden die Kriterien verschieden gewählt und teilweise auch gewichtet, um den vielfältigen Anforderungen gerecht zu werden. Die erreichte Punktzahl wird im OAT-Testsiegel (siehe Beispielbild) dargestellt. Mit diesem Siegel kann der Entwickler des Addons überall für sein Addon &quot;werben&quot; und somit zeigen, dass er sich um Qualität bemüht.<br /> <br /> == Weblinks ==<br /> [http://www.oat-online.de www.oat-online.de]<br /> <br /> [[Kategorie:Anschlussprojekte]]<br /> <br /> [[en:OMSI Addon Testers (OAT)]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=OMSI_Addon_Tester_(OAT)&diff=139 2011-09-12T21:37:42Z

<p>Janniboy: Überschrift angepasst</p> <hr /> <div>== Gründung und Zielsetzung ==<br /> <br /> Die OMSI Addon Tester - kurz &quot;OAT&quot; - sind ein Zusammenschluss von Mitgliedern aus dem offiziellen OMSI-Forum.<br /> Gegründet wurde die OAT am 30. April 2011 durch die OMSI-Forenmitglieder Yufa, Felix01 und Janniboy ([http://omnibussimulator.forumieren.com/t4415p60-prufung-neuer-maps Link zum Thread]).<br /> <br /> Die OAT ([http://www.oat-online.de www.oat-online.de]) hat es sich zum Ziel gesetzt, kostenlose OMSI-Addons von Privatpersonen sachlich und objektiv zu bewerten.<br /> Damit soll einerseits interessierten Benutzern bereits vor dem Download ein Einblick darin geben werden, was sie mit dem Addon erwartet; andererseits soll so dazu beigetragen werden, dass sich die Qualität von OMSI-Addons mit der Zeit steigert.<br /> <br /> All das fasst die OAT in einem Statement-Satz zusammen:<br /> ''&quot;Wir möchten die Autoren aktiv dabei unterstützen, ihre Addons zu perfektionieren.&quot;''<br /> <br /> Alle Mitarbeiter der OAT arbeiten ehrenamtlich, jeder kann sich bewerben. Welche Kriterien ein Addon-Tester erfüllen sollte und was von ihm erwartet wird, kann [http://oat-online.de/info_bewerben.php hier] nachgelesen werden.<br /> <br /> == Testverfahren und Bewertung ==<br /> <br /> Interessierte Addon-Entwickler können ihr Addon direkt über das [http://oat-online.de/einsenden.php Online-Formular] einsenden.<br /> <br /> [[Datei:OATIconExplanation.jpg‎|right|Erklärung zum OAT-Testsiegel]]Die OAT veröffentlicht den jeweiligen Testbericht nach der Testphase auf der offiziellen Website [http://www.oat-online.de www.oat-online.de]. Daraus gehen zum Einen die Einzelwertungen, zum anderen die wichtigsten Punkte (Positiv- und Negativlisten) sowie die Gesamtpunktzahl des Addons hervor. Bei allen Tests soll größtmögliche Transparenz walten. Daher veröffentlichen wurden auf der Website außerdem Leitfäden und Empfehlungen veröffentlicht. Nach der Meinung der OAT sind die dort genannten Kriterien elementar für &quot;das perfekte Addon&quot;, und sie sind zugleich auch die Bewertungsmaßstäbe für Testsphasen.<br /> <br /> Die maximal erreichbare Punktzahl beträgt für alle Einsendungen 100 Punkte. Je nach Art des Addons werden die Kriterien verschieden gewählt und teilweise auch gewichtet, um den vielfältigen Anforderungen gerecht zu werden. Die erreichte Punktzahl wird im OAT-Testsiegel (siehe Beispielbild) dargestellt. Mit diesem Siegel kann der Entwickler des Addons überall für sein Addon &quot;werben&quot; und somit zeigen, dass er sich um Qualität bemüht.<br /> <br /> === Weblinks ===<br /> <br /> [http://www.oat-online.de www.oat-online.de]<br /> <br /> [[Kategorie:Anschlussprojekte]]<br /> <br /> [[en:OMSI Addon Testers (OAT)]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=OMSI_Addon_Tester_(OAT)&diff=138 2011-09-12T21:37:13Z

<p>Janniboy: /* Gründung und Zielsetzung */</p> <hr /> <div>== Gründung und Zielsetzung ==<br /> <br /> Die OMSI Addon Tester - kurz &quot;OAT&quot; - sind ein Zusammenschluss von Mitgliedern aus dem offiziellen OMSI-Forum.<br /> Gegründet wurde die OAT am 30. April 2011 durch die OMSI-Forenmitglieder Yufa, Felix01 und Janniboy ([http://omnibussimulator.forumieren.com/t4415p60-prufung-neuer-maps Link zum Thread]).<br /> <br /> Die OAT ([http://www.oat-online.de www.oat-online.de]) hat es sich zum Ziel gesetzt, kostenlose OMSI-Addons von Privatpersonen sachlich und objektiv zu bewerten.<br /> Damit soll einerseits interessierten Benutzern bereits vor dem Download ein Einblick darin geben werden, was sie mit dem Addon erwartet; andererseits soll so dazu beigetragen werden, dass sich die Qualität von OMSI-Addons mit der Zeit steigert.<br /> <br /> All das fasst die OAT in einem Statement-Satz zusammen:<br /> ''&quot;Wir möchten die Autoren aktiv dabei unterstützen, ihre Addons zu perfektionieren.&quot;''<br /> <br /> Alle Mitarbeiter der OAT arbeiten ehrenamtlich, jeder kann sich bewerben. Welche Kriterien ein Addon-Tester erfüllen sollte und was von ihm erwartet wird, kann [http://oat-online.de/info_bewerben.php hier] nachgelesen werden.<br /> <br /> === Testverfahren und Bewertung ===<br /> <br /> Interessierte Addon-Entwickler können ihr Addon direkt über das [http://oat-online.de/einsenden.php Online-Formular] einsenden.<br /> <br /> [[Datei:OATIconExplanation.jpg‎|right|Erklärung zum OAT-Testsiegel]]Die OAT veröffentlicht den jeweiligen Testbericht nach der Testphase auf der offiziellen Website [http://www.oat-online.de www.oat-online.de]. Daraus gehen zum Einen die Einzelwertungen, zum anderen die wichtigsten Punkte (Positiv- und Negativlisten) sowie die Gesamtpunktzahl des Addons hervor. Bei allen Tests soll größtmögliche Transparenz walten. Daher veröffentlichen wurden auf der Website außerdem Leitfäden und Empfehlungen veröffentlicht. Nach der Meinung der OAT sind die dort genannten Kriterien elementar für &quot;das perfekte Addon&quot;, und sie sind zugleich auch die Bewertungsmaßstäbe für Testsphasen.<br /> <br /> Die maximal erreichbare Punktzahl beträgt für alle Einsendungen 100 Punkte. Je nach Art des Addons werden die Kriterien verschieden gewählt und teilweise auch gewichtet, um den vielfältigen Anforderungen gerecht zu werden. Die erreichte Punktzahl wird im OAT-Testsiegel (siehe Beispielbild) dargestellt. Mit diesem Siegel kann der Entwickler des Addons überall für sein Addon &quot;werben&quot; und somit zeigen, dass er sich um Qualität bemüht.<br /> <br /> <br /> === Weblinks ===<br /> <br /> [http://www.oat-online.de www.oat-online.de]<br /> <br /> [[Kategorie:Anschlussprojekte]]<br /> <br /> [[en:OMSI Addon Testers (OAT)]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=OMSI_Addon_Tester_(OAT)&diff=137 2011-09-12T21:36:27Z

<p>Janniboy: Weblinks hinzugefügt, Überschriften verkleinert</p> <hr /> <div>=== Gründung und Zielsetzung ===<br /> <br /> Die OMSI Addon Tester - kurz &quot;OAT&quot; - sind ein Zusammenschluss von Mitgliedern aus dem offiziellen OMSI-Forum.<br /> Gegründet wurde die OAT am 30. April 2011 durch die OMSI-Forenmitglieder Yufa, Felix01 und Janniboy ([http://omnibussimulator.forumieren.com/t4415p60-prufung-neuer-maps Link zum Thread]).<br /> <br /> Die OAT ([http://www.oat-online.de www.oat-online.de]) hat es sich zum Ziel gesetzt, kostenlose OMSI-Addons von Privatpersonen sachlich und objektiv zu bewerten.<br /> Damit soll einerseits interessierten Benutzern bereits vor dem Download ein Einblick darin geben werden, was sie mit dem Addon erwartet; andererseits soll so dazu beigetragen werden, dass sich die Qualität von OMSI-Addons mit der Zeit steigert.<br /> <br /> All das fasst die OAT in einem Statement-Satz zusammen:<br /> ''&quot;Wir möchten die Autoren aktiv dabei unterstützen, ihre Addons zu perfektionieren.&quot;''<br /> <br /> Alle Mitarbeiter der OAT arbeiten ehrenamtlich, jeder kann sich bewerben. Welche Kriterien ein Addon-Tester erfüllen sollte und was von ihm erwartet wird, kann [http://oat-online.de/info_bewerben.php hier] nachgelesen werden.<br /> <br /> <br /> === Testverfahren und Bewertung ===<br /> <br /> Interessierte Addon-Entwickler können ihr Addon direkt über das [http://oat-online.de/einsenden.php Online-Formular] einsenden.<br /> <br /> [[Datei:OATIconExplanation.jpg‎|right|Erklärung zum OAT-Testsiegel]]Die OAT veröffentlicht den jeweiligen Testbericht nach der Testphase auf der offiziellen Website [http://www.oat-online.de www.oat-online.de]. Daraus gehen zum Einen die Einzelwertungen, zum anderen die wichtigsten Punkte (Positiv- und Negativlisten) sowie die Gesamtpunktzahl des Addons hervor. Bei allen Tests soll größtmögliche Transparenz walten. Daher veröffentlichen wurden auf der Website außerdem Leitfäden und Empfehlungen veröffentlicht. Nach der Meinung der OAT sind die dort genannten Kriterien elementar für &quot;das perfekte Addon&quot;, und sie sind zugleich auch die Bewertungsmaßstäbe für Testsphasen.<br /> <br /> Die maximal erreichbare Punktzahl beträgt für alle Einsendungen 100 Punkte. Je nach Art des Addons werden die Kriterien verschieden gewählt und teilweise auch gewichtet, um den vielfältigen Anforderungen gerecht zu werden. Die erreichte Punktzahl wird im OAT-Testsiegel (siehe Beispielbild) dargestellt. Mit diesem Siegel kann der Entwickler des Addons überall für sein Addon &quot;werben&quot; und somit zeigen, dass er sich um Qualität bemüht.<br /> <br /> <br /> === Weblinks ===<br /> <br /> [http://www.oat-online.de www.oat-online.de]<br /> <br /> [[Kategorie:Anschlussprojekte]]<br /> <br /> [[en:OMSI Addon Testers (OAT)]]</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Kategorie:Anschlussprojekte&diff=132 2011-09-12T18:16:44Z

<p>Janniboy: Die Seite wurde neu angelegt: „== Die OMSI Addon Tester (OAT) == '''Gründung und Zielsetzung''' Die OMSI Addon Tester - kurz &quot;OAT&quot; - sind ein Zusammenschluss von Mitgliedern aus dem offizie…“</p> <hr /> <div>== Die OMSI Addon Tester (OAT) ==<br /> <br /> <br /> '''Gründung und Zielsetzung'''<br /> <br /> Die OMSI Addon Tester - kurz &quot;OAT&quot; - sind ein Zusammenschluss von Mitgliedern aus dem offiziellen OMSI-Forum.<br /> Gegründet wurde die OAT am 30. April 2011 durch die OMSI-Forenmitglieder Yufa, Felix01 und Janniboy ([http://omnibussimulator.forumieren.com/t4415p60-prufung-neuer-maps Link zum Thread]).<br /> <br /> Die OAT ([http://www.oat-online.de www.oat-online.de]) hat es sich zum Ziel gesetzt, kostenlose OMSI-Addons von Privatpersonen sachlich und objektiv zu bewerten.<br /> Damit soll einerseits interessierten Benutzern bereits vor dem Download ein Einblick darin geben werden, was sie mit dem Addon erwartet; andererseits soll so dazu beigetragen werden, dass sich die Qualität von OMSI-Addons mit der Zeit steigert.<br /> <br /> All das fasst die OAT in einem Statement-Satz zusammen:<br /> ''&quot;Wir möchten die Autoren aktiv dabei unterstützen, ihre Addons zu perfektionieren.&quot;''<br /> <br /> Alle Mitarbeiter der OAT arbeiten ehrenamtlich, jeder kann sich bewerben. Welche Kriterien ein Addon-Tester erfüllen sollte und was von ihm erwartet wird, kann [http://oat-online.de/info_bewerben.php hier] nachgelesen werden.<br /> <br /> <br /> '''Testverfahren und Bewertung'''<br /> <br /> Interessierte Addon-Entwickler können ihr Addon direkt über das [http://oat-online.de/einsenden.php Online-Formular] einsenden.<br /> <br /> [[Datei:OATIconExplanation.jpg‎|right|Erklärung zum OAT-Testsiegel]]Die OAT veröffentlicht den jeweiligen Testbericht nach der Testphase auf der offiziellen Website [http://www.oat-online.de www.oat-online.de]. Daraus gehen zum Einen die Einzelwertungen, zum anderen die wichtigsten Punkte (Positiv- und Negativlisten) sowie die Gesamtpunktzahl des Addons hervor. Bei allen Tests soll größtmögliche Transparenz walten. Daher veröffentlichen wurden auf der Website außerdem Leitfäden und Empfehlungen veröffentlicht. Nach der Meinung der OAT sind die dort genannten Kriterien elementar für &quot;das perfekte Addon&quot;, und sie sind zugleich auch die Bewertungsmaßstäbe für Testsphasen.<br /> <br /> Die maximal erreichbare Punktzahl beträgt für alle Einsendungen 100 Punkte. Je nach Art des Addons werden die Kriterien verschieden gewählt und teilweise auch gewichtet, um den vielfältigen Anforderungen gerecht zu werden. Die erreichte Punktzahl wird im OAT-Testsiegel (siehe Beispielbild) dargestellt. Mit diesem Siegel kann der Entwickler des Addons überall für sein Addon &quot;werben&quot; und somit zeigen, dass er sich um Qualität bemüht.</div>

Janniboy http://wiki.omnibussimulator.de/omsiwikineu.de/index.php?title=Datei:OATIconExplanation.jpg&diff=131 2011-09-12T18:14:41Z

<p>Janniboy: Quelle ist die offizielle Website www.oat-online.de Urheber der Grafik: Jan Kiesewalter (Upload genehmigt)</p> <hr /> <div>Quelle ist die offizielle Website www.oat-online.de<br /> Urheber der Grafik: Jan Kiesewalter (Upload genehmigt)</div>

Janniboy