Click to learn more about Gamer\'s Dungeon Community  
 
Latest News: next@Acer: 15,6-Z
Thu 24.05.18 06:08:38
 Weekly Shot
Click me real hard but I will pop up for ya
Der Golden Gibus Club


 Community
Members
Member Login
Calendar
War List
War Stats

Next Actions:
Keine Wars geplant

 User Online
4 User online
4 Guests
0 User in Chat
GDC TS not available
Online User Details

XMP
Erste Scripting-Versuche/GDC-XMP-Mutator

Ich habe jetzt mal angefangen, mich mit dem Thema Scripting zu beschäftigen. Als Anfang mache ich einen "kleinen" Mutator für XMP:



Der Recon wird eine 4. Klasse für XMP mit folgenden AufgabenPräferenzen:

1. AntiSniper
2. Infiltration
3. Assassin

By Faust on Monday April 05 2004 @ 08:51PM CEST

  Nekrataal writes on Tuesday April 06 2004 @ 12:19AM CEST [ reply | parent ]  
 
Na da bin ich mal gespannt. kann gerne assistieren ... aber eine neue Klasse zu erschaffen ist denke ich so ziemlich das aufwendigste was man machen kann. EInfacher wäre es ne Waffe zu modifizieren oder so ...

 
  Mango writes on Tuesday April 06 2004 @ 08:01AM CEST [ reply | parent ]  
 
Mich beschleicht das Gefühl, dass unser Faust nicht ausgelastet ist ... aber gut, wenn du meinst, ist ja für einen guten Zweck, nur zu!

 
  Faust writes on Tuesday April 06 2004 @ 09:29AM CEST [ reply | parent ]  
 
Soooo schwierig ist es auch nicht, eine neue Klasse einzuführen. Hackelig wirds denke ich mal erst bei den Player- und Waffenmodels.

Ich seh das ganze so als DIY-Extreme-crashkurs und wenn ich die neue Klasse dann zuende gestrickt habe, dann bin ich auch in der Lage, ALLES andere zu coden , denke ich mal... Ist etwa so wie der Unterschied zwischen eine Sprache 1x die Woche in der VHS zu lernen oder gleich in ein anderes Land zu ziehen.

BTW: Die Story hab ich auch schon wieder aus Versehen Intern gemacht. Könntet ihr die bitte nach XMP verschieben? Dann kriege ich vielleicht noch ein paar Tipps von nicht-GDClern!

 
  Nekrataal writes on Tuesday April 06 2004 @ 10:09AM CEST [ reply | parent ]  
 
Also meine Erfahrung mit dem Coden ist eher, das man klein anfangen sollte, sonst ist man am Ende nur frustriert. Die Vielfalt an Klassen ist doch sehr gross und gerade bei XMP gibt es keine Tutorials. Für UT2003 erhält man gute Hilfestellungen und jede Mange Beispielcode. Bei XMP ist das anders, wie ich schon bei einem schnellen Versuch die Minen zu ändern ferststellen musste. (dazu unten mehr). Zunächst sollte man einen Plan haben von welchen Klassen man ableiten muss, welche Animationen und Meshes man überschreiben muss und welche Funktoinen man überladen muss. Für schwierig halte ich auch und damit habe ich mich noch nicht beschäftigt, den Netzcode, die sog. Replication und die States. Mit Glück kann man alles übernehmen. Ich hoffe DU hast Programmiererfarhung in einer OO Sprache sonst brauchst DU viel Einarbeitungszeit.

Bei den Minen hatte ich mich mal knappe 2 Stunden durch den Code gewühlt und ein paar Klassen gebaut, die den Teamschaden von Minen aufheben sollten. Das Ableiten war soweit klar. Wo man den Teamdetection macht schon nicht mehr so ganz, da gabs mehrere Kandidaten. Leider scheiterte das Unterfangen bisher an einer anderen, eigentlich recht trivialen Stelle. Bei einem Mutator - und darum handelt es sich hier - gibt es verschiedene Standard Funktionen, die überladen werden könenn. Dazu gehören so Dinge wie z.B: das Austauschen eines "Dinges" gegen ein anderes z.B. alle Waffen gegen die Shockrifle unter UT2003. Die Funktionen die diesen bewerkstelligt heisst CheckReplacement. Unter UT2003 habe ich schonmal einen Waffenmutator gemacht. Dort tauscht man alle xWeapons vom Typ X gegen den Typ Y. Dazu fragt man die Property WeaponType ab. Bei einer Mine handelt es sich aber weder um eine Weapon noch konnte ich igrendeine Type Property entdecken und schon steht man wieder im Dunkeln und muss sich durch die Klassen wühlen, um ein adäquates Mittel rauszukriegen wie man das Problem löst. Kennt man den Code nicht bereits schon sehr gut ein zeitintensives unterfangen.

NIchtdestotrotz würde bei mir die Motivation erheblich steigen mich einzubringen, wenn sich ein anderer GDCler mit Coding auseinander. Ich würde vorschlagen erstmal mit kleinen Mutatoren anzufangen

 
  Faust writes on Tuesday April 06 2004 @ 01:07PM CEST [ reply | parent ]  
 
Na guuuuut, kuemmern wir uns also erstmal um die Minen. Dann habe ich ja auch unterstuetzung (Ich werde trotzdem an meiner Klasse weiterarbeiten !:-P!). So wie ich das gesehen habe, sind die Minen eine Unterklasse zu den decorations, so wie der Artifactnode zB. Ich denke, bei einem Mutator sollte man wohl da ansetzen. Ich habe mir den Code von den Minen auch schonmal angeschaut, da gibt es dann auch Dinge wie eine Detektorfunktion. Verbnden mit einer Freund/Feind-erkennung (Die findet man zB bei den U2Pawns, zum Thema resupply) sollte man da schon eine Unterklasse einbinden koennen, die diese function noch zusaetslich eingebaut hat. Weiter braucht man dann ja nur statt der standart-minenfunktion diese Funktion laufen lassen, und schwupps, haben wir ihn Ich kuemmere mich mal heute abend darum...

BTW: Das mit den Animationen/Meshes uebernemen ist alles kein Problem, steht in den defaultproperties in den entsprechenden .uc-files.

 
  Nekrataal writes on Tuesday April 06 2004 @ 01:18PM CEST [ reply | parent ]  
 
KLar steht das als Prooerty drin, aber Du musst die ANimationen ja auch machen

Wie gesagt besteht noch das Problem mit CheckReplacement. Die bekommt nämlich nen Actor übergeben, soweit ich das in Erinnerung habe.... keine Decoration, müsste man mal schauen, wie man da an ne Landmine drankommt.

 
  Faust writes on Tuesday April 06 2004 @ 03:00PM CEST [ reply | parent ]  
 
Och, bis sich jemand findet, der skeletalmeshes bastelt, solange kann ich ja das Ranger-model benutzen.

 
  Faust writes on Tuesday April 06 2004 @ 03:09PM CEST [ reply | parent ]  
 
Aber die Decoration-Klasse gehoert doch auch zu den actors?

Nee, ich wollte mal schauen, wie es mit den Minen als Waffe des Gunners aussieht, welche Klasse da angesprochen wird. Die wuerde ich dann gegen eine Unterklasse mit zusaetslicher Freund/Feind-Abfrage ersetzen.

 
  Nekrataal writes on Tuesday April 06 2004 @ 06:04PM CEST [ reply | parent ]  
 
MInen sind definitiv keine Waffe sondern liegen nur im Inventory des Spielers herum und sind im SPiel dann Decoration allerdinsg Breakable. naja, muss ich ich mir nochmal genau ansehen, dann können wir fachsimpeln.

 
  Faust writes on Wednesday April 07 2004 @ 01:20AM CEST [ reply | parent ]  
 
So, zum Thema Minen: ich habe mir mal die Klassen genau angesehen und die Mines sind Definitiv Waffen!

Erklärung:

unter Deployables gibt es die DeployableInverntory-Klasse. Diese Umfasst alle Deployables, darunter auch LandMineDeployable. Diese gehört zum Defaultweapon-Array für den Gunner: DefaultWeaponNames(1)="Deployables.LandMineDeployable"

Leider habe ich jetzt ka wie man die GetDefaultWeapon()-function benutzt. Muss man da jetzt GetDefaultWeapon(Waffenklasse) eingeben, oder was?

Ich merke gerade, dass Basic-Kenntnisse irgendwie noch nicht ausreichen... Aber ich werde es schon noch lernen!

 
  Nekrataal writes on Wednesday April 07 2004 @ 09:01AM CEST [ reply | parent ]  
 
Jein !

Also die Klassenhierarchie ist wie folgt:


Die zwei Zweige gelten beide für Minen. Rechts wenn die Mine gelegt wurde (deployed). Dann sind es Decoration, die breakable sind, also z.B. eine überladene TakeDamage oder BreakApart Funktion haben. Minebase ist eine abstrakte Basisklasse für beide Minenarten.

Links wenn die Mine noch beim Spieler ist. Dann wird sie wie eine Waffe behandelt.

Für den Mine Mutator müsste man von allen vier unteren Klassen ableiten und neue bauen incl. der DamageType Klassen.

DIe CheckReplacement Funktion muss dann sowohl das INventory als auch die Decorations ersetzen.

MIt dem DEfaultArray ist ein guter Hinweis, weil man da sieht wie man die Klassen als string anspricht. Die CheclReplacement Funktoin könnte dem nach z.B. so aussehen:

 
if ( DeployableInventory(Other) != None )
{
if ( DeployableInventory(Other).DeployClass == class'Deployables.LandMines' )
DeployableInventory(Other).DeployClass = class'TeamSensitiveLandMines';
else if ( DeployableInventory(Other).DeployClass == class'Deployables.LaserTripMines' )
DeployableInventory(Other).DeployClass = class'Deployables.TeamSensitiveLaserTripMines';
else
return true;
}
else if ( MineBase(Other) != None )
{
if ( string(Other.Class) == "Deployables.LandMines" )
ReplaceWith( Other, "Deployables.TeamSensitiveLandMines");
else if ( string(Other.Class) == "Deployables.LaserTripMines" )
ReplaceWith( Other, "Deployables.TeamSensitiveLaserTripMines");
else
return true;
}

Die Stelle wo ich eventuell ansetzen würde für die Team erkennung ist ein Überladen der Methode:
function bool CanBeTrippedBy( actor A ) in der abstrakten MineBase Basisklasse. Hier müsste noch einen Teamunterscheidung rein, nicht nur eine Prüfung ob es sich um einen gültigen Pawn handelt.

Das Team kriegt man vermutlich über eine Methode des Pawn GetTeam(). Diesen Teamindex muss man vergleichen mit GetTeam() auf der Mine selbst.

so langsam hammer alles zusammen für einen ersten Versuch ...

 
  Chucky writes on Wednesday April 07 2004 @ 10:57AM CEST [ reply | parent ]  
 
Wollte ich eigentlich gestern schon gesagt haben:



 
  Chucky writes on Wednesday April 07 2004 @ 10:59AM CEST [ reply | parent ]  
 

Hmmm... Also geparsed wird's jetzt schon - ich muss nur noch das Bahnhof-Bildchen anpassen und das Ganze im FAQ nachtragen...

Hab übrigens noch ein paar neue Smileys eingebunden - - SCNR

 
  Nekrataal writes on Wednesday April 07 2004 @ 01:04PM CEST [ reply | parent ]  
 
DEnn zweiten SMiley versteh ich nicht. ISt das überhaupt ein Gesicht oder nur ne dicke Wurst ?

 
  Chucky writes on Wednesday April 07 2004 @ 01:33PM CEST [ reply | parent ]  
 
Der 2. Smiley sind 2 Cents.

Just my ...

 
  Faust writes on Wednesday April 07 2004 @ 12:52PM CEST [ reply | parent ]  
 

Das mit der Teamerkennung geht doch ganz einfach!

if( SameTeam( Pawn(Other) ) ), damit wird doch abgefragt, ob der Player vom eigenen Team ist, oder irre ich mich? Das würde ich als Negative Abfrage einbauen, und schon hätten wirs!

Und falls es mit der Checkreplacement Funktion nicht funktioniert, dann können wir immernoch über die GetDefaultWeapon-Funktion gehen, auch wenn wir da quasi über 2 weitere Kanten gehen müssten (Erst andere Deployable-Klassen einfügen, die dann als DeployClass dann die überarbeitete MinenKlasse haben....)

Aber schaun mer mal! Ich lerne immer mehr dazu, und irgendwann komme ich auch mit der Syntax klar!

BTW: Ich glaube, du hast da oben bei deinem Aufsatz Links und Rechts verwechselt!

 
  Nekrataal writes on Wednesday April 07 2004 @ 01:01PM CEST [ reply | parent ]  
 
Kann sein, ich habe eine ausgeprägte links rechts Schwäche.

Das mit dem SameTeam denke ich funktioniert nur bei zwei Pawns. Nicht bei einer Mine (Actor) und einem Spieler (Pawn). Die Funktion SameTeam erwartet als Übergabe ja einen Pawn und keinen Actor. Die von mir vorgeschlagene Vorgehensweise ist aber auch nicht wesentlich komplizierter

Wenn es über CheckReplacement nicht geht müssen wir einen Total Conversion bauen ! Also => Es MUSS über CheckReplacement gehen. Das ist die Funktion, die einem bei einem Muatator zur Verfügung steht. Du kannst nicht einfach im bestehenden klassenbaum rumfummeln Ich bin mir aber sicher, dass es gehen sollte, denn alle UT2003 Waffenmutatoren arbeiten so.

BTW: Ist es nicht komisch das Turrets einen WeaponType haben und Minen nicht ... ?

 
  Faust writes on Wednesday April 07 2004 @ 01:15PM CEST [ reply | parent ]  
 
Wieso komisch? Turrets schiessen ja auch zurück!

 
  Nekrataal writes on Wednesday April 07 2004 @ 02:36PM CEST [ reply | parent ]  
 
aber Minen explodieren auch und töten, aber ok könnte eine Erklärung sein

 
  Faust writes on Wednesday April 07 2004 @ 04:39PM CEST [ reply | parent ]  
 
Aber haben wir jetzt nicht schon genug zusammen für nen ersten Test? Ich meine, die Mutator-Klasse ist klar soweit ich das beurteilen kann (Mit der CheclReplacement-Funktion) und die Actor-Klassen für die Minen auch (Mit der Getteam-Abfrage). Obs funktioniert, müssen wir dann eben sehen. Coden kann ich es nicht selber, weil ich die Syntax noch nicht gut genug beherrsche (werde wohl erstmal das ein- oder andere Tutorial reinpfeifen). Ich habe nämlich schon Schwierigkeiten, deinen Code da oben so ganz zu verstehen...

 
  Nekrataal writes on Thursday April 08 2004 @ 10:21AM CEST [ reply | parent ]  
 
Also so 100% bin ich auch nicht drin, weil Usciprt so einige Besonderheiten hat wie z.B. States. Unterschiedliche States können dieselbe Funktion mehrfach überschrieben, also so eine Art weitergefühjrte Polymorphismus zu normalen OO Programmierung und wichtig zu wissen, daran habe ich mich anfangs sehr gestossen.

Das hier :

DeployableInventory(Other)

ist KEIN COnstructor Aufruf

sondern:

Ein Typcast !

 
  EnergyRex writes on Tuesday April 06 2004 @ 02:37PM CEST [ reply | parent ]  
 
cool Faust, ich würde dir auch gerne dabei heldfen. Etwas Scripting Erfahrung hab ich schon.
Aber erstmal soll ich bestimmt meine GOEmassif fertig machen, gelle? !weed! kommt alles noch !!!

 
  Faust writes on Wednesday April 07 2004 @ 04:41PM CEST [ reply | parent ]  
 
@Rex: Yo, ich kann jede Hilfe brauchen, die ich kriegen kann! Ich werde das Projekt neue Klasse aber vor allem dazu missbrauchen, mir selbst das Coden und modeln beizubringen. Es wird also etwas seeeeeeeeehr langfristiges werden

 
  EnergyRex writes on Wednesday April 07 2004 @ 10:39PM CEST [ reply | parent ]  
 
Must mir nur sagen in welche richtung ich mich mal orientieren soll. Was vom Code sollte ich mir mal ansehen? Was brauchst du alles? Was genau macht die Klasse?
übrigens....GEOmassif macht auch Fortschritte.

 
  Faust writes on Thursday April 08 2004 @ 12:30AM CEST [ reply | parent ]  
 
Na gut, ich sach ma was die Klasse alles leisten soll und wie ich glaube, dass das mit dem Script zu bewerkstelligen sein wird:

Zunächst mal soll sie von der Bewaffnung her am schwächsten sein, dh im Nahkampf so gut wie keine Chance haben (Wenig Shield, schwache Bewaffnung).

Dafür wird sie einige lustige Features haben:

1) Wenn ein Gegner eine Sniper als Waffe eingeschaltet hat, dann kann sieht der Recon einen Rahmen um diesen Gegner (ähnlich wie der Gunner im sekundärmodus des Raketenwerfers, da müsste man mal schauen, wie das genau funktioniert)

2) Der Recon besitzt die Fähigkeit, sich unsichtbar zu machen. Dh nicht ganz unsichtbar, es wird mit der Adrenalin-Unsichtbarkeit von UT2003 zu vergleichen sein. Wenn er sich allerdings hinhockt und sich nicht bewegt, ist er ganz unsichbar.
Wärend des Unsichtbarkeitsmodus darf der Recon nicht schiessen, denn dann wird er wieder sichtbar. Ausserdem regeneriert er dann keine Energie. (Zu lösen wird das wohl über Alternate-Skins in der Recon-Klasse selber sein. Als Trigger will ich dann den primären Modus der "Schield-gun" benutzen, aber da gehe ich später noch drauf ein...)

3) Ich bin mir noch nicht sicher, wie die Verhältnisse sein werden, warscheinlich wird der Recon ein bisschen langsamer und schwächer als der Ranger werden (50 Schield oder so)

4) Besonders wichtig ist mir diese Fähigkeit: Assassinate: Wenn der Recon nahe genug an den Gegner rankommt, dann kann er mittels benutzentaste diesen um 95 Healthpunkte runtersetzen. (Es gibt ja sowas ähnliches schon vom Ranger, mit der MercyKill-Funktion)

5) Das ist vielleicht etwas abenteuerlich, aber wenns klappen würde, dann wärs einfach geil: Disguise. Wie der Covert ops bei ET könnte der Recon dann die Gestalt von seinem besiegten Gegner annehmen und so die Gegnerischen Teamkameraden täuschen.(Gut, das müsste warscheinlich wieder über die Mercykill-Funktion gehen. Allerdings weiss ich nicht, ob man dem Spieler einfach so einen anderen Mesh geben kann, aber wenns klappen würde...)

6) Bewaffnung:

1.Waffe: Als primäre Waffe gibts ne Armbrust (Ok, ne Techno-Armbrust, ist ja SciFi ), Primärfeuer ist ein Bolzen, der am Körper kaum Schaden macht (vielleicht wie die Pistole vom Ranger) dafür extrem effektiv auf kurze Distanz und mit Headshots. (Da so ungefähr wie die Sniper vom Ranger) Als Sekundärer Modus wird eine Kamera an den Gegner angeheftet, durch die er das quasi auskundschaften kann wie die Base vermient ist, wieviele Turrets da stehen, die genaue Feindposition usw.(Ok, PrimärFeuer ist standart, bei Sekundär wirds dafür heikel... könnte man aber warscheinlich über die PlayerController-Funktion lösen, ich hatte da im Wiki so was von Kameraeinstellungen gelesen...)

2. Waffe: Silenced Pistol: Wie die Pistole des Rangers, eben nur schallgedämpft (Ok, ist auch Standart, ggf muss man nichtmal ne neue Mesh importieren, dann ändert man einfach den Sound der Rangerpistole.)

3. Waffe: Granatenwerfer: Da würd ich sagen als primärfeuer EMP gegen Fahrzeuge und als Sekundär, Springgranaten (Die funktionieren so: Die Granate erzeugt einen Rückstoß, der keine HP kostet, aber dafür schön hoch springen lässt, etwas wie die Blendgranate vom Gunner)

4. Waffe: Das Sahnestückchen: Die Schield-Gun. Manchen vielleicht bekannt aus WFUT. (Zumindest der sekundärmodus). Primärfeuer: Macht den Träger unsichtbar, bzw schwer zu erkennen. Schon oben erklärt. Sekundärfeuer: baut einen Schild vor dem Träger auf, an dem das Feuer der Feinde abprallt. Dieser Schild wird 1) grösser als bei UT2003 sein und 2) viel effektiever, weil er nichts durchlässt (mann, ich vermisse WFUT ) (Durchführung: Primärmodus schon oben erwähnt, sekundärmodus, da muss dann eben ein Actor erschaffen werden,der Schild nämlich. Das Abprallen hört sich zwar seltsam an, aber das gibt es tatsächlich schon! Beim spielen mit den Warpactors für meine Map habe ich nämlcih dieses Phänomen schon entdeckt, dass Raketen zB einfach am Actor Abgeprallt und wieder zurückgeschossen sind. ggf kann man ja die vectoreinstellungen der Actors wie Raketen, Granaten etc entsprechend verändern.)

5. Deployable: Ich habe da an Zeitzünder gedacht. So wie Minen, die allerdings nach 5-10 sek immer explodieren. (Da könnte man die Landminenklasse kopieren, anderer SM, Abrage bei der Armed-Funktion raus et voilá!)

6. Supplypacks: Eigentlich ist ja nicht mehr alzuviel übrig für ein 4tes Supplypac, deswegen dachte ich mir folgendes: das Supplypack macht einfach wieder Stamina und Energie des Players voll! Das wäre auch von Vorteil, wenn der Recon unsichtbar ist, denn dann regeneriert er ja nicht mehr Energie (allerdings kann man dann die Packs gut sehen, die er wirft.)

Selbsverständlich kommen dann noch der SkeletalMesh (Da bräuchte ich jemanden, der sich mit MAX gut auskennt) und die Entsprechenden Skins und Animationen (Gut, die könnte ich ggf selbst machen, wenn die Mesh da ist, und UPaint wollte ich auch schon immer mal benutzen.). Desweiteren natürlich noch die Meshes für die Waffen (Kleinigkeit ).

Du siehst also, ist jede Menge Bedarf da, falls du Lust hast, irgendwo dabei schonmal was zu proggen, würde ich mich freuen, für mich bleibt noch genug Arbeit

 
  Nekrataal writes on Thursday April 08 2004 @ 10:45AM CEST [ reply | parent ]  
 
Das klingt für mich aber garnicht nach einem Recon sondern eher nach einem klassischen Infiltrator.

Der klassische Spion darf in keinem Fortress Mod fehlen. Er erst bringt das echte Paranoia Feeling. Ist es wirlich ein Teammate der Dir da an der Flagge zuwinkt ? Der Spion kann sich fast unsichtbar machen während er läuft und wird komplett unsichtbar wenn er sich nicht bewegt. Die dazu notwendige Energie regeneriert allerdings nur langsam. Seine Tarneigenschaften gehen aber noch weiter. Er kann sich als jeder Klasse jeden Teams tarnen. Die Bewaffnung ist entsprechend schwach. "This class isn't complete but is already a blast to play."

Das mit dem Stamina auffüllen könnnte m,an dann selbst gut nutzen um Dauerzuthrusten ne finde ich keine gute Idee, ebenso wie die Springgranate. Denn es ist relativ einfach für einen Infil eine Basis zu infiltrieren. Wenn er auch mit dem Artefakt mühelos einem Ranger davonhüpfen kann ...

Auch der WFUT Infil hatte die Möglichkeit wenn er den Spieler von hinten berührte einen tödlichen Streich mit dem Tazer durchzuführen, der ihn allerdings enttarnte. Eine solche Waffe (Messer, Dolch) wie auch immer würde ich als Primärwaffe vorschlagen. DIese ist eines ASsassin oder Infils würdig.

Die Sache mit der Disguise ist zwar nett, führte aber in Spielen nur dazu (WFUT war 0% FF), dass jeder der in die Base rennt vorsichtshalber beschossen wurde, wenn er blutete, wusste man : AHA! Ein Infil. Ich denke prinzipiell ist das nicht so schwer zu machen. Man wechselt einfach die Skin. Problem ist hier aber, dass es keine gemeinsame Waffe aller Klassen gibt, sodass der Infil über die Waffe auch auffällt. Das war bei WFUT anders. Eventuell braucht man dann noch ein "FAKE Weapon" Sache.

In dem Zusammenhang fällt mir auch immer die schöne Funktion "Feign Death" ein (aus alten UT Tagen). Ähnlich wie Disguise ein Täuschungsmanöver und im Spiel, wenns jeder begriffen hat, völlig nutzlos, da sicherheitshalber jede rumliegende Leiche nochmal beballert wird.

Das Shield könnte Sinn machen am Infill, weil seine Tarnung beim Tragen eines Artefakten nicht mehr funktionieren sollte.

Zu den Minen. Es wäre schön eine effektive Blendgranate zu haben, die einen nicht selber blendet, sehr wohl aber den Gegner. Damit man nicht 2x denselben Granatentyp hat, könnte man es Tränengas nenen und den Bildschirm schwarz werden lassen. Somit hat der Infil mit Shield und den Granaten eine Chance zu entkommen (wenn er schon schlecht bewaffnet ist und nicht die Sprungfähigkeit wie oben erwähnt). ALs zweiten Granetntyp würde die Fraggrenade vom Ranger reichen.

 
  Chucky writes on Thursday April 08 2004 @ 11:53AM CEST [ reply | parent ]  
 
Problem bei XMP und Infil ist mE nach auch, dass bei XMP die Spielernamen beim eigenen Team über dem Model erscheinen. So halte ich's z.B. immer so, dass ich auf alle SPieler schiesse, die nicht vor sich hertragen, wie sie heissen. Auf die Skin guck ich da idR gar nicht...

Just my ...

 
  Faust writes on Thursday April 08 2004 @ 12:26PM CEST [ reply | parent ]  
 
So funktioniert es ja auch bei ET. Wenn ich bei einem aus meinem Team nicht sehe, wie er heisst, dann ist das ein CO und wird abgelascht.

 
  Chucky writes on Thursday April 08 2004 @ 05:56PM CEST [ reply | parent ]  
 
ET? Enemy Territory?? Dieses komische WWII-Gedöns???



 
  Freeway writes on Thursday April 08 2004 @ 09:57AM CEST [ reply | parent ]  
 
Ich hab neugiriegerweis den Punkt 5 mal angetestet.

Und so sieht eine Kombination von Gunner und Ranger aus.

Der Austausch in XMP Ed ist einfach, über Gunner Properties/Display/Mesh.
Leider kommt dann ein Mutant dabei rum.
Ich hab es dann noch über AlternatSkin versucht aber der blieb so Mutantenmäsig.
Wie das dann im Spiel funktionieren soll, der Austausch de Meshes, ist mir dann doch schleierhaft.
Aber lustig wäre es dann schon.
Die Properties vom Gunner mit den Animationen eines Ranger. Müßte Lustig aussehen wenn der Gunner mit der Scharfschützen Animation versucht den Racketenwerfen abzufeuern. Theoretisch gesehen müßte der Werfer im Kopf des Ranger stecken.
Mesh austausch, glaub ich, funkt nicht.

Und jetzt wo ich das schreibe frag ich mich was du vorhast. Das ist der blanke Wahnsinn, gefällt mir.
Eine neue Klasse, der Körper ist dabei das kleinste Problem, na ja, vielleicht ein gutes Designe finden könnte was brauchen.
Aber dann, die Bewegungsanimationen die für den Typ gebraucht werden. Ich hab mich noch nicht mit der ukx Klasse auseinandergesetzt. Das einzige was ich festgestellt hab ist es keine Vehicle nach k3 Ed zu laden. Ich hab die Meshes der Klassen von XMP ausgepackt. Ohne Animationen und UV Koordinaten. Der andersherum Weg ist mir noch unbekannt. Das ganze, den Mesh und Animationen zusammensetzen und dann wider ein ukx File draus machen. Ich wollt aber in nächster Zeit mal neugierig da reinschnuppern.
Ich hatte mich mehr mit den gem Files von U2 beschäftig. Ich war scharf auf einen Skaarj aus dem Spiel. Schade, ich fand die Idee gut, für eine Map. Auf der einen Seite eine Terra Base und dem gegenüber eine Skaarj Base. Ohne die Figuren macht es aber keinen Spaß.
Ich hab nichts gefunden wo man die gem Files reinpacken kann um wenigsten an die Meshes zu kommen.

Äh, um wider zurück zum Thema zukommen, der Austausch muß wohl ein Script Dingsbums sein, was die ganze Klasse austauscht, für den Moment wo er ein anderer sein soll.
ich hab noch garnicht ausprobiert ob man ukx von k3 nach xmp laden kann, andersrum geht, Klassen und Waffen, nicht die Vehicles.
Vielleicht kann man da was abgrabbeln und es in XMP zuverwenden.

Es bleibt also noch mehr als genug Arbeit. Gut das du dir keine Kleinigkeit ausgesucht hast, sonst käm womöglich noch Langeweile auf.


 
  Faust writes on Thursday April 08 2004 @ 10:36AM CEST [ reply | parent ]  
 
Natürlich hat der Recon eine eigene Klasse (Unreal-Script-Klasse, meine ich) bzw 3, dadurch ist das zuweisen einer Mesh nicht das Problem (Vorrausgesetzt, es existiert eine solche Mesh)

 
  Faust writes on Thursday April 08 2004 @ 10:21PM CEST [ reply | parent ]  
 
Zum Thema Minen-Mutator:


Ich stehe drauf, aber sie explodiert nicht! (Explodieren tut sie, wenn ich das Team wechsel oder drauf schiesse).

Yet-has-to-be-fixed: Ich brauche eine Möglichkeit, den EnergyThresholds-Array in der XMPGame-Klasse zu ändern. Vielleicht schaffe ich es heute noch!

 
  Nekrataal writes on Friday April 09 2004 @ 10:43AM CEST [ reply | parent ]  
 
Na prima ! Schick mirs und ich schau wo ich noch helfen kann hab bis jetzt noch nix bekommen Ausserdem können wir es vielleicht mal zu 2 testen auf dem Server, wegen Replikation und so.

Denk daran, das die Properties einer Klasse an alle Subklassen vererbt werden. Du kannst also, wenn es sich um eine Proerty handlet die einfach in Deiner Subklasse anders setzen.

 
  Faust writes on Friday April 09 2004 @ 11:36AM CEST [ reply | parent ]  
 
Dann gib mir mal ne Mail-Adresse, die dein SPAM-Filter auch Akzeptiert

 
  Nekrataal writes on Friday April 09 2004 @ 12:22PM CEST [ reply | parent ]  
 
Dirk.Langheim(bösesZeichen)gmx.de Samstag morgen bzw. Sonntag nachmittag habe ich Zeit. wäre doch gelacht, wenn wir das nicht hinbekämen Du hast aber schon extra Klassen von den ganzen Minenklassen bageleiten so mit extra Package uns so ?

Ach ja, schön das sich noch jemand mit Coden beschäftigt, da kriegt man wieder richtig Lust Apropo, wenn wir die neue klasse wirklich machen sollten, könenn wir danach XMP auf UT2004 portieren. Das könnte sogar einfacher sein

 
  Faust writes on Friday April 09 2004 @ 12:27PM CEST [ reply | parent ]  
 
Ja, ich habe 6 neue Klassen im Package.

Ich schicks dir mal im Laufe des Mittags.

 
  Nekrataal writes on Friday April 09 2004 @ 05:07PM CEST [ reply | parent ]  
 
THx, freu mich drauf

 
  Faust writes on Saturday April 10 2004 @ 12:54PM CEST [ reply | parent ]  
 
Sach ma Nek, der Code, den du mir geschickt hast lässt sich mit UCC nicht kompilieren

 
  Nekrataal writes on Saturday April 10 2004 @ 04:59PM CEST [ reply | parent ]  
 
!Hm! bei mir schon ? Welche fehlermeldung kriegst Du ?



Falls es nicht laufen sollte, dfinden wir die Ursache schon. Ansonsten versuche doch den bug mit den tripmines zu fixen setze mich jetzt auch nochmal kurz dran ...

sehr komisch. Selbst wenn die ModfiyPLayer funktion nicts enthält ausser dem Aufruf des nächsten Mutators, sind die Landminen erst da wenn online und die Tripmines sofort nach dem Spawnen )


 
  Nekrataal writes on Saturday April 10 2004 @ 06:13PM CEST [ reply | parent ]  
 
ichglaub ich habs. Das ist ja blöde. DEr ucc Compiler gibt keine Fehlermeldung aus wenn ein .u File schonmal erfolgreich compiliert wurde und ein fehler auftritt. Dann überschreibt er das orginal einfach nicht und hält die klappe. Man muss also jedesmal erst das .u File in Systems löschen, sonst erhält man kein vernünftiges Ergebnis

 
  Faust writes on Saturday April 10 2004 @ 06:21PM CEST [ reply | parent ]  
 
Jepp, ich habs aber schon gefixt. Die Probleme waren nämlich folgende:

1) In der SmartLaserTripmineDeplyable-Klasse wurden auf Funktionen in der SmartLaserTripmine-Klasse verwiesen, die logischerweise nicht existierten. deshalb musste schonmal diese Klasse KOMPLETT kopiert werden.

2) der Teamabfragen-Aufruf war für den Compiler total unverständlich. Ich habe also trotzdem die SmartMineBase-Klasse eingeführt...

Also sein tue ich jetzt da wo ich vorher auch war. Was ich gerade versuche, ist mit der Other.Weapon.SetAmmo-Function (oder etwas ähnlichem) in Verbindung mit der IsValidInventoryLaser-Funktion hinzukriegen, dass man keine Muni mehr für die Minen hat, sobald das Feature Offline ist.

 
  Nekrataal writes on Sunday April 11 2004 @ 07:51AM CEST [ reply | parent ]  
 
ja da waren nen Haufen Fehler drin, weil ich es gewohnt bin die ganzen Tools für UT2003 zu nehmen. Da drückt man auf compile und feddich. Trotzdem müsste das mit der Ableitunghierarchie so gehen wie gedacht. Ich schau jetzt noch mal rein und versuche ein wenig mitzuloggen

 
  Nekrataal writes on Sunday April 11 2004 @ 10:27AM CEST [ reply | parent ]  
 
So hab Di nochmal was geschickt was ich gerade noch korrigiert habe. Heute nachmittag setze ich ich mich nochmal ran. Ich verstehe nicht ganz warum wir die SmartMineBase Klasse brauchen und nicht direkt von Landmines oder Lasertripmines ableiten können. Was hattest Du nochmal dazu gemeint ?

 
  Faust writes on Sunday April 11 2004 @ 01:22PM CEST [ reply | parent ]  
 
Ich habe die Teamerkennung in der SmartMineBase-Klasse eingebaut, deswegen. Kann man das auch in den Klassen selber machen?

 
  Nekrataal writes on Sunday April 11 2004 @ 01:43PM CEST [ reply | parent ]  
 
, den Code, den ich Dir geschickt habe hat die Teamabfrage vollständig in die Funktion CanBeTripped integriert. Diese Funktion kann man auch direkt in die Klassen SmartLandMine / SmartLaserTripMine übernehmen (habs probiert), und überschreibt somit die CanbeTripped Funktion aus der abstrakten Basisklasse (SmartMineBase). Theoretisch unterscheidet sich die SmartMineBase Klasse damit nicht mehr von der MineBase Klasse. Gehe ich aber dann hin und leite SmartLandMine/SmartLaserTripmine respektive von LandMine / LaserTripmine oder auch von MineBase ab funzt es nicht mehr. Ich weiss nicht genau warum.

 
  Faust writes on Sunday April 11 2004 @ 01:58PM CEST [ reply | parent ]  
 
Du machst das schon! Btw, ich habe den Bug übrigens 'behoben', dass allerdings nicht sonderlich elegant:

Man hat von anfang an zwar Zugriff auf die Lasertripmines, aber wenn dafür keine Energie da ist und man sie legen will, dann verliert man nur Energie und sonst passiert nischt . Gut, ist jetzt nicht soooo schön, aber mir reichts....

Das allerallerletzte Problem besteht darin, bestehende Minen auf 'Offline' zu schalten.

 
  Nekrataal writes on Sunday April 11 2004 @ 03:43PM CEST [ reply | parent ]  
 
Ich wundere mich warum wir diese Probleme habe und hatte gehofft, dass wenn wir uns wie oben erwähnt von Landmines / Lasertripmines ableiten alle EIgenschaften behalten bis auf das was wir ändern wollen. Es ist komisch, dass wir DInge die eigentlich schon in den Vaterklassen drin sind neu programmieren müssen ....

 
  Analhusten writes on Sunday April 11 2004 @ 11:41AM CEST [ reply | parent ]  
 
@Faust: Also sein tue ich jetzt da wo ich vorher auch war.
Cooler Satz!

 
  Faust writes on Sunday April 11 2004 @ 03:47PM CEST [ reply | parent ]  
 


 
  EnergyRex writes on Thursday April 08 2004 @ 10:44PM CEST [ reply | parent ]  
 
Na du bist mal echt arg, Faust. Du bist ja schon bald wieder fertig mit allem. GENIAL !!!
Was soll ich da noch helfen? Du hast das scheinbar so gut drauf...... da bin ich überflüssig.

weiter so. du schaffst es!!! tschaka

 
  Faust writes on Sunday April 11 2004 @ 04:14PM CEST [ reply | parent ]  
 
So, der Bug speziell für die LaserTripmines ist jetzt behoben, wenn keine Energie mehr für die Lasertripmines da ist, können auch keine gelegt werden.....

Leider, gibt es noch ein kleines Problem: Wenn alles mit Minen zugespammt ist und die Energie für die Minen ausgeht, dann schalten die aber nicht in den Offline-Modus!

@Nek: Weisst du, ob die CheckReplacemnt-Funktion auch bestehende Actors durchleuchtet? Und ob man denen dann darüber Befehle geben kann? (Ich hab mal was darüber gelesen, dass man über die CheckReplacement-Funktion auch Eigenschaften der Actors verändern kann, weiss aber nicht mehr wo....)

 
  Faust writes on Sunday April 11 2004 @ 09:52PM CEST [ reply | parent ]  
 
MANN BIN ICH GEIL! Den Bug habe ich jetzt auch behoben Und die oben erwähnte unelegante Lösung klappt jetzt auch ganz normal!

@Nek: Ich denke, wir sind ann so langsam so weit, dass wir einen OnlineTest machen können. Oder? Ich schicks dir mal!

Muss allerdings der Ordnung halber einen Bug erwähnen, den ich bis jetzt nicht ausrotten konnte: Wenn jetzt die Minen Offline gehen, weil keine Energie da ist, und GERADE mal so viel Energie da ist, dass die Minen theoretisch wieder online gehen könnten, dann weigern sich die Minen einfach wieder online zu gehen!
Das heisst praktisch: Wenn die Energie ausgeht, explodieren alle entsprechenden Minen. Im normalen Game würde nur der grösste Teil explodieren. Macht aber imho jetzt nicht den grossen Unterschied (nervt mich aber als Coder(Yeah! I'm A CODARRRRR!)schon ein bisschen )

EDIT: Achja, nochwas: ich habe jetzt nicht deine abgespeckten Klassen genommen, weil ich nicht so ganz kapiert habe, ob die jetzt gehen oder nicht ?! Ausserdem habe zum testen immer mal wieder eine function umgeschrieben, so dass es schon praktischer war, die ganze Klasse kopiert zu haben (Werde ich wohl in Zukunft immer so machen, denn welche Functionen ich GENAU ändern will, weiss ich erst hinterher.) D.H. Die DamageTypeKlassen wurden nicht übernommen (Momentmal, die kann ich jetzt ja eben eintragen )

 
  Nekrataal writes on Monday April 12 2004 @ 12:41AM CEST [ reply | parent ]  
 
Die Damagetypeklassen sind ja schnell eingebunden. Das mit dem Kopieren ist kein guter Stil, besser ableiten und nur die Funktionen kopieren, die Du brauchst. Macht das Ganze auch schneller. Leider bin ich heute zu nix mehr gekommen ... werde mir den Code anschauen und vorallem noch an den oben erwähnten Sachen bzgl. Vererbunghierarchie rumsuchen (irgendwann nächste Woche).

Das mit dem Explodieren müsste im State offline ändern. Dort gibt es ein SelfDestruct.

Damit die Minen wieder online gehen, müssen sie in einen anderen State überführt werde. Weiss leider auch nicht wie das geht. Schau mal bei den Turrets nach. Da sollte das eindeutiger rauskommen.

 
  Mango writes on Monday April 12 2004 @ 11:13AM CEST [ reply | parent ]  
 
Echt bitter, wenn so wenig gute Doku oder Beispiele verfügbar sind. Hach, wenn ich das so lese, fühle ich mich an die Zeit zurück erinnert, zu der ich mich noch gefreut habe, wenn nach poke 57irgendwas 244 sich die Hintergrundfarbe änderte ...

 
  Faust writes on Monday April 12 2004 @ 12:59PM CEST [ reply | parent ]  
 
So. Den Bug, dass man als Gunner plötzlich 4 verschiedene Minentypen zur verfüging hat, habe ich erstmal so gelöst, dass 2 davon nicht benutzbar sind (tauchen wohl noch in der Inverntory-Liste auf).

Ich guck mir nochmal die Sache mit den Offline/Armed states an. muss man da was in den MinenKlassen selber umschreiben...

 
  Faust writes on Monday April 12 2004 @ 01:14PM CEST [ reply | parent ]  
 
So, der Bug ist auch gefixed, war ganz easy!

 
  Faust writes on Monday April 12 2004 @ 07:16PM CEST [ reply | parent ]  
 
So, der Mutator ist für Offline soweit klar. Jetzt müsste er nur mal auf den Server draufgeladen werden, und Online getestet werden. Wie wärs mit Mittwoch?

BTW: @Nek: States sind ziemlich geil, wenn man mal durchsteigt. Eigentlich ganz simpel: Unter den States befinden sich ein Haufen Events und functions, die dann mit begin: innerhalb des States aufgerufen werden.
Will man jetzt alle diese Function noch einmal aufrufen oder befindet sich in einem anderen State, dann gibt man einfach GotoState ('blala') ein, und schon ist man wieder im vorherigen State!

 
  Analhusten writes on Monday April 12 2004 @ 10:08PM CEST [ reply | parent ]  
 
Bitte noch mal Doofe: Was macht der Mutator jetzt ???

 
  Faust writes on Monday April 12 2004 @ 10:32PM CEST [ reply | parent ]  
 
Er sorgt dafür, dass du und die Leute aus deinem Team von den eigenen Minen nicht in die Luft gesprengt werden, wenn ihr darüberlauft.

 
  Analhusten writes on Monday April 12 2004 @ 11:34PM CEST [ reply | parent ]  
 
OK, Danke! War mir vielzuviel Text und zuviel Coding...
Gute Arbeit,
Mal im Ernst, das ist jetzt als Übung zu verstehen, oder habt Ihr tatsächlich vor, den Mutator auf unserem Server dauerhaft einzusetzen???

 
  Nekrataal writes on Tuesday April 13 2004 @ 08:52AM CEST [ reply | parent ]  
 
Der Bug mit den 4 Minentypen war mir gestern noch aufgefallen.

Das was mir noch nicht am Mutator gefällt , ist, dass der Code ziemlich wirr aussieht und ich nicht das Gefühl habe so vorgegangen zu sein, wie es logisch erscheint (siehe oben Vererbungshierarchie). Dadurch hatten wir viele Probleme, wie z.B: das Vorhandensein der TripMine von Anfang an nach dem Spawnen oder das die DInger nicht offline gehen usw. die für sich wieder ausgemerzt werden mussten. Aber prima, dass Du es soweit geschafft hast. sollte man das Ganze noch kommentieren und die Sachen rausschmeissen, die man nicht mehr benötigt.

Für mich werde ich aber probieren, ob es nicht auch anders einfacher zu haben ist... im Moment habe ich aber das Problem, dass die Minen zwar in der ChecKReplacement ausgetauscht werden, auch zur richtigen Zeit on/offline gehen, aber man sie nicht legen kann, sondern immer diese "BEEP" kommt. Naja mal sehen ... vielleihct liegt es daran, das 4 Minen im Inventory sind ...

 
  Nekrataal writes on Tuesday April 13 2004 @ 09:24AM CEST [ reply | parent ]  
 
Ich denke das ich durch den neuen Code, den DU mir geschickt hast ein anderes Bild von CheckReplacement gewonmnen habe.

http://wiki.beyondunreal.com/wiki/Chain_Of_Events_At_Level_Startup

oder

http://wiki.beyondunreal.com/wiki/NoRedeemer

Das fand ich auch interessant. Mit dem Wissen werd' ich nochmal an die Sache rangehen ...

=> kurz und bündig:

CheckReplacement returns false => IsRelevant returns false => Actor ist nicht relevant und entfällt

CheckReplacement returns true => Der nächste Mutator wird befragt => geben alle true zurück bleibt der Actor drin, da IsRelevant() = true. Actors die man ersetzt mit ReplaceWIth oder anderweitig müssen daher immer true zurückgeben, da sonst auch die Ersetzung entfernt wird.

Gut das wir drüber gesprochen haben

frage mich nur wann muss ja leider noch ein wenig auf der Arbeit codieren ...

 
  Faust writes on Tuesday April 13 2004 @ 12:05PM CEST [ reply | parent ]  
 
Yo, ich hab mir nochmal dine Mails durchgelesen und stimme mit dir überein, dass man die CheckReplacement-function direkt dafür benutzen kann, die Minen beim legen auszutauschen (Dann hat man das ganze Gedöns mit den Defaultweapons nich, und man braucht auch keine Deployable-funktionen. Eigentlich braucht man dann fast garnichts ). Aber ich trotzdem stolz darauf, dass der Mutator auch so funktioniert, weil so unglaublich viel lernen konnte. Ich denke, ich bin jetzt fähig, einen beliebigen WaffenMutator für XMP zu proggen (Wie wärs mit InstaGib-XMP? )

Achja, nochwas anderes: Ich habe festgestellt, dass Teamabfragen in der Mutator-Klasse nicht richtig funktionieren! So hat das Blaue Team nur Minen bekommen, wenn diese für das Rote Team Online waren Deswegen habe ich die TeamEnergyAbfrage in den DeployableKlassen selber untergebracht. BTW sowohl der Bug mit den 4 Minentypen als auch der Bug mit dem nicht mehr wieder Online gehen wenn einmal Offline, hatte ich beide schon behoben.

 
  Nekrataal writes on Tuesday April 13 2004 @ 12:19PM CEST [ reply | parent ]  
 
Yepp Arbeit, aber wie gesagt, es muss auch hübscher Code sein ... daher werde ich probieren es wie gedacht ans Laufen zu bringen ... vielleichts hast Du ja Lust es nochmal auf diese Weise zu probieren ... natürlich testen wir auch die bestehende Version servermässig .. die MInen waren allerdings einfach, schwieriger wird, wenn man eigene Projektile bauen will und diese z.B. über die Distanz schwächen möchte (siehe TacOps) , d.h. auch bei Waffenmutatoren kann man noch viel lernen

 
  AzzraelDLX writes on Tuesday April 13 2004 @ 12:49PM CEST [ reply | parent ]  
 
Womit wir beim Thema wären:

Im XMPFORUM.DE habe ich ja was zur Klassenbalance gepostet und da als Anti-Ranger-Einheit der Gunner zur Sprache kam und wie nutzlos doch oft dessen Homies sind, könnte man doch mal spaßeshalber einen Mutator basteln, der ein kleines Bißchen effektivere Missiles bewirkt, damit die ach so bösen Ranger nicht mehr so "Uber" sind Nur probeweise halt!

 
  AzzraelDLX writes on Tuesday April 13 2004 @ 01:06PM CEST [ reply | parent ]  
 
Und noch eine gute Idee für einen Mutator, der auf großen, freien Maps ein wenig gegen Ranger helfen könnte: Tarnung.

Man kann sich unsichtbar machen, aber nicht 100%ig, sondern eher so "wabernd" wie in UT und auf keinen Fall lange!
Es wird persönliche Energie verbraucht. Das ganze soll nur dazu dienen, sich kurz zu schützen.

1. Auf keinen Fall länger als 2 Sekunden! Eher so 1,0 bis 1,5 Sekunden.

2. Man darf nicht schießen, sonst deaktiviert sich die Tarnung. Auch keine Granaten/Turrets/Packs supplien!

3. Man darf nicht hacken oder andere Spieler supplien!

4. Wenn man ein Artefakt trägt, lässt sich Tarnung nicht einschalten.

5. Wenn man ein Artefakt aufnimmt, deaktiviert sich die Tarnung sofort!

6. Evtl. wenn man das Jetpack einsetzt, deaktiviert sich die Tarnung.

7. Tarnung ist nach dem Gebrauch für mind. 5 Sekunden gesperrt.

Der Energieverbrauch sollte recht hoch sein, unter Umständen. Einmal aktiviert, lässt sich die Tarnung nur durch Einsatz einer verbotenen Aktion wieder abschalten (Schießen, Hacken, ggf. Jetten).

Weitere Idee: Tarnung lässt sich nur aktivieren, wenn man mindestens 75% Playerenergie hat.

Vielleicht kann man ja noch Dinge einbauen wie: Funktioniert nur im Gelände, nicht in Gebäuden (oder mit "Himmelsicht").

Mit diesem Mutator sollte es möglich sein, nach etwas Feintuning eine kleine interessante Balance-Note in XMP einzubringen.

Die CBP-ArtefactPowers sind ja nicht sehr verbreitet. Einen Versuch wäre es wert! Ausbalancieren und im Praxiseinsatz testen kann man es dann ja immer noch.......

Und???

 
  Nekrataal writes on Tuesday April 13 2004 @ 01:19PM CEST [ reply | parent ]  
 
Ich könnte mir vorstellen, dass es reicht, die Homing missiles schneller zu machen, wenn es sich beim "gelockten" Pawn um einen Ranger handelt.

 
  AzzraelDLX writes on Tuesday April 13 2004 @ 01:27PM CEST [ reply | parent ]  
 
Hmmm, da sprichst Du etwas an, was ich persönlich gar nicht bedacht habe:

Homing Missiles werden ja auch gegen andere Gunner und Techs eingesetzt. Und wenn die Homies nur gegen Ranger "schneller" gemacht werden, wäre das vielleicht balancemäßig "besser", aber irgendwie auch logisch schwer nachzuvollziehen.
Mich würde das stören, weil es keine Begründung dafür gibt. Nur weil ich Ranger bin, will ich keine negative Sonderbehandlung.

Dann doch lieber den Tarn-Mutator
Was sagt der Neckermann hierbei zur Machbarkeit...?! Faust?

Codet doch mal was in dieser Richtung...

 
  Faust writes on Tuesday April 13 2004 @ 02:28PM CEST [ reply | parent ]  
 
Hatte ich im zusammenhang mit der Recon-Klasse eh vor...

 
  AzzraelDLX writes on Tuesday April 13 2004 @ 02:36PM CEST [ reply | parent ]  
 
Ich denke aber auch, dass ein Mutator, der für alle Klassen gilt, einfacher durchzusetzen ist, als eine komplett neue Klasse, die die Spielbalance eh wieder total durcheinanderwürfelt.

 
  Faust writes on Tuesday April 13 2004 @ 02:40PM CEST [ reply | parent ]  
 
Bevor ich das für die Klasse progge, probiere ich eh, das ganze erstmal so als Mutator zu machen, auch wenn den dann keiner haben will.

 
  Nekrataal writes on Tuesday April 13 2004 @ 02:55PM CEST [ reply | parent ]  
 
unsichtbarkeit ist zwar prinzipiell witzig, aebr als Schutz gegen Sniper neeeee, DEr gunner ist ja auch nicht primär die Anti Ranger Klasse. Wenn man eine Anti Ranger Klasse haben will osllte man RANGER spielen

 
  AzzraelDLX writes on Tuesday April 13 2004 @ 03:37PM CEST [ reply | parent ]  
 
Ja klar, das ist so: Ranger mit Ranger bekämpfen. Aber man kann trotzdem mal schauen, wie sich das mit der Tarnung auf die Balance auswirkt. Wie gesagt: Nicht jedem liegt der Ranger, wenn er einen anderen bekämpfen soll

 
  Faust writes on Tuesday April 13 2004 @ 04:00PM CEST [ reply | parent ]  
 
Stimmt, unsichtbarkeit ist echt witzig:


Ich wusste garnicht, dass der Gunner schwanger ist!

 
  Nekrataal writes on Tuesday April 13 2004 @ 04:25PM CEST [ reply | parent ]  
 


 
  Faust writes on Monday April 12 2004 @ 07:43PM CEST [ reply | parent ]  
 

Jetzt kann man endlich als Gunner ungestört seine Kunstwerke vollenden!



 
  AzzraelDLX writes on Tuesday April 13 2004 @ 11:24AM CEST [ reply | parent ]  
 
Kühl! Das schaut ja schonmal nach was aus! Bin ja mal gespannt, wie sich das mit dem Mutator spielt.

Frage ist nur, ob Clanwars/Matches ohne FriendlyMining irgendwann einen offiziellen Charakter bekommen bzw. Standard werden.

Mittlerweile hat man sich halt an das Debakel gewöhnt, wenn man auf die Minen eines Freundes tritt.

By the way: Es wäre ja schön, wenn man erkennt, ob eine Mine friendly ist, damit ich sie dann nicht zerstöre, wenn ich sie sehe.

In der eigenen Base ist das zwar an sich eindeutig, aber was hindert einen Gegner, mal eine Mine in meiner Base zu legen, auf die ich dann frohen Mutes herumtrampel: "Hach ja, ist ja von uns!" --- BOOOOOM!

 
  AzzraelDLX writes on Tuesday April 13 2004 @ 11:27AM CEST [ reply | parent ]  
 
Und man kann den Gegner gut verarschen:

Wenn man mal (so der Zufall es will) in der Gegnerbase ist, kann man deren Arti gut verminen. Das hat zwei Effekte:

1. Der Gegner trippelt rein und BOOM!
2. Der Gegner denkt, er muss den Arti nicht mehr selbst verminen...und tut es auch nicht mehr: EASY CAPTURE!

Je mehr ich drüber nachdenke, desto unsicherer bin ich mir, ob friendly Minen gut sind....erscheint im Moment noch etwas "halbgar", weil es u.U. einen etwas zu starken Eingriff auf das generelle XMP-Gameplay nimmt.....aber mal sehen!

 
  Faust writes on Tuesday April 13 2004 @ 11:57AM CEST [ reply | parent ]  
 
Dir ist klar, dass Minen vom eigenen Team die eigene Farbe haben, oder?

 
  Nekrataal writes on Tuesday April 13 2004 @ 12:22PM CEST [ reply | parent ]  
 
Azze hat nicht ganz unrecht. Spammen ist mit den Teamminen natürlich einfacher ! Bei WFUT war es z.B. so gelöst, das man als Spieler nur 4 Minen platziern konnte. Das wird bei XMP über die Energie geregelt. Minen verbauchen schliesslich Energie. Muss man mal schauen, aber eventuell kann man die Anzahl der Team friendly minen begrenzen oder einfach Ihren Energieverbrauch erhöhen. Letzteres denke ich wäre eventuell einfacher zu regeln, da man nur ne Property umstellen muss. Auch begründen könnte man das Ganze durch die zusätzlich notwendige Teamerkennung ...

 
  AzzraelDLX writes on Tuesday April 13 2004 @ 12:43PM CEST [ reply | parent ]  
 
Ja, aber achte mal auf das Bißchen Farbe, wenn Du Dich unter Feuer dem eigenen Node oder wem auch immer näherst....Ok, in so einer Situation gilt eh: Vorsichtshalber lieber kaputtballern...

Man wird sehen, wie der Mutator sich auswirkt...

 
  SlasHeR writes on Tuesday April 13 2004 @ 12:34PM CEST [ reply | parent ]  
 
Nice Work!
Hoffentlich gibts bald ne 4. Klasse :)

 
  AzzraelDLX writes on Tuesday April 13 2004 @ 12:44PM CEST [ reply | parent ]  
 
Hoffentlich nicht...

Naja, gut, als Studie ist das schon ok!

 
  Nekrataal writes on Wednesday April 14 2004 @ 01:48PM CEST [ reply | parent ]  
 
Kleiner Nachtrag:

Gestern abend konnte ich noch mal 2 Stunden investieren, um den Gedanken mit der (an sich) logischen Vererbungshierarchie nachzuvollziehen. Ich habe nach und nach in eine von z.B. LaserTripMine abgeleitete Klasse SmartLaserTripmMine alle FUnktionen, States usw. der Vaterklasse übernommen und mit Log einträgen versehen, sodass ich im U2XMP Log File nachsehen kann, wann welche Funktion aufgerufen wird. Erstaunliches tat sich dabei auf.

Zum einen gibt es vieel Verweise auf die Vaterklassen (mittels super. usw.). Das sit nicht immer gut, wenn man von da aus keine Kontrolle mehr über seine Mine hat. Das krasseste war jedoch, dass selbst wenn alle diese Aufrufe raus sind z.B: hatte ich den Armed State kopiert und den für das Minenauslösen wichtigen Touch event völlig leer gemacht (also er tut nichts! ausser logging), es trotzdem dazu kommt, dass die Mine explodiert und das obwohl im Logfile steht "Jo war im Touch event und CanbeTripped liefert false".

Tja, spätestens da beschlich mich das Gefühl, dass hier irgednwas faul ist und die Klassenvon Legend u.U. nicht dafür gedacht sind von Ihnen abzuleiten. Bei events ist es nämlich so, dass da eventuell noch C++ Code hinterhängt und wer weiss welcher Mechanismus da letztendlich die Mine explodieren lässt, wenn das Touch Event sagt "Jo Touch erfolgt aber muss nichts tun". Das wiederum lässt es aber (es sei den man kennt den Behindcode) dem Glück des Programmierers, den richtigen Ansatz zu wählen, der da im Zweifelfall heisst, so hoch wie möglich in der Vererbungshierarchie abzuzweigen. Grrrr!

Zum neuen Minencode von Faust:

Leider funktioniert der SmartMines Code in der oben geschilderten Variante nicht. In der CheckReplcement Funktion werden alle Minen (auch die SmartMines, die ja dann zu den Laser>TripMines gehören) ersetzt z.B: durch

 
if ( Other.IsA('LaserTripMines'))
{
return False;
}

Aber auch der ursprüngliche Code führt nicht zu akzeptablen Ergebnissen. (Kein Bug in Deinem Code Faust, der ist ok, ich meine den Code wenn er wie oben geschildert verfasst wäre).

Ich denke als nächstes werde ich erstmal den Code von Deiner Version säubern, kommentieren und testen


 
  Faust writes on Wednesday April 14 2004 @ 04:35PM CEST [ reply | parent ]  
 
Funzt er jetzt, oder nicht? Also beim testen habe ICH nichts negatieves bemerkt!

 
  Nekrataal writes on Wednesday April 14 2004 @ 05:15PM CEST [ reply | parent ]  
 
Nene (hab ich doch extra geschrieben). Deinen Mutator hatte ich noch nicht reingeschmissen sondern slebst mit verschiedenen Vererbungshierarchien experimentiert insbesondere mit der im Screenshot erwähnten, die eigentlich am logischten erscheint. Was dabei passiert ist habe ich beschrieben

 
  Faust writes on Wednesday April 14 2004 @ 05:44PM CEST [ reply | parent ]  
 
Hehe, kleines Update zum Projekt Recon:

1. Die Klasse wird trotzdem Recon heissen, weil Infil ein scheiss Name ist!

2. die primäre Waffe wird nicht mehr eine Armbrust sein, sondern eine Nahkampfwaffe (bei der ein Heady tödlich ist)

3. Die sekundäre Waffe wird nicht eine Schallgedämpfte Pistole sein, sondern eine Art Betäubungsgewehr: PrimärFeuer ist ein Projektil, das den Gegner für 3-5 Sekunden extrem verlangsamt, Sekundär ist entweder ein Sniper-Zoom oder eine Art Betäubungsgas, das jeden um den Recon herum verlangsamt. Damit kann der Recon auch besser in der Defense eingesetzt werden (Flüchtende Ranger betäuben, damit Gunner sie zerfleischen können, harhar)

4. Die Shield-Gun wird die Anti-Fahrzeugwaffe des Recons sein. wenn ein Fahrzeug gegen den Shild fährt, dann explodiet es oder nimmt zumindest grossen Schaden.


 
  Nekrataal writes on Wednesday April 14 2004 @ 07:27PM CEST [ reply | parent ]  
 
Die Klasse heist volständig ja auch Infiltrator. Nenn es wie Du willst ein Recon wird es nicht sein, dass ist nämlich der Ranger !:-P!

 
  Mango writes on Wednesday April 14 2004 @ 07:28PM CEST [ reply | parent ]  
 
Aber verglichen mit dem Boost des Recon, ist der Ranger ein Waisenknabe! Haaach damals ...

 
  Splinti writes on Wednesday April 14 2004 @ 07:28PM CEST [ reply | parent ]  
 
Finde ich keine gute Idee... Einem heranrasenden Raptor wegzuspringen macht viel zuviel Spass!

 
  Nekrataal writes on Thursday April 15 2004 @ 10:06AM CEST [ reply | parent ]  
 
OK habe den Mutataor gerade getestet und es ist eine Mischung aus "Es funktioniert" und "es hat Bugs". Die Teamsensitivität funktoniert prinzipiell. Allerdings sind Landminen und Lasertripmines von Anfang an anwählbar. Legen kann man sie aber erst, wenn genügend Energy da ist.Ich hatte allerdings das Gefühl, das die Lasertripminen sich manchmal nicht legen lassen, obwohl die Wand dafür geeignet ist Jedenfalls schmeisst das Log noch jede Menge Fehler aus, die durch die Funktion kommen, die mit dem Timer aufgerufen werden.

 
function CheckTeamEnergy()
{
if( !Level.Game.IsTeamFeatureOnline( Class.Name, GetTeam() ))
{
bDamageable = true;
GotoState( 'Offline' );
}
}

Der Aufruf Class.Name bezieht sich hier auf nichts (da nichts übergeben wird). Der Aufruf endet daher mit einem Access None oder was soll Class.Name sonst beinhalten ?

Das Serverlog kann man sich hier ansehen. Es sieht so aus, als würde immer eine Fehlermeldung geschrieben sobald das Feature prinzipiell online ist. Ädnere doch die Funktion kurz ...

Desweiteren scheint noch ein Problem mit dem Offline Status zu sein. Da tritt auch ein Accessed None auf.

 
  Faust writes on Thursday April 15 2004 @ 10:29AM CEST [ reply | parent ]  
 
komisch... das stand aber nicht in dem Code, den ich dir geschickt habe?!?!?
Da stand da das drin:

function CheckTeamEnergy()
{
if( !Level.Game.IsTeamFeatureOnline( Class'Deployables.LaserTripMines'.Name, Owner.GetTeam() ))
{

GotoState( 'Offline' );

}

}

Falls du Class'Deployables.LaserTripMines'.Name zu Class.Name geändert hast, dasnn hätte ich dir sagen können, dass es Fehler geben würde. Wenn Du das nicht geändert hast, dann ist das seeehr seltsam

Was das von Anfang an anwählen betrifft, das ist im Prinzip kein Bug, sondern bei mir Offline auch so. Die Minen können nicht gelegt werden, wenn das Feature offline ist, und die Lasertripmines auch (Das du das Gefühl hast, sie könnten an manchen Stellen nicht gelegt werden, täuscht meiner Meinung nach, weil ich nichts an der Abfrage für den HitActor geändert habe.

Der Grund, warum die Minen am Anfang anwählbar ist, war der, den ich dir schon geschrieben habe: Die Teamabfrage funzt in der Checkreplacement function nicht richtig! Da bekam man dann als blauer Gunner die Minen erst, wenn diese für Team Rot Online waren! Und seltsameerweise hat eine Änderung in der ModifyPlayer-function nicht funktioniet! Deswegen fand ich es erstmal akzeptabel, wenn die Minen zwar anwählbar sind, aber nicht benutzbar (so als Kompromis)

Kannst du mir den Code mal schicken, den du modifiziert hast?

 
  Faust writes on Thursday April 15 2004 @ 10:34AM CEST [ reply | parent ]  
 
Achja, nochwas: Den Anwählbarkeits-Bug wollte ich ursprünglich so beheben, und zwar, indem ich DIESE Abfrage in die Deployable-Klasse einfüge:

if( !Level.Game.IsTeamFeatureOnline( Class'Deployables.LaserTripMines'.Name, Owner.GetTeam() ))
{
Destroy();
}

Dadurch wären die Minen zwar nicht mehr anwählbar, wenn keine Energie da ist, allerdings würden sie sofort verschwinden, wenn die Energie kurz mal Offline geht, und dann muss man ständig resupplyien, wenn die Energie dann wieder da ist. Hab ich mir so gedacht, getestet, habe ichs aber noch nicht.
Kann mir mal jemand verraten, wie ich hier in HTML Code erkennbar mache?

 
  Nekrataal writes on Thursday April 15 2004 @ 10:41AM CEST [ reply | parent ]  
 
Ich hab nichts modifiziert, sondern direkt das compiliert, was Du mir zuletzt geschickt hast. habs gerade nochmal runtergeladen und es ist diese Funktion.
Für einen weiteren Test schick mir einfach nochmal die aktuellste Version, die DU hast. Das klingt doch schon wesentlich besser in Deine Variante ...

Mh das Problem mit der CheckReplacement Funktion ... könnte es daran liegen, das zu diesem Zeitpunkt wenn sie aufgerufen wird, das Team noch nicht feststeht ?

Es ist schon ein wenig verwunderlich auf wie viele Ungereimtheiten man stösst. Da muss man einfach Zeit haben , Reinwachsen, sonst gibt das nix.

Versuch doch mal mit der Log Funktion nachzuvollziehen wie das Ganze abläuft.


 
  Faust writes on Thursday April 15 2004 @ 12:01PM CEST [ reply | parent ]  
 
Problem gelöst!

Aus dem Wiki:

Accessed None
Probably the most common error message in the log file. This error occurs whenever lines like

Owner.SetPhysics(PHYS_Falling);
i = Owner.LifeSpan;

are executed and Owner is set to None.

Also habe ich Owner.GetTeam einfach mit Self.GetTeam ersetzt, und schon gibt es keine Fehlermeldungen mehr!

 
  Nekrataal writes on Thursday April 15 2004 @ 02:31PM CEST [ reply | parent ]  
 
Das ist klar ! Du musst schon schauen ob das Objekt irgendwo überhaupt vorhanden ist . Das heisst aber auch das in Deiner Version noch Fehler drin waren ... schick mir einfach die neuste zum Ausprobieren.

 
  EnergyRex writes on Thursday April 15 2004 @ 06:40PM CEST [ reply | parent ]  
 
Hi

ich verfolge es ja jetzt auch schon ne weile.
Inzwischen kann ich euch beim coden wohl kaum noch helfen, da ich zugeben muss..... Ihr seid da deutlich besser drin wie ich .
Kleine Veränderungen bekomme ich noch hin, aber so wie Ihr das macht, kann ich nicht mithalten.
Naja, muss ja auch nicht
Wenn ihr nur ein Model braucht und die Standard animationen verwendet kann euch Atomicbrain evtl. helfen. Der kann mit dem 3DMax recht gut modeln und skinnen, wobei skinnen mehr mein Part ist.
Als Beispiel sein UT2004 Bot:
http://unrealed.myexp.de/index.php?P=info&D=1356 den es als Download gibt.
Nur Animationen erstellen verstehen wir nicht.

Ich muss ja meine GEOmassif mal fertig machen, welche mich zur Zeit voll zurückwirft und ankotzt wegen dem Bug im Bunker
Viel Glück mit dem Recon
freu mich drauf !!!!

 
  EnergyRex writes on Thursday April 15 2004 @ 08:38PM CEST [ reply | parent ]  
 
Also... wir haben uns mal bissl im Max und UEditor umgesehen und haben schon gleich ein Problem.
Ohne eine vorhandene Skeletal-Information kommen wir da nicht sehr weit. Im Editor kann man zwar in etwa die Bones ablesen, aber auch nur fast. Oder wir bräuchten eine Bone-Hirachie Anleitung. Aber alles eben nur solange eine vorhandene Animation verwendet wird. Animationen im Max zu machen ist eigentlich auch nicht das Problem, nur verstehe ich nicht ganz, von wo bis wo eine Animation geht. Mir fehlt da der sozusagen der Mittelpunkt der Animation oder so ähnlich. Ich kann mich da grad nicht richtig ausdrücken und schreiben was ich meine. Wenn ich mal wieder richtig viel zeit und lust hab muss ich mal wieder mehr in die Richtung arbeiten.


 
  Faust writes on Thursday April 15 2004 @ 09:38PM CEST [ reply | parent ]  
 
Ok, Danke für die Mühe!

 
  Faust writes on Friday April 16 2004 @ 10:57AM CEST [ reply | parent ]  
 
Nur ob der transparenten Informationspolitik: Die Unsichtbarkeit macht Fortschritte!



 
  Faust writes on Friday April 16 2004 @ 02:20PM CEST [ reply | parent ]  
 
Ich verlinke mal frech:

http://xmpforum.de/forum/viewtopic.php?t=367

 
  Faust writes on Saturday April 17 2004 @ 02:39PM CEST [ reply | parent ]  
 
Sag mal Nek, wolltest du den MinenMutator heut nicht mal antesten? Hast du das schon gemacht? Und wie gings?

 
  Freeway writes on Saturday April 17 2004 @ 08:06PM CEST [ reply | parent ]  
 
He, das würd mich auch interessieren.
Erzähl mal.

 
  Nekrataal writes on Sunday April 18 2004 @ 10:14PM CEST [ reply | parent ]  
 
Soory aber ich war das ganze WE unterwegs und habs daher nicht geschafft Probiere es Di oder Mi morgen

 
  Faust writes on Thursday April 22 2004 @ 04:40PM CEST [ reply | parent ]  
 

Yo, sieht ganz nett aus, ist aber trotzdem voll der Unfall! Aber so langsam komts!

 
  Faust writes on Sunday May 02 2004 @ 04:57PM CEST [ reply | parent ]  
 
Update in Punkto Laserpointer: Den Strahl habe ich jetzt stabil und die Turrets sprechen auch schon drauf an!




 
  Splinti writes on Sunday May 02 2004 @ 05:19PM CEST [ reply | parent ]  
 

Welcher Laserpointer?

 
  Faust writes on Sunday May 02 2004 @ 05:21PM CEST [ reply | parent ]  
 
http://xmpforum.de/forum/viewtopic.php?t=367

 
  Freeway writes on Sunday May 02 2004 @ 05:23PM CEST [ reply | parent ]  
 
Versuchst du die Turrets zu steuern ?


 
  Splinti writes on Sunday May 02 2004 @ 05:30PM CEST [ reply | parent ]  
 
Ja, sorry, habs soeben kapiert... Ich wusste doch, das ich mal was gelesen hab dazu habs aber in der Story hier nicht gefunden... *g*

 
  Freeway writes on Sunday May 02 2004 @ 05:35PM CEST [ reply | parent ]  
 
Ach schön, könnt mich mal jemand aufklären.
Ich weiß mal wieder von nichts.

Later: Ja schon gut habs gefunden.


 
  Faust writes on Friday May 07 2004 @ 12:13PM CEST [ reply | parent ]  
 
Können wir das Dingen mal testen?

 
  Zoom writes on Tuesday January 04 2005 @ 06:21PM CET [ reply | parent ]  
 
He Faust

what about a recon for utxmp?

 
  Faust writes on Tuesday January 04 2005 @ 10:17PM CET [ reply | parent ]  
 
Would you like to do the playermodel?

No, serious, I definately have this in mind, but unfortunately I'm rather busy with other projects right now, so that I have to set this on hiatus...

But it's slowly evolving

 

Thread closed ! Story is too old too contribute. Please contact administrator to repost this story.


 Topics
  • Convention (54)
  • Technique (64)
  • Games In General (172)
  • Community (223)
  • UT2003/4 (299)
  • CS:Source (17)
  • Internal (153)
  • XMP (87)
  • Magic the Gathering (58)
  • Team Fortress 2 (51)

  •  Main
    Latest Postings
    News Index
    Search
    Contribute News
    Contribute Image
    Links
    Stats
    FAQ
    Contact
    Chat

    Copyleft © 2003 Gamer's Dungeon
    All trademarks and copyrights on this page are owned by their respective owners.

    Powered by phpWebLog