SteveL

Thinking about it more, that script isn't quite doing the right thing. Its traces collide only with AI (or the player) which is convenient way to find out if an AI got hit, but because it doesn't collide with anything else, it could pass straight through solid walls and hit an AI on the other side. A better version would use CONTENTS_SOLID instead of CONTENTS_BODY to collide with anything solid, then test if what got hit was an AI. If not, it'd go and do the next trace, as before.

Yes, the melee frame command calls script event attackMelee(), which checks whether your AI's current weapon can reach an enemy. I don't know why getEnemy() isn't working. One way to do this would be to use the projectile system, which can also be controlled via a frame command, but that's only really suitable if your priest is throwing a fireball. Using your script is probably best anyway because it'll give you maximum control over how it works. Projectiles, the melee frame command, and other attack methods all end up doing a trace in the background to find out what will get hit by the attack. You can do your own trace in a script, tracing out from the priest's hands to see what gets hit. I can never resist messing with stuff like this, so here's an example. The script fires out 5 lines from roughly where the AI's hands would be, with the first line going straight out, and the others spreading out in a pyramid shape. It stops when one of the lines hits an AI and reports which AI got hit. You can set a spawnarg "debug_fire" on the casting AI which'll make the trace lines be drawn in game so you can see what's going on. I added a test function so that you can fire this up as a main map script, and it'll show the lines on screen as the AI walks around (the AI is called $priest in my example). WHen the trace hits something, a message will appear on the console. You can use console command con_noprint 0 to be able to see console messages while the console is hidden.

Maybe, but an oil lamp can get very hot! From a practical perspective we need to offer mappers big and small light sources that can be extinguished by expending limited resources (water arrows). Torches, fires and oil lamps fill that role in TDM. We certainly wouldn't change the default behaviour even if we thought of another option, because it'd break the gameplay in maps.

It sounds like you have vsync on, which means the perf difference could have been very small, and possibly due to something unrelated that your machine was doing at the time. With vsync on, your fps will drop to 30 if it can't manage a full 60. With vsync off, you might have seen 55 in that spot. There are loads of things that could have caused the drop in the first place: doors left open, AI doing different stuff, a pile of settling objects somewhere. But you ruled out most of them when you reloaded the map, which makes me wonder if this was a subtle drop magnified by vsync.

Hi and welcome to the forum! None of that sounds out of place to me. TDM is a hard stealth game, but players are not required to ghost. I end up running away a lot We already have tools with the same gameplay uses as caltrops: flash bombs which you can drop at your feet as you run away, and mines that you can plant at strategic spots. Caltrops were fun to use in assassin's creed. A mapper could invent them whether or not we had them in the core mod, but both would probably hinge on whether we have appropriate animations and AI vocals to make it look good. I like the idea of rope bridges too, but mappers would probably have to design levels with them in mind. I don't know whether the AI chasing you over them would be possible given the pathing system... but I'm not sure. grayman would know. Sprinting: that would be a realistic feature, although I suspect the player not being able to outrun AI easily is a design feature that mappers have built around. You can already dive into water or leap over a wall or into a hole to escape pursuit (but only if you can find one!)

During map load. Please raise a tracker for this. Yeah, we know The reason it hasn't been done yet is we lack Windows experts. NagaHuntress has given us a fix for Linux which will be in the next release, so that gives us another motivation to try to fix it for Windows too. This was implemented in the most recent release. No mappers have built a mission around it yet, but I expect it'll happen.

What version of DR are you using? It's there for me in DR 2.02

It sounds like that must be a virtual path in that case... the command shell isn't finding it. If you break up your cd command, at what stage does it fail? d: cd Gamefiles cd gen_lang etc You could also create a folder using the command shell (so you know for sure where the command shell thinks it is) then copy+paste the contents of your tdm_lang_gen folder into it and see whether you can access it from there.

The algorithm in that pdf you posted is tailored to the specific task of creating multiple repeating windows in a regular pattern. Also, it's mostly concerned with how to do it without using a cube map -- not a problem we need to tackle. No doubt we could get some useful info from it nontheless, but before trying to adapt it I'm trying to figure out whether we can fix it with a simple tweak to the standard cubemap method of generating texture coords. Instead of using the player's absolute view direction, can we simply use the direction from the player's eyes to a given pixel on the window? That sounds like it should work, but I'm uneasy about the fact that it doesn't take into account the place where the cubemap was captured.... I need to do a couple of diagrams to work it out.

Thanks for the correct search term I was getting 1000s of false positives with every term I made up. The pool reflection isn't a great illusion. You can see in the first demo shot (before the water gets added) that the corner of the room isn't lining up right with the reflection. It works well enough I guess because (1) the player can't get too far away from the spot where the envshot was taken, and (2) the heat haze effect hides minor misalignments. Mirrors in TDM are not cube maps. The scene gets rendered a second time from a camera behind the mirror, and the mirror surface is painted with that (2d) image. All the interior mapping articles I've seen have been about rendering interiors that'll be seen from a distance. Easier to preserve the illusion that way. We'll just have to try it and see how good a job it can do with an envshot taken from just outside the room. I did try it with a normal cubemap about a year ago. As expected, I couldn't get it to look right even for a distant or high-up window. Cubemaps work by taking into account only the direction the player is looking. As Rich said, if you look up you see stars or ceilings. Down and you see floor. Now imagine standing still in front of a cube map window and looking around so that the window moves round the edge of your screen. What you can see "through the window" will change as your view direction changes, even though your eyes haven't moved. The effect looks bizarre and wrong. So we need corrected texcoords for the cubemap. It's probably best and easiest to do this the modern way in a shader program rather than add to the texgens in the engine.

I'm having trouble finding a method by googling, which seems strange. Plenty of articles on adjusting your generated textures coords for correcting parallax in cubemap reflections, but nothing so far on faking room interiors. But this is going to be a texgen thing isn't it? I'm imagining now you'd take the envshot from the middle of the room and then correct the sample coordinates somehow to adjust for the player's current position. Edit: no, not from inside. You'd want to make your cubemap from outside, probably close to the window, so the right parts of tables, chairs etc are on show when the player is close up. Even with the right texgen, I guess there'll always be some error if the player isn't standing in the spot from where it was taken.

That makes perfect sense, although I can't imagine what the right way to do it is. I'll do a bit of research in the hope that it's possible and implementable.

Cool, I'm majorly impressed you got this far. Could you include some instructions to let people know how to try it? Players don't need to be concerned about backing up the old executables... if they forget or don't bother, they can just run tdm_update.exe from their darkmod folder to revert their TDM to the current release version.

While testing (1) I made some huge cubemaps in my tiny 640x480 screen. I got to see the individual tiles of each face rendered. I did my tests in PD2. The result was stunning, TDM can look so good in a 4800x4800 cubemap Yes you can be noclipped. I don't know where to stand to get a room illusion looking right, sorry. Thinking about it makes my head hurt. Someone must know though. This thread would be better in the public forum I reckon, if someone with the right privs stumbles across it Envshot discussion and tip-sharing would be good.

From memory there were 3 things we talked about: fix the output file names and rotations/flip of the images so the envshot pics can be used straight away as a cubemap in TDM. capture the skybox in the cubemap, not just the main map. fix it so you don't have to change your screen size to take an envshot1 is fixed in svn. 2 has an open tracker. It's a big modification so might not get done. But you shouldn;t need it for fake indoor rooms. 3 isn't tracked afaik. It's not a deal-breaker, because you can render any size of cubemap using the command, even though it forces you to use a small game window to do it.

Mappers can select a different sound with a spawnarg. We could also change the prefabs to update that spawnarg, though it wouldn't help existing maps.

We honestly don't know when 2.04 will be out -- we're still adding issues to the roadmap rather than winding it up -- but you can of course leave it and fix it later only if you need to It did occur to me that a simple func_smoke might work. I've not tried it and can't remember from when I did that fix whether they use the same broken mechanism, but it could be worth a try. Just change entity type of your emitter to func_smoke and rename the "model" spawnarg to "smoke" if you want to try it.

No problem, it's not obvious. Feel free to follow on with the next problem (though once you've got it set up once, you won't have any more problems)

General info abnout how you're meant to get in: Full-on spoiler:

No and I don't know how it's done, but I wouldn't mind seeing one. You could probably get it work my including a header that'd be ignored by the game compiler, something like #ifdef __MSVC__ #define object struct #include game_header.script #endif // ifdef __MSVC__ struct instead of class so the members are public. I can't think of any other redefinitions that'd be needed off hand, but there are probably some... It might work!

I'm sure I've seen a proof of concept map that shows how it can be done... can't for the life of me think where. Can anyone remember?

This is a bug that's been fixed for 2.04, http://bugs.thedarkmod.com/view.php?id=3945 In the meantime you could use the world particle system and a script to get the same effect. See the "natural timing" section on the wiki for an example script. If you need any help setting it up, give me a shout. http://wiki.thedarkmod.com/index.php?title=World_Particle_System

Check tdm_lg_interleave is 1 using the console too. A setting of 0 locks the lightgem at its current value.

I thought that NULL was just a #define 0 in any case, i.e. an integral type already? An I just mistaken or is there a difference between platforms? Some of the "unused" variables are used in sections of the code hidden by compiler switches, so that's another tricky thing to look out for.

Can you provide some details? What happens when it "doesn't work"? Do you get an error and a stack trace, or what? I'm not familiar with the localization code but I'm sure it's fixable. I don't remember any changes in 2.03, other than extra translations being added to all.lang.