SteveL

Like Dragofer said, you don't need to snap anything if you carve your brushes using the clipper. Another approach is to make your sealing walls from simple caulk textured brushes, which will be solid but invisible in game, and then add your visible roofing and/or walls using separate brushes and patches which you can turn into a func static. That way the job of sealing your rooms is kept separate from the job of looking good. Your visible surfaces won't have to line up right or seal or snap to grid, you only have to worry about what they look like.

I noticed when I set mine last year, it didn't work until I downsized the image to about 200px. Too big and it fails silently.

I like (1). More ways to distract an AI without causing an alert are good. Maybe we could reuse the same mechanism that AI use to inspect a body, but without the alert. Or just get the AI to play the kneel animation, if that covers it. For 2, scaring an AI out of a room might turn out to be too easy unless it causes an alert. It'd be hard to design a challenging map if the player can clear any room without effort.

Hmm mantling sets an immobilization on the player to prevent the player changing weapon or attacking while mantling. That might be a way for scripts to pick it up. if ( $player1.getImmobilization( "MantleMove" ) != 0 ) The script reference for getImmobilization says "new feature, use at your own risk!" or words to that effect, but that note was added 10 years ago and I guess we can consider it a stable part of TDM by now

Yeah, shaderparm meanings were a point of confusion for me too while learning TDM. The shaderparms mean what the material definition says they mean, and it's not consistent. It probably *shouldn't* be consistent, because we have only 9 or so of them to play with, and we want different shaders to have different options. The wiki should probably reflect that. Most shaders respect the rule that shaderparms 0 to 3 are reserved for color and alpha information, but all other parms are up for grabs.

One quick way to color those lamp glares is to set the "entity color" checkbox in the particle editor, and then you can use the "_color" spawnarg on the emitter to colour them. I agree with springheel, no glares by default. They suit misty environments but they'd look out of place on a clear summer night. If you do want to use them by default on a switchable light, you could set them up like torch flames are now (light_torchflame in tdm_lights.def), with their own entity def and separate lit and unlit models. There are easy workarounds for some individual spots in maps: you can set spawnarg "cycletrigger" "1" on the func_emitter and just target them in some way to toggle them on and off, for example. I haven't noticed that problem, but I always hit Enter to set a spawnarg. You can see whether it's changed if you look at the panel above (you might need to turn off inherited spawnargs).

I tried the stars at 1280x720 and at a few 16:9 screen sizes. They always twinkled nicely when the player view was changing: a big improvement over textured stars. I also tried adding a rotation to the decl, to see if it would make them twinkle when the player view is still. It didn't. I see the regular pattern too... maybe a consequence of the flies distribution.

Good point, I didn't think of that. Unpredictability is very frustrating for players.

The difference is, the AI difficulty settings were around when people were designing the bulk of maps (I think!), Also, AI difficulty settings are about how fast they react, not how many resources you have, so less likely to have been used for designing puzzle situations. It does make a bit more sense, and I wouldn't be dogmatic about any of this. I'd volunteer to implement any suggestion that had a consensus of support from mappers even if I'd argued against it. Mappers are god

Spawnargs are the settings that mappers can use to tweak the behaviour of entities that they place in their map. A new spawnarg that defaults to "off" means future mappers have an easy and obvious option, but existing maps don't get changed. That's pretty advanced stuff. It's about easiness. TDM and DR have a steep learning curve, and mappers might never discover that method. If we add a spawnarg that shows up in DR on every light entity, that's just easier for everyone. We already have loads of options that are effectively hidden from mappers unless they ask in the forum. Whenever I tweak an entity def, I always update the list of spawnargs that show up in DR and add any missing documentation. Still no good (IMHO). This could still destroy a mapper's hard work by making their map play entirely differently from what they worked hard to create. Maps don't have a message to advise players that "this map is intended to be played with stationary oil lamps non-frobbable". I'm not singling out your suggestion, and we do introduce lots of new features. You have no idea how hard we work on backwards compatibility! It's important.

Yes. You don't have to touch the archives at all. If your modified file is a def file, for example, put it in a defs/ folder in your dark mod folder, and the game will use it instead of the "official" version that's hidden away in the pk4. You'd probably have got more support if the option had been "add a frob_extinguishable spawnarg for future use". The thing is, we will never risk breaking existing maps, and if we do it by accident, we fix it or revert the change. We must have nearly a hundred maps by now, representing 100000s of hours of work. Part of the deal is that we look after mappers' hard work, even after they've left the forum, and we don't change stuff that could ruin it. There are maps where water arrow management is a key gameplay element... Sotha's map about rescuing a fence in an example that springs to mind (sorry can't remember the name, but I do remember the excitement of finding lots of water arrows then later realizing I was going to need them all!).

This did get discussed at length and there was no agreement that it'd be an improvement. Certainly not in existing maps, the consensus was very much against it. That's why it hasn't been picked up.

Agreed completely, but I can't think of a way to implement it without a heap of work. There are quite a few particle distributions, and they each have their own code. So deriving the max size of distributions could mean writing and testing a lot of new code, and we'd have to either remove the editParticle code from the engine, or make all changes in two places (DR and the engine), plus we'd have to update all existing particle decls. We do have some options that don't involve changing the output of the particle editors in DR and the engine: Stick with the Monte Carlo method during map load, but limit the number of samples. Spread a fixed number of samples across the particle lifetime instead of calculating the bounds at every (60fps) frame during the lifetime. Stick with the existing method and calculations but do it during dmap instead of at map load time, and store the results in the proc file.(1) strikes me as attractive. Not the way we'd design it if we were starting from scratch, but it needs very little new code. What do you think?

@nbohr1more Do you know how to find out whether there's a compatibility problem here? Whether those functions are supported by that driver? Most of these functions were temporary EXT variants of what later became standard, but I can't imagine why a newer driver would ever remove any old function hooks, because it's almost zero cost to keep them in, and the cost of removing them is lack of backwards compatibility, which is very costly for driver manufacturers. So the problem is likely something different, but it would be good to exclude dropping of support for old EXT functions. Edit: In fact, the list in the console dump seems to be ALL of the opengl function hooks that the engine tries to tap in to, in two affected places. So it's not likely to be down to support for individual functions.

I'd class this as a bug report rather than a question. But I'm unsure whether the right fix is to change the behaviour of activate(), or to change its documentation. The change to activate() would be to make the entities apply a stim_trigger when activated -- that's what the documentation you quoted implies will happen. Problem is, lights in holders share the spawnclasses of very common objects: they are idMoveables or idStaticEntities under the hood. Fixing the lights to bring them into line with that documentation would potentially change the behaviour of every func_static and moveable in every map! In the meantime, other workarounds from scripts are to call the LightsToggle(), LightsOff(), or LightsOn() functions on the light holder's script object. Here are two ways to do that: entity someLightHolder = $whatever; someLightHolder.callFunction("LightsToggle"); tdm_light_holder someLightHolder = $whatever; someLightHolder.LightsToggle();

Hmm that's a lot of old opengl functions missing. Can you tell us your driver version?

It's not crashing. What's happening is the estimation of the particle effect's bounds is taking almost forever. The engine runs a Monte Carlo simulation during map load, trying 1000 random configurations for each particle and calculating the bounds of the particle effect at every frame. These particles have a life of a million seconds, so multiplying that out, it's a lot of calculations. I've been meaning to look for a way to short-circuit that calculation anyway. I've clocked this process taking up 10% of map load time in particle-rich maps. There must be a more efficient way to estimate max bounds. You'd think it'd be trivial to calculate the maximum from max size and speed and time... but maybe that would produce frequent and vast overestimates, which'd cause a performance hit through particles being drawn unnecessarily. The reason why the engine wants to know the bounds is so it can work out in which visleafs a particle could possibly be seen. Any ideas? If we stick with simulation as the only method, I guess we could limit the number of samples to a sensible amount, which'd fix this example. We could also provide a manual override in the particle decl.

This is timely. I've been looking at night skies too: messing with noise functions on shadertoy to make a procedural cloud shader. I'll have a look why your particle isn't loading...

NB the script pasted above isn't the latest version. It works only for lights with holders. The right version, that works with all lights, is attached to the tracker http://bugs.thedarkmod.com/view.php?id=4186

I don't understand... the hinge position is static for your ottoman, so you want the lid to pivot about a stationary axis (which is what it does). It's not like that gun where you have both translation and rotation happening at the same time.

Another thing that could be improved: give mappers a way to find stuff in the pk4 files so they know what they have to override if they want to tweak the game in their map. I do have a way to do it that I use myself: I wrote a python script that searches a darkmod installation, looking inside pk4s, both the official ones and in published missions, so I could check for anything that might be affected by stuff that we change. I need to give it a GUI so people can use it without having to mess with python. I'll open a tracker. @ Destined: if you want to change the default behaviour of all maps, your /script/ folder should be in your darkmod folder alongside your /fms/ folder. If you want to change the default scripts only for an FM you are working on, your /script/ folder should be in darkmod/fms/<yourFM>/

Thanks for making the bottom non-frobable

Guys could you try DR version 1.8.1 and see whether your problems go away? DR 2.0.x is the new port of DR to wxWidgets, done because of lack of ongoing support for GTK on Windows. I'm not sure whether we had Linux mappers at work during the rapid dev work on v2. Until development resumes on 2.x, you might find 1.8.1 is the version to use. It's missing very few features.

Did you have any entities in the map? Some prefabs are pure worldspawn. You could try placing a player start entity in the map to make sure there's at least one. Of course, it shouldn't be crashing with a seg fault anyway. What version of DR are you using?

Here's the fixed bit. I daren't try to edit my post above. I'm stuck on the world's weakest and slowest mobile data connection this week.