AnnoZone Forum

ich möchte diesen thread benutzen um hilfreiche erfahrungen, tipps, noch nicht bekannte syntax für das skripten in 1503 zusammenzutragen.
biete gebt auch an mit welcher version (1.04.02 oder addon) ihr einen befehl erfolgreich verwenden konntet.

------------------------------------------------------------------------
als ersten beitrag meine syntax zu SELECTED_CURSORCONSTRUCTION. (unter version 1.04.02)
bedeutung des befehls, noch nicht in allen einzelheiten getestet: erkennt ein bestimmtes im baumenü ausgewähltes bauwerk und erlaubt es darauf zu reagieren.
beispiel:

IF PLAYER "<spieler>" SELECTED_CURSORCONSTRUCTION "<gebäude-ID>" THEN
{
anweisungen
}

nun ja, sofern ihr die id für den uferkontor (1302) eingebt entstehen die im anderen thread geschliderten probleme,*gg.

nachtrag 2004-05-10: nach meinen experimenten bin ich mir ziemlich sicher, dass die abfrage nur im baumenü durchgeführt wird. die abfrage scheitert beim bauen aus dem schiffs- und scout-menü.
1.04.02: schiff und scout getestet
1.04.328.01: schiff getestet
irgendwie typisch 1503: gute idee aber einfach nicht zu ende gedacht.
------------------------------------------------------------------------

annokrat

meine erfahrungen mit der anweisung unter version 1.04.328.01

IF AREA "<area-object>" TOUCHED_BY_CONSTRUCTION "<gebäude-id>@<SpAlias>" THEN
{
anweisungen
}

das "touched" ist wörtlich zunehmen. liegt das gebäude innerhalb der area ist die abfrage erfolglos. das gebäude muss den rand der area überbauen.
es sieht so aus, als ob der einflussbereich des gebäudes, der zur auslösung von bedeutung ist, 10 felder, ausgehend vom ankerfeld des gebäudes, betragen könnte.
der reguläre einflussbereich eines gebäudes ist es nicht, auch nicht der tatsächliche umriss.

da diese abfrage so ziemlich unbrauchbar ist, habe ich die verwendung erst mal verworfen... und auch weitere tests dazu.

annokrat

ich würde sagen, es heisst "SHOWTEXT", nicht -MESSAGE.

ich denke das SET VARIABLE ist nichts anderes als die variablendefinition, wobei du halt sofort einen wert zuweisen musst.

annokrat

SHOW... hat ja nicht zwangsläufig was mit der questlog zu tun??
mit SHOWTEXT kannst du lediglich ein beliegiges htm-file als zusätzliche info bei bestimmten ereignissen auf dem bildschirm ausgeben.
wie bist du auf die anweisung SHOWMESSAGE gestossen? die macht ja nur sinn wenn sie einen unterschied zu ...TEXT darstellt(ok, hat bei 1503 nichts zu heissen, trotzdem, so dämlich kann eigentlich niemand sein).
könnte es sein, dass du bei MESSAGE nicht ein htm-file ausgibst, sondern den text, der in der zugeordneten klammer steht?

zu den variablen:
ich denke da gibt es 2 bereiche. einmal den definitionsbereich mit SET <variable>=<boolean>, zum andern den signals-bereich, der vielleicht den aktuellen wert der variablen speichert, so dass beim reload die werte rekonstruiert werden können.

annokrat

hat sich schon mal jemannd mit den ATTACK_-befehlen auseinandergsetzt?
ich versuche sie ohne erfolg unter der addon-version zuverwenden.
ich bin mir auch ziemlich sicher, dass die befehle in dem kirchen-verteidigungsscene verwendet werden, zumindest ATTACK_OBJECT.
bei ATTACK_AREA("CG01", "N3_T03") geschieht nichts, obwohl das gebiet N3_T03 komplett auf gegnerischem gebiet von HUMAN01 liegt und auch lohnende angriffsziele bietet(mhh, salz- und werkzeugproduktion). das programm verzweigt in diese bedingte anweisung(überprüfe ich durch setzen eines fähnchens auf der minimap).
die gleichen effekte (=NULL) erziele ich mit ATTACK_OBJECT("CG01", "CITY_XY", 7).
die einzige möglichkeit angriffe auszulösen besteht durch SET_DIPLOMACY(....,...; -128 ). dann läuft jedoch lediglich das bekannte einfältige anlanden der truppen auf der hauptinsel nahe des kontors ab. diese angriffe verebben allerdings auch wenn ich bei jedem skriptdurchlauf SET_DIPLOMACY(...,..., -128 ) vorgebe.

ich habe immer noch die hoffnung, dass mir irgendein blöder fehler unterläuft....
ansonsten beginnt mich das skripting böse anzukotzten.

einen wert im cg-profil habe ich wahrscheinlich geklärt: ZIELGRUPPE legt die maximal angestrebte bevölkerungsgruppe an (0 = pioniere, 1 = siedler, 2 = bürger, 3 = kaufleute). zumindest blieb ein CG mit wert 1 bei siedler ganz hartnäckig stehen. nach dem ich im savegame mit hex-ed den wert auf 3 geändert hatte und das spiel startete stürzte der cg los und erschloss eine gewürzinsel und baute eine grosse kirche.
es gibt da noch einen wert ZIELANZAHL. darin könnte die maximal zu erreichende einwohner zahl der ZIELGRUPPE stecken. da der wert jedoch überall auf 0 steht befürchte ich, dass das auch ein lost feature ist.
was passiert wenn der cg mehr als 1900 kaufleute hat und ZIELGRUPPE = 4 vorgegeben ist? das problem beginnt leider schon damit, dass der cg nie 1900 kaufleute besitzt und ich keine idee habe ihn dazu zu bringen.

sooo, das waren gerade mal meine neuesten, zum grössten teil frustigen skripterfahrungen.

annokrat

na, wer sagt es denn! ich muss mir nur mehr mühe geben

ich habe 2 veränderungen am skript vorgenommen und jetzt scheint es zu funktionieren:
1.) bevor ich ATTACK_AREA() aufrufe setze ich SET_DIPLOMACY("CG","HUMAN01", -127) an stelle von -128 vorher(die -127 habe ich der belagerungsmission entnommen).
2.) ich sorge dafür, dass der ATTACK-befehl nur einmal ausgeführt wird.

ich könnte mir vorstellen, dass 2.) die lösung ist. vielleicht gibt es nach ausführen von ATTACK eine art totzeit, die jedesmal beim erneuten aufruf wieder auf 0 gesetzt wird, so dass es nie zum angriff kommt wenn der ATTACK-befehl bei jedem skriptdurchlauf ausgeführt wird.
auf alle fälle überrennen mich zur zeit die cgs, die auf der gleichen insel siedeln. ausserdem landen die anderen auch truppen an. mein scene scheint jetzt sehr unausgewogen, weil ich nicht in der lage bin das geld für den truppennachschub bereitzustellen. entweder werde ich pleite gehen oder die schiessen mir meine stadt zusammen... oder beides

mich freut, dass die cg-nachbarn tatsächlich über land angreifen.
jetzt muss ich noch die ATTACK_OBJECT("CG","CITY_XY",7)-anweisung zum laufen bringen.

annokrat

so wie es aussieht bin ich an eine grenze des skriptsystems gestossen:
es können maximal 32 variablen definiert werden.
die schütti-gedenk-variable zählt dabei nicht, denke mir, dass die den "wert" des möwengags besitzt.

annokrat

"2. Die gabs aber schon vor dem AddOn..."

da siehst du, dass die auch schon früher auf tolle ideen gekommen sind, leider vollkommen unbeachtet. das haben sie dann mit den möwen geändert


"2. Hab noch gar nie versucht, was passiert, wenn man die Gedenkvariable FALSe setzt oder weglässt.."

ich denke mal sowas funktioniert nicht, sonst hätte sie ja ihre gedenkfunktion verloren.


aber noch mal zu den variablen.
ich habe das single30 ungeschaut und bin darauf gestossen, dass es unter SIGNALS mit gedenkvar genau 40 sind, 32 mit wert FALSE, 8 mit wert TRUE.
dem entsprechend habe ich dann meine variablen definiert: 32 mit FALSE, 8 mit TRUE, gedenkvar habe ich nicht berücksichtigt, da ich annehme, dass es keine variable im skriptsinn ist(es existiert ja nirgends ein SET <variable> = TRUE).
es gelingt mir genau 40 variablen unter SIGNALS einzutragen, 32 mit FALSE und 8 mit TRUE... ich weiss, klingt total bescheuert, ist aber so. erhöhung von 32 oder 8 führt zum absturz.

allerdings definiert SIGNALS wohl nur die "übergabe"-parameter beim reload eines games, so dass diese 32+8-grenze wahrscheinlich nur für variablen gilt, deren aktueller wert für das nächste reload eines savegames gespeichert werden muss.
variablen, die bei jedem reload den gleichen startwert haben sollen, dürften von dieser begrenzung nicht betroffen sein.
.... was noch zu testen wäre...

annokrat

lol, wenn du recht hast, dann hättest du für mich einen brutalen fehler gefunden.
an befehlen für areas doktore ich schon geraume zeit rum, ohne anhaltenden erfolg.
ich habe die ganzen inseln in aneinander grenzende areas aufgeteilt (end-x des einen gebietes ist anfangs-x des nächsten, für y analog), allerdings habe ich schon die ganze zeit den verdacht, dass die anweisungen auf area nicht funktionieren, obwohl ich vorher tests mit einem area gemacht hatte.
... muss ich auch mal versuchen, nicht identische werte für die grenzen zu definieren.

annokrat