Spooks

The King of Diamonds Info Summary: Your accomplice is in over their heads and needs your help. It's the end of winter and the streets are quiet. Taverns, city watch, graveyards and pipes... you might even encounter a diamond! Build time: about 6 months Type: City FM/Exploration Size: Medium Completion time: 30 mins - 3 hrs, depending on how much you're willing to explore! Download http://www77.zippyshare.com/v/Z1fZy41Q/file.html - Zippyshare https://www.dropbox.com/s/428jkpoi14544pd/kingofdiamonds.pk4?dl=1 - Dropbox Available via the In-Game Mission Downloader! Screenshots Notes This is my first TDM FM, it came about from me learning how to use the editor and all of its different features. No doubt, you may see the variance in quality between the FM's different sections. Have fun figuring out what I built first and last, hah. For the most part, I focused on exploration and interesting readables. You'll find that you can complete the main objective in about half an hour, if you know what you're doing and that's perfectly fine, but if you're not getting lost and exploring, you're missing out! Big thanks to Bikerdude for his help throughout the beta-testing phase of this FM - fixing a lot of performance hitches, putting some bells and whistles and introducing new spaces that allowed me to expand greatly on the FM's readables and objectives. Without those, and my beta testers' further suggestions, this FM would be decidedly more boring! Acknowledgements Mapping credits: Bikerdude - Re-visportalling half the map, SE Maketplace, Graveyard, Bell Tower, SW street, misc. Spooks - the rest. Readables: Spooks Voice work: Goldwell, Bikerdude, Spooks. Beta testing: Aosys, AluminumHaste, Goldwell, Oldjim, nbohr1more Lute songs from No Honor Among Thieves. Breath script from Business as Usual. Technical Info Version 1 Last Updated: 13/05/2016 This mission has a very open layout. Even though a lot of care was taken to ensure performance would be good, it's bound to fluctuate at long view-distances. If you have an average computer expect some dips to the 30s. You have my apologies for that.If you're having FPS troubles, try setting your LOD Detail menu setting to Low. Numerous objects will have their shadows disabled, which may improve performance somewhat. I also recommend typing tdm_lod_bias_changed in the console when you're in-game, just to make sure all LOD entities have been activated.This mission does not support localization out of the gate.This mission requires TDM version 2.0.3.FAQ Stuck somewhere? I've some hints for you in the FAQ section. Enjoy playing and remember to be kind to Birdie!

I'm trying to get a func_portal with a lod_bias to work, but when you start the map func_portal doesn't close the portal. You have to change the LOD setting in game for it to activate. Alternatively, you have to type tdm_lod_bias_changed in the console. Is this a known bug?

Hey, greebo, I've submitted an old bug I actually had encountered way back when I started mapping in Oct last year, it's completely on me that I forgot to report it all this time 2.0.4 has been in beta-testing, sorry. I just found another one with rotation too and it's pretty severe, I'll put it on the tracker post-haste. edit: here's another small bug, I copied a shader from a patch and pasted it on a brush and the scaling was 0.0019500000000000001. In 2.0.3 it used to be scale of 1, which still wasn't ideal but this is worse.

I got through both this and In a Time of Need recently. Two play sessions for Breaking out the Fence, the first was me enjoying the different areas (like the spider cave, which was great!) and the second one was me being annoyed by the high loot req. on the hardest difficulty since I was required to either get dock treasure, safe or boar secret in order to pass. In hindsight getting pissed off a long time after I've had a good time the first time unfairly colored my opinion of the FM - overall I think it's a little gem! On to Exhumed, I suppose!

I've a pet peeve and I don't know if it's easy enough to fix. The _color argument should have 3 points of decimal precision instead of 2. When you pick a color, and the 0 to 255 values get turned into the 0 to 1 values the spawnarg works with, they'll have 2 points of decimal precision, which does not represent the full color gamut, and will possibly band the color you've chosen. You can observe this in the entity pane. Get an entity with a color argument (e.g. a _color on a light or an ambient_light on a location settings ent), then click on that argument. You have the raw 0-1 value in the type field and the RGB value below. Manually increase the RGB value by typing in its box. Suppose you have Blue at 17, which corresponds to 0.07. When you change it to 18, the raw value should change to 0.071 - 0.074, but it stays at two points of precision.

It's one year closer to the expected introduction of 10 nanometer chips! Nanoelectronics! The future is now!

Here's how I see the implementation of such a feature. Long post. DR writes into a .map file, in which the geometry is represented by a collection of primitives described by their vertices. Dmap then reads from the .map file in order to produce the .proc - the pre-processed geometry, triangulated and grouped into surfaces. The consequences of introducing a negative brush means that its vertex data has to be recorded somewhere too, much like with positive brushes. If you put the data in the .map file, then you hoist the responsibility of understanding and compiling that data into convex volumes, ready to be triangulated, onto dmap. This is a bad idea since DR isn't used solely by TDM map makers - if we introduced negative brushes in DR then tuned our dmap compiler to make sense of them, we'd be screwing everyone else who's using DR for their idtech4 projects. (This is why I've not suggested to greebo that he put "convert to func_group" in DR 2.0.4, the thing's only going to get fixed in TDM 2.0.4, it's still broken in D3 and other idtech4 games.) So, it's clear you've got to make this a completely DR-side feature, making DR spew an intermediary file containing negative brush info, then compile a final, regular .map file from that. The .darkradiant files already exist, and they hold layer information, so that'd be a fine place to store negative brush info. Then you draw your negative brushes in DR, and they're a DR thing and not children of worldspawn, and at savetime DR uses all those negative brushes to carve spaces and writes the .map file. But when you reopen it you don't really have the original positive brushes, just the carved versions! To avoid this, DR obviously shouldn't be reading the .map file for [positive] map geometry info, just writing into it. So really, you have 3 things to keep track of - vertex information for all positive brushes, vertex information for all negative brushes (and both of those have to be a DR-side ordeal), and then the .map output, which is the final file which dmap can read. You can see at this point you're not using DR to directly edit the .map file anymore, you're doing it behind an entire new level of abstraction. The whole thing is feasible and I could see some actual quality of life improvements coming from it, but it fundamentally changes Dark Radiant - how it stores brush information and how it displays it to the end user. The front-end is the least of a would-be implementer's problems. The most user-friendly interface IMO is to have a toggle (that could be bound to a keyboard button) to work in either negative or positive space, and a special option to select both types at once for layer assignment, movement, etc. The back-end, however, makes for a lot of problems. How do negative brushes interact with other DR features? If you group a negative brush and positive brushes into a func_static, does it carve everything, or just what's in the func_static? Should negative brushes just be their own entity altogether, like the worldspawn entity, but editor only? If you're using the CSG algorithms to carry forth this whole premise I've outlined, how do you make those algorithms not shit? It's a lot of effort that could be better spent on other parts of DR that would expedite a mapper's workflow by a far greater margin. How about DR having the equivalent of func_instance? Or Bethesda's Snap to Reference (ctrl+f "snap to reference" on that page and you'll find it)? I'm not trying to bust you balls or discourage you here, as I said I'm well aware of the benefits of negative brushes. Not saying those features would be easier to put in either - not by a long shot. But in the grand scheme of things there's far more useful features I pine for - substractive editing is pretty low on the list.

You can emulate a substractive building mode in DR if you really want. Make a cuboid as big as you want, then draw smaller cuboids inside it and use CSG Carve, then delete the brush you used for carving, or move it and carve again. You'll soon see the problem with it all though. Quake and its derivatives use Binary Space Partitioning, meaning you can't have concave brushes. The carving algorithms don't have the concept of cutting brushes symmetrically and the carve has to happen right away, so with enough carves your convex brushes will be reduced to mush. Even if you don't plan on doing any additive operations (which would be really hard at that stage), the compiled map will have a lot of degenerate triangles. It's kind of the same thing like trying to carve a torus inside of a sphere in Source's Hammer. Only bad things happen.

If you're looking for TDM in VR, http://forums.thedarkmod.com/topic/17501-oculus-rift-the-dark-mod-vorpx/page-2?do=findComment&comment=388585 would be a nice place to start! I think TDM's pretty far away from being able to use motion controls for sword swings and bow draws, but at least getting it to run should be satisfactory for now.

That head/skin combo is definitely in 2.0.3, atdm:ai_burglar comes with it as default. The model head_02 is obviously not in the file structure, but the model is in fact models/md5/chars/heads/npcs/commoner_head02.md5mesh. No idea why the model spawnarg in the EntityDef and the actual model name differ, probably an md5 quirk.

Has http://bugs.thedarkmod.com/view.php?id=4131 been fixed as a consequence of the rotation improvements? The .0001 thing definitely looks like a float number issue, but I've seen FS actually fly out of place when you rotate them enough in 2.0.3. I can't provide a test map right now, but I'll see about it.

Here I thought there was only indie movies and whatnot on Steam. I see Mad Max is not available in my region so that explains why I didn't know of this earlier.

It seems to me that the rgb parameters work on cubemap stages ONLY when there are no diffuse/bumpmap/specular map blending stages set on the material. For Epi's purposes, if he wants to only use the heathaze program + any other material stage with a blend add/filter/etc. he can tint the cubemap fine. For opaque materials that need light interaction though, yeah, the method you described seems to be the only way to tint cubemaps. I've just tried it and it works, you have to define a new alpha stage above each of your three cubemap stages and put MaskRed etc. on them. Then you control each color's intensity through the alpha arguments of the makeAlpha stages above the corrseponding cubemap ones. Of course, easy way's just make a new, colored cubemap with the envshot command, but that's one thing, the ability to tint them in the material is another, so it's good to know it's at least possible. Edit: here's the code edit edit: note that you can use different cubemaps for each of these makeshift "color stages", so you can go hog wild there if you wanted to do some super trippy effect. I mean it is cumbersome, but it's also pretty flexible.

I watched the Payday 2 shorts through that, they're pretty entertaining, if overly cheesy.

You're in luck, I just figured out a way! Looking over those material stages just now, I'm seeing the use of red/green/blue and a float value between 0 and 1 to modify the RGB value of the map. Well, when you make an alpha stage with makeAlpha, the resulting image wouldn't have any RGB values, just a grayscale alpha value. So, for a cubemap that's blended with gl_dst_alpha and a makeAlpha stage defining said alpha, this is how you can make the cubemap less bright: { maskcolor map makealpha (textures/darkmod/tile_s_bright) //here I use the specular of the texture alpha 0.5 //this darkens the alpha by half, modify it as you wish } { blend gl_dst_alpha, gl_one maskalpha cubeMap env/gen2 texgen reflect } As you can see, this lowers the output of the cubemap by darkening the alpha stage it's drawn with, so there's caveats - using other blending types on the cubemap stage will invalidate this method and if you're using that alpha stage for something else this might break the appearance of that. I still don't know why the rgb argument doesn't work on the cubemap stage proper (and no, "alpha" doesn't work either), but my best guess is "cubemaps are magic" and they don't obey the rules.

Yes, I was, it seems my map for maskAlpha was the problem however. Too black I think. It looks proper now. While I have you attention, how's the "red/green/blue Parm0*0.2" in the cubemap stages supposed to work? Does it work? Neither that nor the "rgb 0.2" I've seen seem to affect the brightness of the cubemap. Not bogarting the thread or anything, it's relevant to windows. Reference from the thread I posted:

I think the heatHaze program is what you're looking for, the stained glass window materials AluminumHaste made might be a good starting point: http://forums.thedarkmod.com/topic/17203-transparent-stained-glass/ For pointers, I've not done glass but the heathaze should distort the image behind it with the normalmap you provide, get a cubemap or a mirror stage on top of that if you want reflection as well. I've been playing with blending modes some more and I think any blendmode that references an alpha (eg gl_dst_alpha) actually means the opacity the material has rather than any abstract alpha value or alpha channel on an imagemap you feed the material. Pretty restrictive.

I'm currently unable to test but off the top of my head how does the shader handle simple point lights underwater? I'm not assuming it does crazy subsurface scattering and all, just wondering.

Okay, here's a question for you all. I looked around and it seems TDM has three options for Ambient Rendering, but I was never aware of that since the options menu only displays Simple and Enhanced (Enhanced being the equivalent of what I read being described as "Normal"). This stuff has been in since 1.03 and putting it in the console actually makes a difference, but hell if I know why it isn't in the menus. Can anyone give me a rundown? http://forums.thedarkmod.com/topic/13676-whats-the-difference-between-ambient-modes/ Reference thread. edit: hey here's a post edit edit: The one reason I'm investigating this is just trying to get better looking cubemapped materials. edit the 3rd: it's not worth updating the thread over this, but I'm just going to edit in this snippet I posted on Epi's thread, because I think this code's about the best I'm going to get for cubemaps for now and it's nice to have it here in one place. I suppose I'm done with env stuff for the moment. { maskcolor map makealpha (textures/darkmod/tile_s_bright) //here I use the specular of the texture alpha 0.5 //this darkens the alpha by half, modify it as you wish } { blend gl_dst_alpha, gl_one maskalpha cubeMap env/gen2 texgen reflect }

It's like a scrapbook, but for mapping! Hello, personal threads are all the rage so it's time I made one! I plan to be posting my forays and experiments in mapping, level design, scripting and whatever else in here. Here's to many, many pages! OK, let's start it off. You may remember that back in November I posted some screenshots of a cubemap slapped on some materials. Now that I'm at least a tad more educated on how materials work, I wanted to go back and see if I can improve on what I wanted to do. Firstly, here is a clip of a default material without a cubemap reflection on. Now here's the same material with a cubemap stage. The stage was just something I found and copied off a shiny tile and it's really simple - it goes like this: { blend gl_dst_alpha, gl_one cubeMap env/blueroom texgen reflect } As you can see, the result looks pretty unrealistic. The odd thing here is "gl_dst_alpha". It tells the stage to take the alpha value of the destination, which would be what's on screen I suppose. For a texture like our wood there, this is useless, since it's not transparent, the alpha is always going to be constant. In this particular case "blend gl_dst_alpha, gl_one" might as well be "blend add". Replace gl_dst_alpha with gl_dst_color, however, and you get this. It's quite subtle, but I like it a lot. It's still not ideal, from far off it's almost invisible, I would like some way to make it a bit more pronounced but none of the other blend modes achieve the same effect. If anyone has any ideas, shoot. Another thing I was wondering about while looking into the materials is this portion: { if (global5 == 2) blend add program ambientEnvironment.vfp ... } It's supposed to only work when Ambient Rendering is set to Enhanced, but there's no difference if you delete this. The ambientEnvironment program only seems to work when Ambient Rendering is set to Simple as a matter of fact, set if (global5 == 1) and you can see the actual effect. Putting a cubemap in this stage makes it looks pretty nice, actually, that would be a nice look to achieve but again, I can't get it working with Ambient Rendering Enhanced. There's another program, the bumpyEnvironment program, but it seems to just do what the envmap/texgen reflect stage does. edit: here's how the cubemap looks under the ambientEnvironment stage: Note that you don't get that Fresnel effect with the dst_color, gl_one blending stage.

Well if you set the diffuse to _black, you can make decals that only apply a bump/specular map, which is pretty nice! I can imagine a specular decal could be used for wet spots on walls/floors, and you can probably do fancy stuff like animate the texture too. However, say you have white slime on bricks, your diffusemap would be the slime and your bumpmap would be the brick normal map - but then put it on top of the brick and you have two brick bump maps overlapping - and for the trouble of aligning them in DR you may as well put the decal into the brick diffuse texture instead. How I imagine it in its simplest form, the decal would render its diffusemap in front of other materials, but let other materials' bumpmaps render in front of it. Slightly unrelated: http://wiki.thedarkmod.com/index.php?title=DDS_creation states that we currently don't support soft blending transparency, but this isn't true, saving a DXT 3 with an Alpha and using that with a "blend blend" then "map <the dds>" allows for smooth gradient alpha.

Honestly, what I'd love with those sort of decals is if a source texture's bump map could affect the decal, like you see in those Wolfenstein screnshots. That would make grime decals 10x more believable. Bumping because I was looking into this too and I don't think you can do it with blend tricks in the material, might need a separate vertex program for that, which is wholly out of my league.

Thank you, it works now. I didn't see those strings mentioned in selectWeapon's description here, might be worth to put this info on that page or somewhere on the wiki.

Is there a way to force-select a weapon for the player through scripting? Say they're holding the blackjack and you make them unsheathe their sword. Looking through the scriptEvents all I see that might work is selectWeapon but I don't know.

I just did and you're right, and I'm wrong. It's really weird because I swear I had the problem I described in my map and that's how I fixed it. Totally weird. @steve: Oh, this might just be what happened, as I wanted a location to be completely pitch black. I must've ended up putting the ambient there at 0.01 0.01 0.01 after doing what I described and thinking that fixed it. That explains it!