SteveL

I don't think there's any legal or techie problem with what you proposed. You wouldn't even be selling the file you had created if I understand it right. Patreon is more about taking donations to encourage or enable people to do more work. Any talk of money on an open-source project tends to bring people out in hives. The general feeling is that commercialization ruins projects.

I saw both those scenarios when testing Zybl's patch for scripts querying mission scores. When stepping out into the light in front of a guard, sometimes the alert level would jump straight to 5, sometimes it'd clock up one or more intermediate alerts along the way. If it ramps up step by step, you end up with a higher stealth score for the same misdemeanor which doesn't feel quite right.

Hmm, did you activate the trigger_timer or set its "start_on" spawnarg? Also, "cycletrigger" goes on the func_emitter not the trigger. I should have made that clear.

We might split up the plans for 2.04 into more than one release. There's plenty of work going on, but there's also plenty still to do and in the meantime there are some important bug fixes waiting to be released. That was being talked about a week or so ago, but I don't know whether anything's been decided: I just got back from a busy trip and I'm way behind on news. Note that svn has moved on from version 2.03 to 2.04. I think the engine will run ok, but the new game code is incompatible with TDM 2.03. If you want to test that out, you'll have to patch your TDM installation while you test it. Let me know if you plan to do that, and I'll post the necessary file.

Also use spawnarg "cycletrigger" "1". NB this won't work in TDM 2.03 but it's fixed in svn for 2.04

The editor image is opaque (well, a normal image), but DR is rendering it 50% transparent presumably because its only diffuse stage is a blend stage. I could try hacking it around, but I wondered if there was an editor_ keyword or some other good way to fix it.

Does anyone know a way to force textures to be opaque in DR? The "forceOpaque" keyword is used by dmap, but it seems it doesn't work in DR. I tried changing portalsky to be a blended material to fix a problem with it drawing over lit decals, but now it's semi-transparent in DR which might drive people nuts.

The game already sums adjusted contributions from all possible paths, and adjust both the volume and apparent source of the sound. I fixed a bug in the calculation a few months ago, that was causing sound cards to pop when multiple paths happened to align. As for change of direction, I think we fake it through sound loss on the portal.

Sure. It's idDeclParticle::GetStageBounds. Feel free to claim the tracker off me if you want to fix it. It runs 1000 tests, each one testing the position of a random particle quad for each frame of the particle stage's life. Equivalent to testing 1k random quads at each frame. Like you say, it's the "each frame" bit that's causing the problem for long-lived particles. And it's done once for every particle stage, not once for the whole emitter. We can't just use the last frame. There are probably particles that shrink over time instead of growing. My thought was to use a set number of samples spread over the particle lifetime.

I'll be coming back to it when I get my new skybox working! I'm sure the issues can be resolved to make it look as good as it did in attempt #1 while getting rid of the regular patterns. I spotted a bug in the flies distribution code while looking at your original -- it only uses one of its random number sequences in error instead of 2, although fixing that alone doesn't cure the patterns. I've tracked the load time issue.

Going back to the feedback on that video, what do our difficulty settings default to? I think there's a case for defaulting to the easiest "nearly blind" etc settings, so that newcomers get a chance to explore. People wanting a tougher time will find the option later but people who can't get started might put it down like the reviewer.

Nice one!

There is no performance overhead to using spawnargs generally, but of course they can change the behaviour of an entity. What entities / spawnargs?

I don't speak Esperanto, so I'd need those subtitles. That said, foreign languages can work well to add atmosphere. Assassin's Creed 2 made great use of Italian+subtitles on their "English" option. Friends of mine who don't speak Italian (I do, no doubt with very bad intonation because I learned it as an adult) were quoting bits at me that they'd memorized from playing the game Strong "foreign" accents (or "wrong" intonation etc) aren't really a problem though IMO. Could you work it into your FM plot? Maybe using our Moor AIs or a context that says the AI are foreign? If that doesn't fit the FM then still no problem, English in a strong foreign accent won't be a problem as long as it's intelligible. English has become the common tongue in the west, so everyone's used to hearing it in every intonation. Where are you from btw?

As VanishedOne said, use the "transparent" "1" spawnarg on the door, which will keep it open while the player can see it. An open visportal is still a lot better for performance than no visportal.

I'm not sure. We don't have an in-game cursor, so highlighting might be the only way. You have to interact with the 3d world, not a HUD. Highlighting is unsubtle in some circs, but it's consistent in the game too. Players will know what it means. If you're really determined, TDM's HUD is editable and extendible, and scripting could give you an even quicker fix if you wanted to do something different.

On my monitor, there's banding in the original too. Less visible than in #3, but that could be due to the brightness difference. Subtle colour gradients don't look good brightened. #2 looks like the bands have been hidden by oversaturation. The gradient has been lost too, but that could just be in the screenshot given that some detail is back in #3 -- hard to tell without seeing what #3 looks like when the brightness is lowered again. You can tweak the rgb channels in the material shader.

That doesn't sound right at all. Are you still having this problem? I don't use Linux so can't help much except to suggest a completely clean install of your 1.8 build, but it's worth bumping the question if that doesn't help. We do have prior using Linux build without this hassle. Yes you can set an npc to be frobbable, and trigger something.. a target or a conversation or a script.

You can make your tripwire a func_damagable with 1 health. It'll trigger its targets if touched by a moveable or weapon. I've tested that much. It looks like func_damagable supports a "broken" model too, assuming you've used a model. Or you could just have it target your existing trigger so it uses the current setup.

That's great! Do you want it to work with a moveable or weapon? Both will do damage, so there might be a way for the wire to respond to it.

The humming is pretty intrusive unfortunately I have no idea whether it's fixable. It makes the owl call hard to recognise.

input.xml, that was the one. Glad it worked!

There's a config file containing key bindings and other user interface settings that gets borked if you install DR 1.x over the top of 2.x. Deleting that file and reinstalling 1.x over the top should fix it (or you can get a clean copy of the file). I can't remember the name of the file off hand. It was mentioned a lot during 2.0 test threads.

If anyone finds a highly reproducible instance of this problem I'd like to take a look at it. I hope we'll fix it for good in 2.04, but in the meantime, we might be able to apply a temp fix for 2.03 in the form of a patched game script.

That's the way experienced mappers tend to do it. If you're doing anything complicated, it makes for an easier workflow and it's certainly much easier to track down leaks etc when you can filter/hide all the entities in the map and just be left with your sealing caulk. It's not obligatory so you can mix and match, reserving the func_statics for twiddly bits if you prefer. No, each AI size has its own set of routes through the map (AAS). These are calculated during dmap. AI will take only one AAS into account, the one that's right for their size. Yes, func_aas_obstacle http://wiki.thedarkmod.com/index.php?title=Pathfinding#Dynamic_blocking.2Fclipping_with_func_aas_obstacle. There's an example usage in the Elevators wiki article, but I think they are pretty straightforward. Place one and trigger it on or off using any of the usual triggering mechanisms.