User:SuperApe

SuperApe

Who dat?

My name is Glenn Storm and I'm an UnrealWiki user with interests in game design, map design and artificial intelligence.

Short Biography

I am a game designer, animator, story developer and general tinkering monkey. I've been an Unreal community contributor for many years. Before I became a professional game designer, I worked as an animator in feature films and made games as a hobby.

Game Design Experience

I have always made my own games. Simple or complex, each game came from imagining something fun to do, some puzzle, struggle or adventure that would engage the player. Board games, role-playing games, choose-your-own-adventure type games, strategy games, word games, drinking games (in college), etc. This started when I was very young; having a good imagination, plenty of playtime and an inherent need to organize the design into a workable, playable, fun game.

I've made video games ever since I got my hands on a computer. I'm a game design enthusiast and programming hobbyist. So I've done this off and on, in my spare time, for years now.

• 1983, Commodore PET, top-down Tron Lightcycle game with an ASCII character display. Used Commodore BASIC.
• 1984+, Apple ][e/Atari 800, Several text adventures, like Zork. Used AppleBASIC/AtariBASIC.
• ~1987, Apple ][e, Monsters & Magic : a RPG fantasy game engine (with spells, monsters, weapons, items, etc.) where you're able to make custom characters, custom levels and play through them with a 2D ASCII-style gui interface. Used AppleBASIC. (I still have the program printed out and stored somewhere around the house. Maybe I should convert it to a Flash game.)
• 1999, PC, a 2D turn-based strategy game based on a (turn-based strategy) board game I developed in college. (~1991) Full sound, GUI interface, computer opponent AI, & animation. Used QuickBasic. (compiled to an .exe)
• 2001, PC, a 3D engine prototype for a raster-looking hover ship racing game in tunnels. I made this to figure out the problems of displaying and working with 3D, but it was way too slow to display more than raster lines. Used QuickBasic. (compiled to an .exe)
• 2005, PC, a very simple Flash shooting gallery game with a humorous twist. I just wanted to make a simple game to explore Flash's capabilities and ActionScript language. Used Flash. (The Great Outdoors)
• 2007, PC, a casual single-player 2D platform adventure game called Stick Man Doodle. Release version included the full function game and a map editor. Made during early development of a custom 2D game engine (GEE). Used QuickBasic. (compiled to an .exe)
• Since March 2007, I've been working as a staff Game Designer at an independent game development company. (yay!) :D
• 2008, Web (Flash plug-in), Multiple games developed as an arcade for our new home page. From casual to action to strategy. Currently in development.

Mapping / Modding Experience

Previous mapping experience includes Doom I & II, Quake I & II, Duke Nukem, and Interstate '76. (<– yes, mapping for a vehicle combat game) A few of those maps got published. "bludsprt", or BloodSport, is a Doom2 map that comes to mind. It's in both the Tricks of the Game (& Doom) Programming Gurus books that came with CDRoms put out by SAMS publishing. It's also available at gamers.org. "bathal", or The Royal Hall of Battle, is Quake1 map you can still find on gamers.org. "madhaus", or Mad House Mayhem is another Quake1 map available here. "TagArena", one of a few custom DukeTag maps for duke3d, can still be found online. "Clone Canyon Speedway" and "Ed's Farm" are two Interstate '76 Nitro maps exclusively available at Lightfoot's Stolen Maps. Other maps I have made have either not been published, uploaded or I simply forgot their filenames.

I found UT2003 in the store one day and saw it came with the editor. I was sold. It didn't take long to realize just how open it was, allowing access to the code, easy tools to make custom content of all kinds, etc. I began by creating a few cutsom actors in each map I made for Unreal. Steadily these custom components began to take over the designs of the maps. I've always wanted to see how custom components could affect gameplay in new and interesting ways.

With UT2004, I began to create mutators, like the ROOtator and Flashlight Mutator. I then forged into a longer project, Old Skool Monsta Toolz, which compiles several individual custom components into a mapping toolset *and* new singleplayer / cooperative gametype, OSM Adventure. OSMT is an add-on to the stock object tree in UT2004, offering many more options for mappers who want to work with creatures or create story-driven adventures. The OSMT project took took six months (and one video card) to complete.

You can find playable examples of my work in the Unreal Engine at UnrealPlayground.

Eventually, the experiments with the Unreal Engine will continue with UT3, but first I'd like to release one more version of OSMT for UT2004.

What do I do with the Unreal Engine?

I try to make maps that concentrate on good gameplay design. 

This is a great editor compared to most map editors I've used. After I finished my first map "BaseIck", I posted it on UnrealPlayground and others. It was meant to address most of the design problems I'm interested in. ONS-MudSling & ONS-Mudsling][, for UT2004, are available from UnrealPlayground as well. VCTF-TerraForma is still in beta and sitting on the shelf. My latest released map is OSM-Gauntlet an example map for the new OSM Adventure gametype I introduced with Old Skool Monsta Toolz.

I have been interested in game AI since it reached a believable level. 

That means, ReaperBots for Q1. Of which the Unreal bots are not-so-distant cousins. (Steve Polge) Anyway, this means I tweak pathnodes and spectate a lot of bot only games. Sounds weird to most people. I've delved into custom AI constructs with the ROOs, Kangaroo NPCs. (see ROOs section below) I've worked extensively on monster AI for the Old Skool Monsta Toolz add-on. (see the Old Skool Monsta Toolz section below) Now that I work in game design professionally, I receive opportunities to work on a much wider variety of AI than multiplayer Bots. This is addition to my general interest in artificial intelligence, including experiments in artificial evolution in gaming, which I have believed for a long time the Unreal Engine could help to demonstrate.

I have been modifying the engine. 

I've made quite a few custom actors for just about every map I've released. (I like to offer a different gameplay experience in each map I make) After that, I began working with Mutators, like The ROOtator. This project combined modeling and animation with AI coding and game programming. With that under my belt, I started a project to create an entire set of mapping toolz, designed to help mappers implement Monsters with complex AI in any gametype. This project is called Old Skool Monsta Toolz and this small package includes a custom gametype, OSM Adventure, capable of single player and cooperative adventures with a storytelling emphasis. Old Skool Monsta Toolz is now available as a free download.

I have a lot of high-end animation experience from working in feature animated films. 

I've been both a 3D character animator and an effects animator. Unreal's skeletal animation system is similar to many 3D animation packages and I'm able to have fun creating a variety of player and non-player characters. The unreal engine allows many of the same particle systems, physics emulations, etc. that I'm used to. I've had fun using of them in my maps and mods.

One day, I'd like to work in game development using all my skills as an Animator, Story Artist, Game Designer, Programmer and Director. 

This is a common goal of a lot of game enthusiasts, I know. What gives me hope is my experience in an industry known as the most collaborative art form: Feature Animation, combined with my passion and experience designing and creating gameplay experiences in a wide variety of settings. I feel that I just need to meet a producer who's willing to look past all the obvious Animation experience in my resume to see all the unpaid game design experience I've acquired over the course of my life that I can offer a game production. Until that day, I'll just keep on helping the people in the online Unreal community and using the Unreal Engine to produce my own projects.

UPDATE: I have been hired as a staff Game Designer for an independent game development company! I work in various capacity on a variety of projects, just like I was hoping for. It also just happened that I was hired based on someone who was willing to ask me what other experience I had besides what was on my resume, just like I was hoping for. Moral of the story is persistently pursue your dreams.

What do I do on UnrealWiki?

• Help out with little holes and repair. :)
• Working on the organization of the Artificial Intelligence family of pages.
  • Working with Trigger Systems for UT200x. (originally a revision of the old Trigger Systems (UT) page)
  • Tutorial on Bot AI Design and Testing. (instead this became a large revision to Bot Support and all it's sub-pages.)'
  • Monster Support, Monster implementation in UT and UT2004.
    • Basic ScriptedPawn Tutorial, implementing UT creature support for complex behavior.
    • A UT2004 Monster Tutorial, controlling UT2004 Monsters to perform complex behavior with ScriptedSequences.
  • NPC Support, designing and creating custom Non-Player Characters for Unreal.
    • Basic AI Scripting Tutorial, experiments in recreating the NaliCow NPC for UT2004.
• Organizing the old Unreal ScriptedPawn family of pages
  • Pieced together the Basic ScriptedPawn Tutorial
  • Corralled links to pages related old Unreal AI, like HomeBase, AmbushPoint, AlarmPoint, PatrolPoint, etc.
• Tutorial on Map Layout For Gameplay. (instead this became large revisions to Gameplay, Map Design and Map Flow.)
  • Working on the organization of the Topics on Mapping family of pages.
    • Map Planning
    • Mapping for BR
    • Mapping for VCTF
• Tutorial on Importing Models From Maya.
• TeamVehicleFactory, spawn any Vehicle class (even random vehicles) and have more control over timing and spawn effects.
• VariableTimedMover, variable Mover speeds supporting any number of keys, all InitialStates, etc.
• RandomTrigger, trigger random Events from an Event list of any size.

• Providing an information base for my mod / mapping toolset, Old Skool Monsta Toolz.
• Actually, I've probably touched most of the pages you'll see here on the wiki. (fixing, editing, linking, making better) You can too. Head on over to UnrealWiki To Do to find out how. ;)

Why "SuperApe"?

• Sub-Human, but Super-Ape.
• My deathmatch style is a bit aggressive; to the point of recklessness.
• It's a name from a song/album I like.

Contact Info

• Email
• SuperApe Website
• Mapper Profile on UnrealPlayground
• I can usually be found lurking on The UnrealPlayground Forums.

Projects

Some of my Unreal Engine projects are listed here, in the order they were started. You can see the progression from mapper (new to Unreal, but experienced in map design) to modder (more complex custom items and features in the maps and eventually my own Mutators and Mods).

Although it might be embarrassing to me to leave mistakes I've made in these accounts of my progress, it could be useful to those learning the Unreal Engine to see my thinking at the time and the updated corrections I've since posted.

---

BaseIck

The following is a Map Design Rant / Developer Journal detailing the BaseIck maps I made for UT2003. Although lacking in visual detail and decoration, this project explores and focuses on the gameplay issues I feel strongest about.

Gamers looking for cheats should refer to the Spoliers/Cheats heading at the bottom of this section. Interested mappers (novice to intermediate) are encouranged to download one of the four maps for reference while following this document. Whatever your reason for reading this section, my hope is that these maps remain in your map collection. I appreciate all descriptive comments. I invite anyone to post a reply with your comment. Each map has a thread running on Unreal Playground Forums: DM, CTF, BR, DOM.

(use the expand/collapse arrows here to see the full development post-mortem)

Concept

The idea was to design a map capable of great Gameplay and many different bot play styles, based solely on the rules of the Gametype played. Because I enjoyed the fact that UT200x had so many gametypes, I wanted to see if a single layout could potentially serve multiple gametypes and still be functional in terms of botplay, balance, available strategy, fun, etc. This idea is an All-Purpose map, one that can be released as with a "DM-" prefix, but simply be copied-pasted as "CTF-", "BR-", "DOM-", and work fine. Also since this was my first map in the Unreal Engine, I needed to succesfully create several basic map elements like lifts, triggers, ladders, particles, dynamic lighting, etc.

In the end, I submitted four maps: BR-BaseIck, CTF-BaseIck, DM-BaseIck and DOM-BaseIck. (This is in lieu of a working All-Purpose map, as descibed above.) The maps are virtually identical, except for the GameObjective and other game type-specific pieces.

"BaseIck", obviously comes from the map's original function and scope, which is pretty basic Map Design. But, the name BaseIck gave me the idea for a theme of an old, out-of-fashion place with serious health and safety issues. Conveniently, that would allow for rather simple design that would still be in keeping with the theme. So, the introductory description evolved into:

Design

As this design was originally an All-Purpose map, it needed two sides of equal strength; a symetrical map seemed the obvious choice. A requirement of BombingRun is a third area equally reachable from both sides. The map started with three large rooms.

Q: Why large? Don't you know that you'll ruin your framerate?

A: Yes, I'm aware of how painful it is to see a beautiful panoramic view of a massive firefight, but only at 6 fps. My reasons for large sized spaces within a map are based on the game engine itself. I think about how far you can launch weapons like the Bio-Rifle or a Grenade. I think about how far a player can fall without taking sizeable damage. I think about the size of the explosion of the Redeemer. But, I also consider the variety of gameplay a wider space offers; few things are as satisfying as having to work for that LightningGun headshot with full zoom. Don't worry, I'll try to keep the fps as high as possible.

While on the subject of spacial relationships, I'd like to point out a few things in BaseIck that take advantage of the game engine space. The distance from the floor of either the Blue or Red room to the catwalk opening nearest the Lightning Gun is about the maximum vertical distance a standing player can shoot the translocator. (about 1536 units) The distance from the floor of the catwalk opening nearest the Power Plant to the top of the small mound nearest the JumpPad is the maximum distance a standing player can fall without taking damage. (about 368 units. I can only do it right half the time by walking off the ledge, but bots do it consistenly.) A player at the lowest catwalk opening, standing near the wall closest to the Lower Tunnels, can Dodge (Forward) all the way to the Shock Rifle. (A similar Dodge spot from atop a large mount in the Center Hall will allow you to reach the 'funnel' hole to the Lower Tunnels.) A crouching player can still shoot over the barriers in the Center Hall. (about 48 units) (A discussion on this subject has started on General Scale And Dimensions; Some things that might be handy to know.)

The next element I consider is Map Flow. To help understand well designed map flow, I get Zen and kinda Feng Shui with it. While playtesting a map, I'll be looking at the spaces I'm in and thinking about good entrances and exits. The idea is to have more than one "way in" and one "way out" for each spot in the map. That may sound way too simple, but I find it prevents situations like a perfect sniper spot or a dead end. It makes sure that if you know where your opponent is, you'll be able to choose between a frontal assault or a sneaky back way (or more) no matter where he is in the map. Suprise attacks abound in maps like this.

Variety is a designer's best friend. So, I knew that I wanted small spaces, long straights, twisty tunnels or mazes to go along with my large rooms. And because it makes sense with many GameObjectives I also wanted a couple dead ends. (They usually kill map flow, but with proper risk/reward balance they should be challenging instead of frustrating.)

Everybody talks about the Z-Axis but I hear very little said on the subject, if you get my drift. Here's my take. You remember Star Trek II: The Wrath of Khan? (Of couse, you do.) You remember when Khan had the enterprise on the run and they ducked into this space cloud that interferred with their sensors, effectively blinding both ships? (Uh-huh.) You remember Spock's solution to their dilemma?

They stop, lift up a bit, sneak in close behind Khan and blammo! But, I digress.

Unfortunately, that is how I see players play (like Khan), that is how I see mappers map; most of the time. I believe this can be overcome by allowing the variety in your map to include the Z-Axis. Let's say, you're playtesting and you decide, "This area needs a way out". Go ahead and consider the cardinal directions (North, South,...), but don't forget to "look up", or down as in the case of a good escape route. When considering cover (like walls, columns, barriers, etc.), remember to think about players dodging vertical fire as well. Example: A platform suspended in a room not only provides a base to stand on and collect goodies, it also serves as a barrier from enemy fire down below; players can shoot down and dodge. (and vice versa) And with vertical cover, you can even hide from players who don't "look up".

The Z-Axis considerations can also be drawn from basic combat theory. The player above is the one with the advantage, if for no other reason than he can jump down to meet an opponent but his opponent can not jump up. (translocator notwithstanding) So I consider higher places harder to reach, but more desirable places to be in combat.

There were other design considerations I let the game engine dictate. The default sound levels of weapons, footsteps, etc. gave me good benchmarks for setting levels on my own ambient and triggered sounds. The pure satisfaction that can be found from the Karma Ragdoll physics led to strategic placement of railings, beams and spaces between platforms. (I love to play this game with the 'Slow Motion Corpses' mutator on.)

Next, I considered Inventory Item Placement. Of course, the nature and tactics used with each weapon helped determine their placement (like placing the Flak Cannon in twisting hallways for good bank shots, or the LightningGun near a couple decent sniper spots), however I was not afraid to place weapons in an unconventional area (like the Bio-Rifle in an open area). I figure part of the fun of this game is learning to use the variety of weapons/fire modes in all the variety of combat situations, so while you might want to use the Bio-Rifle in a tighter space to take advantage of the splash effect, you'll have to duck into the lower tunnels to do it on this map. Maybe then you realize there's another way to use the Bio-Rifle, or you get more accurrate, or you use another weapon, or you just run. I like that it could force players to think a little.

Gametype-specific design considerations were suprisingly few and far between. A BombingRun touchdown traditionally results in the death of the scorer, so why not have them just jump into lava? I notice bots will 'punt' a BombingRun ball when they are distressed and near any ShootSpot, I ended up using that in placing ShootSpots for suprisingly interesting results. A Capture the Flag game is the only one where bots need a return AssaultPath, I added a Straight one through the Center Hall. I had best results working on the Deathmatch map, then copying it to BR, DOM and CTF and adding in the unique elements. BombingRun took the longest; more elements, some BSP changes and a custom touchdown effect. Capture the Flag was the easiest; just add flags. After that I'd set the GameObjectiveTags for the AssaultPaths. That's about it.

Construction

Those design elements in mind, I connect the two "end" rooms with long corridors, I connect the long corridors with a small network of twisting tunnels. (the lower tunnels) I add passages that lead around these large "end" rooms, acending from the bottom (the lower tunnels) to the top height of the map (the catwalks). I connect the catwalks directly to the "end" room they surround at three points around the room. The third large room sat above the lower tunnels and I connect them. I connect the third room directly to the "end" rooms. I add a dead end space to the back wall of each "end" room. (the bases)

Big (vast) empty spaces need to be filled with usable space. I place suspended platforms in the three large rooms. I add usable cover to the floor of the large rooms as well in the form of mounds and barriers.

The two "end" rooms become the Red Room and Blue Room, with their respective bases and catwalks. The third room becomes the Center Hall.

Although I add a few Zone Portals at this stage, I leave most of the other zoning work until the end, when I can truely find the bad spots in the map (in terms of fps).

Yep, all those custom Static Meshes were originally BSP. (Can you believe I was actually playtesting with all that as BSP?) Although a painful lesson to learn, I did see the difference between BSP and meshes, first hand. (UPDATE: For an excellent report of why, look here. Thanks to Angel_Mapper!) And I was able to keep some elements BSP, if it didn't hurt framerate or it looked horrible lighting-wise when I tried it as mesh. UPDATE: During later projects, I was able to use my experience in Maya to import custom static meshes and eventually, custom Skeletal Meshes for custom characters and complex props.

Texturing? ... What texturing? Although it took me long enough, let's face it: it ain't pretty. My main concern from the start was to use standard textures to avoid installation problems for end users. Other than keeping the texture scale reasonable and the direction (texture rotation) appropriate for nearby light sources, I let the lighting and shadow do most of the talking, so to speak.

Lighting was fun. Simple red and blue saturated lights (notoriously tabboo, but who cares?) delineate the "end" rooms and a yellowish indoor lighting fill the Center Hall. Simple local white lights fill the tunnels and catwalks. Overall distance fog helped make the place look stuffy and humid from poor ventalation. (However, I was disappointed to see how bright it made all the little holes in the creases of BSP work. Could be used to find holes to fix, though.)

The dynamic lighting was kind of a pipe dream for a while. I was very disappointed with the lack of BSP light occlusion with dynamic lighting. But, I knew I needed the big effect for the map to be true to the theme. I love the end result. And the "lava lamp" globe lights are a nice bonus.

Sounds were the most fun. I use the music from BR-Slaughter because it was the only one that helped make the place "smell bad", if you get me. All the other songs were way too clean and bombastic for this run-down stink hole. The sounds helped all the platforms feel old and rickety. It made some of the tunnels creak and I hope someone is listening intently for their foe when one of these creaks catches them by suprise. Finally, the sounds needed to help give clues to the map's secrets. They needed to consistently point to a reasonable structure for the big effect and the other secrets in the map. I feel I was subtle, but successful.

I was used to working with particles like these in Unreal and I had fun making really cool effects that ate fps like there was no tomorrow. In the end, I managed to balance it pretty well by economizing my Emitters. The JumpPads, for example, needed enough particles to look like a quick puff of steam, but I needed it to be able to trigger repeatedly and rapidly without running out of particles. (Play Invasion and retreat via JumpPads and you'll see why when the monsters jump after you in rapid succession.)

The Trigger Systems were a source of some frustration, when it came to my trigger door lock. The solution was as simple as a triggered door trigger that is placed at the door itself. (...simple, right?)

The big effect also needed a custom TriggerJumpPad. Tarquin and Foxpaw came to my aid and the result is nice. (Thanks, folks!) :)

Then, I worked on carefully Placing PlayerStarts. Now, one thing about Team Deathmatch always bothered me: Players spawn randomly around the map. This makes it difficult to group a squad and make use of your numbers. You spend half your time just trying to get your Team together. Now the reason is logistical: Deathmatch maps are rarely balanced and set up for Teams, so PlayerStarts aren't owned by any Team, as opposed to other TeamGames like CTF, DOM and BR. "How can I get a Team Deathmatch game to spawn players on the Team side?", was one of my first questions here on UnrealWiki.

Foxpaw and Tarquin helped me to make my first custom actor: TeamSpawn. It forces players of Team Deathmatch games to spawn only at PlayerStarts that match their Team Number. (That actually came about from the GameTypeTrigger discussion; they do kinda go hand-in-hand, as Foxpaw points out.)

//=============================================================================
// TeamSpawn.
// Forces player spawning based on PlayerStart -> TeamNumber if a Team Game.
//=============================================================================
class TeamSpawn extends Actor
    placeable;
 
var() bool bForceTeamSpawn ;   // Will check PlayerStart -> TeamNumber 
 
simulated function PreBeginPlay()
{
  if ( bForceTeamSpawn )
    if ( Level != None && Level.Game != None && Level.Game.IsA('TeamGame') )
      TeamGame( Level.Game ).bSpawnInTeamArea = true;
  Super.PreBeginPlay();
  Destroy();
}

I left decorations and extraneous things like the rattling fans until the end, and I didn't use very many as I tried to keep framerate high and filesize low.

Bot Support

Then came the meat of this project, the Bot Support; starting with Bot Pathing. I tested to see how far apart PathNodes could be before the paths broke. I used that as a guide for the initial placement to keep the numbers down. As I went on, I would replace PathNodes with other NavigationPoints.

JumpSpots were originally placed to give bots safe places to land from great heights, they ended up being great places to translocate to as well. Translocator JumpSpots took a while to work out and I'm still only 90% happy with them. Lower skill bots still have problems translocating due to poor aim and a wide variety of angles to the JumpSpots. (Bots seem to have no problem reaching it from above but miss a lot from below, for example) UPDATE: This is the answer I was looking for! (under Tricky Translocatoins) Now I know. Thanks to Blitz!

AssaultPaths came last, as I saw a suprising amount of positive combat behavior without them. (to be elaborated in Problems and Solutions, "Did that bot just psyche me out?")

Starting from a central point (for good Squad grouping), I use four paths to the opposing GameObjective: Straight ahead, to the Left, death from Above and the Back way. These all converge to a single node in front of the opponent's base. Playing around with AssaultPath -> Priority and the order in which the PathTags list, I came up with something I'm very happy with.

My last considerations were about creating more Strategic Bots. I wrestled with the idea of giving bots the ability to get the Redeemer; one of the two secrets of the map, leading to the big effect. But, I wanted it to be a true secret. (Bots always give away secrets, you know; just follow them around.) Not only are bots notoriously bad about using the Redeemer effectively, but I also had minor problems getting the bots to work my complex trigger systems. That tore it. My official line on the subject is this:

UPDATE: Today I saw the bots actually get the Redeemer on their own! See "Did That Bot Just Psyche Me Out?" below.

Problems And Solutions

The following is a list of difficulties I ran into with various elements of this map. Later, I found the solutions to these problems and keep this as a record of my progress from Unreal Engine n00b to the confident and capable UScript Programmer & Level Designer I am today.

• Don't Ever Put Namespaces In Your Map Filenames

The original namespace in "DM-Base Ick" causes a Server to attempt to transfer a 8.8MB file called, "DM-Base". Obviously, namespaces in map names are evil and wrong. I understand they prevent Linux users as well.

• Dynamic Lighting in Online Play

Well, I finally got to test this map online. (Thanks, Sihunt!) Immediately, I see the dynamic flashing blue lights in the catwalks are initially on. Of course, it's not supposed to do that; it doesn't do it in offline play. Not sure why that happens. But that's not the weird part. The strange thing is, when I go to those lights in the catwalk, they reset to their proper off state upon line of sight. So, I'll see the flashing lights until I round the corner and am in line of sight with the (hidden) light actor. After I've gone thru both catwalks and "seen" all the flashing light actors, the map behaves as it should. To me, that's the weird part. Comments on past experiences with dynamic lighting, anyone?

Off-Kilter: I'm no expert, but basically dynamic lighting is, for all intents and purposes, broken. It has been suggested in various forums to use Trigger Lights instead and just start them in the on state. Those, from what I've read, work.

SuperApe: Yes, these are TriggerLights initially set to Off, not On. (They use dynamic lighting) I've heard / read / experienced the same things about dynamic lighting being essentially broken, and to use projectors instead. And I agree that for a lot of basic uses, dynamic lighting just looks bad; that's why not *all* the lights go out during "the big effect". However, the dynamic lights can produce good results on basic lighting effects if used with discretion, as demonstrated by BaseIck's big effect. I think dynamic lighting has it's place. What does everyone else think?

(BTW, the name "big effect" is a bit tongue-in-cheek, as turning on/off lights really should be one of the most basic lighting features in a 3D engine as sophisticated as this one is. Yet, you rarely see lights shut off in maps.)

Uncommon: Objects with bHidden=true (like Lights) don't get replicated in a network game, so that could be related to the problem. You might try setting DrawType=DT_None instead. Of course that could make them hard to find and select in the editor, so you'd have to remember their names ;) Another approach might be to create a subclass of TriggerLight in the myLevel package, with altered default properties.

SuperApe: Yes, the light actors are invisible. Here's the problem that I saw in Online play: The blue-ish flashy TriggerLights set to go off during the big effect are dynamic lights that should stay dormant until triggered. I saw those lights acting as though I had set them initially on (they aren't, and they don't act this way offline) so I could see flashing blue lights coming from within the Catwalks. Because these are dynamic lights, they shine straight through BSP-work. But, when I walked up the Catwalk those lights would switch to their proper Off state by themselves. I realized they switched back only when I had a line-of-sight to the hidden TriggerLight actor. (I know where those lights are without the actors visible.)

So, my real questions about dynamic lights in online play are mainly about other people's experiences using them. Bugs, pitfalls, work-arounds, etc. I worked with them as best I could, trying to duplicate the look of the normal lights by using multiple dynamic lights in different positions and intensities. If you look in the Catwalks on BaseIck, you'll see the light/tones cast from those look no different than the ones in the Lower Tunnels, yet the light doesn't (visibly) shine through the BSP-work. Anyone else see problems like the ones described above?

SuperApe: Having a lot more experience with Replication now, I understand why my TriggerLights weren't automatically set to off on Client machines. One day, I'll make a custom TriggerLight that solves this little bug.

• Dead Men Tell Tales

I worked for a time to give the bots a way to the Redeemer. As mentioned, I finally decided not to give them the power to do so on their own. This was decided in part due to the bots tenacious nature. Their ability to go from the most powerful powerup in the map to the biggest gun to the supershield, no matter how hidden or secret it is. Just follow bots around in an unfamiliar map and you'll pick up all the secrets and fruitful routes in no time. Bots give away secrets.

But there's another problem that proves to be a bigger secret killer to BaseIck. When a player or bot is killed and Karma takes over, the Pawn's collision changes with respect to movers. You've probably seen it more than a few times: a bot you mowed down flies back through one of the sticky doors in Flux2, or falls through a lift it was just riding on. It's annoying to see such a big bug in an otherwise neato Engine.

This problem proves devastating to BaseIck. The Redeemer access is supposed to be secret. Even to spectators who can normally fly through doors and lifts, the Redeemer can remain a secret because it is tucked out of the way. But on several occasions during testing, a bot had me cornered near the power plants and I responded in force, only to watch the lifeless body fly through the access hatch, indicating to me and anyone else watching (or dying) where the Redeemer is. At times, the bodies even triggered the emergency hatch release and opened the door for me. Argh!

SuperApe: Update: I don't know why I missed it, but Collision->bBlockKarma seems to actually do this properly. I was checking to see if UT2k4 did Ragdoll collision with movers, noticed that AS-Convoy (the big bridge that swings around) does collide and I noticed that attribute set. When I double-checked one of the lifts in BaseIck in UT2k3, it worked there too. (!) My only good guess as to why the power plant door doesn't block Ragdolls is that the model is not subdivided enough for proper collision; that Ragdolls slip thru the Mover's mesh. BSP->Mesh work bites me in the a$$ again. Live and learn.

• That's too much occlusion!

While working on Map Optimization, I had the opportunity to take each part of the map and optimize step-by-step to see how much each helped framerate during testing. This included taking large BSP decoration and coverting it to the imbedded mesh work. As expected, conversion from even simple BSP objects to meshes significantly increased the speed of the map (like 60%) while decreasing file size (like 30%). However one piece didn't look good at all after Ued's conversion to mesh: the large circular platforms in the bases. I decided to leave this piece as BSP. To help with the framerates, I tried creating an anti-portal, just like the ones used in the Center Hall platforms. It did occlude some of the BSP faces of the spherical room, but to my suprise, it actually lowered the frame rates. I removed the anti-portals and left the bases as BSP. The rooms are simple enough that they only slightly impact framerate as BSP.

• If Jesus were my developer...

"The big effect" would just be the beginning. With repeated abuse, the power plants would be unable to restart. And without power from those plants, the geothermal forces that drive the base go unchecked and unregulated. What results would be an overflow of the underground magma chambers from the bases, through the main rooms and into the large pits. Lava would rise, crawl and flow in the bases and main rooms until reaching the level just below the lower tunnels. Only the mounds would be sticking up from the floor of the main room; cutting off access to the base for an extended period of time; when the lava would receed and drain. The entire base would become a steamy oven. Older pieces of the base could break off, fall to the floor and crush.

• "Did that bot just psyche me out?"

I saw the Bot Mind perform some interesting things. While working on the PathNodes, I had forgotten to place nodes that would help bots escape from a crawlspace under the small platform in the bases. While Testing Botplay, I saw a bot get stuck there and I made a note to fix that on the next pass. I ignored that bot and continued to test; I believe I was playing DoubleDomination. An enemy bot came to that base and cut me down. As soon as the enemy bot touched the DomPoint, I saw from my DeathCam the "stuck" bot jump out from the crawlspace and reduce the enemy to ground meat, graceful as could be. This interesting behavior made me decide to keep the crawlspace clear of paths, until I saw bot behavior that actually warranted fixing. But I expected to see that behavior shortly.

Several test games later, playing Capture the Flag, I saw another bot who was in the crawlspace under the platform. I didn't actually see this bot until I had boldly charged into the enemy base, gibbed all defenders, grabbed the flag and was heading out the base. At that moment, a little low on health but feeling good with the flag, that bot sniped me in the back. It was hidden from sight, crouching under the platform. And once again from my DeathCam, I saw the bot merrily crawl out, leap up and return the flag without a hitch.

I saw bots use the crawlspace a dozen or more times. I saw suprising behavior that just flat outweighed any problems with "sticky" bots. That particular pathing bug is now officially a feature.

Other behavior I was happy to see bots doing on their own included intelligent use of all sniper positions and ducking to use cover provided by mounds and barriers. I also expected many more friendly fire deaths when squads are in the longer lower tunnels, but these bots do pretty well.

SuperApe: UPDATE: This beats all! Today the very highly improbable happened: The bots got the Redeemer on their own (and kicked butt)!

I was just now playing Team Deathmatch (4-on-4) in DM-BaseIck. (I had just used our Blue Team's Redeemer half a minute earlier and took out two) I was running with two Teammate bots towards the Lower Tunnels when I saw something I honestly haven't seen in a long time, the Redeemer model. I guess I was a little stunned because it took me and my two bot Teammates out. (bots aren't ususally any good with the Redeemer)

I was nowhere near the Red Team's Redeemer, I didn't retrieve it at all that game. The probablility of bots getting it on their own is very low because two key events have to take place in rapid succession. One, a bot has to "hack" the door lock (open it); which can probably only happen by being knocked into the Trigger with a weapons blast. Two, a (different) bot has to open the door, again probably by being knocked into it. (Door actor is set to Block when closed, so I know they aren't "trying" to get it.)

Now, I even though I kept a possible path for bots to see the Redeemer (with help), I thought I had disabled their ability to get to it. But, I suppose with as much playtesting and just playing, the odds caught up with me.

Final Notes

Man, I love UnrealWiki. I couldn't have finished this map without it. I hope I can contribute as much as I've taken from it, but I kinda doubt anyone could do so. Gushing aside, thanks to anyone to helped, whether you knew it or not. ;)

Spoilers / Cheats

The following section spoils the two secrets of BaseIck:

1) The smuggled Redeemer can be found inside each power plant. Sounds made by the plants suggest something is wrong; turns out they are running at half power. The right side chamber is not running, due to the Redeemer spawn device stuck inside. (The Tournament roadies have almost a third of the base powered from their own generators.) By "swiping" the power plant's center control panel, or running into it at a 45° angle left to right, you should be able to hack into the otherwise inaccessible power plant controls and release the door lock to the right side chamber for a few seconds. Open that door and retrieve the Redeemer. (If caught inside the chamber, an emergency release can be reached by double jumping.)

The control panel button is a mover with a very small collision radius; so small that the recessed control panel almost makes it inaccessible. I wanted a button you really had to work on to trigger, so that players are standing in a vulnerable spot (with their backs to the action) for a while in order to get to the Redeemer. (risk vs reward) It also allows causal collision with the panel without unlocking the door. Tip: If "swiping" the panel doesn't work, a Dodge move into the panel should.

2) The power plants are still unstable from previous Redeemer explosions; this old base was never designed for such high power weaponry. Power can be knocked out to nearly half the base with a Redeemer hit to a power plant's control panel. This will not only shut off lights in the catwalks and the main globe lights in the big rooms, but the jump pads are also disabled until the Tournament roadies can bring the working half of the power plant back online. (This is "the big effect".)

The disabled jump pads change the game flow in all BaseIck maps. Without a translocator, the Keg o' Health is inaccessible, as are quick routes to the Center Hall and the ammo cache near the power plant. Even a Redeemer inside the disabled plant is inaccessible until power is restored. The team with the disabled power plant is temporarily crippled.

---

MudSling

This map marks the next step in my Unreal mapping evolution. I started with the strong gameplay foundation that I had honed with the BaseIck maps and built upon that to deal with more aesthetic issues including better lighting, much more decoration, more detailed effects, etc.

ONS-MudSling was an UnrealPlayground ONS Mapping Contest entry.

NOTE: It is highly recommended that you download MudSling][ instead. Although containing essentially the same features, Mudsling][ updated and upgraded just about every aspect of the map. (See next section)

Design Post Mortem

I spent about eight days on this map. It started with a grey scale painting of the heightmap in photoshop. When I brought it into a substracted space, I adjusted the Terrain scale until the steep slopes felt right. I spent some time on the terrain, most of the time was spent on rebuilding the terrain for the bunkers as smaller terrain maps. Those terrains were made in Ued and are G16 maps. The decorative grassy clumps are a bit greener than I wanted, but then again, they do look like a fresh spout of grass.

The decoration was fun, particularly in the bunkers. Some new stock meshes available in UT2004 and I found myself hunting through nearly all of them. Of course, they gave me ideas for many of the gimmicks and gadgets.

I have three big gadgets in this map, the burning trees, the exploding bunkers and the laptop computers. They run on ScriptedTriggers using TriggerLights, Particle Emiters and Material Switches.

Except for a few choice pieces of Art (including the required UP ONS Mapping Contest Logo), all of the textures, static meshes, sounds and music are all stock items that came with UT2004. That includes the building in the center, AW-Nature.garfunkel.

As I said, I spent about eight days on this map. I think my wife wishes I'd spent none. ;)

Cheats and Spoilers

There's just a few hidden things to this map.

Forest Fires 

You can easily start small forest fires. All single tall trees are dry enough to catch fire and burn. Look out, fire hurts!

Command Bunkers 

Each team has dug a command bunker loaded with health, armor and ammo. There's also a laptop computer set up in each bunker.

Latop Computers 

Use with the Use key; either "U" or "E", both are default Use keys. This will allow access to vital information on the 'net ;) as well as the enemy's laptop, if hacked. Computers start in their initial window state. Tip: Return them to that state for smooth, bug-free operation.

Sabotage 

There's some demolition equiptment stored in each command bunker. You can take the enemy's TNT and rig it to blow up their bunker. This will cut off the enemy's supply of powerups and extra ammo.

Enemy Web Cams 

Once a Teammate has entered the enemy command bunker, they broadcast the codes needed to hack into the enemy's own surveillance camera, mounted on their laptop. From your bunker, you can spy on the enemy and remotely detonate the fuse to the rigged TNT.

Birdy 

A bird flies by periodically.

---

MudSling][

Download it here. Comment on it here.

This is an updated version of ONS-MudSling. The biggest improvements include greater variation in height, four foxholes with health, ammo and a weapon, Added ONSGrenadeLauncher, Online (replication) fixes for the laptop computers, More decos, Tweaked botpaths, More effects, More sounds. And all with only a modest increase in filesize.  :)

It should be included with the UnrealPlaygroud ONS Map Pack.

Special Thanks Go To Wormbo for posting the ClientMaterialTrigger here on the wiki.

---

ROOs

Using my skills as an animator, I helped out Lord_Simeon with an Australian-themed map called, AS-Outback (which was later updated and released with the Epic Mega Pack), by modeling, skinning, rigging, animating and coding an NPC character. I hadn't seen many NPCs in UT200x, except the TankVictim and I've always been interested in artificial intelligence, so this was a very interesting project all around. Later, I created a mutator that populates any map with ROOs, and offers minigames that are really more like whole new gametypes. (RooHunt and Australian ROOlette)

Stand Alone ROO NPCs

ROOs are Kangaroo Non-Player Characters (NPCs). DM-RoosOnline is a simple one-room map that acts simply as a pen to hold some sample ROOs. You can simply select them from that map, cut and paste them into your own map. Download it here. Comment on it here.

The ROOtator

This mutator adds kangaroo NPCs (ROOs) to any map, any gametype, and offers many gameplay options like the RooHunt and Australian RooLette minigames. Find the final version of the ROOtator here. (FileFront) ( mirror avaiable from VGPro ) A thread on UnrealPlayground details the mutator here.

Behavior

ROOs graze a lot. They are startled easily. When they're startled, they'll hop around until they get tired. Then, they stop and graze. If they get stuck while hopping or if they hop into water, they try to turn back to where they started. You can startle ROOs by Bumping, Triggering, Touching, or Damaging them. If a ROO is killed, it calls out to startle nearby ROOs.

Properties

RooRate 

The overall speed (movement and animation) of the ROO. 1 = 100%, recommended 0.7-1.2.

RooRest 

Percentage chance the ROO will rest at each hop. 1 = 100%, recommended 0.0-0.3. 0 = Never rest.

RooTimer 

How many seconds after the ROO is startled before it is removed from play. 0 = Never remove.

Tips

• ROO size is modified by Display -> DrawScale, however to keep animation looking good and to keep feet from "sliding", use a higher RooRate for smaller ROOs, lower RooRate for larger ones. (Example: A Joey ROO might have a DrawScale of 0.67 and a RooRate of 1.15)
• Minimum recommended RooRate is 0.67, Minimum reccommended DrawSize is 0.5.
• Groups of ROOs will look synched unless their RooRates are different. RooRates of slightly different values (like < 0.01) will appear synched at first but will slowly run out of phase, but similarly timed as if the timing were simply offset.
• When placing groups of ROOs, be aware of their relationship to your botpath network. Bots will not go after ROOs, but if they're placed on a path, it might be a wasted Roo that is triggered and dissappears before any player sees it.
• Groups of ROOs will get startled when one dies (either by weapons fire or vehicular slaughter, etc.). You can get a scattering effect by placing them facing away from the center, or a "bumbling" fire drill effect, by having them face the center.
• (Fast) ROOs set up to run alongside (paralell with) the roads, can add some interest on the way to the next objective.

RooBallet

Like setting up dominos to fall, placing ROOs can lead to similar patterns of choreographed movement, or "RooBallet". Although their code makes them turn a bit each hop, their RooRest can be set near or at 0 to help ensure that short distance target ROOs can be reached reliably.

An example of a simple RooBallet pattern is a triangle placement, where each ROO faces the next at around 512 UU away. By placing a triggering ROO about 1024 away from such a formation, and setting its RooRest to .01, once the triggering ROO was startled it would definately run into one of the three in the formation, each of those would trigger the next. Each ROO can be a trigger for another single or group of ROOs.

By setting the RooTimer and RooRest to 0, you've created a ROO (CatalystRoo) that once startled will hop around the map, startling any ROO it bumps into, until it is killed or otherwise dies (via lava, pain volume, etc.) Chaos Theory rules with a CatalystRoo. Get creative.

Installation

For use in your own custom map follow these steps:

1. Remove any previous ROOs from your map, save, exit and re-launch Ued.
2. Open DM-RoosOnline.ut2
3. Copy single or groups of ROOs to the clipboard.
4. Open your custom map.
5. Somewhere in your map, Right click and go to Edit -> Paste -> Here.
6. Save your map.
7. Credit me by saying, "Thanks to SuperApe for the ROOs!", in your ReadMe file.

---

VCTF-TerraForma

Representing the next step, this map combines strong gameplay and aesthetic details with custom elements meant to alter the basic gameplay, breathing new life into the standard flow of the game.

Features

• A change in the normal VCTF gameplay structure, by adding a "gate" that teams can use to close and block opponents from reaching the flag. The gate is open at map start, must be activated by the team, will then become the primary goal of the opponent (and bots), and can be destroyed, returning the gameplay to normal.
• An additional vehicle, Unmanned Aeral Vehicle (UAV) that can be launched from a base and used to provide cover fire while the pilot remains at base. (with bot support) For early beta tests, a HumanSpaceFighter was used, but the UAV vehicle is modeled, rigged, animated and imported.
• Fortified bases, gates and outposts with auto turrets that are activated by team members to defend against the enemy.
• "Team Doors", doors that open for one team, not the other unless they carry a KeyCard inventory item, which can be stolen from a dead opponent player. This allows covert sabotage of outposts, gates, bases, etc. It was also designed to allow access to enemy team vehicles.
• Plenty of custom meshes, textures, actors, etc.

This map is still in beta form. It was being developed and tested on UnrealPlayground, but I've set this aside for the moment. You can view the beta map thread on UnrealPlayground here to see screenshots made during development. More later.

---

Flashlight Mutator

This short project represents another venture into mutli-actor modding. I started with the idea of wanting to learn more about Projectors, and ended up developing a system for implementing fairly realistic-looking flashlights in a multiplayer map, including sophisticated bot support.

The result of the project was a simple map, aptly named SimpleMap, where I encorporate the actors I had to develop to carry the effect of realistic flashlights. You can download this SimpleMap and join the discussion on the Flashlight Mutator on UnrealPlayground forums.

The set of actors used to pull this effect off varies from the Projector itself to the Display Message needed to indicate to players how to turn the Flashlight on and off. Here's the component list:

Actor
  +- (Brush)
  |  +- (Volume)
  |     +- DarkVolume
  +- (Info)
  |  +- (LocalMessage)
  |  |  +- (BulldogMessage)
  |  |     +- MessageFlashlight
  |  +- (Mutator)
  |  |  +- MutFlashlight
  |  +- (ReplicationInfo)
  |     +- FlashlightReplicationInfo
  +- (Light)
  |  +- (TriggerLight)
  |     +- CoronaFlashlight
  +- (Projector)
  |  +- (DynamicProjector)
  |      +- Flashlight
  +- (Triggers)
     +- ButtonFlashlight

The ButtonFlashlight is a simple trigger that follows the player and enables them to hit Use to toggle the flashlight. MessageFlashlight is a simple message telling the player to "Hit Use to Toggle the Flashlight". FlashlightReplicationInfo keeps things running online. CoronaFlashlight provides a nice directional glare when players with flashlight face the viewport. Flashlight is the actual projector which travels with the player pawn and works with DarkVolume to help AIControllers determine when to toggle the flashlight on or off. MutFlashlight is the mutator that applies the Flashlight, ButtonFlashlight and CoronaFlashlight to each player and cleans up flashlights when not needed.

With this system, maps are specifically designed with an area to be dark and a DarkVolume is used to indicate that area to Bots. So, this is not an all-purpose stand-alone mutator. The map must be designed with flashlights in mind. That's why I embed each of these components in the virtual myLevel package in SimpleMap. Because the flashlights are toggled via the Use key, this is not a good system to implement in vehicle maps or vehicle gametypes.

---

Old Skool Monsta Toolz

This is a project meant to help mappers implement complex Unreal-style monster A.I. in any gametype. It comprises a toolset of mapping tools and a new set of ScriptedMonsters that mimic the old ScriptedPawn AI from UT99. It also contains a new story-driven gametype Old Skool Monsta Adventure (OSM). This project is in development at UnrealPlayground and has been publicly available since July 2006. OSM maps by some of my favorite mappers are available at the OSM Adventure Map Archive at UnrealPlayground or available from other addresses via internet search. Comments are welcome on The OSMT subforum on UnrealPlayground.

OSM-Gauntlet

This is an example map I made to demonstrate how the new OSM Adventure gametype can be implemented. OSM mappers are encouraged to reverse-engineer it for reference. This is a single player map that features a story that leads the players to enter an ancient tomb. Once inside, three different routes are available to players, each one emphasizing a different important element of OSM Adventure: Puzzle, Trap or Monster. This is meant to add some replay value for players as well as demonstrate to mappers various ways these three elements can be combined for interest. At the end of each route, the player will find themselves at the final battle area, where the story wraps up and the biggest challenge is presented. Finally a short ending cutscene completes the adventure.

This is by far the most complete and prettiest map I've made in any game engine. I'm reasonably proud of the visuals as well as the technical elements, as I normally concentrate more on the gameplay and technical aspects of my maps. It may not be the ultimate map ever, but I had fun developing it concurrently with the Old Skool Monsta Toolz toolset. Comments on this map are welcome here.

OSM-Guide

Another example map for OSM Adventure, that takes a more instructional tone. This map isn't pretty, but it is informative. It contains several Note actors scattered around the map and paired with various OSM Adventure elements. These Note actors explain what these elements do and how they are set up. This is the "just the facts, Ma'am" version of an example OSM Adventure map. It covers concepts from basic to advanced. Download and comment on it here.

OSMT Golem

The first custom OSMT creature built from scratch is in development now. This character was modeled by King Mango at very high resolution, on par with UT3 (around 5800 triangles in game). After UV mapping and mocking up a simple skin, I've been working on the rig, animation and code. When this is done, a overview guide (rather than a step-by-step tutorial) will be created to help others who wish to create their own custom OSMT creatures. For now, check out the progress on UnrealPlayground.

Links

• SuperApe/Old Skool Monsta Toolz – An information base for the OSMT toolset. (download link)
  • SuperApe/OSMT Monster Manual – OSMT creatures, their properties and behaviors detailed.
  • SuperApe/Mapping For OSM Adventure – An information base for the OSM Adventure gametype, including a FAQ and mapping guide.
• Old Skool Monsta Toolz Forum at UnrealPlayground – Grab the latest version of the toolset and join the discussion on UnrealPlayground.
• Monster Experiments – Read about the early development and experiments that led to the OSMT project.
• OSM Adventure Map Archive – Play examples of the OSM Adventure gametype.

---

Discussion

SuperApe: I've done some major cleaning on the Wiki today. I've just uploaded my maps to NaliCity (UPDATE: I've since relocated to UnrealPlayground) and I'm feeling a bit giddy. Pass the egg nog. WebTender.com :cheesy:

Dragonmaw: Welcome to the wiki super ape!

SuperApe: Many thanks to all.

Dr.AwkwArD: Well... I'm impressed, sir. Very thoughtful, insightful contributions to this community so far. I look forward to more WIKI updates. BTW, do you still work in film? I'm not in post, myself, but I worked for Digital Domain for a while and am currently talkin' with New Line about some things. Anyway, it's always pleasant to bump into fellow lunatics... :D Though, I suppose this game-dev crowd qualifies, too. ;) heh heh.

SuperApe: Thank you for the kind words. I wouldn't be suprised if we knew each other in RealLife™. I worked on a project in collaboration with DD back in the 90's called, Marvin the Martian in the 3rd Dimension. I also have animated for Warner Bros and Dreamworks Feature Animation. And yes, this is a bunch of loonies of a different kind.  ;)

Tarquin: SuperApe, have you got logged out?

SuperApe: I was working away from my normal machine for a couple days. :)

StarWeaver: Hey, I was just trying out BaseIck, and it seems like a pretty nice map, but it was *extremely* dark. As in, I couldn't actually get up those spiral staircases dark. I haven't seen how other maps are doing yet, but I don't think i've done anything funky to my visual settings lately, so ... O.o

SuperApe: BaseIck is an okay all-purpose layout with some effects and strong bot support. You'll want to make sure DynamicLighting is on to see the effects in BaseIck, but yes, there are parts of BaseIck that are mostly unlit. The spiral staircases in particular, without a handrail, are meant to give an advantage to those who know the map. Without a handrail, it's a lot harder to go up, unless you know how much to turn. It's not pitch black, but I know what you mean. Thanks for your comment.

EricBlade: You are going nuts cleaning this place up! I, for one, have definitely appreciated all the work you've done here, and the help you've given.. Thanks!

Ambershee: Just finished reading through the NaliCow tutorial. Farking great stuff there :)

SuperApe: Thank you. :) Actually, you're reminding me I need to revise/refactor that page.

fleshsniper1 hello SuperApe, iv been reading alot about your OSMT and was hoping youd let me use the tool for my mod. id like to talk to you more about what is required in my game and how much your tool could help me. one of my question is how good is your NPC/monster AI compare to what is provided with UT2004. i know youve worked realy hard to get this tool even starting back in the 80's if im correct. so i understand the pride in your work if you let me use it or not. i dont think i will ever release my mod publically though so i hope that for some reason allow you to let me to use it.

SuperApe: I understand. To get in touch with me, and others using OSMT, and to continue any substantial discussions on use and distribution, you can find me on UnrealPlayground Forums. There's an OSMT subforum with lots of info and that's a good place to discuss this, or you can Personal Message (PM) me there. That's normally the most reliable way to get in touch with me, aside from my contact info above. And, while I've been fiddling with games since before the 80's, I've only developed OSMT in the last year and a half.

fleshsniper1: thanks, i sure will do that

PiX any chance one could get a hold on that custom keycard class of yours? If so, would you please send an email to me? (email removed to save you from spam)

SuperApe: Sorry, the team keycard for VCTF-TerraForma was not completed (along with that entire map). If I revisit the map and that item again, I'll let you know.

PiX Alright. Do you know of any other custom script that might do the job? Oh, and that's my spam-address, so that's ok.

MythOpus: What does this keycard entail? If you're wanting to let only certain teams into an area, I'm sure that can be done easilly with a scripted trigger. If you wanted something more along the lines of a player having to pick up a 'keycard' to be able to open certain doors, you can have one class that is that 'keycard' and when the player touches it, have it add the players pawn onto to a list that would reside in a custom mover or whatever. Then when the player would go to open said mover, the mover would first check to see if that particular player was on the 'list' of those with a keycard and if they are, it opens. It sounds less messier than dealing with an inventory class.

SuperApe: Any lengthy discussion might be better served elsewhere, so I'll try to be brief. PiX, I don't know of any other system that does this, but you can try searching for Team-based tools for CTF/VCTF. Many ways of using stock methods for blocking or limiting by team can be "clunky" and/or compromised in unintentional ways; making it messy to map with. In response to Myth, I've explored many methods of team blocking using stock actors and trigger systems. Your second description of what the TeamDoors/Keycard system is meant to be in VCTF-TerraForma is close, but if you review the description I give above and/or follow the link there to the UnrealPlayground forum thread on this map, I give at least one important feature, "you can pick one up from a dead opponent." This is crucial to the gameplay mechanic, as it is a designed way to infiltrate the opponent's gatehouse, outpost, etc. But, futher details are classified. Rest assurred since I put this map down, I've had a lot more experience in UScript development and should be able to put this together without much trouble.