SteveL

Ok, shall I hold off on committing your patch until you say? The only reason I didn't commit it right away is I couldn't test it myself. I was looking for another Linux user who builds their own to test it. But I haven't found a volunteer so we‘ll test it with the rest of 2.04, which will remove the "build it yourself" requirement.

@Biker: Are you using the script that got packaged with DR, or the version linked by nbohr1more? DR 2+ accidentally packaged an older broken version of the script. I've not tried it, I'm just reporting what I've read in other threads.

Here's an example of what the material should look like. For "yourChosenDRpath" you specify where you want to find it in DR's media tree. If you want to find it easily in a top level "Epi" folder, use "Epi". None of this is case-sensitive. We have parallel lights. Select a light in DR, hit 'L' to bring up the light inspector, and there's a "parallel" checkbox. You set the direction NOT by rotating the light, but by pressing V to enter vertex editing mode, then moving the light vertex. The bad news: Parallel lights are fiddly and glitchy. If you try to stretch them across too many visleafs, you'll get shadow errors or areas where they vanish. The good news: Once you've got them working right, they are stable. So it's not a deal breaker. They look ugly if you can see the edge of the light volume. That should be in an unreachable part of the map. If you need a parallel light to stretch across many visleafs, you are better off using several and making sure there are indoor or covered regions between visleafs to hide the edge of the light. It doesn;t have to be "indoor". A natural arch of rock would do. That's not a bad idea anyway to be honest: Don't plan for huge open areas with no pinch points in TDM, it's not what our portalled engine was designed for. Feel free to dazzle us with the illusions of space that you can create though I did some experiments with moonlight as my first ever experiment with TDM and DR. I ended up finding an overly complex method of making moonlight work through unlimited visportals and map size (although it would have a perf hit so don't think of doing this on a very large map with loads of outdoor AI). If you are interested see this thread: http://forums.thedarkmod.com/topic/16046-dynamic-moonlight/ Random tip: The forum search facility is pretty useless, especially with our tendency to bury loads of information in umbrella threads, and the wiki search isn't great either. To search both sites well, use google instead, with a search like this: site:thedarkmod.com blend vertexcolor

You can make a decal patch for your terrain manually, by duplicating the patch then trimming away the parts you don't need. There's a patch splitter script I made for DR that makes that job easy. It's not part of the official DR distribution but you can assign the script to a hotkey in DR and the instructions are here: http://forums.thedarkmod.com/topic/16090-patch-splitting-in-dark-radiant-new-version-29-mar/?p=340549 The engine supports vertex colouring, but for two textures only. Their contributions will always sum to 1. The first texture's colour is multipled by the vertex colour, and the second texture's colour is multiplied by one-minus-the-vertex-colour. It's good for blending two textures on a model, basically. DR doesn't have any support for vertex painting. Obsttorte came up with a method for letting people do this to terrain in DR by using brushes to mark the places where the second rextures shows up (iirc). http://forums.thedarkmod.com/topic/15026-dr-ase-blend-exporter/?do=findComment&comment=318475 NB the version of Obs' script that's packaged with DR isn't the latest / correct version. The latest is linked in that thread. As a modeller though, I expect you'd always reach for your modelling program for that task. I agree that would be awesome, and it might not even need any engine changes. It could be possible with a tweaked interaction shader, that a modeller could package with their map. The problem would be the workflow. Without a lot of DR changes, could mappers take advantage of it? You can split your mesh to get a 3-texture blend in the meantime, although not with all 3 textures on the same spot.

They already have a wide area of effect, but not at the point where the arrow hits. The water spreads as it falls. You should shoot something directly above the flame, like the ceiling, to get maximum effect.

My workaround for this is to use CTRL+ALT+Delete, and minimize TDM from the task manager. That gives you normal windows use until you click on TDM in the taskbar again. But it would be nice just to be able to alt+tab. NagaHuntress recently submitted a patch that'll fix the problem for Linux in TDM 2.04. Looking at the code, it seems to prevent the fullscreen setting taking complete control of the keyboard and mouse etc. Does anyone know how the equivalent would be done in Windows? I don't mind trying it out if anyone can start me off on the right track. I suspect the brightness/gamma problem is separate. I sometimes get that even when TDM is running in windowed mode, which lets you alt+tab normally.

I've sent you a fixed script. There were 3 problems: The rotation was less exact than I thought. Sometimes it was more than half a degree out, so rounding the number of degrees wasn't doing the job. Fixed by rounding after the division by 36.All the results needed 1 adding, as observed above.You had the division by 36 in 2 places. It now happens in the getChosenNum() function, so you don't need to do it in the line where you pass all the angles to that function.Is there a wiki article containing that script, or explaining how to use the numberlock prefab? I should make one or update it if so.

These 2 results at least are consistent. They mean the angle needs to be offset by 36 to give the right result. This is intriguing. And I can't work out a pattern. Could you do one of following things please? Either: Get it to print the angles (all 3, xyz) for the wheels as well as the result, and try your tests gain? (0000, 1540, 2540) Or, export the wheels and lever as a prefab and PM it to me so I can have a play with the matching config in a test map!

The way we ended up implementing it, I think everyone's wishes are covered. There are no dedicated quicksave slots, and no fixed filenames. The one rule is that all quicksave file names begin with "quicksave", which is how the game recognises them. The player decides how many they want. The default is two. People who want to keep the current setup can set it to one. People who want all quicksaves kept can set it to 100000.

For my part I think it's definitely worth discussing. I don't remember any previous discussion of what the problem is or what we'd have to do to get it to work. I only remember discussions around the fact that it doesn't, and about workarounds. I do have a workaround but it would be nice just to alt+tab. NagaHuntress recently gave us a patch to make it work right on Linux. I don't know the issues on Windows, but there are likely people on the forum who do and could give us a start.

Woah!! £20k for a monitor! The 55-inch 4k TVs that I spotted were "only" about $3k. I guess monitors don't have any savings from mass-production yet.

Are OLEDs even available? I tried to find out the prices on google and all I can find are tiny screens for tablets and smaller, or > 50 inch 4k TVs. Nothing in the monitor-size range.

You should start a new thread so people can find it

Probably not hard at all (I've never changed a menu, but it can't be hard to do).

I've implemented the cvar. The save game code is in the engine framework, so the cvar is a com_ one, com_numSaveGames. It defaults to 2. I didn't have to write any date-handling code The engine already has the facility to give you a list of save games sorted by date descending: that's what's use by the load game menu. It also has a facility to find an unused file name, so all this tweak does when saving is: look through the sorted list of saves and count the number of quicksaves, and if there are too many already, the last (oldest) one that it saw gets overwritten. If there aren't too many, it generates an unused filename beginning Quicksave, e.g. Quicksave_0 or Quicksave_1 (adjusted for language/l18n). When loading, it just finds the first (most recent) matching save, or if there aren't any quicksaves it gives you the same console error that you get now. This method will never *reduce* the number of quick saves that you have for a mission. If you create 5, then reduce the cvar to 3, it'll just overwrite the oldest each time, so you'll keep 5. File timestamps don't include fractional seconds, so the game can choose the "wrong" file if you tap F5 several times in one second. But that won't be a problem in practice. The overwritten file will always be one that you created that second.

On second thoughts, rather than shoehorn in another menu option, we can make this a cvar that gets remembered between map loads. Sound ok?

I think this is because rotateOnce() doesn't produce an exact rotation. Sometimes it stops 0.001 of a degree short, sometimes it goes over by a similar amount. The naive script will count a fraction-over as the next number, so you sometimes get two numbers on the dial mapping to the same output. The way to fix that is to round the result. We seem to be missing a round() function, so you'll need to provide one: float roundToInt(float n) { float i = sys.floor(n); float diff = n - i; if ( diff >= 0.5 ) { i += 1; } return i; } float getChosenNum(float zAngle) { while ( zAngle < 0 ) { zAngle += 360; } zAngle = zAngle % 360; return 9 - sys.floor( roundToInt(zAngle) / 36 ); } I also changed the 10- to 9-. 10 was incorrect and it's why one of your results has 5 digits. Lastly, it looks like your dials are using different 0 points. Have you rotated the individual dials to start it with a combination other than 0000? I'm not sure how that could produce the error... Are they showing the same starting angles?

It *would* be possible to get it to give the right answer every time by tweaking the function after a bit of experimentation (if you give me three examples, displayed number plus output I could probably work it out), but it wouldn't work any *better*, it'd just be erm.. tidier

I see. You need a proper modulus. TDM scripting does have one, but it doesn't automatically correct negative numbers by making them positive, so you have to handle that. I'd use this in place of your mod() function: float getChosenNum(float zAngle) { while ( zAngle < 0 ) { zAngle += 360; } zAngle = zAngle % 360; return 10 - sys.floor( zAngle / 36 ); } ... then in the wheel_lever function ... f1 = getChosenNum(a_z); f2 = getChosenNum(b_z); etc Whether or not the "10 minus z_angle/36" calculation is correct will depend on your starting setup. If it doesn't work first time, add a sys.println to your script so it prints out the number every time you pull the lever. That should let you spot the pattern as to what's going on if you get incorrect results.

Yes, Obsttorte added mapper control of saving in the most recent release. No, no-one's built a checkpoint-save map yet. The new system would work with both that and with the mission stats (which just count the number of times a save has happened and store it with the other mission objective information).

Thanks everyone for the feedback. It's pretty clear that no-one enjoys tidying up manually I'll see whether we've got space on a menu for setting the number of quicksaves, because it'd keep maximum flexibility but would probably be a little-used feature.

Does that compile and run ok then? I'm at work so can't check but it looks wrong. Specifically, the use of "mod" doesn't seem right. I'd try it with sys.floor in place of mod, i.e. f1=sys.floor(a_z/36); etc

I didn't get a captcha, it just went straight to the article. Their TDM screenshot -- is that from Protecting the Flock?

Wow!

I've never had a corrupt save either, but we do get reports. I occasionally hit F5 when I'm about to die and mean to hit F9, so I'd like this feature to make up for my brain farts The system you describe sounds like what we already have. Maybe I should have added a poll option for "don't change it".