Objekttypen

[Generalwest]

Da du weist was MARS bzw Warenlos. Fürn listenplatz hat (Main und Subtype) kannst du es direkt erzeugen.

Woher weiß ich das? Ich habe keine Ahnung von Main- und oder Subtypen oder woher ich die bekomme. Wie bereits gesagt - ich habe das noch nie gemacht!

Ok ich post gleich n script zum erfassen von waren und ain und subtype.

BZW ich post alle beiden Möglihkeiten: das was Uni meinte und ich....mom Scripten ist

[Reflexer]

ok - wenn ich Deinen Edit richtig verstehe, dann ist das bei Mars

Code: Select all

<page id="17" title="Cmd Desc" descr="">
 <t id="2213">MARS Ziel Projektions Erweiterung</t>
</page>

Maintype = 17
und
Subtype = 2213

Korrekt? Langsam erschließen sich hier die Zusammenhänge

[Gazz]

Jedes Ding in X3 hat Main/Subtype.

Alle Schiffe z.B. MT 7.


Bei den Trade commands gibts

1. get number of subtypes of maintype X
Wenn Max.Subtype kleiner als der für die Ware nötige, dann ist da ein Mod nicht installiert.

Also keine Prüfung > Max.Subtype, sonst Kabumm.

2. get MT / ST of ware X.
zum Abfragen derselben. Ware kann natürlich auch ein Schiffs- oder Raketentyp sein. Alles eben.


Wichtig wäre also nur, ob der Subtype des entsprechenden MT hoch genug ist - also ob z.B. ein Ware-Mod installiert ist,
und ob eine TFile-ID aus dem TFile des Scripts existiert. (genau dafür gibts einen eigenen Befehl)

Dann gibts da natürlich noch die SPK-installationen. Die können eigene Waren genereiren und haben Scripts, um diese wieder zu finden. Von SPK versteh ich aber nix.

[Generalwest]

um Gottes Willen stehst du neben dir.

Das ist Page ID und TID...das hat mit Main und Subtype nix zu tun.



hier Maintyp und Subtype Möglichkeiten:

114 $maintype = get maintype of ware Artefakte
115 $subtype = get subtype of ware Artefakte
116 * ODER
117 $obj = get player tracking aim
118 $maintype = $obj -> get maintype
119 $subtype = $obj -> get subtype
120 * ODER
121 * Page ID & TID der jeweiligen Scriptware
122 $Warename = read text: page=7790 id=98473
123 $Name = 'ReadText'
124 if not $Warename == $Name
125 end
126

Beim ReadText musst du etwas basteln.... Seit TC gibt es den Befehl

" 122 if = read text: page=7790 id=98473 exist" der Prüft ob sie PageID 6 TID existiert wenn nicht wird ja ReadText der Engien übergeben da die SS_WARE nur eine LISTENID deer entsprechenden Typesdatei ist (zum Beispiel TWareT oder der TShip etc pp)

Gazz: Die SPKs werden soweit ich weis über eine Variables Script in SE eingeführt. hat auch ein load Text etc pp ein readtext und füge waren in das spiel ein. zudem macht es immer einen kleinen Mod der geladen werden muss. beim letzen satz bin ich mir nicht sicher ob das bei nur scripts auch der fall ist.

[Gazz]

Tja, den TextID exist Befehl meinte ich vorher.

Auf Page 17, TextID 2213 zu testen ist aber Quatsch, denn da bekommt man immer den Standardtext, der auch bei den nicht benutzten Egosoft Waren nicht leer ist.

ABER wenn du (für MARS)
Page 7046 TID 6422101 prüfst,
dann ist sicher, daß speziell das MARS Textfile geladen wurde und nicht nur der Dummywert aus t\0001-L044.xml.

Und wenn die Prüfung OK ist, dann ist auch der Rest des selbigen Textfiles t\7046-L044.xml geladen worden - inclusive des Namens für eventuelle Waren.
Und die Tatsache, daß das File geladen wurde, beweist daß das setup file des Scripts derzeit funktioniert.
Das ist schon ein ziemlich sicherer Test für ein Script.

Gazz: Die SPKs werden soweit ich weis über eine Variables Script in SE eingeführt. hat auch ein load Text etc pp ein readtext und füge waren in das spiel ein. zudem macht es immer einen kleinen Mod der geladen werden muss. beim letzen satz bin ich mir nicht sicher ob das bei nur scripts auch der fall ist.

Ja, und es gibt libraries, mit denen sich die Scripts ihre extern installierten Waren wieder heraussuchen können.
Ich hab das glücklicherweise noch nie gebraucht. =P

[Reflexer]

so - die entsprechenden Typen hab ich also rausgefunden

Code: Select all

MARS:
MARS-Maintype:16
MARS-Subtype:20
WLS:
WLS-MK1-Maintype:16
WLS-MK1-Subtype:64
WLS-MK2-Maintype:16
WLS-MK2-Subtype:65
{SS_WARE_SW_NEW1}:
{SS_WARE_SW_NEW1}-Maintype:16
{SS_WARE_SW_NEW1}-Subtype:59

Damit sollte der Rest auch kein Problem mehr sein

Vielen Dank für die Hilfe. Ich wusste nicht, wie das mit den Main- und Subtypes ist, aber jetzt werde ich es hinbekommen

Die {SS_WARE_SW_NEW1} ist übrigens MEFOS

[Gazz]

Die MARS Ware existiert übrigens auch in Vanilla-TC.
Die Ware selbst kannst du direkt und ohne irgendeine Prüfung eingeben. Da passiert nix.

Sinnvoll ist es halt nur dann, wenn auch das zugehörige Script läuft.

[Reflexer]

Meine Prüfung um MARS als Erweiterung anzubieten sieht nun folgendermaßen aus:

Code: Select all

$tmpSector = get sector from universe index: x=1, y=1
$tmpWare = create flying ware: maintype=16 subtype=20 count=1 sector=$tmpSector x=20000 y=10000 z=30000 selfdestruct=null
$tmpName = $tmpWare -> get name
$tmpSubstring = get substring of $tmpName offset=0 length=2
if $tmpSubstring != 'SS'
  $tmpEntry = array alloc: size=3
  $tmpEntry[0] = $tmpWare
  $tmpNotoReq = get notoriety required to buy ware: $tmpWare
  * Rangcheck:
  if $MaxNoto >= $tmpNotoReq AND $tmpNotoReq != null
    $tmpEntry[1] = [TRUE]
  else
    $tmpEntry[1] = [FALSE]
  end
  $tmpEntry[2] = 108
  append $tmpEntry to array $tmpArray
end

$tmpWare -> destruct: show no explosion=[TRUE]

Analog für WLS und MEFOS und es funktioniert reibungslos

Vielen Dank an alle... vor allem an General

[Reflexer]

Die MARS Ware existiert übrigens auch in Vanilla-TC.
Die Ware selbst kannst du direkt und ohne irgendeine Prüfung eingeben. Da passiert nix.

Sinnvoll ist es halt nur dann, wenn auch das zugehörige Script läuft.

Dann kann ich mir die Prüfung ja bei MARS theoretisch sparen... wobei ich sie jetzt schon eingebaut habe Schadet ja nix

[Gazz]

Schadet ja auch nicht obwohl eine Prüfung, ob das Script läuft viel sinnvoller wäre.
Sonst wird die Ware auch angeboten wenn es gar keinen Sinn macht.

Übrigens - warum create flying ware? Ein echtes Objekt brauchst du nicht, da du sowieso nur mit dem ware type arbeitest.

Get ware from MT / ST tuts auch und ist einfacher.
Den Namen als String bekommt du auch mit
$tmpName = $tmpWare + 'x'
oder
$tmpName = sprintf: fmt='%s', $tmpWare

[Generalwest]

Übrigens - warum create flying ware? Ein echtes Objekt brauchst du nicht, da du sowieso nur mit dem ware type arbeitest.

da er mit get name <Obj> arbeitet.

ob das Script läuft. Sicher ist es Sinnvoll aber wenn der Waren Name nicht existiert bzw nur der Dummyname angezeigt wird ist die TFile nicht geladen worden, was das Bedeutet hast du ja schon näher erklärt



Naja in Vanilla müsste das MARS anders lauten den ich hab es soweit ich mich errinern kann nicht im log (Script Sammelpage bei mir @ Mai und Subtypliste incl Script). Da du aber den Namen via TFile überschreibst....

@

Und wenn die Prüfung OK ist, dann ist auch der Rest des selbigen Textfiles t\7046-L044.xml geladen worden - inclusive des Namens für eventuelle Waren.
Und die Tatsache, daß das File geladen wurde, beweist daß das setup file des Scripts derzeit funktioniert.
Das ist schon ein ziemlich sicherer Test für ein Script.

hier mal die 16 (und das du ein Wareneintrag verwendest der Vanilla mitbringt ist was anderes)

Code: Select all

Liste zu lang zum Posten denk ich

Das mit der Hilfe..bitte bitte

[Reflexer]

Genau. Anders kann ich keinen Vergleich machen.

Aber iss alles schick Es tut was es soll und bietet an, was es gibt und was es nicht gibt wird auch nicht angeboten.

Uuuuuund ich hab was dazugelernt!

Danke Männer

[ScRaT_GER]

da er mit get name <Obj> arbeitet.

Verstehe den Grund nicht. Das Ziel war doch folgendes:

Ich wollte eigentlich im Ship Order Manager Schiffserweiterungen anbieten, die der Spieler durch andere Scripts erhält wie z.B. MARS, MEFOS oder WLS.
Bsp:
Solange der WLS nicht installiert ist, gibt es den Warentyp {SS_WARE_SW_NEW6} . Durch die Installation des WLS wird dieser Typ auf {Warenlogistiksoftware MK1} gesetzt (über das t-File). Soweit so gut. Um die WLS als Erweiterung anzubieten müsste ich nun wissen, ob es die Ware gibt.

Da sollte es doch möglich sein es folgendermaßen zu machen:

Code: Select all

* Skript: lib.wls.installed
$ware = {SS_WARE_SW_NEW6} (1)
$wareString = printf: fmt='%s', $ware, null, null, null, null
if $wareString == 'Warenlogistiksoftware MKI' (2)
  return [TRUE]
else
  return [FALSE]
end

zu (1): Der SE speichert die Ware nicht wirklich als {SS_WARE_SW_NEW6}, sondern intern wird das natürlich irgendwie als Zahl interpretiert. Wenn jetzt die WLS installiert ist, würde dort stehen {Warenlogistiksoftware MKI}.

zu (2): Hier würde man dann mit dem Namen der gesuchten Ware vergleichen. Dabei wäre es noch besser, wenn man den Namen, statt ihn direkt im Skript zu hinterlegen, aus einer Textdatei lädt (evtl. sogar direkt aus Lucikes Textdatei).

Das sollte doch eigentlich reichen. Kein "create ware", kein "get name".
Oder übersehe ich was?

Mich würde mal interessieren, wie du das jetzt gelöst hat. Nach den ganzen Posts hier, kann ich deinen Lösungsweg nämlich nicht mehr ganz nachvollziehen.

MfG,
ScRaT

[Reflexer]

da er mit get name <Obj> arbeitet.

Verstehe den Grund nicht. Das Ziel war doch folgendes:

Ich wollte eigentlich im Ship Order Manager Schiffserweiterungen anbieten, die der Spieler durch andere Scripts erhält wie z.B. MARS, MEFOS oder WLS.
Bsp:
Solange der WLS nicht installiert ist, gibt es den Warentyp {SS_WARE_SW_NEW6} . Durch die Installation des WLS wird dieser Typ auf {Warenlogistiksoftware MK1} gesetzt (über das t-File). Soweit so gut. Um die WLS als Erweiterung anzubieten müsste ich nun wissen, ob es die Ware gibt.

Da sollte es doch möglich sein es folgendermaßen zu machen:

Code: Select all

* Skript: lib.wls.installed
$ware = {SS_WARE_SW_NEW6} (1)
$wareString = printf: fmt='%s', $ware, null, null, null, null
if $wareString == 'Warenlogistiksoftware MKI' (2)
  return [TRUE]
else
  return [FALSE]
end

zu (1): Der SE speichert die Ware nicht wirklich als {SS_WARE_SW_NEW6}, sondern intern wird das natürlich irgendwie als Zahl interpretiert. Wenn jetzt die WLS installiert ist, würde dort stehen {Warenlogistiksoftware MKI}.

zu (2): Hier würde man dann mit dem Namen der gesuchten Ware vergleichen. Dabei wäre es noch besser, wenn man den Namen, statt ihn direkt im Skript zu hinterlegen, aus einer Textdatei lädt (evtl. sogar direkt aus Lucikes Textdatei).

Das sollte doch eigentlich reichen. Kein "create ware", kein "get name".
Oder übersehe ich was?

Mich würde mal interessieren, wie du das jetzt gelöst hat. Nach den ganzen Posts hier, kann ich deinen Lösungsweg nämlich nicht mehr ganz nachvollziehen.

MfG,
ScRaT

Das ist ein Irrtum Scrat. Das geht so nicht. Wenn die SS_xxx-Irgendwas-Ware mit einem Wert aus einem t-File überschrieben wird, dann gibt es diese SS_xxx-Irgendwas-Ware NICHT mehr. Die Ware heißt dann so, wie es im t-File definiert ist.
Die einzige Möglichkeit zu prüfen, ob es eine Ware (ich rede jetzt nicht von den Standard-Ego-Waren) wirklich gibt, ist es den Typ und Subtyp zu prüfen und diese auf ein "SS"-Präfix zu prüfen. bzw. auf "SS_xxx-irgendwas" wenn man ganz sicher gehen will. Ansonsten gibt es eine Exception im Exscripor bzw im SE passiert irgendwas ganz komisches, da es die Ware nicht gibt

Glaub es - ich habe heute zusammen mit Gazz und General 3 Stunden mit dem Kram zugebracht, bis ich es verstanden und umgesetzt. hatte

Wie ich es gelöst habe, habe ich etwas weiter oben gepostet....

[ScRaT_GER]

Das ist ein Irrtum Scrat. Das geht so nicht.

So, ich habe es jetzt mal wirklich getestet und *TADA*: Es geht so!

Wenn die SS_xxx-Irgendwas-Ware mit einem Wert aus einem t-File überschrieben wird, dann gibt es diese SS_xxx-Irgendwas-Ware NICHT mehr. Die Ware heißt dann so, wie es im t-File definiert ist.

Eben deswegen der Kommentar bei (1).
Am Beispiel der WLS:
Wenn die WLS nicht installiert ist, heißt die Ware {SS_WARE...}.
Wenn die WLS installiert ist, heißt die Ware {Warenlogistiksofware MK1}.
Für den SE ist das aber beide Male die gleiche Ware. Der SE speichert ja nicht den Namen, sondern irgendeine Zahl, die für diese Ware (oder besser: diesen Warenslot) steht.
Dann brauchst du nur noch den Namen der Ware, der ja davon abhängt, ob die WLS installiert ist, mit dem Namen der WLS, sprich mit 'Warenlogistiksoftware MK1', zu vergleichen und schon hast du dein Ergebnis ohne irgendwelche Dummywaren erstellen zu müssen.

Ansonsten gibt es eine Exception im Exscripor bzw im SE passiert irgendwas ganz komisches, da es die Ware nicht gibt

Eben nicht. Im Exscriptor gibt es diese Exception. Im internen SE nicht.

Glaub es - ich habe heute zusammen mit Gazz und General 3 Stunden mit dem Kram zugebracht, bis ich es verstanden und umgesetzt. hatte

Glaube es - ich habe es soeben ausprobiert.

Im Endeffekt ist es dein Bier und du kannst es machen wie du willst. Ich wollte nur nochmal darauf hinweisen, dass es eine einfachere Lösung gibt.

MfG,
ScRaT

[Reflexer]

Aber ich poste die Lösung nochmal:

Es geht jetzt zum Beispiel um diesen Eintrag hier im SOM. Ich biete eine Konfigurations-Möglichkeit an, bei der der Anwender seine Wunscherweiterungen speichern kann. Zu diesem Zeitpunkt gibt es kein Schiff, kein Objekt, kein nix. Es ist eine Auswahl verfügbarer Schiffserweiterungen.

[ external image ]

Um die Standardeinträge (z.B. Handels-Sw MK1) in die Liste zu bekommen ist es relativ einfach. Ich prüfe in einem Script, ob der Spieler den nötigen Ruf hat um die Ware zu erwerben und Trage dann die Ware, nötiger Ruf (true/false) und die Rubrik (korrespondierend zu meinem eigenen t_file) in ein Array ein:

Code: Select all

$tmpWare = {Handelssoftware MK1} 
$tmpEntry = array alloc: size=3
$tmpEntry[0] = $tmpWare
$tmpNotoReq = get notoriety required to buy ware: $tmpWare
* Rangcheck:
if $MaxNoto >= $tmpNotoReq AND $tmpNotoReq != null 
  $tmpEntry[1] = [TRUE]
else
  $tmpEntry[1] = [FALSE]
end
$tmpEntry[2] = 109
append $tmpEntry to array $tmpArray

Diese Standard-Waren werden immer eingetragen, da sie auch immer verfügbar sind und immer gleich heißen.

Komplett anders verhält es sich nun mit den durch externe Scripte erzeugte Waren, wie z.B. "Warenlogistik-SW MK1". Diese Ware wird erst mit der Installation über eine bestehende Ware drübergebügelt.

Die Warenlogistig-SW heißt vorher {SS_WARE_SW_NEW5} oder 6. Jedenfalls heißt sie ab der Installation NICHT mehr so, sondern eben {Warenlogistiksoftware MK1}. Ab diesem Zeitpunkt ist diese Ware auch nur noch so abfragbar. Sobald man auf den ehemaligen SS-Typ abfragt kracht es. Andersrum natürlich auch, wenn die Erweiterung nicht installiert wurde.

Da ich nun nicht wissen kann, ob eine Ware installiert wurde oder nicht, habe ich nur die Möglichkeit über Maintype und Subtype zu prüfen. Diese Werte sind nämlich eineindeutig. Wenn Du den Main- und Subtype einer Ware kennst, dann kann diese auch "Hugo-Egon-Fritz" heißen. Völlig irrelevant.

Ich prüfe nun, ob die Waren, die von "außen" durch fremde Scripte angelegt werden, genauso heißt, wie es der im t-File hinterlegte Name. Ist das so, dann ist die Ware auch vorhanden. Geht nämlich beim init des jeweiligen Scripts irgendwas schief, dann ist die Ware nicht vorhanden!

Der Code dazu sieht nun folgendermaßen aus:

Code: Select all

$tmpSector = get sector from universe index: x=1, y=1
$tmpWare = create flying ware: maintype=16 subtype=64 count=1 sector=$tmpSector x=20000 y=10000 z=30000 selfdestruct=null
$tmpName = $tmpWare->get name
* Lesen des Warennamen aus dem t-File:
$tmpTName = read text: page=17 id=5803
$tmpWare->destruct: show no explosion=[TRUE]
if $tmpName == $tmpTName
  * In diesem Fall entspricht der Warenname dem Warennamen aus dem t-File
  $tmpEntry = array alloc: size=3
  $tmpWare = get ware from maintype 16 and subtype 64
  $tmpEntry[0] = $tmpWare
  $tmpNotoReq = get notoriety required to buy ware: $tmpWare
  * Rangcheck:
  if $MaxNoto >= $tmpNotoReq AND $tmpNotoReq != null
    $tmpEntry[1] = [TRUE]
  else
    $tmpEntry[1] = [FALSE]
  end
  $tmpEntry[2] = 109
  append $tmpEntry to array $tmpArray
end

So - falls Du Dich fragst, was das mit der flying ware soll, erkläre ich das auch noch gerne.

Ich benötige den Namen der Ware für den Abgleich mit den Namen im t-File. Dafür muss die Ware existieren. Auf ein Referenzobjekt kann ich diesen nämlich nicht abfragen.

Speichern hingegen tue ich die Ware als Referenzobjekt, da ich diese später brauche.
Aus diesem Grund lösche ich die erzeugte flying ware wieder und erzeuge mir, wenn die Ware übereinstimmt eine neues Referenzobjekt.

Ich hoffe, dass ich alle so erklären konnte, dass es verständlich ist.

[Reflexer]

Eben deswegen der Kommentar bei (1).
Am Beispiel der WLS:
Wenn die WLS nicht installiert ist, heißt die Ware {SS_WARE...}.
Wenn die WLS installiert ist, heißt die Ware {Warenlogistiksofware MK1}.
Für den SE ist das aber beide Male die gleiche Ware. Der SE speichert ja nicht den Namen, sondern irgendeine Zahl, die für diese Ware (oder besser: diesen Warenslot) steht.
Dann brauchst du nur noch den Namen der Ware, der ja davon abhängt, ob die WLS installiert ist, mit dem Namen der WLS, sprich mit 'Warenlogistiksoftware MK1', zu vergleichen und schon hast du dein Ergebnis ohne irgendwelche Dummywaren erstellen zu müssen.

Das stimmt so nicht. Seit wann bekommt man die Namen von Referenztypen? Namensabfragen gehen meines Wissens nach nur auf Objekte Zumindest habe ich das vorher mit den Namen und den String-Vergleichen auch probiert.... da kam nur Mist bei raus...

Und in dem Fall müsste ich da auch Dummy-Objekte erzeugen

[ScRaT_GER]

Das stimmt so nicht. Seit wann bekommt man die Namen von Referenztypen?

Mache ich ja auch nicht. Schau dir nochmal mein Skript an: Ich konvertiere die Ware einfach in einen String.

Namensabfragen gehen meines Wissens nach nur auf Objekte

Das ist vollkommen korrekt.

EDIT: Im Endeffekt unterscheiden sich die Lösungen nur dadurch, dass ich keine "flying ware" erzeugen muss. Ich finde das relativ unschön und würde das immer vermeiden wollen.

MfG,
ScRaT

[Reflexer]

Ich werde es aber nicht nochmal umbauen, da es so 100%ig funktioniert und eine relativ große Sicherheit bietet.

Drum rum hab ich noch abfragen, ob das Script auch tut... aber den Teil hab ich vorhin rausgelöscht... wollte Dich ja nicht langweilen

[Reflexer]

EDIT: Im Endeffekt unterscheiden sich die Lösungen nur dadurch, dass ich keine "flying ware" erzeugen muss. Ich finde das relativ unschön und würde das immer vermeiden wollen.

Die fw existiert Bruchteile von Sekunden und ist somit kein wirkliches Problem