Legacy:Inbox

This is a page for material that doesn't yet have a home. Add anything you like here, and seasoned contributors will at some point find it a home elsewhere in the Wiki. To get started, click the "Edit text of this page" link at the bottom of this page.

Example

This is the body text. Here's a link to the New Contributors Quick Start page.

New paragraph. Check the above link for info on giving yourself a username & your own user page on the system. Below is a rule-off. Start new entries below & follow this markup.

---

Mysterial: In UT2003, GameInfo and Mutator have a function GetServerDetails() that allows modmakers to add to the info displayed by the server browser in the bottom left window.

---

A problem some mods could have is that they want to modify all of a specific kind of object's properties, yet functions like Mutator's IsRelevant() don't get called on them. This problem can be fixed with the code:

local Object O;
 
foreach AllObjects(class'object', O)
			if (ClassIsChildOf(Class(O), class'BaseClass'))
				class<BaseClass>(O).default.SomeVariable = SomeValue;

This code needs only run once, and allows you to change the default properties of any class below some base class.

Foxpaw: You could do that with a lot less CPU usage by cutting out the middleman:

local Object O;
 
foreach AllObjects(class'BaseClass', O)
  class<BaseClass>(O).default.SomeVariable = SomeValue;

Mysterial: That doesn't work; the iterator would return actual objects, not classes that you could cast like that. Plus, the point is to change the default value for all subclasses of the BaseClass, not BaseClass itself.

Foxpaw: I see you are right about the class casting. I'm not sure where my head was when I wrote that bit. This one would work - and subclasses of that class will still get the call from the iterator:

local BaseClass O;
 
foreach AllObjects(class'BaseClass', O)
  O.Class.default.SomeVariable = SomeValue;

---

Mysterial: It seems as though Actor references don't get properly set to None in objects not subclassed from Actor. I had an Interaction that set a variable to one of the local pawn's inventory items, and if that pawn died the game would often crash because the variable wasn't None even though the inventory item no longer existed.

In addition, the game will randomly crash during garbage collection if an object that is no longer referenced (for example, a menu long closed) if that object contains an invalid Actor reference. The trademark of such a crash is a long list of (Some Object)->Serialize strings in the backtrace.

---

Foxpaw: This works, but is bad mojo. So don't do it. It's probrably unstable. If you have a wierd, really wierd bug, maybe it's caused by something like this. I did it by mistake before I realized that I was using something I hadn't declared in that class, but in a subclass of it.

Ph3AR! A hole in the time-space continuum:

class ImAClass extends Actor;
 
var Someotherclass Classtastic;
 
function Ihavefunctions()
{
  ClassTastic.AStruct.Avar = 3;
}
// Blah blah blah.
 
class ASubclass extends ImAClass< SEMI >
 
struct StructDef
{
  var float AVar;
  var string AnotherVar;
}
// And then some...
 
class Someotherclass extends actor dependson(Asubclass);
 
var ASubclass.StructDef Astruct;

Note that we are calling something that hasn't really been defined yet. An even easier way of causng mayhem:

class MyClass extends Actor;
var MySubClass Submarine;
 
class MySubClass extends MyClass< SEMI >

Suffice it to say, don't refer to subclasses of a class within that same class, or the UEd Goblin will eat your babies! Alternatively, this type of wanton class looping results in GPFs if you make a wrong move.

Wormbo: That second thing works reasonably well with the Actor class and its Instigator variable which is a Pawn reference (subclass of Actor) or its Level variable which a LevelInfo reference (also a subclass of Actor).

Foxpaw: Well, yes, it works, it's just that it has a high risk of ceasing to work as a result of changes.. plus it's extremely poor OOP form, if you ask me.

---

Foxpaw: BSP that is extremely distant seems to not be drawn, or not be drawn properly. I made a cubic brush 2^18 units per side and the surfaces did not show up at all when I subtracted it. A brush 2^17 units per side showed up but had a HOM effect in the editor. Brushes of 2^16 units per side and smaller seem to work fine. This seems to work fine if the surfaces are fake backdrop, however.

Birelli: To the BSP drawing thing - I imagine that has something to do with textures. When each "tiling" of the texture becomes less than 1 pixel, for instance, the algorithm might start to break down. This wouldn't necessarily happen with fake backdrop because the backdrop isn't drawn the same way.

---

Foxpaw: I noticed that if you override a function in a subclass that has one or more variables declared as "out" variables, if you change the declaration in the subclass and leave out the "out" keyword, the compiler will accept the new version and that variable will not be treated as an "out" variable for that class and it's subclasses. I'm not sure if this works the other way around. (making a non-out variable an out variable.)

---

Foxpaw: If you destroy an actor within KImpact, UT2003 gives you a GPF. I believe this is because the list of all colliding actors is generated, then each collision isis evaluated. As a result, after the actor is destroyed other things that were colliding with that actor still want to collide with it an there's a null pointer being accessed within the native code. But that's just speculation on WHY it GPFs. The workaround appears to be setting a flag so the actor can destroy itself in Tick.

Mysterial: This is true of pretty much every Karma event. In addition, you shouldn't edit the Karma properties of an object in a Karma function, for similar reasons. I *think* there are checks for these kinds of things in UT2004, but I'd take the safe path and just flag things for processing elsewhere.

Foxpaw: I really hope they do include checks.. I'd really like to be able to destroy objects from within the KImpact event. If one of the ships in my mod hits something going at any kind of speed, it takes damage, which may result in destruction.. so I've had to delay all destruction due to damage to the next tick, which is a bit hackier than I like.

---

Foxpaw: Apparently, using a reference in the default properties to call an iterator gives an "invalid code token" at runtime. IE, class'Whatever'.default.Singleton.SomeFunction() is okay, but foreach class'Whatever'.default.Singleton.AllObjects( class'etc', etc ) gives the invalid code token. I found this interesting as both seem like function calls and you can use an iterator like that for references not stored in the default properties.

Also AllActors is amazingly slow. A Uscripted Dynamic array with all the same contents can be iterated through in roughly one quarter of the time.

---

From Mod Authoring/Introduction to Gametypes

Update for UT2K4 :

BigJohn: This seems to have changed a bit in Unreal Tournament 2004. In order to make a gametype mod and have it appear under the game list, we now need to have 4 values in our GameType's class' defaultproperties :

class MyGame extends DeathMatch;
 
defaultproperties
{
   GameName="My Game"
   Acronym="MG"
   MapPrefix="MG"
   Description="A bloody fight to the death!!!."
}

Also, there is no need for the Object line in the game's int file (But you do need the Preferences line!).

Your MyPackage.int should look like this:

[Public]
Preferences=(Caption="My Game",Parent="Game Types",Class=MyPackage.MyGame,Immediate=True)
 
[MyGame]
GameName="My Game"
Description="A bloody fight to the death!!!."

You can use the command

ucc dumpint MyGame.u

to create the [MyGame] section in the .int file.

UCC can generate a .ucl file from our package's .u file. This can be achieved by typing this command:

ucc exportcache MyGame.u MyGame.ucl

Once this is done, the only thing left is to have a map in the UT2004\Maps folder with the appropriate prefix, in the above case MG.

---

Tarquin: We can't edit these pages because they are by Epic. Please can we find another home for the above piece of text?

Co11: Also, for ut2004.. it seems that Deathmatchplus and TeamGamePlus are no longer functional. Try just Deathmatch and TeamGame.

Wormbo: As stated on Mod Authoring this whole tutorial is only for UT, not for newer engine versions. For anything else go to UnrealScript Lessons or Making Mods.

Category:Legacy To Do → Move content to the correct pages.

---

Foxpaw: I noticed something interesting today, apparently function arguments in subclasses need not have the same names as their original declarations, as long as they are of the same type and in the same order. IE, the following is valid:

class A extends Object;
 
function F( float P )
{
  // Do Stuff.
}

class B extends A;
 
function F( float Q )
{
  Super.F( Q );
 
  // Do some other stuff.
}

Of questionable value, but it's possible. I noticed that some of Epic's code uses "dt" as the argument name for tick some places instead of "Delta," so I tested it in my own code and it seems to work.

MythOpus: Yep :D I caught on to that quite quickly. It helps to give more descriptive names to arguments in your code, rather than using epics stuff.

Mychaeel: Indeed. Usually, in any object-oriented language, only the function prototype – i.e. the function name, its return type and its parameter types, but not the symbolic parameter names – are relevant for resolving a function reference. (In many languages which support function pre-declaration, it's even valid to leave the parameter names out: void foo(float, int) is perfectly valid in C and C++.)

---

Blip2: I found this cool program for the text colours in UT this apparently causes problems with names but I have found it is useful with in-game coloured messages I would write happily write a paragraph or two about how to do this and where to get this program if I knew where to write it (any ideas?)

Graphik: Create a page for it.