Diskussion:Ennos Vorlageskript

Transporte und Ad-Hoc Befehle

Dies kann man allerdings auch mit @GIB (und natürlich ROUTE für die Trnsporteure) erreichen und ist dann sogar NMR-Sicher, das heißt das läuft bis ans Ende aller Tage unabhängig von outgame Ereignissen (ingame kann natürlich der Nachbar/Verbündete immer dazwischen funken).

Steinbauer (kies)
 MACHE Stein
 @GIB tran 2 Stein

Transporteure (tran)
 ROUTE w PAUSE o PAUSE
 @GIB bau ALLES Stein

Burgenbauer (bau)
 MACHE burg xyz

Das kann man natürlich mit Vorlage ergänzen. Z. B. das Burgenbauer (bau) nur bei genug Steinen arbeitet und an sonsten lernt. Aber solches Mikromanagement ist mMn selten von gewinn gekröhnt. K

Hat aber den Nachteil, dass man viele Fehlermeldungen kriegt: "Einheit xyz nicht gefunden." --Solthar

Was Solthar sagt. Ich habe das anfangs auch so probiert, mich dann aber auf den Standpunkt gestellt, das Fehlermeldungen mir nur echte Fehler zeigen sollen, und nicht sowas. Ausserdem ist bei meiner Lösung alles in einer Einheit versammelt, und nicht über mehrere verteilt. Das heisst, wenn ich meine transporter umrouten will, muss ich nur bei ihnen was ändern, nicht auch noch bei der Geber-Einheit. --Enno 01:00, 4. Jan. 2010 (CET)

Der für mich alles entscheidende Nachteil bei @-Befehlen: die Einheit verbleibt erstmal unbestätigt. Ich möchte mich letztlich auschließlich mit Einheiten beschäftigen, die ein Problem haben, mit irgendetwas fertig sind oder neu sind - alle anderen möchten bitte nach dem Scriptlauf (egal ob Vorlage, Extended Commands oder eigene Tools) bereits bestätigt sein. Die unbestätigten Einheiten durchgehen und die Fehlermeldungen untersuchen - dass bleibt als "Wichtiges" übrig. Fiete 14:05, 4. Jan. 2010 (CET)

// #ifunit tran { gib tran alles Stein } damit wird der GIB Befehl nur ausgeführt wenn der Transporter wirklich in der Region ist = keine Fehlermeldung. Bleibt der von Enno erwähnte Nachteil, dass ich zwei Einheiten umstellen muss wenn ich was ändern will --Xolgrim

Gruppenzugehörigkeit

Ich empfehle für die Sortierung nicht die Gruppe, sondern das Nutzen eines extra dafür vorgesehenen Tags in Magellan. Wenn Gruppeneigenschaften genutzt werden sollen (verschiedenen Status zu bestimmten Parteien) müssen sonst verschiedene Gruppen eingerichtet werden (Krieger_Heimat, Krieger_Feind1, Krieger_Feind2, ... ).

Bei den verfügbaren Gliederungsebenen in Magellan (siehe Optionen, Übersicht) gibt es die Ebene Tag "ejcTaggableComparator" (und weitere Tag ""s). Die Tags können und müssen beim Scriptlauf gesetzt werden, da sie kein Teil der Befehle an den Eressea-Server sind und auch nicht von diesem "zurückkommen". Kann leider nicht nachschauen, wie entsprechender Befehl bei Vorlage lautet. Dieses Tag eignet sich perfekt für Sortierung nach und durch das script, da es explizit durch das script gesetzt werden kann und sofort wirksam ist (noch ein Vorteil über die Gruppe, deren Änderung ja auch eine Runde über den Server braucht). Fiete 15:29, 4. Jan. 2010 (CET)

Tag mit Vorlage setzen: CmdTag (Fiete 15:33, 4. Jan. 2010 (CET))

Cool. Das werde ich benutzen. Es war mir unwohl bei den Gruppen, zumal der Eressea-Server diese Woche ein Problem damit hat, das in E2 in einer Region so viele Gruppen (und damit Heere) hat, dass das Limit von 128 Armeen in einem Kampf überschritten wurde... --Enno 04:05, 6. Jan. 2010 (CET)

Ist jetzt im Skript so eingebaut. --Enno 22:30, 9. Jan. 2010 (CET)

Skill-Bug

Wie ich im Forum schon schrieb, müsste es statt

 #proc dig $item $skill
 {
   #if region.resource[$item].skill>unit.Talente[$skill].Stufe {

meiner Meinung nach

   #if region.resource[$item].skill>unit.$skill.Stufe {

heißen. Unit.Talente nimmt als Index nur Zahlen. --Solthar 16:47, 10. Jan. 2010 (CET)

Danke, ist korrigiert. Seht ihr, deshalb ist es eine gute Idee, seinen Krempel mit anderen Menschen zu teilen - man lernt immer noch was dazu :-) --Enno 06:01, 11. Jan. 2010 (CET)