Infrarot-Modus für Waffen Trigger Version 2

Wie der Titel schon sagt handelt es sich um ein IR-Modus-Trigger, den man an einer Waffe geben kann. Ich habe dazu einen simplen Skript geschrieben.
Bemerkungen: (Dies hier ist die neue Auflage des Triggers) + (Dieser Download ist nur für Modders/Mappers brauchbar)

Die Properties-Datei kann man hier herunterladen: "gamefront.com/files/21151571/IRMode_V2_u"
Die Datei muss in den Properties-Ordner gespeichert werden: "C:\Programme\LucasArts\Star Wars Republic Commando\GameData\Properties"

Wie funktioniert ein IR-Modus?

Wenn ihr mit euer Waffe in den Zoom geht, dann ändert sich die Textur von Personen (Pawns) zu einem Wärmebild (IR-Strahlung). Sobald ihr wieder aus dem Zoom geht, hat die Person wieder die normale Textur.

Der IRModeTrigger findet man unter der Subclass vom MaterialTrigger. Damit der Trigger funktioniert, muss er in eurem Map platziert sein. Wenn ihr den Trigger auswählt und F4 dückt, könnt ihr im Properties-Fenster unter IRMode gehen. Dort ist ein Array. Ihr habt zwei Möglichkeiten. Entweder gebt ihr unter "ClassOfActor" an, wie der Actor heisst, für den der Skin gewechelt werden soll, oder ihr gebt unter "MotherClassOfActor" an, wie die obere Klasse im Actor-Browser-Baum heisst. Alle Actors, die unterhalb der ausgewählten "MotherClassOfActor" sind, für die wird der Skin abgeändert. Im Feld "ClassOfActor" könnt ihr die Klasse nicht auswählen, sondern musst selber den Namen des Actors Schreiben: Bsp.: "TrandoshanSlaver" oder "GeonosianSunFac" Wenn ihr wollt, könnt ihr auch beide Felder ausfüllen.
Zusätzlich könnt ihr auswählen: bGoalTexUnlit. Wenn "true": der Actor leuchtet immer (für IR-Mode)... Wenn "false": der Actor ist normal
Dann müsst ihr natürlich angeben, welches die IR-Texture für den ausgewählten Actor gilt unter "GoalTextures". Der Array GoalTextures[?] ist analog zum Array Skins[?] eines Actors. Unter Event im Trigger müsst ihr einen Tag angeben. Dieser Tag müsst ihr durch einen Event-Notify ausführen an allen Zoomanimationen eurer Waffe.

Sobald alles steht, könnt ihr den Trigger dublizieren in eurem Map. Dem Dublikat müsst ihr einen neuen Tag geben, der über einen Event-Notify an allen Animationen anheftet, die nicht im Zoom sind. Dann müsst ihr im IRMode im Array überall die Wahre Textur des Pawns angeben (die Textur, die er normalerweise Trägt). bGoalTexUnlit muss auf "false" sein.

Der erste Trigger ist also um den IR-Mode anzuschalten und das abgeänderte Dublikat um den Prozess rückgängig zu machen, also wenn man aus dem Zoom herausgeht.

Viel Spass mit dem IR-Mode

Bei Unklarheiten... meldet euch hier.

MfG Sky Corp

nettes script

falls du vorhast das auf den mp auszuweiten musst du wahrscheinlich das material bei der variable "repskin" eingeben und nicht wie gewohnt bei skins[0]. hat den nachteil dass man so nicht auf skins[1] und höher eingehen kann, aber ansonsten wird das nicht repliziert. ehrlich gesagt machts aber auch nicht so viel sinn noch für mp zu modden.

ich hab mich noch nie mit materialtriggers beschäftigt und anscheinend geschieht die magie ja auch eher in deiner neuen klasse als im parent. wenn ich das richtig verstanden hab ersetzt du die currenttexture(welche skins[?] entspricht) mit der goaltexture. was ich nicht verstehe ist, warum man die currenttexture überhaupt angibt.
um das problem, dass die textur des actors bei skin[0] eingegeben sein muss zu lösen musst du einfach die variable currenttexture und die bedingung, dass skins[i] dieser entsprechen muss entfernen.

Code:

class IRModeTrigger extends MaterialTrigger   placeable;

struct TexPair
{
   var()       bool         bGoalTexUnlit;
   var()      Material      CurrentTexture; # <-könnte entfernt werden
   var()      Material      GoalTexture;   
};

var(IRMode)   array<TexPair>   TexturesToChange;

function Trigger( Actor Other, Pawn EventInstigator )
{
   local Actor A;
   local int i;
   local int j;

   foreach AllActors( class 'Actor', A )
   {
         for( j = 0; j < TexturesToChange.length; ++j )
         {
            for( i = 0; i < A.Skins.length; ++i )
            {
               if (A.Skins[i] == TexturesToChange[j].CurrentTexture) # <-könnte entfernt werden
               {
                  A.Skins[i] = TexturesToChange[j].GoalTexture;
                  A.bUnlit = TexturesToChange[j].bGoalTexUnlit;
               } 
            }
         }
   }
}

dann muss der originalactor seine texture nicht aus dem array skins[?] beziehen. dann kanns ganz normal auch bei den einstellungen des meshes oder staticmeshes geregelt werden. wenn du die funktion beibehalten willst, dass das script überprüft, ob der actor die entsprechende textur hat, kannst du alternativ beim array nen bool anlegen, welcher besagt ob es überprüft werden soll(dass der actor unter skins[i] die currenttexture hat) oder nicht. und dann dementsprechend die bedingung "if (A.Skins[i] == TexturesToChange[j].CurrentTexture)" ignorieren lassen oder nicht. so kann man das individuell einstellen.

ist keine negative kritik, nur ein vorschlag. wie gesagt, das script gefällt. ehrlich gesagt, schön zu sehen, dass überhaupt noch jemand sich die mühe macht für dieses alte spiel zu scripten.

Hi CCP VI

Ich weis nicht ob du den Skript ganz versteht hast ... vielleicht verstehe ich auch deine Verbesserungsidee nicht ganz...


Im IR-Mode-Trigger kann man ja eine Liste erstellen, welchem Actor (gemäss seiner Textur) welche Texture zugeschrieben wird.

Code:

if (A.Skins[i] == TexturesToChange[j].CurrentTexture)

Dieser Teil braucht es wirklich!!! Man muss ja zuerst wissen, für welchen Actor der Skript durchgeführt werden muss. Ansonsten ändert sich die Texture für jeden Actor in der Map.
Jedem Pawn mit der gleichen Texture muss eine korrespondierende IR-Mode-Texture zugewiesen werden. Ansonsten kann der zweite Trigger ja gar nicht mehr die Pawns unterscheiden, wenn alle die gleiche IR-Mode-Texture haben. So würde der Trigger nicht mehr alles rückgängig texturieren. Sonder allen die gleiche Texture geben (bsp.: einem Droiden eine Trandotextur...)

Der Skript durchsucht alle Actors und schaut ob, die Textur des Actors mit der CurrentTexture übereinstimmt. Erst, wenn eine Übereinstimmung da ist, wird die Textur eines Actors geändert mit der korrespondierden Texture (GoalTexture)

Ich habe z.B. ein Trando Grenadier und ein Trando Söldner in einer Map (haben verschiedene Texturen). Nun muss ich zwei IR-Mode-Triggers erstellen. Der eine für das Aktivieren und der andere für das Rückgängigmachen. Dann muss ich im ersten Trigger unter IR-Mode [0] für den Trando Söldner und [1] für den Trando Grenadier machen. Damit der Trigger weis, welcher Trando welcher ist, muss ich angeben, welche Textur der jeweils gesuchte Trando trägt (CurrentTexture). Und unter der GoalTexture, welches die korrespondierende IR-Mode-Texture ist.

Damit der IR-Modus wieder rückgängig gemacht wird:

Beim zweiten Trigger muss ich wiederum für beide Trandos einen Separaten Teil im Array des IR-Mode machen. Unter CurrentTexture muss man angeben, welche IR-Texture der jeweils gesuchte Trando trägt, um ihm wieder über GoalTexture die alte Textur zu geben. (Der Trando trägt ja momentan die IR-Texture)

Damit alles einwandfrei läuft, muss man ja die beiden Trandos unterscheiden können. Sie werden hier durch den If-Condition unterschieden:

Code:

if (A.Skins[i] == TexturesToChange[j].CurrentTexture)

...Falls ich es zu kompliziert geschrieben habe, kann ich auch die Testmap dir schicken, in der die Einstellungen gemacht wurden.

MfG Sky Corp

ah, ja, stimmt, bitte um verzeihung, den aspekt hab ich vergessen. in der von mir beschriebenen form würde es alle actors betreffen. dann müsste man besser noch ein anderes kriterium erstellen. man könnte zum beispiel ne if-condition machen welche abfragt ob A einen bestimmten tag hat oder eine bestimmte klasse ist. so könnte man auch spezifisch droiden oder trandos texturen geben. ändert nicht wirklich viel. der einzige unterschied ist, dass du das kriterium nicht mehr mittels des arrays skins ausmachst und es somit nicht mehr da angeben musst. geschmackssache.

mich interessiert ob man irgendwie im code direkt an die wahre textur des meshes/staticmeshes kommt. ich schau mal nach ob ich was finde aber ich glaub nicht so wirklich dran.

Ich hatte die Idee mit dem festlegen der Klasse des Pawns hatte schon bevor ich der Skript herausgab. Dieser Ansatz funktionierte leider nicht....

Hier ist der Code...

Code:

struct OneSection
{
   var()      class<Actor>            ClassOfActor;
   var()      array<Material>      GoalTextures;
   var()       bool            bGoalTexUnlit;   
};

var(IRMode)   array<OneSection>   SkinsToTrigger;

function Trigger( Actor Other, Pawn EventInstigator )
{
   local Actor A;
   local int i;
   local int j;

   foreach AllActors( class'Actor', A )
   {
      for( j = 0; j < SkinsToTrigger.length; ++j )
      {
         if( A.class == SkinsToTrigger[j].ClassOfActor )
            {
               for( i = 0; i < SkinsToTrigger[j].GoalTextures.length; ++i )
               {
                  A.Skins[i] = SkinsToTrigger[j].GoalTextures[i];
               }
            }
      A.bUnlit = SkinsToTrigger[j].bGoalTexUnlit;
      }
   }
}

Das Problem ist, dass die Klasse des gewünschten Pawns nicht in der Liste von "class<Actor>" vorhanden ist....

Für einen B1 findest du unter hidden > class: Class'Properties.BattleDroidDefault'
In der Liste von "class<Actor>" findest du diese Klasse nicht... Somit macht der if-Contition keinen Sinn.

Die beste Lösung ist, wenn man die Textur direkt beim verwendeten SkeletalMesh abändern könnte. (Habe dazu keinen Weg gefunden)

Ich mache mir darüber nicht mehr so gedanken, da der Skript für eigene Mods ja funktioniert (Was das Ziel war des Skripts). Man muss für seinen Pawns einfach die Textur über Skins[?] festlegen. Und falls man den Helm eines Troopers mittels eines Accessoires anheftet, muss man dort auch die Texture unter Skins[?] festlegen.

Trotzdem danke für deine Vorschläge CCP VI

PS. der MatrialTrigger ist noch etwas nützliches. In YYY_04a und anderen Kampagnemaps wurden mit Hilfe dieses Triggers einen erhellten Himmel gemacht, wenn es Blitzt.

MfG Sky Corp

ich weiß, das thema ist im grunde geklärt, das problem ist eigentlich kein problem und ich will auch nicht nerven, aber vielleicht hilft das hier dir ja. kennst du die funktion isA()? syntax sollte so aussehen Actor.IsA(class 'class')

in deinem falle sollte es wahrscheinlich if(A.isA(SkinsToTrigger[j].ClassOfActor)) usw. sein. kann gut sein, dass ich mich irre, müsste aber stimmen. das wird dann wohl einen type mismatch ergeben, weshalb du den variablentyp von ClassOfActor von class<actor> auf den typ name umändern solltest. frage mich gerade was genau man dann im endeffekt da eingeben soll in den properties. ich glaub der entgültige klassenname, zb. battledroid würde reichen.

das mit dem materialtrigger ist interessant. man kann auch auf die variabeln von texturen zugreifen und diese via script verändern. wollte somit mal ein menü machen wo man seinen pawn einfärben kann. lief nur in maßen. änderungen im script die ganz früh verliefen haben geklappt, was später ablief wurde ignoriert. bei einem auto-mapneustart nach jeder änderung hätts geklappt, fand ich aber dämlich. müsste dynamische texturentypen geben wo das direkt funktioniert. egal, war nur so am rande und nicht weiter wichtig.

Hi

Tönt interessant. Vielleicht lässt sich was damit machen. Mal austesten. Im Internet suchte ich nach Beispielen. Dort wird nicht mit Name gearbeitet, sondern doch mit einer Klasse: "celticwarriors.net/Website/Mirrors/CHiMERiC/Tutorials02/Tut03/UnrealScript%20Tutorial%203%20-%20ModBot.htm"

MfG Sky Corp

jo, wenn du das im script direkt festlegst, also nicht via variable dann sieht das auch so aus A.IsA(class 'BattleDroid'). oder A.IsA('BattleDroid') sollte auch gehen. der variablentyp davon ist glaub ich trotzdem name.
guter weg das zu überprüfen ist immer die funktion selbst anzuschauen. die hier findet man in der hauptklasse object.

Object schrieb:

native(303) final function bool IsA( name ClassName );

variablentypen waren aber auch schon immer ne sache bei der ich eher rumprobiere als mit köpfchen drangehe.

nebenbei, zufällig lag eine zeile darüber eine weitere funktion die du auch nutzen könntest.

Object schrieb:

native(258) static final function bool ClassIsChildOf( class TestClass, class ParentClass );

if (A.ClassIsChildOf(A.class,SkinsToTrigger[j].ClassOfActor)) sollte also eigentlich bewirken, dass die neue textur draufgelegt wird, wenn der überprüfte actor eine unterklasse von der klasse, die du in ClassOfActor angibst ist. ich bin mir nicht ganz sicher aber die funktion müsste sich eig auf alle unterklassen beziehen und nicht nur die direkt darunterliegenden.
im konkreten beispiel könntest du alle pawns einfärben wollen. dann setzt du ClassOfActor auf Pawn und dann sollten sich alle actors welche als ursprungsklasse pawn haben, wie zb der battledroid verfärben.

arbeitest du an einem speziellen projekt oder moddest du nur so für dich hin?

Hey CCP VI deine Funktionen haben ohne Probleme funktioniert

Habe jetzt folgende Linie im If-Condition:

Code:

if( A.isA(SkinsToTrigger[j].ClassOfActor) || A.ClassIsChildOf(A.class, SkinsToTrigger[j].MotherClassOfActor))

Die Funktion ClassIsChildOf geht auch für unter, Unterklassen (habe es getestet)
Man kann jetzt im Trigger beide Möglichkeiten verwenden, wie du oben siehst.
Ich habe den obersten Eintrag in diesem Forum aktualisiert und die neue Version der U-Datei hochgeladen.

Danke für deinen Einsatz

MfG Sky Corp

PS: Ich war früher MP-Mapper für verschiedene Clans. Alle diese Clans gibt es schon lange nicht mehr. Ich sah dann ein, dass MP-Mapping sich nicht mehr wirklich lohnt. War dann für ein Jahr nicht mehr im RC. K. a. wieso ich RC wieder fand... Vor kurzem begann ich an einer SP-Kampagne weiterzuarbeiten, für die ich früher mal zwei, drei Prototyp-Maps gemacht habe. Wenn du dich interessierst: "xfire.com/profile/skycorp0/"

sieht nett aus und freut mich falls ich helfen konnte. ich verbring eig nur noch recht wenig zeit mit udk aber wenn du eine bestimmte animation oder was anderes spezielles brauchst würde ich gern helfen.

ich will dich auf keinen fall von deinem projekt abbringen oder so, aber falls du lust hast nebenher mal mit udk, also dem editor für unreal engine 3, zu arbeiten, dann informier dich mal über das foreneigene udk-projekt "level zero". das projekt ist sehr transparent gehalten. du kannst also einfach mal reinschauen und gucken obs dir gefällt. und falls du dann ein bischen mit der neuen engine experimentieren willst, kannst du das ohne zwang ergebnisse abzuliefern da gern machen. würdest mit offenen armen willkommen geheißen werden.

Hi

Danke für dein Angebot Six.

Habe mich über das Projekt genauer informiert...

...Respekt für solch ein Projekt. Ich hätte wohl nicht den Mut gehabt sowas zu starten

Ich weiss, dass ihr dringend weitere Modders braucht und ich finde das Projekt auch interessant. Ich habe normalerweise nicht all zu viel Zeit um an etwas zu arbeiten, wenn ich nicht für einmal Ferien habe wie jetzt. Ich müsste mich also entscheiden, ob weiterhin in RC arbeite oder für Level Zero. Ich möchte nur ungern mit Modden aufhören in RC, auch wenn das Game schon älter ist und Teile im Editor manipuliert wurde von LucasArts. Ich habe Spass daran zu modden und das zählt. Für meine SP-Kampagne selbst ist mir eigentlich egal, ob ich sie je beende oder nicht.

Ich habe schon viele Waffenmodelle im Forum gesehen. Falls ihr doch noch für Modelle offen sind. Ich werde vermutlich für RC noch neue Waffen modellieren. Ich könnte das Grundmodell für euren Level Zero - Game zur Verfügung stellen. Falls ihr wollt, könnte ich Bilder posten, falls ich was habe.

Mh... Vielleicht sollte ich doch Blender hohlen. Wie du schon gesagt hast unterstützt GoogleSketchUp nicht UV-Mapping. Das würde mir viel Zeit sparen beim Texturieren. Kennst du ein empfehlenswertes Tuto (vor allem UV-Mapping)?

MfG Sky Corp

uvmapping liegt mir nicht so sehr, ist aber wohl ne recht wichtige sache. wenn man professionell drangeht kann man mit verschiedenen taktiken spezifisch nach modell arbeiten. ich rate zu den blender wikibooks. hier ein link zu UV-mapping. hab nur nen blick drüber geworfen, scheint empfehlenswert zu sein, kanns aber nicht versichern. ansonsten ist youtube voll von blendertutorials.
für fragen bezüglich blender steh ich immer offen. ich bin nicht sonderlich gut in blender, kenne aber die grundlagen von modellieren und texturieren einigermaßen.

ich wollt dich auf keinen fall drängen eine entscheidung zu treffen. wie gesagt, unser projekt ist sehr offen gehalten. ich verstehe den spaß, den du mit repcom hast sehr gut. ich selbst kann mich von dem alten kram nicht vollständig lösen und helf manchmal anderen moddern wenn möglich. kann deine situation gut nachvollziehen.
trotzdem würde ich dir empfehlen mal ein klein wenig zeit der neuen engine zu entbehren. die graphischen und spieltechnischen möglichkeiten scheinen grenzenlos. sicherlich ist das meiste nicht so einfach aber im gegensatz zu repcom hat man hier eine unmenge von leuten die sich damit beschäftigen und tutorials machen.
arbeite erstmal ruhig an der kampagne weiter. ich wollt das hier nur mal im raum stehen lassen, falls du lust hast dich mit was neuerem zu beschäftigen. ich benutze das projekt auch eher zum erfahrungen sammeln.


nebenbei, du weißt es sicherlich schon und ich glaub ich habs auch im anderen thread gepostet, aber um sicherzugehen: du kannst modelle aus sketchup als .obj exportieren und dann mit blender importieren.

Hi, danke für deine Hilfe

Der Plugin für Google Skech Up, den ich gepostet habe, hat einen funktionstüchtiger .obj-exporter inbegriffen. Habe mir Blender 2.59 geholt und dazu einen passenden .ase-Exporter hinzugefügt. Ich importierte das Modell in Blender, machte dort UV-mapping, dann exportierte ich es. Alles klappte bestens... Als ich das Modell in UnrealEd importierte, sind alle Flächen verkehrt (nur innen sichtbar, statt aussen)... Auch wenn ich die Normals in Blender umkehre, sind sie in UnrealEd immer noch verkehrt. Selbst wenn ich in SkechUp die Flächen umkehre... K. a. wieso das passiert. Ich versuche mal eine ältere Blender-Version zu finden. Vielleicht geht es dort.

Die importierten .ase lassen sich auch nicht zu Brush konvertieren, egal ob es ein Würfel ist oder was komplexeres (= Absturtz)

MfG Sky Corp

hm, altbekanntes problem, aber bisher hat das mit den flächen umkehren immer geklappt. ich hatte dasselbe problem. ich hab blender 2.49 aber mit blender 2.5 und höher muss es eig genauso funktioniere. du hast im edit mode alle faces mit A ausgewählt und dann auf W gedrückt und anschließend die funktion 'flip normals' benutzt? so muss das eigentlich funktionieren.
wenns immer noch nicht klappt kannst du es auch hochladen und ich teste es mal.

Hi

Problem gelöst!!! Habe jetzt Blender 2.49a geholt. Dort funktioniert alles prima. Musste zwar zuerst die Normals umdrehen, aber im UnrealEd waren sie dann richtig.
Fazit: Blender 2.59 und sein .ase-Exporter sind nicht geeignet für SWRC UnrealEd, denn egal ob man die Normals umdreht oder nicht sind die Flächen des Static Meshes immer gegen innen zu sehen und nie gegen aussen.

MfG Sky Corp