Wikis / Unreal Wiki / Legacy:UT2003/Suggestions

Engine suggestions for UT2003. See also UnrealEd suggestion list.

UnrealScript

Comment blocks

EntropicLqd: Make multi-line comment blocks at the top of class files behave correctly. The code snippet below will not compile because it thinks the class name is was. Look for the class keyword on line two.

ZxAnPhOrIaN: The only, I mean ONLY, way to include "class" in comments is to put it into a single line comment.

/*
   This trigger allows mappers to change some of the zone properties using a trigger.
   The specific case this class was written for was to enable a switchable "escalator"
   zone to be created, where the escalator could move in two directions at once.
 
   Version By  Description
   ------- --- -------------------------------------------------------------------------
   1.00    DML Created for Pitboy from the UT Editing fourm.
*/
//   The class keyword will work in in single-line comments:
//
//
//   This trigger allows mappers to change some of the zone properties using a trigger.
//   The specific case this class was written for was to enable a switchable "escalator"
//   zone to be created, where the escalator could move in two directions at once.
//
//   Version By  Description
//   ------- --- -------------------------------------------------------------------------
//   1.00    DML Created for Pitboy from the UT Editing fourm.
 
 
 
 
class TriggeredZonePropertyChanger extends Actor;
...

States in non-Actor classes

Mychaeel: Do states still only work in classes derived from Actor? It'd occasionally be very handy to be able to use states in other classes as well – I remember coding some UWindow widget with a couple of states and being a bit disappointed when (after compiling alright) it just didn't work because the object wouldn't change states.

Mongo: This is possible to do with native code. Just call InitExecution() on your new object. Unfortunately, you don't get latent code with this, because you need to be ticked in order to have state code, and objects aren't ticked.

Mychaeel: States are what I'm striving for here, not latent code; and native code is certainly a poor choice for a mod developer, especially when it's used just for the developer's convenience instead of the user's.

Dma: Look at Console.uc. It uses states. It is not a subclass of Actor. Go forth and code.

Mychaeel: As UsAaR33 points out in the "Comments" section below, Console is the only other class besides Actor subclasses that supports states. I'd like to have it in all classes though.

Typecast from byte to enum

Mychaeel: Being able to typecast from byte to enum would be great – or just being able to assign byte values to enum variables. Especially with UnrealScript's arcane enum scoping rules that'd be very useful at times.

Mongo: It'd be useful, yes. But it'd also make code more hairy to deal with. You can copy and paste your enum between classes if you like. At least that should help code clarity.

Mychaeel: Copying and pasting enums (apart from being a slightly ugly thing to do in its own right) doesn't make them compatible though. I can't copy Canvas.Style to Actor.Style, for instance, even though both are used with the ERenderType enum throughout the code (but Canvas.Style is a byte variable).

Xian: It is already possible. Just look at the Canvas thing in UT99: Canvas.Style = ERenderType.STY_Normal. You can do the same with every enum and the syntax is: <byte_var> = <enum_name>.<enum_element>; As for the reverse thing:

var enum ETest
{
   Test1,
   Test2
} Testing;
 
function Blah ()
{
    Testing = 1;  // Testing = Test2
}

Simple and clean :)

Foxpaw: You can do this now with dependsOn, though dependsOn is sometimes a bit flaky. Optionally I think you might be able to do this with setpropertytext as well.

InStr function

Mychaeel: Just a minor improvement: The InStr function could use an optional third "offset" parameter specifying where in the string the substring search starts. There's always the following UnrealScript idiom to achieve the same, but it would be so much more efficient natively...

function int InStrFrom(coerce string StrText, coerce string StrPart, optional int OffsetStart) {
 
  local int OffsetPart;
 
  OffsetPart = InStr(Mid(StrText, OffsetStart), StrPart);
  if (OffsetPart >= 0)
    OffsetPart += OffsetStart;
  return OffsetPart;
}

UsAaR33: And why not add a 4th optional boolean parameter for Case Insensitivity?

Mongo: Well, you just defined the function. I guess there's no point to implementing it natively. And speed is not a valid argument, considering the number of things that are done in unrealscript. :)

Mychaeel: If that was the case, there wouldn't be an InStr function in the first place – InStr could be just as well done by iterating over the string in a for loop. I've been using InStr for parsing HTML (nothing you'd usually do in UnrealScript, without doubt, but even Epic did that themselves) and any bit of generic acceleration would have been a big plus there.

Boolean operators could coerce their arguments to bool

Boolean operators could coerce their arguments to bool (and the same for if, while, until). That'd make many expressions more concise and thus more readable. (Of course it also has the potential to make code less readable and more obfuscated, but which powerful syntax construct doesn't? At the end of the day the quality of code is up to the coder anyway.) →Mychaeel

if (ThisPawn && ThisPawn.Weapon)
  ThisPawn.Weapon.Fire(0.0);

Foxpaw: I agree, although I wouldn't use this personally, it seems like the way it should be.

Global constants

EntropicLqd: Support for global constants than can be used across classes, within object default properties, and within array declarations.

Mychaeel: Well... how, across classes? Where would a constant whose scope goes beyond this class and its subclasses be defined?

EntropicLqd: How about if you simply defined a constant outside of a class definition (before the initial class declaration) it had global scope? I realise it could lead to somewhat untidy code if people littered their constants across their class files, but that's their problem. I guess I could always dig out a pre-processor and tweak the code a little :)

Tags other than Tag and Event

Actors such as the Dispatcher and RoundRobin don't show ties as read lines in UEd – presumably UEd is hard-coded to draw the lines when "Event" and "Tag" properties match.

It would be handy to have syntax like this:

var() pseudoevent name AnotherEventProperty;

This would notify UEd that the property should be inspected & red lines drawn if a match found. (note that the actual keyword "pseudoevent" is lousy. Something better would be needed. Mych is always good with naming ;) )

In-Scope Declaration

[BWF]GrimReaper Wouldn't it be nice to be able to do things like the following. 'See int declaration' Don't know if it is implementable into ucc.

for (int i=0; i<10; i++)
    Log(i@"Blah");

Foxpaw: I don't like that format. It's kind of neat, but it makes the language less flexible. With that kind of format you can't do the following:

  var MovementType MovementType;
  // or...
  local string String;

Which may seem like poor style to some, but I'd like to see some solid experimental evidence to back up the suggestion that my so called "bad" style is worse than so called "good" style.

Debugging Timer.. thing.

Foxpaw: I think it would be very useful if there was a somewhat detailed breakdown of where the Engine was spending its time. This would help optimizing of code greatly I think. I would think it could be invoked via command line or maybe a special option during package compilation, and could display statistics like:

• Percent of Time spent in Unrealscript loops
• Percent of Time spent in iterator loops
• Percent of Time spent tracing
• etc.. for all the heavyweight functions
• Perhaps the ability to log a list of all functions that got called in order of how frequently they are called.

You could of course test many things like this by using the existing script timers, but it would take a very long time for me to go through ALL my classes and add timers before each trace I do, etc.

UnrealScript Development Environment

Incremental search

Mychaeel: Incremental search, one of my favorite navigational features in any text editor: Pressing a certain keyboard shortcut (Ctrl+E) puts the input focus to an edit field in either the status bar or a toolbar. The search within the active window is performed as the user enters and modifies the search string, starting from the current cursor position. (Pressing Home resets the search start point to the beginning of the text, pressing F3 searches for the next occurrence.)

It's the most efficient way of searching a text document, from the user's point of view, because he/she never has to enter more text than necessary to find what he/she's looking for.

Tabs and blanks for indentation

Mychaeel: As an option, use the Tab key to enter spaces up to the next tabstop. Many coders prefer indenting their code with blanks instead of tabs, but still find it convenient to use the Tab key to enter as many blanks as necessary to jump to the next tab position. (For that matter, the tab width should be configurable.)

(I'm implying the presence of auto-indent here, by the way...)

[BWF]GrimReaper Most programming language styles prefer blanks due to the fact that any editor/viewer will give the same indentation result. Tabs however is easier and less strainful than 4 spaces or something. The editor or IDE should directly convert a tab to 4 spaces if it where up to me.

Block indention/unindention

Mychaeel: Block indention/unindention, using the configured tab width (and tab-vs-blank setting). Suggestion for a shortcut: Tab and Shift+Tab when text is selected.

Hugh: Personally, I like the way Textpad handles this. For a start, you can specify how many spaces you want each tab to take up (x). You can also tell it to a) always put x spaces in when you hit the tab key, or b) convert all tabs to x spaces.

Classes

ControlPoint, FlagBase deletable

EntropicLqd: It would be great if the ControlPoint and FlagBase actors were deletable by game type and mutator mods. It was one of the more painful things to have to code around when writing my CTF+ mod.

Associating custom data with players

Mychaeel: A very common problems mods and mutators used to have was associating custom data with players. Game type mods might indeed create their own PlayerReplicationInfo subclass and use it, but that's something mutators definitely shouldn't do unless their author intends to scratch any compatibility the mutator might have to custom game types and other mutators. Usual idioms to work around that problem were

• Using PlayerID as an index into an array (breaks if more than 32 players/bots enter and leave a game in total).

• Using a ReplicationInfo subclass owned by the player's PlayerReplicationInfo and retrieved with a ChildActors call (inefficient if it has to be done frequently).

A ReplicationInfo NextCustomInfo reference in ReplicationInfo would make associating and efficiently retrieving ReplicationInfo actors with a given player very easy and convenient. For good measure, the following method (in ReplicationInfo) would make it even easier.

// in ReplicationInfo
 
var ReplicationInfo NextCustomInfo;
 
 
function ReplicationInfo GetCustomInfo(class<ReplicationInfo> CustomInfoClass, optional bool bNew) {
 
  local ReplicationInfo ThisCustomInfo;
 
  for (ThisCustomInfo = NextCustomInfo; ThisCustomInfo != None; ThisCustomInfo = ThisCustomInfo.NextCustomInfo)
    if (ThisCustomInfo.Class == CustomInfoClass)
      return ThisCustomInfo;
 
  if (bNew) {
    ThisCustomInfo = Spawn(CustomInfoClass, Owner);
    ThisCustomInfo.NextCustomInfo = NextCustomInfo;
    NextCustomInfo = ThisCustomInfo;
  }
 
  return ThisCustomInfo;
}

Thinking about it, it might be a good idea to make that a doubly-linked list and automatically remove a ReplicationInfo object from it when it is destroyed.

Per-mod keybindings

UsAaR33: This may be asking a lot, but to help mod support, additional keybind classes would be great. These could be made into some sort of linked list and a mod would have a subclass of it to support the system. When a key is pressed the Input would look through the classes until it finds a binding for a key or reaches the end of the list. Thus, different mod's keybinds would not conflict with each other (unless they are run simultaneously. For instance, many UT mods have a reload binding. Wouldn't it be great if reload could just be bound to the same key for all the mods without going into complex manual keybindings?

Foxpaw: The problem with this is the same as the problem with it now: how do you decide if two things are the same? Mod A may have an exec function for reloading, and Mod B may use an input variable. How would the Unreal Engine discern that they were both intended for reloading? You could add a tag to each keybind to say what it was supposed to do, but there still there's no standardization.

GetItemName function

UsAaR33: Actor.GetItemName() should 1) Be in the Object class and 2) Be static.

Miscellaneous

UWindows vs. simple menu system

UsAaR33: Oh and please dump the existing menu system. UWindows are superior to any form of "single-menu-window-showing-at-a-time" menu system.

Mychaeel: That's within Digital Extremes' responsibility, not Epic's. I understand Epic themselves mourn the removal of the UWindow system just as we do.

UsAaR33: Well, in that case I'll just add that to the Oldskool 2k3 (or whatever TNSe's mod will be called) fix list. In that case, maybe I can just request continued support for uwindows? (so that mod authors can still use them and even *cough* redo the entire menu system.

Foxpaw: It's entirely possible with custom script to replace the GUI system. Having said that, UT2004 promises a new GUI so this is more or less already resolved.

MythOpus: I wonder where that 'new' menu system is. I feel that all the new games have turned to U2/UT2004's style of menus. I miss UT + UWindows..

Menu accessible in-game

UsAaR33: Be sure the mod menu is accessable in-game, in addition to globally.

Custom model/voicepack support client-side only

UsAaR33: Having models, skins, and possibly voicepacks being treated in a similar manner as Quake, Half-Life (I believe), and Valhalla Avatar (UT mod). In which the client loads such media itself, as opposed to UT's system of the server loading it and then sending the export index to clients. This allows for usage of models/skins/vp's even if the server doesn't have them installed. Clients with the given model/skin/vp installed will use them; if not, the default. With the Controller/Animation handling split, I wouldn't imagine this being too hard to code at the last minute. Perhaps support for peer-to-peer transfering? (Altough peer-to-peer transfering can create cheating issues with cheat skins and the like...)

Mongo: That sucks. UT2003 will give more functionality to the model creator for support with footstep sounds, blended animations, particle effects, etc. As such, given that you're executing custom code, it's not feasible to implement this without opening up a can of worms (see: cheating.)

UsAaR33: Any default property can be read. It is only non-static functions (or static functions with actor pointers) that can cause security concerns. It is a known fact that most model authors do not want to touch code. I think the only custom UT models that ever had custom scripts were the U4E ones and Spawn. (or ones Psychic_313 or myself did coding for). And I am willing to bet that the majority of model creators would be willing to sacrifice uscript functionality in exchange for a broader audience (that is online). Why do you think the Quake model scene is so much larger than UT's? IMO, it is the lack of such a system that hurts UT. (What is the point of making a model that you can only use on bots and can't show off to a bunch of random people on the Internet?)

Birelli: Maybe I'm missing something about adding support this kind of thing ala Valhalla Avatar. As far as I can see, there is no security loophole opened by allowing people to use content that some people don't have. The one thing that comes to mind here in terms of cheating is invisible skins/skins with flags/skins of the wrong team color, etc. With the system in Valhalla Avatar, and presumably what would be added here, the only people that would be affected by this cheating content would be people who had this content themselves. Ironic that only cheaters can be cheated upon with this system isn't it? ;-)

Hugh: I seem to remember that the problem with Quake in this aspect was that people could get it to give the other players on their client a different skin. So somehow get their client to tell the server that yes, they did have this custom model/skin, and yes, it would display it, but when it wasn't actually the one that that player had chosen to use...

UsAaR33: Well, Hugh, peer-to-peer transfering doesn't have to be implemented. Just the basic clients-load media system is what is important.... And I suppose "override" models (i.e. a default one) would be a sweet addition (I was going to add that to VA.. never got around to it though :/)

Enhanced demo driver

UsAaR33: A Demo Driver that supports pausing and speed controlling. Preferibly time jumping as well, although the existing Demo code (i.e. really just network packets) makes that quite difficult.

Hugh: I don't know what the demo format itself is like at the moment, but some kind of demo format that is easily editable - so someone can make a tool for re-camming matches, etc. (Like KeyGrip 2 for Quake 2)

UsAaR33: Hugh, as I said, it is pure UT network packets. Demos are generated by analyzing the replication statements, but instead of sending the packets over a network, they are written to disk. Hence, editing/recamming is extremely difficult. (in other words, the demo system can best be described as a "hack".

Hugh: What would be nice would be an additional system which would record things block by block - like the way Quake and Quake 2 do it. They would take a snapshot every 1/10 seconds - then the game would interpolate between them when playing it back. There were little problems with this, but if anyone was going to try to implement it, then I'd be happy to run through it with them and iron out all the problems that Q2 had...

Demo browser

UsAaR33: Some form of a Demo Browser? Not unlike Demo Manager 2.0 for UT. It seems foolish to take so much time to have programmed support for demos and then only have them accessable via console commands, leaving most users unaware of their existance.

Package handling in multiplayer

UsAaR33: The current UT package loading methods in multiplayer are flawed.

• I believe it acts like:
  1. Search for a required package by order of Paths list.
  2. If not found, search in cache for GUID.uxx
  3. If still not found, request download.
  4. If a file was loaded from the paths list, but does not match GUID, version mistmatch error.

• I'd like this order:
  1. Search for a required package in the cached directory (GUID.uxx)
  2. If not found, search the paths list. If the filename is found, verify that its GUID is correct before loading the entire thing.
  3. If still not found, request download.

This will prevent the version mismatch errors once and for all, making updates much easier on the end-user.

Mychaeel: I heard they've been thinking about something like that. It has been mentioned in the discussion, anyway. (Related: The ability to conform packages has been removed without substitution.)

UsAaR33: Um.. why did they strip conforming? It is very useful.. especially patching on their end. (I've used it for my own mods as well.)

Mychaeel: For security reasons, or so I recall Dr.Sin saying. (Or maybe I'm not remembering it correctly. He did say something about that, anyway.)

UsAaR33: Heh.. I'm on the CSHP/UTPure team. I do recall him mentioning that he didn't like package conforming and would like it stripped (though I disagreed). Well, that makes life harder on mod authors and UT users. I hope they at least have more friendly "different version" handling, which would make up for the conforming loss.

[BWF]GrimReaper: I asked Dr.Sin to remove it since it's THE holy grail for UT hacking. Until today it still remains a part of UT. His reply was that people would build one if it was removed. Personally i'd bottle out at that point. Question? Who needs conforming except for Epic patches that need to be inter-version comapatible? Answer: Nobody, and if you would, you could go and ask Epic to do it for you 5mins job in the name of security.

dup() like functionality for objects

Foxpaw: It's come to my attention that the ability to make a bitwise copy of an object would be very useful in UnrealScript. Sometimes I have an object that I need to make a copy of, and it's rather tedious and error-prone to have to write a special function to copy all of the variables, plus it wouldn't perform as well as a native object copying function.

Discussion

Tarquin: Are these suggestions that were made at the conference, or a list that people can add to now? In either case, will Epic be reading this page?

Mychaeel: Suggestions I should have made at the conference, but forgot to. I guess Epic won't read this page unless I point them to it, but I plan to...  :)

Hugh: I've just pointed this page out to the devs – At this stage, they wouldn't be able to make any changes to the engine for UT2003, as it's so close to release (we hope!), but anything that they feel is a good idea may make it into future incarnations of the engine (which is evolving all the time) for other games (U2, etc). That said, there are some things on here that are so small, while they may be useful, they'd probably cause more havoc by breaking people's maps.

Mychaeel: Thanks, Hugh. I still hope that some of the things suggested on this page will make it into the first UT2003 release, for instance the UDE items and things with good backwards compatibility like that InStr suggestion and the defaultproperties one...

Tarquin: ... and the Lift thing is just a class script tweak :)

Hugh: How did you know that was the one I was thinking of? That was actually the only one I've read..

Tarquin: property groups are just a cosmetic feature for mappers. Variables are just stored by name ("LiftTag=arf"), so my hunch is the engine wouldn't care or even know it was opening older maps.

Mychaeel: Tarquin, only properties declared in the selected actors' common superclasses are displayed in the property sheet. LiftTag is defined once in both LiftCenter and LiftExit, so your suggestion would require LiftTag either to be moved into NavigationPoint or LiftCenter and LiftExit to be derived from the same intermediate class (holding LiftTag).

Tarquin: I don't think so. Subclasses of ScriptedPawn add extra properties to the ScriptedPawn group, so I think it would be possible for both Lift navpoints to have var(LiftTag) LiftTag

Mychaeel: It's possible for both subclasses to do that, but the property won't show up when both actors are selected anyway. (I tested it before I wrote it.  :) And it makes sense – only imagine what would happen if both subclass properties of the same name in the same group had different types.)

Tarquin: i was just testing it too... doesn't work :( urg. another one bites the dust

UsAaR33: Just for the record, state support also exists in console and its subclasses. But no other objects. (well, in UT build 436 that is). Oh and personally I would not the C style auto 0=false, none=false, etc. casting ability. It really just makes code harder to read. Well, as long as Epic continues using != none and == 0 in their code, I can't complain if support is added.

Mychaeel: The casting ability is in already, it's just not automatically done in if and the likes... As I said, whether it makes code harder to read or not is largely the responsibility of the coder. I personally believe it'd have the potential to make some code much more readable (!bleh instead of bleh != None – the latter requires you to focus on the middle of the expression).

Dma: I personally think that "if (Enemy != None)" is MUCH more readable than "if (!Enemy)" or something. Lets the reader know that Enemy is an Object and not a bool. (Well, duh...)

UsAaR33: Dma, my point exactly. When I first started working with the Unreal C++ API, I spat out some nice vulgarities. It was rediculous having to look constantly at superclasses to know what type a given variable was.

Mychaeel: As I said, clarity of code is the coder's responsibility. You can hardly enforce good coding style on a language level. I personally prefer a consistent set of variable naming conventions a lot over needless code. I don't want to have to rely on a variable's context to be able to figure out what it means, is and contains – exactly your point, UsAaR33.

EntropicLqd: I use (my own form of) hungarian notation to distinguish between data types. It works well, and allows the flexibility of handling object references as bools without the possibility of confusion.

UsAaR33: Mychaeel, I agree 100%. But if I was Epic, I wouldn't start renaming every variable in the last minutes of development. They do have nice nice conventions b* is a boolean and the enum thing.. but after that, basically nothing. (and the fact that input bytes start with b* is really confusing to newcomers..). Maybe a page could be started on wiki covering conventions (But with my "wonderful" programming style, I don't think I should be the one to start it :p).

Tarquin: There's Coding Guidelines. (also known as CodeIndentationPissingMatch... ;) )

[BWF]GrimReaper: Case sensitive variables would force the code to be much more stylish. I'm a JAVA person and a style whore :].

Foxpaw: Well, making the lanes on the roads smaller would force people to drive straighter, but doesn't the increased restriction outweigh the benefit? (which, at least in my case, is approximately 0) Down with case sensitive languages!

RDGDanClark: I'm of a mixed mind when it comes to case-sensitivity, on the one hand, I like the way it keeps everything looking good and (possibly) more organized, on the other hand, I'm a lazy bastard sometimes and don't always feel like checking my seplling  ;)

Foxpaw: Well, if people want their code to be organized like that then they'll use the same case all the time anyway. If they don't want to do that, why force them? It doesn't benefit anybody, (unless you look at someone elses source, and then you can plame them for writing messy code) and it would limit people who wanted to use different cases for some things.

[BWF]GrimReaper: How can your code be organized when the very source you work with doesn't use 1 style. IMO your lazy when you prefer case-insensitivity. Riding your bike is hard but once you get used to it, it has benefits.

Foxpaw: Well, my source DOES use 1 style - but it's not the same style Epic uses, and I don't much care from their choice in capitalization. If the language was made case sensitive you would have no choice but to conform to Epic's standards. Like I said, if you think using the same case consistently is important, that's all fine and good and you are welcome to do that, but why should it be enforced at a language level? If a person writes messy code the only person they're hurting is themselves - why make more work for them when they occasionally use a different capitalization?

The only advantage I can see in case sensitivity is being able to have numerous variables with the same name but different capitalizations - and even the value of that is highly questionable.

RDGDanClark: I question the whole puritan work ethic that says that being lazy is always a bad thing. In this case, it seems to me that if it takes me 1 hour to write some code with "proper" capitalization (and the error checking that goes into it), then it might take me only 45 minutes or less to do the same code if I don't have to worry about spell checking. When I was in school at Full Sail, they tried to enforce a certain code style, and I can't tell you how much time I wasted chasing down errors that were generated because the variable was called thisIsMyVariable and I referenced thisisMyVariable in a different file. Yeah, fun.

[BWF]GrimReaper: Well if you have capitalization problems and have trouble tracking them down you should choose to do something else than coding (not to piss you off or anything :)). There are so much benefits with forcefully styling code at language level. Easier error checking. Other peoples code is readable/understandable. I was hammered at skool to code in explicit styling and even the difference between a tab instead of 4 spaces was frowned upon. But hey i pulled through and now i see why it's a good thing. I write code consting of a 100 classes with 10 other people and they all look similar and are instantly understandable because of explicit styling. Can't say the same when i pull open a C++ include file :/. According to you and my courses in logics and programming language fundamentals you are leaning towards obscure languages that make sentences like 'I kick you in the nuts an cry' this has two totally differenct interpretations. The only right meaning is the one the compiler happens to accept first. The more style in a language the easier it is to learn, understand and work with. This is my opinion and if you don't like it ..... :p

El Muerte TDS: using tabs instead of spaces is very important. I prefer to have 2 spaces wide tabs, and if people use spaces instead of tabs code will often be screwed up.

[BWF]GrimReaper: I do tabs due to RSI prevention, however official JAVA specification stipulates 4 spaces so all viewers will give the same result. IMO tabs go awry not spaces (combos are worse). IMO the editor of choice should help you out on that.. What i forgot to mention in the above is that 80% of coding is fixing problems and a fast first draft of styleless working code often is a bad choice for the person trying to read your code. Or if you look at your code after a year it seems auwful. Coderot is the word.

Mychaeel: Tabs, by principle, break any visual structure code can have with the sole exception of indentation. I prefer the benefit of being able to vertically align common structures in subsequent lines over the potential advantage of being able to reconfigure the indentation width after having written the code. For stuff like that there are code beautifier tools which can do a far better job.

Note that these arguments are for an ideal environment where tabs are used with consideration and only for indentation. In fact, though, people happily intermix tab-indented and space-indented code lines (because they "look alike" in their editor configuration), thus breaking even the advantage of being able to configure one's preferred indentation width (just look at Epic's UT2003 UnrealScript code; it's unreadable in parts unless you configure a tab width of no more or less than 4 characters). That is why I have set up my editor to insert blanks when I press the Tab key.

Foxpaw: "official JAVA specification stipulates 4 spaces" - no offense, but I don't see the relevance of this. At any rate, I use two spaces, even when I'm forced to program in Java at University.

Tarquin: Ynurg :( Can we keep this ForestFire debate on tabs v spaces to one place please! Once you have a texteditor like TextPad that inserts spaces for the TAB key, and removes all of them for the DELETE key, why do you need tabs?

Tarquin: Should we consider promoting this page to top-level so it can be split into subpages itself?

HSDanClark: I guess... but wasn't this page created before UT2003 was released, and envisioned as a way to get the devs to see what the community would like? If that's the case, and given that there will be no more patches for UT2003, is this page even still relevant?

Tarquin: Rename to "Engine suggestions"?

GRAF1K: Most of the stuff here isn't engine but Uscript suggestions, unless I'm wrong. It's kind of a limiting title anyway.

Foxpaw: I vote in favor of renaming this page. It was rather hard for me to find with it's given title. I was only able to find it using the search because I remembered some of the text on it.

Link: http://www.planetunreal.com/feba/wishlist.htm

Mychaeel: Some things that are in there are a bit strange. Others will be in, in any case.

• "Support for multiple attachment points," "manipulation function hooks for skeletal animations" – Is in.
• "Support for PHYS_Driving" – Care to elaborate?
• "Support for virtual classes" – All UnrealScript classes are virtual, by principle.
• "Add the ability for map makers to add comments to a map (using a special actor)" – Is in.
• "The ability to add new physics to the engine within script" – Depends what that's supposed to mean. You can, of course, do anything in UnrealScript, including simulating new physics types.

Foxpaw: Basically everything on the page at that link is availible in UT2003.