SteveL

Cool, thanks. I'll merge it when I get back to the UK on Sunday. I expect so. I favoured 'i' because that's what every other game does, but if people will have rebound it then we should probably leave it alone.

Your original version seems finished to me, but it's just my opinion, I'll defer to any consensus. We should discuss how to deploy it in 2.04 though. What do people think of rebinding the default action of the 'i' key from cycling through readables to showing the inventory grid?

Should we be adding options? IMO the simple version that we already implemented is the right solution. It just works, perfectly, without the player having to do any research. Touching the scrollwheel is not a inconvenience.

I've seen the strange specular highlights in my test map. I put 3 spinning cubes side by side, the two models that you supplied plus a third using the dirt texture only. Both textures on the blended model were lit ok, but the corners could be black and at certain angles the specular was really messed up. I'm on holiday in Seville with friends so I've not got round to diagnosing it yet, but I will. It must be a bug in the light interaction shader, very curious. I think we could do the other stuff you mention by tweaking the interaction shader too. The engine doesn't let you specify a different light shader for different models, but it might be possible to tweak it so that it does its existing thing on most materials but does something different for your custom materials. You'd be limited too using the existing set of input maps though: specular, bump, diffuse. Unlit materials are completely flexible, but lit materials have their setup coded in the engine.

I like the "current" system and don't think a bigger grid is needed. It feels perfectly natural to use the mousewheel in the test map, and it won't often be needed in real maps. I'll help deploy any changes though if you guys decide in favour of tweaking it. I'm looking forward to being able to cope with lots of readables I usually end up leaving a pile of them somewhere inappropriate in whatever mansion I'm robbing, which offends my sense of ghosting. Although they'll usually confuse the people who're investigating my crime

If you post your simple model that shows this effect, I'll take a look what's going on. It'll probably take me a day or two to get to it, I'm travelling right now. I started to learn Blender last summer myself, and want to get back into it, and I'd be interested in anything that can smooth the workflow between Blender and TDM/DR.

Remove the (inverse)vertexcolor keywords from your bumpmap stages. There's not a lot else could be going wrong in that simple material, so that might be it. And a messed up bump map would explain your seeing the colour at only certain odd angles. You don't have to mix bump maps explicitly. What happens is the engine simply uses the last bump map that it saw when it paints a diffuse layer, and then it modulates the overall colour contribution of that diffuse layer by your vertex colour. The order of the stages is important. Each bump map needs to come before the diffuse map that it controls. So your material looks right, except for those keywords.

You can produce a soft blend, but you do it all in the rgb channels. The alpha channel is completely ignored for "blend add" material stages, which is why you've had trouble getting it to soften your image. So: A black-and-white image, with optional greyscale blurring A single material stage, as demo'd by VanishedOne above Optionally, you can add red green blue keywords to that material stage to tint your white image. They default to 1 (full colour) so adding keyword blue 0.5 will reduce the blue channel while leaving the others at full strength and tint your grey-white image yellow. The black parts of your image will add nothing to the background colour, so they will be invisible. The white parts will add the full brightness of your white image, so making a saturated white result. The parts where white is blurring out to black through grey tones will add varying amounts of colour and they'll provide your soft edges. When I say "background colour" I mean the solid background of your TDM scene, e.g. a wall behind your particle quad or glass pane. It also works with earlier stages of your material, but in your situation we're talking about adding the colour of an electric arc to the solid backdrop formed by the surrounding room. Example material, in full textures/darkmod/my_map/add_ballburn { { blend add map textures/decals/ballburn01 blue 0.5 } } ballburn01 is a simple b/w image with no alpha channel: Here's what it looks like in game, on a patch floating in front of a dark wall: I realise now, ballburn01 doesn't have any truly black parts so the edges of the patch are just about visible.. or at least they were before I compressed the image. Last bit of advice: when tweaking your material def, for colours, scroll speed etc, you don't have to reload. Just alt-tab out of TDM, tweak your material file, then go back into TDM and use console command reloaddecls. That saves a lot of time when experimenting.

Yep, that minibug got fixed in the same commit.

What's wrong with blend add? It sounds perfect for getting some glow around an electric arc, if that's what you need. With blend add, you'd make a black-and-white image in some other app, and then blur it. No need to use the alpha channel (it'll be ignored anyway). In game, the black areas will be unseen, the white areas will be whatever you set the colour to be in the material file, and the grey areas produced by blurring the white arc image will blend in. Blend add is best for things that produce their own light, like a spark. Blend blend is for transparent materials that produce no light themselves like glass. Their transparency can vary across the surface. The alpha channel says how much of the background colour gets used, and how much of the foreground colour (the transparent surface) is used. Areas with "black" alpha will be pure background, i.e. the transparent surface not visible. White areas on the alpha map will give you pure foreground, i.e. the "transparent" surface will be opaque and 100% visible in those places. 50% grey will give you 50/50. Best used for glass of any type. Blend filter always darkens the background colour using the colour of the transparent surface, producing a result darker than either. Like Blend Add, the alpha channel is ignored. Best used to modify other effects rather than represent a real world object on its own. TDM materials do support all the other additive blend options too.. the 3 above are just the common ones with built-in keyword names. To produce your bloom in a material, I guess you could use the blend add technique plus a shader prog that blurs the white image of the electric arc. I see we do have a few blur shader progs, but I've not tried them. It would probably be easier to just blur the black/white image in Gimp.

Yep, my fault again. I added the dds icons (5 of them) to my local copy before committing, but I forgot to mark them for version-control before I committed the changes. SVN users please update to get the icons.

The compass icon worked for me. I'll double check what I committed when I get home in about 30 mins. Edit: personally I wouldn't embellish it at all. Decoration would be distracting and it already holds lots of images. I vote for minimalism.

Done. To use in 2.04: update svn, launch game, and bind a key. I used bind "u" "_impulse30"

1. Yes that was it. That list of IMPULSE_XX responses is where the repeated code was that made me do a manual merge. I was missing one of the 11 calls to UpdateInventoryGridGUI(), the one for prevWeapon. 2. It's inconsistent. I spotted it too while looking for the missing line in my merge. I think it's a simple bug.... I'd not noticed this before, but I see it takes 2 mousewheel-ups to scroll up in the in-game objectives but only 1 to scroll down! Probably because the mousewheel-down "nextWeapon" message gets broadcast to the GUIs before the objectives GUI gets updated, but the mousewheel-up "PrevWeapon" message gets broadcast after the objectives GUI update. Testing that hypothesis... EDIT: yes, switching the order of those lines means you only need one mousewheel move to scroll objectives in either direction.

I did manual merging and some reformatting: not your fault, it's because of repetitive code in player.cpp and because it turned out that we do have some GUI bugfixes in 2.04, plus some of our current code conventions aren't obvious from older surrounding code. I'll post my 2.04 patch after a successful test. I'll try Maxwell16's test map and if that works ok I'll restart BCD which I got halfway through last night. I can't port my savegame from 2.03 to 2.04 so I'll probably be gone some time Is your to-do list complete now? I mean the various features you mentioned on page 1 that you wanted to tweak or add? p.s. kudos for getting your head round so much code without asking any questions btw! Your first patch touches every level of TDM architecture except the renderer and sound world!! Edit2: Hmm either I screwed up somewhere on the merge (likely), or we have a 2.04 change that changes outcomes (less likely, but possible). Mousewheel-down works in both 2.03 and 2.04, but mousewheel-up works only in 2.03. I'm not familiar with the human interface device setup. Any clues to where I might need to spot the difference?

I have regretfully given up on Firefox because of problems on this forum and it freezing on ad-heavy sites. I suspect people test their shite on Chrome and IE but don't care much about FF . I don't know much about browsers though, and if people know how to get around these problems I'd be delighted to RTFM if someone kind would point me to the FM

Let's leave in the objectives gui change for people to try. We can always remove it later if need be. Are there any other features that need testing? Tracked: #4286

Thanks. That looks fine at first glance and doesn't look like it'll cross with 2.04 code. I'll try it out tomorrow because it's well past midnight here now *yawn*. Why did you end up tweaking the code that destroys the objectives gui by the way? Did it screw up when transitioning between the two?

Sure, if Durandall is ready to share the dll/engine source code patch then I'll check and merge it. We can't use his TDM 2.03 game dll with our svn build because we have script changes in svn that're incompatible with a 2.03 dll. p.s. @Durandall: no need to get the GUI 100% finished for us to merge the source code into the trunk. We can deploy GUI patches later, if you're still working on it. And we can try out your new code with TDM 2.04 in the meantime.

It's working great and a pleasure to use. I'll be forgetting my inventory hotkeys after we get this in the dev build Except for lockpicks, which I still like to toggle with P. I've been playing a proper map and not got too far yet so have yet to gather enough inventory items to try multipaging, but so far everything is good. The UI vanishes on any click or by re-pressing the key... great. It fits the hud very nicely.

Cool, thanks for confirming. It's not surprising you had to extend the game API. I'll try it with 2.03.

I just downloaded 0.17 from 29-Jan so I can try it tonight. I see it contains a game dll and new engine. Just checking, did you have to modify and recompile those? If it's only GUI changes I'll test it with my svn build, but if you've had to modify the game I'll need to use a 2.03 build. I assume you did have to modify the compiled files... they have the later modified date too.

Good question. I just looked in material.cpp and it turns out they're synonyms.

I know you can do that with lights, but can it be done with normal materials? Whether or not it can, you could play around with a small light tuned in to your sound. You could put it on a different spectrum if needed, so that it only illuminates your particles, but it might be better to use a normal light. Particles don't shed any light of their own, and you probably want your arc to cast a bit of light over short distances. If you want your particle to be lit by the light, make sure you add a bumpmap stage to the material def (the built-in bumpmap _flat will do). Yes, that's rightYou can't deploy a mesh in particle effects. Like VanishedOne said, the way to fake 3d volumes is to use view-aligned quads (which can include rectangles) and an image.

That's a particle effect added (yes, on purpose) by the map designers to indicate a murky damp atmosphere. It's not bloom. Afaik, the only way to turn it off is to set r_skipParticles via the console, but doing that would also remove weather and torch flames, so not really a possibility.