triggerId zu Trigger Object

Hallo,

ich bekomme eine triggerId als callback eines Raycasts. Wie genau kommen ich von dieser id zum eigentlichen trigger object? Mit trigger object meine ich das wirkliche Object, in dem alle restlichen Daten (zusätzlich zur triggerId) angegeben sind. Bei einem SprayerFillTrigger also z.B. der fillType bzw. sprayType, litersPerSqmPerSecond, name usw.

Ich habe bisher folgende Methoden versucht, alle jedoch ohne Erfolg:
[lua]
g_currentMission:getNodeObject
--testweise noch folgende probiert, quasi aus Jux und Dollerei
g_currentMission.nodeToVehicle
g_currentMission.objectToTrailer
[/lua]

Hat jemand vlt. ne Idee wie man das hinbekommen könnte? Danke im Voraus.

Hi Bass, danke erstmal für die Idee.

g_cM:getNodeObject() holt, wie du schon angedeutet hast, in der Tat nur die Daten aus g_cM.nodeObjects, wo die Trigger aber nicht drin sind. Ich hab mir schon die g_cM.nonUpdateables, wo zumindest die SprayTriggers drin sind, angeguckt. Das würde funktionieren, würde aber bedeuten ich bräuchte eine Referenz-Index-Table die ich mir irgendwann beim Laden des Spiels erstelle um zu wissen welche triggerId welchen Index hat. Selbiges bei TipTriggers, die ja in g_cM.tipTriggers sind. Also an sich kein Problem.

Nur mit den inzwischen immer öfters auftauchenden kaufbaren Triggers - sein es Placeables, HKL-Auflieger-Tanks, Hänger mit Saat-, Fertilizer- oder Fueltriggers, oder was es da alles gibt - müsste ich diese Referenztabelle relativ oft updaten, was wiederum gegen mein Performance-Herz spricht.

Oder, und das ist gerade eher ein Schnellschuss, ich hänge das updaten jener Referenztabelle an die spielinterne Kauffunktion mit an. Also würde ich bei jedem neu gekauften Objekt kucken ob sie die nonUpdateables aktualisiert hat. Weiß jemand zufällig wie diese Kauffunktion heißt?

Uuuh Fiat, an die append-Funktion beim Erstellen des Triggers hatte ich noch gar nicht gedacht. Prima Idee. Zumal ich dann kein table.insert, sondern table[triggerId] = instance benutzen würde. Das hätte den Vorteil dass ich später keine for-Schleife brauche, sondern einfach direkt die triggerId als Index benutzen kann.

Ein generelle Frage zum Anhängen an Funktionen. Ich kenne zwei Möglichkeiten das umzusetzen:

• Die von dir benutzte, wo ich die alte Funktion manuell in meiner neuen Funktion aufrufe [oldAddTrigger(...)]
• Utils.appendedFunction(originalFunction, newFunction), wo meine Funktion wirklich angehängt wird.

Gibt es bei den beiden denn irgendwelche Unterschiede, sei es Performance, Sicherheit oder einfach Schönheit?

Entweder ich stell mich blöd an, oder ich stell mich sehr blöd an...

Als Beispiel der GasStationTrigger:
[lua]
g_currentMission.registeredTriggers = {};
local oldGasStationNew = GasStation.new;
GasStation.new = function(id, trailer, customMt)
g_currentMission.registeredTriggers[id] = { isGasStationTrigger = true; };
oldGasStationNew(id, trailer, customMt);
end;
[/lua]

Was passiert:

• ich nehme die Funktionsvariablen aus der originalen GasStation:new(), doch diese scheinen nicht zu stimmen. Was ich als id übergeben lasse ist im Endeffekt ne Table, was ich als trailer übergeben lasse ist die id.
• Ich rufe meinen Teil der Funktion vor der Originalfunktion auf, da diese am Ende return self hat. Das scheint aber egal zu sein, denn unabhängig davon wierum ich's mache bekomme ich den Fehler dass die Tabelle nonUpdateable nicht existiert (ergo die onCreate-Funktion mit g_currentMission:addNonUpdateable(GasStation:new(id))
  
  
  Code

  Error: LUA running function 'GasStation.onCreate'
  D:/code/lsim2013_desktop/build/finalbin/dataS/scripts/BaseMission.lua(684) : attempt to index local 'nonUpdateable' (a nil value)

  
  Das könnte mit den falschen Variablen zusammenhängen
  

Benutze ich Utils.appendedFunction passiert natürlich genau das selbe. Jetzt frage ich mich mich, bin ich bei :new() überhaupt an der richtigen Stelle? Das was Kai als instance benutzt, als effektiv die table des Triggers, existiert so meines Erachtens gar nicht.

Ah da haste natürlich recht. Das mit self hatte ich gänzlich übersehen. Und an return hab ich überhaupt nicht gedacht. Läuft jetzt, so ziemlich.

Besten Dank an euch beide.