Mod Ideas/Dark Match
Description
Eavy's Darkmatch 3 is probably one of my favourite mods for UT. Assuming Eavy doesn't beat me to it and ship a darkmatch mutator with UT2003, I'll write one. It turns out the lights and gives every player a torch. The following applies:
- The brightness of the torch is configurable.
- The radius of the torch light is configurable.
- An option can be enabled that will make players glow with their team colour.
I realise that I've removed the "turn torch on/off" options from the original but I never saw the point in it, and certainly when we tried it found that it made no difference to the game - in fact, it made it less exciting.
Links
Interested Scripters
If you are interested in developing this mod for UT2003 then add your name to the list. Once you start development you should indicate that below (and hopefully include a link to a journal page). Before you start development you should also check this section to see if anyone else has started.
- EntropicLqd – Oh yeah, Darkmatch rocks but too much will fritz your eyes.
- AlphaOne – I wonder how 1337 will it be to play DarkMatch at night, in a dark room, with Surround sound!?
Discussion
AlphaOne: Can anyone get the original code from UT?
Also, Is it better to have a mutator for darkmatch or a separate game type, or both?
Is it possible to use the fog (black in colour) in the game to speed up the rendering of invisible things?
By looking at the code it can be seen that the lights in the levels must have been turned OFF in the UED.
I want to add one more thing to this game type: Reduce the visibility of bots, or to make them see only very close to themselves. To simulate the darkness effect.
Wormbo: Black fog != no light. But a Fog Match would be interesting, too... 
For the code just download Eavy DarkMatch. The basic idea behind it was this little loop:
ForEach AllActors(class'Engine.Light', L) L.LightType = LT_None;
EntropicLqd: lol - Yeah - but he did have some other handling for sky boxes and stuff. Hmmmm, a fog match. That might be pretty weird. Configurable min/max distances set across all the zones. Should be easy. It's better if you make the DarkMatch mod a mutator. That way it can be used with all of the game types. Are you likely to write this in the next couple of weeks? My Mayhem mod has got a bit bogged down and I need to take a break from it.
AlphaOne: (to EntropicLqd) Ya, I'll start working on it, now that I have my Christmas break. I don't quite get what you mean by the last sentence you wrote.
BTW: I could not get the code of Eavy DarkMatch, UED crashed when I tried loading the package. It would be great if you could post the code on this page.
I was thinking about changing the visibility of the player to bots. There could be two ways to do it: reduce bots SightRadius (more like the fog effect), or make the player less noticable to bots based on the amount of light the carry (like Eavy DarkMatch)
One last thing: Why did Epic release the new .UC and debug .U files? Could ppl. get thouse by just exporting the scripts?
Mychaeel: The source code exporter is broken (doesn't properly export private objects in property defaults). Recompiling the engine packages in debug mode is outright impossible (or at least very, very impractical).
AlphaOne: IC - starting to download it...
AlphaOne: Anyways, what's the best way to deal with bots?
EntropicLqd: RE: My last sentence - I'm working on a mod that (for the time being at least) has ground to a bit of a halt while I make a couple of decisions. Rather than have it bug me I'll make the decision while working on something else, that's a bit smaller. Darkmatch was at the top of the list 
. If you want the Eavy Darkmatch code then you can grab the UT mutator from the maps n mods section of http://www.snout-clan.co.uk, install it, and then export it. Failing that, drop me an e-mail and I'll pass it on.
In terms of bots the original darkmatch doesn't bother doing anything with them - which isn't so bad since they never turn their lights out. However, I was considering tweaking the AI to effectively reduce their sight FOV (but still allow them to hear players).
AlphaOne: the http://www.snout-clan.co.uk/ doesn't have the mod any more (broken link). I don't like the idea of turning off the lights because it makes it toooooo easy to cheat (like invisibility).
If you want to code DarkMatch then go ahead. I'm not going to compete with you or anything.
EntropicLqd: Right then .. I've put the mod back on the site - dunno why it went away but thanks for letting me know it was broken . It's worth pulling down and playing with. If you are sure you don't want to do it then I'll pick it up, but you have first shout. I'm not short of small mod ideas. Your call. And you could always disable the adrenaline moves you know.
AlphaOne: OK. I'll work on the mod. If I get really stuck then I'll ask you (or anyone else) for help. (BTW: what do adrenaline moves have to do with anything?)
EntropicLqd: Invisibility is an Adrenaline move - disable adrenaline, disable invisibility. You inferred above that going invisible in a darkmatch was cheating. It would give you a hell of an advantage for sure. Don't worry about it - I won't
AlphaOne: I just ran into a problem: When I set the LightType to none, only the (indicated by green lines in RMODE 1) static meshes become black. The lightmaps are still visible on the BSP brushes (indicated by white lines in RMODE 1).
EntropicLqd: Hmmm. Sounds icky. I've been playing aroud with the "Fog Match" idea proposed by Wormbo and I have similar problems. Antalus looks pap because the meshes suddenly appear and the sky is always visible (it seems to be more of an occlusion problem. Asbestos looks OK. I'll have a think about your problem though - One presumes that the lightmaps are properties of the brush - if they are not declared as constant you might be able to null them out.
EntropicLqd: Well, I've sorted my problem - just had to increase the amount of fog in the skyzone until the sky is simply occluded by the fog. Works well. Antalus now looks cool. Just need to sort out the bots now - sigh.
AlphaOne: For bots, just change their SightRadius to make it equal to the fog end distance (where clipping happens). I spent an hour looking for this variable and found it in the Bot class.
I also looked for lightmap variables in brushes, but could not find much. For some reason UnDox skips a lot of vars!??
OH, and btw, include the option to change the colour and the distance of the fog!
EntropicLqd: Would it be part of the materials section? I dunno - not looked at it at all. Options to change the colour, min fog distance, max fog distance are already in there (no config screen yet though). Might also be worth tweaking the AI such that at distances close to the max fog distance it's slightly random as to whether they see you or not.
Wormbo: I noticed this skyzone fog problem when I experimented with distance fog and the "set" command on DM-Antalus a while back. I guess the skyzone needs the same fog color as the other zones and a minimal fog distance to look good.
EntropicLqd: Indeed - I set the fog start distance to 0 and the fog distance to 32 in all sky zones. It solves the problem beautifully. Asbestos really rocks with loads of fog. Anyways - I'm on holiday now so I'm in a non-UT2003 environment, but I'll finish the mutator off when I get back off holiday. Might be worth setting up a "mutator pack project" (although project is possibly far to grand a word for it) for "environment" type mutators. Fog match, Dark match, and any others we come up with (no falling damage, high gravity, .... ).
ZxAnPhOrIaN: I thought that bFogZone couldn't change during gameplay, cause it is a constant? (or maybe im thinking about the original UT)
Wormbo: bFogZone != bDistanceFog 
All the distance fog related variables can be changed from UnrealScript, while bFogZone enables volumetric lighting in the zone.
ZxAnPhOrIaN: So bFogZone and bDistanceFog are diffrent, RIGHT!!!
ZxAnPhOrIaN: Like wormbo said above, "Black fog != no light.", look at DM-Plunge for example, it uses black fog!
ZxAnPhOrIaN: This mod should have darkness and fogness incorperated into it, namechange, maybe?
EntropicLqd: 2 years ago I would have agreed. However, I've come to the conclusion that it's better to have many atomic mutators than one monster one. Configuration for the "dumb user" becomes less of an issue that way.
AlphaOne: I like the idea of darkess+fogness. However, I still cannot find a way to "turn off" all the lights!
Tahngarth: fogmatch- that sounds fun just set the fog so that you can barely see 5 feet in front of you
AlphaOne: I tried the fogmatch myself. It is no fun with bots.
ZxAnPhOrIaN: Why? Can the bots see though the fog? Is it like you cant see him, but he can see you, type of situation?
AlphaOne: Yep. They can see me throught fog. They even snipe me sometimes out of nowhere. I tried lowering the bot's SightRadius. As a result I had to go around the map and LOOK for bots because they didn't see me.
ZxAnPhOrIaN: LOL, make the fog so dense that you cant see a foot away from you and make a bot snipe you from a mile away!!!
EntropicLqd: Right, I've finished my FogMatch mutator - I've given up trying to get the bots to work right with it 
. How's the DarkMatch mutator coming on? Still got that light-map problem?
AlphaOne: Yep. I kind of abandoned the DarkMatch idea for now. Maybe you could give it a try?
EntropicLqd: Yeah - love to. Would it be worth me taking on any code you've written already? If you think it would be then e-mail it to me on entropic@snout-clan.co.uk. If I don't hear anything in the next 2-4 days I'll start from scratch anyways. Cheers.
Tarquin: hasn't this neem made? I got a huge pack of mutators from BU last week that had something with dark. not tested it tho. the xxxpak it's called
Wormbo: Yup, RegularX put a "Night Watch" mutator in his [XXXPak]. (actually a combination of his previous XPak 1, 2 & 3 mutator packs) I don't know about bot support, though.
Tarquin: NightWatch is not very good. Try it on DM-Antalus. Areas of terrain are too bright, and you don't feel like you're using a torch. There's NightVision in the same pack. Way too dark. I don't thie bots are affected by either.
EntropicLqd: Having the bots affected by darkness (or in my case fog) is a right bugger. I still haven't worked out how to do it. Every now and then I have a trawl through the code to see if I can find it but so far I've drawn a complete blank. I have a couple of theories but none of them are particularly palatable (ie. damn hard to code around). I've mailed DrSin to see if he can pass on the query to Steve Polge but not had anything back yet. I'll have to check out the XXX mutator pack though.
Tarquin: How does fog affect bots?
Wormbo: They aren't affected at all, that's the problem.
EntropicLqd: Tarquin - check out the Help Desk page. I have an outstanding problem on there all about it. It's a right teaser.
EntropicLqd I checked out Nightwatch .. I have exactly the same problem on Antalus. I need to know how terrain works - and where the texture proerties come from. I'm happy with the way my objects appear, I've got rid of all projectors (and possibly light maps), but the terrain .... arrrgh. I guess it may not be possible to do a "darkmatch" in outside maps in UT2003 simply because of the way the engine works. There's also some other funnies on Antalus - but I suspect it's where the lighting has been forced into the texture itself - and I really need to change the surface properties of the faces. No chance of that in UScript.
RegularX: NightWatch appeared to be doomed on two fronts: 1) online at either the mutator or gametype level the changes to the lights didn't appear to replicate. 2) Certain lighting features (like on Antalus) didn't seem to be found no matter how many different things I tried to Zones, etc. NightVision was meant to be it's simpler, more net friendly replacement since it basically is just a HUD interaction - but I didn't have time to put in all the options to customize it/special effects in before releasing for Xmas, hence the being stuck with the dreary blue. And there is no bot support for either one - and in Nightwatch I didn't have time to adjust the Bot's view to line up the "torch".
Foxpaw: I haven't seen the code you are using but I think that the problem you may be having with lights not being squelched may be related to the fact that an object does not have to be a "light" to light up. Any kind of actor can be lit as far as I know. Those leftover lights may be other actors set to have a light. Replication is indeed tricky, I had an idea but it isn't compatible with my idea on squelching non-"light" lights. To replicate the changes in lights I would recommend subclassing light and using the mutator to replace all instances of light with your altered light class. Once you have your own light class you should be able to replicate a variable to indicate the light's status, something like the Redeemer in UT. (How it replicates a copy of Location and Rotation, then applies it server-side. I think it's server-side. I didn't actually read that too thoroughly.) I also had an idea for bots but it's not the best programming style - you might be able to have an "item" attached to all players, which would be considered a desirable pickup for bots, it's desirability waning as the player went out of view. I don't know if that would work or not but it might help the bots find the players and each other if their sightradius is reduced.
EntropicLqd: As far as I could tell I managed to get the replication working OK. The problem with the lights isn't with "non-light" light producing actors as such. There seem to be light map areas explicitly coded into the level, and you can't get a reference to them. Antalus is an excellent example of this. The outside area cannot be made dark as far as I can tell.
AlphaOne: What if you project a BLACK texture on ALL surfaces in the level?
Mysterial: EntropicLqd: If you mean ambient light, you can find and presumably alter that in the LevelInfo.
EntropicLqd: AlphaOne: An interesting idea. I'm confident it wouldn't work as the light's I have left don't seem to be sourced from projectors - they are coming from somewhere else (possibly baked right into the texture). The other problem with projecting a black texture over everything is that you'd never know where you were - the flashlight at least gives you the possibility of recognising where you are from the wall, floor, and ceiling textures.
Mysterial: The ambient light was easy to kill. You have to turn it off on a zone by zone basis though.
I've come to the conclusion that the only way to do this would be to create levels that are dark all over. Much like the original DarkMatch idea in Unreal. Which is a shame. I'll post a URL to the code that I've written once I've got it uploaded so that other people can have a look at it.
Mysterial: The ambient light in the LevelInfo controls zones without a ZoneInfo, which I *think* the outdoor area in Antalus is (sorry, I'm not able to check right now), so altering the LevelInfo's ambient light properties might fix your problem. (Sorry if you've already tried that - you mentioned playing with the ZoneInfos but not the LevelInfo)
oneirotekt: Hi folks, long time reader, first time contributor. Until recently I worked at a company that licenses the Unreal tech, so I might have some helpful info. Coding DarkMatch for UT2 is tough going because, as you've seen, setting every light in the level to LT_None doesn't work like it did in 436. Staticmeshes are affected but terrain and BSP remain lit.
Useless trivia: There was some kinda change in the way terrain is drawn between builds 829 and 927, and ever after level designers lost the ability to paint colors in the RGB sections of a terrain layer (now only the alpha channel is used for layer opacity). I have the feeling this has something to do with the new terrain system in which lighting is "baked" into the verts.
As for BSP surfaces (which are still very prevalent in UT2) there's no way to change the lightmap on-the-fly like there was in 436 (notice that most of the old LightEffect types don't work anymore). I remember asking Andrew at one point if there was any way an LD or modder could access the level's lightmaps (because it really is just a DXT1, DXT3 or RGBA8 texture) and he said "no, why would you want to do that?". So that might be the final nail in DarkMatch's coffin. However if you *could* figure out a way to access the lightmap, you could do something like replace it with a new Material that combines the old lightmap with a big black texture with Multiply blending. That way shining a dynamic additive projector onto a BSP surface (I assume that's how you'd implement the spotlight) would reveal something instead of just remaining black.
Fundamental problems:
- Staticmeshes, Terrain and BSP are all lit in different ways
- Shining a nice bright additive projected texture onto something isn't the same as shining an Unreal light source onto it.
- There doesn't seem to be a way to change A) the level's BSP lightmap and B) the light values of terrain vertices.
mnyeah.
So right now the easy solution for DarkMatch seems to be, make new versions of the old levels (or new levels entirely) with no lighting at all, and then equip players with a nice little dynamic projector torch (a la the Bulldog headlight effect). Opening up an existing UT2 map, removing the lights then recompiling and saving is trivial, but it means people would have to download new maps to play DarkMatch
RDGDanClark: This sounded interesting... I thought it might be cool to put it into a pickup that would turn all the lights dim for 30 seconds whenever you picked it up... so I was messing around and came up with this:
auto state Pickup { function Touch( actor Other ) { local xPawn P; local Light L; if ( ValidTouch(Other) ) { foreach AllActors(class'Engine.Light', L) { L.LightBrightness = 16; } AnnouncePickup(P); SetRespawn(); } } }
...but it didn't work. The pickup appears, the message displays, but the lights don't go dim (and yes, I know I haven't put the 30 second limit in yet). I'm still kinda new, so if I'm missing something (and I must be), please let me know.
Foxpaw: The same problem that's been discussed all around here I think. Number 1, most lights are static "I think" so you can't really change settings on them. Number 2, the BSP isn't "lit" anymore per se. It's lit at map build time, and the lighting is saved into the level. Subsequent changes to the level's lighting has no effect on the BSPs lightmaps.
RDGDanClark: I see... okay, I knew there would be problems, I just thought I could try my hand at working through them. Someone slap me for not reading this entire page :
:
RegularX: K, I'm cracking this back open for my new project - Defense Force Omega [| WMP Forums]. So far, I'm having the most luck for using a static mesh (vs terrain) for large structures like mounds and buildings, and BSP for any large flat areas. This avoids the basic problems of BSP in the new engine while also avoiding the vertex lighting issue of large static meshes. Then I'm using the above idea of a black fog combined with ground that's actually somewhat lit. Tossing the Flashlight from SquirrelZero, I've got a dark area in the background, with fairly lit area in the foreground, and projected light which lights most objects fairly well. This is all custom maps, of course. I'm still on the fence about the terrain vs. static mesh setup - but I also kinda hate the Terrain Editor, so I'm torn. If I get something that really flies, I'll update here with the exact setup.
GRAF1K: I think you all are going at this in quite the wrong way – wouldn't a player view fog similar to Screen Flashes do the job quite nicely? You wouldn't need to make new maps, fiddle with existing ones, or anything like that. As for bot support, I had the same problem when I was coding an invisiblity pickup back in the days of UT, before the greatness that is UT2003. I never figured that out, but now there's the Invisibility adrenaline combo. You can find whatever that uses for bot support and ajust for distance by checking distance via the SightRadius property.
RegularX: NightVision of the xpaks does something similar with a HUD overlay, I think, that you'd get with a Screen Flash type effect. It's not a bad approach, but it doesn't really come close to how the old Darkmatch used to look or feel.
GRAF1K: Hmmm... is that because it lacks distance to it?
RegularX: Yeah. It's more of a lens than a light. I mean, you can do some tricks to fade it out/etc. NVision actually doubles up the sniper overlay so that the center is really clear but the edges get pretty hazy. Doc E has a tute on here that uses a slightly different, and probably more functional method. But it doesn't really replace dynamically lighting a dark room as you walk around.
GRAF1K: I think you misunderstand. I'm not talking about "dynamically lighting a dark room" as you put it, but simulating a dark/foggy room via a screen flash-type player-view fog. The torch would remain the same.
RegularX: Maybe I do misunderstand. The torch/dynamic lighting is the big hurdle, and to get the same kinda of effect as Darkmatch, I think the dark room is a pre-req. Adjusting the HUD can get results that do something similar still wouldn't look the same, I think.
Foxpaw: You are likely going to encounter a slight problem with using black fog or any kind of view modification. Black fog makes things farther from you appear darker. (However they may be silhouetted against the skybox depending on implementation.) However, you will not have players lit up in that sort of scenario. A player far away will not appear to have any light with them, they'll just be invisible in the darkness. So, although that allows you to see as if YOU had a light and were in the dark, there isn't really any way to make other players visible using that method. Also, if you use zone fog (as opposed to volume fog) you're going to end up clipping players who are out of view in the "darkness" anyway, so you wouldn't be able to see them even if you did have some way of "lighting" them.
Basically, I think that if you want to have a darkmatch kind of play, you will require either special pre-darkened maps to play it on, or you will need to do some native coding (and thus exclude linux and mac players) to remove the lightmaps on the BSP.
Or you could build your own software renderer from scratch within UnrealScript, but that would probrably be very slow.
GRAF1K: Our own software renderer? No thanks. Custom maps it is. 
RegularX: Yeah, no kidding - anything with "renderer" in the phrase I leave up to the pros . You're right though, FP, the "dark fog" doesn't accurately portray dynamic lights outside your fog distance (I'm using a distance fog) - though this works OK for my DFO project as most of the things in the darkness will be monsters. For players holding lights, I may give the light a corona just to have something "shine" in the darkness.
Foxpaw: What I actually meant by the type of fog is, you can have distance fog in volumes or zones in UT2003. If you make distance fog by setting the fog values in a volume, it colors things based on how far they are from the camera. Anything past the maximum fog distance is drawn completely the fog color, anything before the fog start is it's normal colors, and between the fog start and fog end it interpolates. With this setup, things will be silhouetted against the skybox. (not necessarily a bad thing)
You can also make fog by setting the fog values in the zones, in which case it clips things beyond the fog end distance. That's probrably bad if you want to use a corona to see distant players.
Personally, however, if it's an option I'd make custom maps with lower light levels on them. It will probrably look way better that way. (I'd think so anyway)
If you make the fog by
RegularX: Oh, this is all custom map/gametype - no mutation here. Darkness isn't my problem, it's getting a good look and feel from lighting the darkness. I will play with volume fog to compare/contrast with my current setup.
Foxpaw: Well, if seeing other players isn't really an issue, then black fog would work "decent." However, it has it's disadvantages too, specifically that you wouldn't be able to see distant light sources. For the best effect I would think just using very few lights and some shadow projectors and such would be good. It would make a very "aliens vs. predator" kind of feel anyway. Once you start adding a flashlight into the mix it kind of takes away from the feeling of it. You could use a projector if it's like a tight-beam kind of flashlight, but for a spherical projection of light that wouldn't work as good.
RegularX: K, well I'm picking this back up again for my current stuff. I've basically concurred that the best route is converted/custom maps. At first I thought the best I could do to convert maps is open a map, save as, and then do a find on actor names to hunt down the lights. No! I was an idiot! Experienced UnrealEd'rs will laugh at me and mock me and make fun of me in the streets! You can delete all the lights in a map with just two console (that bar thingy at the bottom!):
ACTOR SELECT OFCLASS CLASS=Light
ACTOR DELETE
And bam. No lights except for the ambient lighting of zones, etc. I found it best to open the console window it self (that box thingy next to the white bar thingy), because that first command takes a while, so I kept thinking it wasn't working. But voila, instead of a buncha time to darken a map, this takes about a minute. Thought I'd share for those who never got that intimate with the console functions.
T1: You don't need console commands for that... You can just click on a Light actor, right-click and choose "Select all actors of class light" or "Select all light" (I don't remember the exact wording) and then press delete.
OlympusMons: Hmm! Is there a way of making macro's for using unrealed using the console. Like make a file and read it in using unrealed. Forgive my stupidity I didnt know unrealed even had a console till a month or so ago. Ive been using it since ut2k3
RegularX: Binding Editor Commands is what you want. And thanks, T1. Figures gosh darnit that after figuring out the sneaky way that there is a SUPER sneaky way . This is going to save me hours and hours.
MMIndustries: Hey. I have not posted here for a long time, but I thought I might share some insight on the darkmatch issue. A while ago I coded a darkmatch gametype. I found a few things to be evident:
1. you can't use pre-made levels. There is no way to remove the lighting from the entire level (bsp, terrain...) as far as I can tell.
2. If you do create cusom levels (since that is the only real solution) I found that using a dynamic projector as a flashlight worked best for a light. I coded the projector's rotation and other properties into the playercontroller, as well as an exec function to turn the light on and off. However, the dynamic projector approach has a few drawbacks: I looks fine on static meshes in the dark level, but once it pans over bsp that has no lights burned onto it during the final build in the editor, the effect is ruined. It seems that bsp that is not rendered with lights by the editor is stored as an ugly "bleached out" texture, ie. a complex yellow metal texture turns to a solid hue of yellow. I found that for the projector to effectively light the leve, I had to build exclusively with static meshes. I haven't tried this with terrain.
3. Maybe it's because I coded the projector into the playercontroller, but I found that during gameplay the framerates drop to next to nothing once you encounter a bot or (god forbid) fire up the minigun.
4. Despite my best efforts, I could not find a way to get the darn bots to cooperate with the darkmatch theme.
I'll check to see if I still even have the code if anyone wants a look at it.
RegularX: I've stopped using projectors for a simple lit actor, set to DT_NONE, tied to the front of a trace. It's much less code and seems more efficient, though I admit it lacks the pleasing look of a projector. My bot code is shaping up, but I'm doing other things (like trying to set cover/hold points) which seem to be confusing it. I seem to be straying away from a pure Darkmatch. I might get bored and try to put a sample together with pure dark again.
DaWrecka: MMIndustries: I'd say building it into the PC probably is your problem. I've got a dynamic projector attached to an assault rifle, and in my DM-DK-Compressed (A version of DM-Compressed in which I painstakingly reduced every light actor's LightBrightness by a factor of 10 - yeah I know, I just thought it'd look better than deleting them all or setting them all to the same low LightBrightness - doesn't seem to be the case) I could point it at bots and there was no perceptible slowdown at all.
