SteveL

Hard to explain? Maybe but that was extremely clear, thanks The same blend add/filter effect that you recommended using to making clear glass dark or bright for looking out or in of a window. Now I know what effect I'm looking for I'll have a play with them. Yes I do think I was after light glow RJ, although having thought about it more.. no, you're right, they'd be far too heavy especially since I want a crystal clear summer night. So I'll just have to be more imaginative about what gets hit by the point lights to add interest.

Guys, what's a blend light and where might you want to use one? I've searched the wiki, the forums and doom3 mod sites (where I guess they didn't exist) but no joy. I've leaned that they're like volumetric decals (???) and are good for performance and are similar to fogs under the hood, but not what they're for. I'm actually casting about for ways to make my outdoor lighting a bit more interesting and to achieve a bit of glow around point lights, so any hints or links for that would be welcome too. I've got parallel moonlight currently looking lovely and not glitching but it's rather upstaged my artificial lights in shaded areas. @PranQster: don't want to hide your question but I can't answer it either, so I'll chuck in an uninformed response Do you have simpler options? Could you achieve the same effect by turning the particles on and off at intervals, the interval being out of sync with the time taken to path round the spline? Could that be done with the material shader properties or a timer?

Caulk only reveals the whole of a func static if a bit of the FS is in your current visportal leaf. If you want to see a big FS from a non-adjacent area, you can create a little brush in area and merge it with your FS.

It's well covered in the City Street Visportal Tutorial which is where I learned about it.

Is the $ throughout a typo? Or does it relate somehow to the (unused?) entity variable declared on line 3?

RP?

Stunning work again Moonbo. Your ceilings and vertical vistas are exquisite. The first time I looked at the proof-of-concept map you provided for the script question, I completely missed the spoken instructions because I was gawking at the ceiling or a window with my mouth open, oblivious to all else.

It can be done I reckon, although I haven't found out how to remove the blackjack or dagger. Turns out there are three types of inventory to consider: loot, weapons, and other. Loot and other are easy enough to get handles on, weapons are trickier. I haven't found a way to remove the melee weapons without borking the player's weapon capabilities entirely, but I've figured out how to remove arrows safely after saving the info re how many there were so they can be put back correctly later. The melee weapon part *might* be fixable, but after a couple of hours' testing I'll wait till I know what you have in mind before experimenting further! Happy to adapt it for your purpose if you want to PM me.

+1 I was about to say the same thing. TDM lockpicking has it better than other games IMO. It would be boring if a minigame stopped you listening out for guards (or froze time so guards couldn't approach). Pickable locks are a gameplay device, not an entertainment in their own right, and it's up to mappers to choose good spots for them rather than scatter them everywhere.

It depends whether the script can detect how many arrows the player is currently holding, and whether the weapon inventory is accessible to the same scriptevents as the item inventory. I'll have a quick play when I finish work later. Presumably it would only be certain equipment that wants swapping. You wouldn't be taking loot or readables off the player.

You could set up the inventory sets in a blueroom and target the items in each set from a tracker entity so that scripts can access the list easily. Or you could just hard code the inventory sets in the script. The script reference provides functions to cycle through the inventory, so you could compile a list of references to the current items and store it for later use. It might show the items scrolling around the HUD though, unless you do something to disable it. Likewise swapping them out would presumably trigger hud messages unless you suppress them. Question: If the inventory sets include disposables like arrows, would you want the process to keep track of how many are remaining? So if the player starts with 5 broadheads and uses 3 then picks up 1, then swaps out inventory twice, should he have 3 broadheads or a fresh set of 5?

I've gone for "avoid AIs" although that has a lot of overlap with ghosting of course, it's just that I don't reload if I get spotted. I'll reload if I get into inescapable combat as I don't think I've ever won a fight in tdm :-) BJ is reserved for special occasions only when faced with a difficult AI. My natural style is to try to ghost everything but I'm trying to discipline myself to use the tools more as tdm has more fun to offer that way. And like Sotha said, escape is fun too.

Thanks for the advice guys. When you think you've tried everything, ask The timescale tip is something I'd not come across before and it's sped up my testing cycle a LOT. Results of latest testing: The extra path corner is fine for fixing a patrol, but not for allowing an AI to chase the player. They still take the long way round once they leave their patrol route. Changing the AI type didn't change anything. Using monsterclip or nodrawsolid instead of caulk didn't change anything in this spot. Varying the types of adjacent walkable brushes (i.e. striping between monsterclip, caulk, and nodrawsolid) doesn't affect the AAS boxes or the pathing. Adding an extra caulk wedge fixed both patrolling and chasing, but it also caused the big AAS boxes to be split up into small ones so it was unclear whether the height difference was the problem, so I tried more tests: Splitting the original caulk wedge into 6 small ones didn't affect the AAS boxes or the broken pathing. Lowering the verts of one of the central split wedges by an couple of units also caused the AAS boxes to be split, and it fixed the problem too. NB This increased the gap between the caulk and the patch. So I've still not worked it all out, but I'm much happier that I can fix this problem where I find it. My take-away lesson is, if AI are pathing around a big AAS box, add a little brush or do something else to break up the AAS boxes. And tweak stuff till it works! ps: If I seem to be taking too long over this, it's because of past experience. The only other time I ever tried to make a FM for any game was 8 or so years ago with T3ED. I put months of work in, but then couldn't get AI to walk between rooms at all. My navmesh looked perfect, but neither I nor any of the experienced people on ttlg could make AI path around my map, and I ended up abandoning the map and mapping for a decade! This time round I've had test AI exploring every corner almost since day one. So happy to have found TDM now and to be giving it another go. TDM is so much better!

My test AI will happily walk through a certain AAS box to get to a path corner, but then walks carefully around it to get back. It's a big AAS box, so the effect's not subtle. In the pic, he's just crossed successfully through area 29 into area 28 going left to right, but to get back to the left hand side of area 29, he's pressing up against the far wall to walk around the box rather than cross it. The floor is a lumpy patch over a caulk wedge. It looks very bumpy but the maximum gap between it and the caulk wedge is 20 units. The underlying brush isn't broken under the problem area, so there's no invisible "step". There's no visportal or intersecting brush. Tweaking the caulk wedge verts hasn't fixed it. Nor has moving the path corners, including z-axis-wise. What *does* seem to fix it is adding an extra path corner in the middle of the offending AAS box. Then the AI paths through it fine both ways. Any idea how to understand or avoid this problem? There's a second spot in my map where it seems to be happening too, though I haven't done as many tests yet as I have with the one above. If I'm somehow messing up TDM's shortest-path calculations, I could end up with lots of pathing bugs

Duplicate post

@RJFerret: the code already has that safeguard built in even at this stage @Biker: you can try it right now without needing to save anything as a file. Just go to the python console in DR and paste in the entire code block above. Nothing will happen at that point, even if you press "run script". Then when you want to use it, select a patch, work out what row or column you want to split on, and in the python console add one of these extra lines (below the code you pasted in): PatchSplitter().split(col=NNN) PatchSplitter().split(row=NNN) Depending whether you want to split on a row or column. Replace NNN with the number. Then hit "run script". Like in the patch inspector, the bottom edge of the patch is row 0. The next row of pink verts above that is row 2, and so on. You can't split on an odd-numbered row (which has only green verts). It's a little awkward to use, but I was going at a fast pace with a clip every few seconds once I'd got started. Thanks for the quick responses guys.. yes in that case I'll finish the job when I get back next week This post was hot off the press after I nuked a bug this morning and actually used it to cut up my map. I've already thought of a way to address the undo problem (in fact it might have been fixed in a change I made earlier), and of one way I might be able to make it purely point-and-click. How friendly the GUI can be will depend on what info I can get, if any, about selected vertices in DR's python API. What I don't know is whether it's possible to add a menu item to DR, or call a python script from a keyboard shortcut just through config file changes. I'll do my research! EDIT: @Biker, yes, good point, it could do that pretty straightforwardly. A use case I never thought of.

I did a python script that splits patches in the editor yesterday, after finding I'd made the horrible newbie error of making the entire exterior floor of my map from just 3 patches. They'd have been hit by about 20 lights each if I hadn't split them, and I'd already painstakingly stitched them together so didn't want to restart. Is it worth me turning this into a more user-friendly tool? At the moment it's just a barebones scripting capability: Undo doesn't work consistently so you have to save first, and there's no GUI. You choose a row or col to split on and issue a 1-liner command in the python console. But it does split patches seamlessly using almost the same method as the text editor / spreadsheet options, and it's very easy and quick to carve up a patch: just turn on vertex mode so it's easy to count the pink dots, put that number in the panel and hit run script. Not sure how much it's needed though. I for one won't be making that same newbie error again. Or perhaps I will come to think of it... making one big patch, curving it and adding noise then splitting it is a lot faster than making lots of small patches and stitching them. It took me less than 5 mins to carve up my bumpy curved floor. I'll paste the code here for reference as I'll be on holiday for a week from this evening and although I'll still be checking in to the forum, I won't be able to get back the code.

I am Windows 7 too... Damn, was hoping it didn't work just for me! A post in the another related thread I was just reading suggested you need to have the "always on top" option enabled in Windows task manager for it to work. As it happens, I don't have that enabled, and it does work for me, but that's something else you could try.

That thing that particles seem to do, when you strafe around the emitter with r_showtris turned on. The decals seem to turn to face the player like the eyes of a picture following you round a room. Can that effect be used on other entities like func_splinemovers? I know I could do it with a script, but something supported by the engine would be far more efficient. @Garrett2014: No prob, it's an incredibly steep learning curve to start with. I know, I did it 2 months ago It doesn't help that some of the info in the wiki only applies to previous versions of DR or is plain wrong, and the people who can edit the wiki aren't the same people who use the articles aimed at beginners, so it doesn't get fixed.

Not any more, but it was 3 years ago when that post was written

I've found a way to switch windows when playing in fullscreen mode without any add-ons or scripts, but it's a few keypresses, not one: CTRL+ALT+DEL > task manager > right-click darkmod > minimize. The game will resume in fullscreen when you click on it in the taskbar.

You can end up with white brushes in both camera and ortho views... The 3d "camera" view has a set of 4 toggle buttons at the top of the window. One of them (the 2nd I think) will make objects untextured white, Just change it to the 3rd button which will give you the textures back. But reading your message again I think you mean the 2d ortho view as that's the one with the grid. White might be the default when you have nothing selected. If you open up preferences you'll find there are alternative skins or themes available. I changed mine to make stuff easier to see almost as soon as I started using DR, so I can't quite remember what the defualt theme looks like, but I'm sure you'll find a colour scheme in there that suits. EDIT: Spotted I'd missed this question earlier. The media browser *is* your main textures browser, so they do all get made available at load time. You can apply textures directly from the media browser (right-click). Think of the separate Textures tab like a "recents" shortcut menu, that shows you the textures currently in your map, plus (optionally, it's a toggle button) the ones you've previewed. You wouldn't want all the textures loading into that tab -- there are so many it would be completely useless. In the media browser they are filed away in a tree structure so you can browse and preview all textures for wooden boards or whatever in one place, and you can apply them from there without using the textures tab.

I am a keyboard shortcut addict, I hate having to touch the mouse so I've not tried binding new mouse buttons but you can get at the bindings under the edit menu> keyboard shortcuts I think. Be wary of rebinding the mouse wheel click though, or at least put its functions somewhere easy. It does different things in camera view and ortho view, both very useful. When you come to make a map you'll use that texture copy / paste a LOT!

Looking good Sir T! Very atmospheric

@RJFerret I never thought of using Google to search the forum! I've been using advanced search to display individual posts instead of threads. The default search is rendered pretty useless by master threads like this one. But even the advanced search won't let you search for short terms like AAS for example. I'll try Google tonight :-)