|
 |
 |
 |
|
|
c't Projekte - c't-Bot und c't-Sim -
Mailinglisten
[Voriger (Datum)]
[Nächster (Datum)]
[Voriger (Thread)]
[Nächster (Thread)]
[Nach Datum][Nach Thread]
Absender: Timo Sandmann
Datum: Do, 19.06.2008 13:30:55
In-reply-to:
<4858FD89.2030403@xxxxxxxx>
References:
<000001c8d09e$f363bff0$0200a8c0@mexpnew> <F57F05A6-3013-4A1D-9337-2358FB3DD378@xxxxxxxxxxxxxxx> <4858FD89.2030403@xxxxxxxx>
Hi,
Am 18.06.2008 um 14:20 schrieb Benjamin Benz:
<snip>
Vielleicht wäre auch ein Offset sinnvoll oder die Kombination mit
einem Verhalten "suche_Startpunkt"?
gute Idee. Denkbar wäre ja auch, dass es in der Welt irgendeinen
allgemeinen Bezugspunkt gibt, mit dem die Bots dann die Differenz
zueinander ausrechnen können und so das Offset bestimmen.
Wir könnten ganz allgemein mal überlegen, ob es Sinn macht, dass
ein Bot per Remote-Call ein Verhalten auf einem anderen Bot starten
kann (das entspricht hier dem go-Befehl).
Meinungen dazu?
Ich denke, dass wäre schon sinnvoll. dann könnte man ein Master-
Slave-Sywtem sehr einfach machen.
Und man hätte mit der Remotecall-Liste ein zentrales
"Verhaltensregister", über das nicht nur Remote-Calls, sondern auch
Starts per Fernbedienung (Ticket 168) und eben von anderen Bots aus
abgewickelt werden können => Eins für alles.
Der Bot-Code ist bisher nicht dafür ausgelegt, große Datenmengen zu
empfangen. Das Thema habe ich in einem anderen Zusammenhang schon
auf der ToDo-Liste. Am besten wäre eigentlich, wenn man die Daten
als Payload überträgt, aber nicht sofort, wie es zurzeit z.B. bei
den Remote-Calls ist, sondern dass der Bot beim Empfang eines
Kommandos die Payload beim Sim abholt. Der Sim müsste die Daten
dafür natürlich so lange puffern (IMHO ist das aber kein Nachteil).
Dann könnten wir eine Funktionen zum Payload-Abholen machen, die
dann von verschiedenen Codeteilen benutzt werden kann, z.B. für den
Positions-Stack oder Dateien und Programme, die man zum Bot
übertragen möchte. Ich glaube, das wäre die einzig stabile Lösung,
um mehr als ein paar Bytes zu einem realen Bot übertragen zu
können. Der Nachteil ist allerdings, dass wir schon wieder am Bot-2-
Sim-Protokoll schrauben müssten.
Meinungen hierzu?
Wie groß seht ihr denn die Notwendigkeit dafür?
Kommen so große Datenmengen denn in der Praxis vor, oder kann der
Sim einfach die Daten etwas "langsamer" ausliefern?
Wie willst du denn langsamer ausliefern? Nachricht N+1 erst dann
abschicken, wenn Versand von N bereits mindestens 10 ms zurückliegt?
Dann muss der Sim aber auch puffern, der Nachrichteneingang soll ja
nicht ebenfalls schlafen gelegt werden, oder?
Ich würde auch gern Programme zum Bot senden und das geht wohl nur als
Payload sinnvoll. Gut man kann auch die Payload noch wieder verzögern,
aber irgendwie gefällt mir so ein von außen aufgezwungenes Timing
nicht so sehr...
Außerdem sind vom Sim künstlich verzögerte Daten irgendwie unschön,
wenn ich die Nachrichten vielleicht mal mit einer anderen CPU am Bot
empfangen möchte und dort gar keine Verzögerung brauche.
Grüße,
Timo
|
|
|