In TTDPatch ist die KI ja in der Lage nicht nur Fz sondern auch Bahnhöfe ja nach Bedarf zu bauen, und zwar gesteuert über den Callback 18.

D.h. bei Benutzung von zB NewStations bauen die Künstlichen verschiedene Bhfe, ja nachdem ob sie Passagiere oder eine andere Fracht, im Fern- oder im Nahverkehr, etc bewegen wollen.

Mich haben in letzter Zeit ein paar emails erreicht von Leuten die mittlerweile mit den neuen AI von OTTD spielen (wollen), wo dies anscheinend nicht (richtig) funktioniert.

Leider habe ich nicht Zeit alles selber auszuprobieren, deshalb frage ich mal die OTTD-Experten hier:

Können in OTTD die neuen AI lediglich Standardbhfe bauen oder bauen sie auch die verschiedenen "neuen Bahnhöfe" wie in TTDPatch? Gegebenenfalls: muss man irgendwas einstellen damit dies funktioniert?

Experten²frage: ist CB18 wie in TTDPatch implementiert?

Gruß
Michael

Also ich bin kein Experte, da ich nur selten bis gar nicht mit KIs spiele.

Ich würde sagen, du solltest dich direkt an Yexo oder das NoAI Forum wenden.

Es gibt auch eine Dokumentation, aber ich finde da spontan nix was NewStations betreffen würde.

also ich hab mal gestöbert, weil ich grob in Erinnerung hatte, daß CB18 mal diskutiert wurde:

#openttd schrieb:[Mo Okt 20 2008] [01-34-29] <DaleStan> Yexo: Re: CB18. I have no clue. Check the source (grep for "18" and "callback" in the same line and go from there) or ask patchman.
[Mo Okt 20 2008] [01-35-43] <Yexo> thx DaleStan, but we already decided that we won't use cb 18 for NoAI (at least not for trains)

#openttd schrieb:[... geht irgendwie um NFO Version 8 ...]
[Di Nov 11 2008] [19-38-24] <Yexo> cb18 (and maybe others) cannot be extended for more rail types currently
[Di Nov 11 2008] [19-39-11] <frosch123> Yexo: you can add new subtypes to cb18. so it does not need a grf version bump
[Di Nov 11 2008] [19-40-35] <petern> cb18 is an abomination anyway :)
[Di Nov 11 2008] [19-41-22] <DaleStan> <petern> 0xffff is a callback value of 0x7fff <-- not so in v4-v7.
[Di Nov 11 2008] [19-42-56] <Yexo> http://rbijker.net/openttd/newgrf_ai_train_purchase.txt <- as alternative to cb18 for trains. I was told a change like that needs a grf version bump, so maybe this is the time to consider that.
[Di Nov 11 2008] [19-45-17] <frosch123> Yexo: That suggestion would restrict callback 18 to be a noai only callback, and would stop supporting TTDP AIs. You have to add a new value for variable 86 for noai stuff. Then you can do what you like, without any version bump.
[Di Nov 11 2008] [19-45-54] <Yexo> frosch123: I don't see why a TTDP AI couldn't use that callback
[Di Nov 11 2008] [19-47-39] <frosch123> you have to discuss that with a patch dev. but I guess they will happily await your patch -)
[...]
[Di Nov 11 2008] [19-52-55] <Yexo> still, the current cb18 has "82 B default selection" where "default selection" is an EngineID when features = 00-03
[Di Nov 11 2008] [19-53-04] <Yexo> ie it doesn't work with the engine pool

#openttd schrieb:[Sa Jan 24 2009] [00-12-35] <petern> so, er, did newgrf's ability to decide which engine/wagon to buy get implemented?
[Sa Jan 24 2009] [00-12-40] <petern> (i assume not)
[Sa Jan 24 2009] [00-14-10] <Yexo> petern: no, because the current callback only supports 8 bit values
[Sa Jan 24 2009] [00-14-36] <Yexo> and I didn't exactly get much help trying to get a improved callback implemented
[Sa Jan 24 2009] [00-15-07] <Yexo> petern: http://rbijker.net/openttd/misc/newgrf_a...rchase.txt <- latest proposal for a new callback
[Sa Jan 24 2009] [00-17-44] <petern> can't read that, what's the jist?
[Sa Jan 24 2009] [00-18-07] <petern> whats wrong with the existing callback?
[Sa Jan 24 2009] [00-18-41] <Yexo> CB18? 1) it returns 8bit values for EngineID
[Sa Jan 24 2009] [00-19-09] <Yexo> 2) for road vehicles and ships you can only do 'check', not 'get'
[Sa Jan 24 2009] [00-19-44] <Yexo> hmm, 2) also holds for the train engines is seems
[Sa Jan 24 2009] [00-21-25] <Yexo> 3) the current callback can only return 2 engine ids, 1 for the engine and 1 for the wagon
[Sa Jan 24 2009] [00-21-55] <Yexo> that means it can never propose a train with a caboose wagon for example (like nars requires for human players, but not for AIs)
[Sa Jan 24 2009] [00-22-24] <frosch123> however, yexo: variables 80..ff can only be bytes, and you should not replace the existing callback, but add a new type to callback 18.
[Sa Jan 24 2009] [00-27-10] <Yexo> I'd still like to see that callback implement (in some way), but it's currently very low on my todo list

Ich weiß nicht, ob das in irgendeiner Form deine Frage beantwortet, aber es zeigt wohl eine Tendenz auf...

Also Yexo wies mich darauf hin, daß bei Bahnhöfen die KI-Entwickler einfach nur die Funktion AIRail::BuildNewGRFRailStation benutzen müssen.

auf die Gefahr mich lächerlich zu machen....

- gibt es....
- wird daran gearbeitet....

.... dass Züge selber erkennen, welches Gleis sie ansteuern müssen, wenn Sie einen Bhf mit verschiedenen Bahnsteigen anfahren?

Dass also ein Zug mit Viehwaggons "erkennt", dass der Fabrikbahnhof Bahnsteige mit Viehgattern und Kornspeichern hat, und bevorzugt (oder ausschließlich) das Viehverladegleis benutzt?

Nein. Dafür ist weder die NewGRF-Spezifikation noch der Pfadfinder ausgerüstet.

CB 18 für Stationen wird unterstützt. Wird auch von einigen AIs benutzt, und mir ist nichts darüber bekannt, dass es manchmal nicht funktionieren sollte.

Im Zweifelsfall würde ich die Schuld auf die AI schieben, sprich schicke die Bugreporter an die AI Autoren weiter


Für Fahrzeuge sieht das ganz anders aus. CB 18 wird dort nicht unterstützt und wird in der existierenden Form nicht unterstützt werden, weil er die Entscheidungsmöglichkeiten viel zu stark einschränkt. (Das NewGRF übernimmt die Rolle der AI)
Es gibt einen Vorschlag wie es anders sein könnte, der taucht auch oben in Eddis Post auf. Der Vorschlag ist allerdings technisch nicht vollständig korrekt (etwa Variablen ab 0x80 sind Offsets in einen kontinuierlichen Block), und auch sehr komplex für die NewGRFs.

Daher ist momentan das Ziel eine Bibliothek zu schreiben, die ähnlich wie Autoreplace durch Probieren einen gültigen Zug zusammenstellt. Wesentlich dafür sind CB 16 und 31.

Und hier kommen wir wieder zu einem "Bug" des DBSets der schon hunderte Male berichtet wurde. Nämlich dass es zu alt ist, um CB 31 zur Verfügung zu stellen. Wenn also die Bugreports der Form sind "Die Züge fahren mit STOP und MORE und ? Wagen" herum, so liegt es daran.
Maßgeblich für die AIs in OTTD ist immer das, was auch der Spieler darf. Und da man als Spieler solche Züge starten darf, und diese auch z.B. durch Autoreplace beim Spieler entstehen können, so darf das die AI auch.

frosch schrieb:Und hier kommen wir wieder zu einem "Bug" des DBSets der schon hunderte Male berichtet wurde. Nämlich dass es zu alt ist, um CB 31 zur Verfügung zu stellen. Wenn also die Bugreports der Form sind "Die Züge fahren mit STOP und MORE und ? Wagen" herum, so liegt es daran.

Das ist natürlich kein Bug sondern in diesem Fall ein unverstandenes Feature, das aber in der zur .grf gehörenden Liesmichnicht dokumentiert und erklärt ist. Wenn die .grf aber (unter Verstoss gegen das Urheberrecht) ohne diese Dokumentation weiter gegeben wird, kann ich daran im Einzelfall nichts ändern. Und wenn die Dokumentation vorhanden ist aber nicht gelesen wird kann ich daran erst recht nichts ändern. Wie die Züge zusammengebaut werden müssen ist dort ausreichend deutlich beschrieben.

frosch schrieb:Maßgeblich für die AIs in OTTD ist immer das, was auch der Spieler darf. Und da man als Spieler solche Züge starten darf, und diese auch z.B. durch Autoreplace beim Spieler entstehen können, so darf das die AI auch.

Auch das ist natürlich kein Bug. DBXL 0.82 ist diesbezüglich spezifikationskonform (action0, prop18). D.h. die KI darf/kann derartige Züge gar nicht bauen. Wenn OTTD dies (per noAI) mittlerweile anders handhabt so kann ich daran für 0.82 nichts ändern. Ich würde sagen, dass OTTD in diesem Fall ein Kompatibilitätsproblem hat.


DBXL 0.9 enthält das "MORE/STOP" Feature aber nicht mehr, da, wie du richtig schreibst, mittlerweile bessere Möglichkeiten zur Konfiguration von Triebzügen vorhanden sind.

Gruß
Michael

Ha! Dann sind die AIs auch zu faul, eine Readme zu lesen.

(18.08.2009 15:02)Bernhard schrieb:   auf die Gefahr mich lächerlich zu machen....

- gibt es....
- wird daran gearbeitet....

.... dass Züge selber erkennen, welches Gleis sie ansteuern müssen, wenn Sie einen Bhf mit verschiedenen Bahnsteigen anfahren?

Dass also ein Zug mit Viehwaggons "erkennt", dass der Fabrikbahnhof Bahnsteige mit Viehgattern und Kornspeichern hat, und bevorzugt (oder ausschließlich) das Viehverladegleis benutzt?

Ich sortiere die Züge vorher über verschiedene Eingangsgleise auf die richtigen Bahnsteige.

klar, per Waypoint... aber stell Dir vor wie schön das wäre, wenn ein Viehzug nur an Viehgleise, ein Getreidetransport nur an die Silos usw. fährt.....

Bernhard schrieb:klar, per Waypoint... aber stell Dir vor wie schön das wäre, wenn ein Viehzug nur an Viehgleise, ein Getreidetransport nur an die Silos usw. fährt.....

S. http://www.tt-ms.de/forum/showthread.php...8#pid31178 (März 2005 )

Gruß
Michael

Bernhard schrieb:klar, per Waypoint... aber stell Dir vor wie schön das wäre, wenn ein Viehzug nur an Viehgleise, ein Getreidetransport nur an die Silos usw. fährt.....

Das stell ich mir schon immer vor, das wäre für meine Art zu spielen sehr schön.

(27.08.2009 08:07)mb schrieb:  S. http://www.tt-ms.de/forum/showthread.php...8#pid31178 (März 2005 )

Gruß
Michael

Ja, die programmierbaren Signale sind klasse, gar keine Frage, damit kann man viel besser die Abläufe steuern.

(27.08.2009 08:07)mb schrieb:  

Bernhard schrieb:klar, per Waypoint... aber stell Dir vor wie schön das wäre, wenn ein Viehzug nur an Viehgleise, ein Getreidetransport nur an die Silos usw. fährt.....

S. http://www.tt-ms.de/forum/showthread.php...8#pid31178 (März 2005 )

Gruß
Michael

ja, ich weiß, das fehlt OTTD in meinen Augen wirklich!

Hallo

(27.08.2009 08:07)mb schrieb:  S. http://www.tt-ms.de/forum/showthread.php...8#pid31178 (März 2005 )

Weil du grad' wieder diesen Thread verlinktest, ist irgendwann damit zu rechnen, dass deine New Stations um die wunderschönen, im Thread gezeigten City Stations on Slopes und/oder (natürlich lieber und) andere Nettigkeiten ergänzt werden?

Programmierbare Signale wären (für OTTD) natürlich was feines, es gab ja mal einen Patch, der programmierbare Wegpunkte ermöglichte. War auch schick, aber mit Signalen sieht das natürlich dezenter aus.

Tschö, Auge

Auge schrieb:Weil du grad' wieder diesen Thread verlinktest, ist irgendwann damit zu rechnen, dass deine New Stations um die wunderschönen, im Thread gezeigten City Stations on Slopes und/oder (natürlich lieber und) andere Nettigkeiten ergänzt werden?

[OT! OT! OT!]

Na gut.

Aber ohne das "custom foundations" Feature (dass es mW im Moment ledig für TTDPatch gibt) würde dir das doch nix bringen.

Grundsätzlich zu NewStations: eine neue Version hat eine geringere Priorität als DBXL 0.9. Meine Arbeitsversion enthält zwar schon seit längerem einige neue Features ("platforms w custom foundations", "Trenngleise", ..., aber eben noch nicht die vier oder fünf "city stations" die ich für eine neue Version eingeplant hatte. Zudem gäbe es noch einige andere "Nettigkeiten" (zB "freight stations" (aber leider auch noch nicht komplett), oder Bhfs-Gleise mit (fake) mittlerem Gleis). Insofern ist eine neue Version von NewStations zZt noch eine richtige Baustelle, die ich übrigens seit Monaten nicht mehr inspiziert hatte.

Auge schrieb:Programmierbare Signale wären (für OTTD) natürlich was feines, es gab ja mal einen Patch, der programmierbare Wegpunkte ermöglichte. War auch schick, aber mit Signalen sieht das natürlich dezenter aus.

WIMRE haben wir darüber schon mehrfach diskutiert. Ich persönlich bevorzuge für diesen Zweck Signale statt "Wegpunkte", allein schon aus zwei offensichtlichen Gründen: eine grössere Anzahl an Signalen sehen einfach besser ("pseudo-realistischer", hehe) als eine gehäufte Anzahl von "Wegpunkten" aus; und Züge halten mW eben an Signalen und nicht an "Wegpunkten". Aber wie wir seit längerem wissen hängen die OTTD-Entwickler anscheinend an diesem missgestalteten "Wegpunkt"-Konzept aus der Anfangszeit von OTTD, statt (wie in TTDPatch) "Wegpunkte" einfach als spezielle Stationen (und im Stations-Menü!) zu behandeln und die signalabhängigen Features als Signalfunktionen zu implementieren, anstatt ihr "Wegpunkt"-Konzept noch weiter mit nicht dahin gehörigen Funktionen auszubauen. Leider.

Gruß
Michael

(27.08.2009 20:54)mb schrieb:  Aber ohne das "custom foundations" Feature (dass es mW im Moment ledig für TTDPatch gibt) würde dir das doch nix bringen.

Ich möchte hierbei anmerken, daß die letzte (mir bekannte) Besprechung zu dem Thema ungefähr zwischen "Es sollte einfach so funktionieren" und "Ohne GRF können wir es nicht testen" verlief.

Zitat:[...] die OTTD-Entwickler [...]

Darf ich dich darauf hinweisen, daß "Entwickler eines Patches" und "Entwickler von OTTD" nicht notwendigerweise übereinstimmende Klassen sind?

In letzter Zeit hat sich beim Thema "vereinigen von Stationen und Wegpunkten" so einiges getan, und natürlich gibt es immer jemanden, der anderer Meinung ist.

Mir ist nicht bekannt, daß sich die OTTD-Devs jemals für oder gegen die Wegpunkt- oder Signalvariante ausgesprochen hätten. Meine Meinung dazu hab ich schon mehrfach dargelegt, und das gehört auch überhaupt nicht hier hin.

(27.08.2009 20:54)mb schrieb:  ..... Ich persönlich bevorzuge für diesen Zweck Signale statt "Wegpunkte", allein schon aus zwei offensichtlichen Gründen: eine grössere Anzahl an Signalen sehen einfach besser ("pseudo-realistischer", hehe) als eine gehäufte Anzahl von "Wegpunkten" aus; und Züge halten mW eben an Signalen und nicht an "Wegpunkten". ....

Man könnte ja die Wegpunktgrafiken umgestallten, zu Signalen! (Wären leider nur immer noch nicht zu programmieren!)

[mehr OT]

Bernhard schrieb:Man könnte ja die Wegpunktgrafiken umgestallten, zu Signalen! (Wären leider nur immer noch nicht zu programmieren!)

Und sie würden keinen Signalbegriff zeigen.

Gruß
Michael

Das brauchten sie ja auch nicht.
Könnten ja auch ein Fernsprechhäuschen VOR dem Signal sein, gibt es ja beim Vorbild auch.
   
So, Schluß mit OT oder soll ich splitten?