Dragofer

Great. This is just the kind of info that you can only get via the forums or gradually through experience and trials.

The problem with this is that there's a bold-printed warning that only one gui file may be changed by map authors, mainmenu_custom_defs, and the only mention of 'complete' in that is for the soundshader. I've already changed that. I've located the 'mission complete' text in the strings folder, english.lang. Will get to work on that.

Could someone give me a tip how I can change the text of the 'mission complete' screen? The wiki and the customisable gui file only seem to have provisions for changing debriefing videos.

Very nice, those look impressive ingame what with the combination of the gas lighting and the wood. A comment about the make, I've seen that you're using very thin detail brushes, grooves and such. That can be problematic in a couple ways: - the engine can run into difficulties if it's asked to generate many brushes of that kind as brushes are meant for things like walls. At some point the engine may start failing to render large chunks of brushes under the strain, even simple ones like floor brushes. - there are many very long and thin triangles, which are unusually taxing for a graphics card. These come not only from the brushes themselves; they get rendered again with every light that hits the details, and yet again for every light if it should cast shadows. And the engine has a tendency to fragment brushes into even more and thinner triangles. This would come under your performance question in another thread recently. The first point could probably be avoided by turning the brush&patch components of the bookcase into an .ase model so that it no longer needs to be compiled by the engine; this would also solve the brush fragmentation problem and reduce dmap & loading times. The second issue would be more a question of asking yourself how visible each detail is. For example, in your second video the trim of the lamp pillars is very noticeable and adds alot to the scene, while all the grooves above the lamps and inbetween the pillars would need to be consciously inspected in order to be seen. Those would be good candidates for saving on perf. And lastly, while normally not making any difference, in this case it might be worthwhile to apply caulk to the unseen surfaces of the long thin brushes because they'll be copy-pasted over and over.

Thanks for the suggestion, that looked promising and does indeed show - some - textures which I know could only be from models, when untoggling 'hide unused'. But no paintings unfortunately. By the way, like grayman I don't have the button that you have between 'hide unused' and 'find and replace'. What does that do again? (My DR is the pre-release 2.0.5, win7 64) I've ended up sorting myself out like this - could be useful for anyone who in the future uses parts of a custom painting pack: - look up names of painting models used under map info -> models. Note that there can be paintings both in the decorative and decorative/wall folders. - look up which size of painting each model uses, i.e. painting01_m, and group them that way. - for each group: create a new filter named after the painting size and add each painting model (type: entitykeyval, entity key: model, match: *name of painting model*) - activate the painting filters, then hide the whole map - deactivate one painting filter, then go into ortho view and note down which skins are used by the paintings of that texture size category. I've hidden every painting that I noted down. Go through each filter this way. - As a result you'd know which skins are used in which sizes in your map. This was tedious but worthwhile, after I also converted the .tga diffusemaps into .dds the archive size decreased by 50mb.

Thanks, it's unfortunate that there's no overview for model textures like there is for brush&patch textures. It could be reasonably fast then to use map info to highlight and isolate each size of painting, then check which skins are used by which sizes.

Is there someplace where I can see which textures are being used by models in my map? Or even better, which image files? 'Map info' only seems to show what's on brushes and patches. This is for trimming down a custom 50-painting pack which has multiple diffusemaps in various sizes for each painting.

Moonbo also mentioned adding more subdivisions to the patch as a way of fixing sparklies, as I remember it.

The script reference does say that directdamage only applies to idAI, while damage is for idEntity. It'd be interesting to know whether somehow directdamage still works on the player, but it seems unlikely. The cleanest thing would just be a script that goes $victim.damage(1); Enter your target and how much damage you want done, maybe also a sound shader for the 'hurt' sound (player/AI voice, glass cracking, wood breaking), no need to look for or create a fitting damagedef.

Ah right, I remember trying to use that and found that it needed a huge amount of parameters, and I didn't know what each one was meant to do. Thanks for pointing it out, I didn't realise that the script reference page has detailed usage information for certain functions. So a script line with this could be something like $victim.damage($arrow, $archer, '0 10 0', "damage_generic", 1);

I thought I'd make use of the moveables system for gameplay in my map but am having problems with this because my thief constantly lets go of moveables. I could pick up any default candlestick and raise it, take my hands off the keyboard, and one or two seconds later it's dropped. It only happens in one area (house + exterior) of my map, in other areas I can walk around with a candlestick as long as I want. Is this maybe a known bug? There was a change to moveables handling in 2.04. Edit: also, is there a simple way to apply n points of damage to the player through a script? I've tried a S/R setup to apply a damage def but the damage gets multiplied by 10. That can be worked around with a custom damage def that deals less damage, but more importantly it seems to ignore the 'chance to apply' parameter in the S/R window.

Very nice, I'd suggest that while you wait you go through your mission over and over so that you can shorten your beta phase, because your beta testers are inevitably (in my experience) going to flood your inbox with pages of bug reports such as: - models with incorrect skins showing up pitch black ingame - out of place prefab components as a result of being rotated en bloc, such as lock bits on chest locks - chest lids clipping into things when opened - AIs stop pathing because their path has a dead end, or they sit on top of the chair's backrest, or they walk endlessly in circles at doors, or they throw rocks at you from one end of a corridor - moveables falling through their surface when touched because they don't start completely clear of it - particles leaking through walls - doors having their origins on the wrong side resulting in z-fighting when they open - visportals' visportal surfaces not being within the door, giving you a chance to look into the void - floating anything - lights leaking through surfaces because either the light or the surface is noshadows - z-fighting of course - welcome to the last 10%

Was just working through Nbohr1more's overhauled Performance Tweaks wiki page when I saw there that you can switch in and out of fullscreen mode with alt + enter, whenever you wish. Well that's very useful.

Airship made a variety of food models a while ago, including grapes, watermelons, lemons. I couldn't find it though. What would certainly be incredible would be a roast pig-with-apple as the centrepiece of a dinner table, surrounded by various dishes. As a side-effect you'd be one step closer to a pig character, just that it would need a different skin. Much of the work with these would probably be the textures. Once there are suitable source images for imperfect food, the models could follow quickly.

Indeed, Tels' call would've been a great thing, feels like something is missing without it. I think you'd have much of the flexibility of scriptobjects from inside DR without having to define any entities. One step further would be to pass a whole line of parameters, maybe even with 'get' commands in there. That might open up interesting new possibilities.

Quite a lot of Victorian vibes going on there.

For those who crash at startup when DR is initialising its XML registry, which is a problem that I get from time to time, usually when my pc crashes while DarkRadiant was saving, I could solve it in my case by deleting the user.xml file in my user account's hidden AppData/Roaming/DarkRadiant folder. Here's a user.xml file that makes my DR crash at startup: edit: had it again today, deleting user.xml alone wasn't sufficient to solve it, I had to delete everything else in there to get it to start again. user.xml.txt

Let's see, the words 'trigger', 'relay', 'target' and 'delay' occur 11 times in your two sentences. I don't think I'm uptodate with the latest trigger/targeting/relay/delay setup in the map anymore.

Great, that solved this part. I've had to go via a trigger_relay instead of letting the light target the candlestick directly, so it looks like objective completion targets aren't the only kinds of triggers that don't count as triggers in stim/response setups. My first question - it's more something like having a room with 40 books and whichever book gets frobbed should run a blendaway_glow script on itself (not a spoiler). The setup I'd have liked to make is that each book has a S/R effect 'Run script' with parameters '_SELF', or failing that, that each book targets a central callscriptfunction which knows by which book it was triggered and passes on the name to the script function. But it seems the closest thing the callscriptfunction entity can do is 'foreach', so that all the books are dematerialised in one go. It looks like the last time someone wanted to pass on variables to a script was Fidcal in 2010.

Activators are just needed in special circumstances, for example if you want to trigger a teleporter and let the activator be the player or a certain AI. Usually you need just the target. The loop might be because it looks like the AI triggers itself everytime it gets triggered, though you're saying you've gotten such a self-triggering setup to work before? It'd probably be easier to let the AI's trigger response be to trigger the relay which targets the speaker.

Second question: When you hold a moveable such as a candlestick and activate it with enter, is there some way I can get that activation to trigger something else as well? I've got some custom stims and responses on a candle in a candleholder that I'd like to toggle off if the player snuffs out the candle.

When calling a script from inside the map, does someone have a way to supply some variables to the script? In the sense that in a test script called: void test(entity book_name) { book_name.remove(); } Could I call the script and send 'ghost_tales' as a parameter so that the script looks up my book named ghost_tales and removes it? What would also work is if the calling entity sent its own name. I have a lot of similar entities that I'd like to call the same script on.

I think there's a misunderstanding, my mission had no special way of ending. That's strange, normally if a path_corner targets another path_corner, then when the AI reaches the first he'll move to the next. How are you making the delay? Via a delay spawnarg on the trigger_relay? Would be strange if that didn't delay.

I'd have suggested to insert another path_corner at the point where the voice should trigger, or a trigger_entityname brush. Though it's good to see you're getting into the swing with the triggers and relays. Thanks, indeed the perf at the beach is a mystery. You've got a 30000 tris model behind you and thousands of stretched tris in front of you because the walls aren't just a texture. Yet still there would've been plenty of space for flashy things like a parallel moonlight, which would make the outdoor stealth parts somewhat more interesting. The absence of such things probably explains the perf. The beach texture scale was to avoid that it repeats so obviously, though in hindsight it'd just have needed more clutter to break up any longer sight lines. There is a default video that plays when the mission completes that could be replaced. Mid-play, you'd need to ask one of the code buffs.