SteveL

Thanks for sharing your advice and experience guys. I have been sandboxing for about 6 weeks in between playing others' FMs. High time to start work on a map but I've been lacking inspiration. I finally came up with a cool idea for a small enclosed setting that has natural constraints on how much I can get carried away with the building work (no room to add more stuff that isn't in the original design), but I immediately started to get carried away with ideas for making my tiny map feel less tiny. The other idea was to add some inaccessible views over a stream from (otherwise enclosed) yards, using patch facades for the stuff the other side. I can rework my idea a bit so the player won't expect an overhead view. Thanks for reminding me that the point of this first map is to get to know DR and the entire production process, not to produce the best work I ever will Hoping not to run into trouble visportalling, the second topic that lots of people have mentioned and it sounds like a nightmare to get wrong... I reworked the map on paper a few times last night until I managed to get all the lines of sight short and blocked with walls that both make sense in the setting and that'll allow me XY-aligned visportals, and I'll be able to create all the sealing geometry and portals first before adding any FS details or textures or hollowing out the buildings. But I've yet to test it. It might not work at all for some reason I've not thought of, but if not I hope to find out before I add any details!

Are long sight lines in themselves a problem then, or is it only the amount of detail in view that matters? I was thinking about a similar idea just before coming back to the thread, but not knowing what's in skyboxes I wondered whether the player could be teleported to a separate room in the void as he entered the rooftop, with the transition covered up by a fall or a patch of full darkness or something. The second room could be a copy of the visible area but taken from a backup at an earlier stage of mapping -- just walls and the first few fs windows and doors. Perhaps it'd be possible to bake in shadows and light too. So less detailed, but with no need to remodel or resize. That said, I get the message that it's fiddly and not the right thing to start with on a first map.

Thanks for the info everyone. I guess if it were easy there'd be a view like that in every mission. I disagree. That's a great illustration! I already downsized my draft plan a couple of times to make it realistic but it looks like I might still have some way to go I'm trying to follow advice from the forum by limiting myself to about 20 rooms or so. Ok, I'll make sure I don't depend on getting that overhead view working...

Is there a way to give the player a view over the map from a rooftop without opening all exterior visportals and rendering everything? I'd love to do that in my first map, but I'm not sure whether it's possible from the wiki articles and forum posts I've found. I don't mind if it's complicated... if it's possible, could someone please point me to some reading material or an example map? I guess you have to blend map geometry naturally with the skybox backdrop somehow too.

Thanks for the confirmation Springheel. No-one else has spoken up to say they recognise this problem either so I'll try reinstalling TDM and DR tonight. UPDATE: Reinstalling current (same) version of DR fixed it.

HI guys. Is it just me, or does the prefab viewer crash DR for everyone? I can view roughly half the prefabs in the viewer. Those that I can view, I can import into maps. But the rest of the prefabs in darkmod/tdm_prefabs01/prefabs crash DR when I click on them. And at least one top-level folder crashes DR when I click on it (/lights). Have I set up something wrong, or is this a known problem with some prefabs that simply hasn't made it to the top of the fix list yet? Thanks, Steve

If you want to discuss possibilities without unveiling your plot idea in the forum, feel free to send me a PM. I'm new too but I'm a scripting junkie and I'll be happy to give it a go. NB the setup I gave above is a bit more complex than it needs to be. I started by trying to make a solution that others could use entirely in the editor, which is why I targeted all the participating AI from the conversation entity, and why the script loops through that list of targets several times. But given that I couldn't get around hard-coding the AI names in the script, there's no need for those loops or targets. I might as well have just replaced it all with hard-coded AI names.

Pretty sure this is the TDM mission I've enjoyed most so far Perfect 2 hours' length, super attention to detail, lots of choices about what to do next, I loved the snowy atmosphere, and I didn't get stuck for ages searching for anything: thorough exploration was enough I think my favourite bit was being made to *really* sneak so carefully in the . You made that very tricky!

Excellent. Thanks guys. And I look forward to learning how to use location settings

It was fun getting this working (see attached test map), although I didn't manage to make a cloneable/prefab-able solution for controlling AIs like this. It seems you can't stop AIs doing their stuff except by using a conversation, and that you have to create one of those in the editor for each AI, and you need at least one script function for each ai with their name hard-coded. I did try lots of workarounds like creating new conversations at runtime in the script, but it seems conversations get compiled at map start. But it's not a problem for one-off usage in maps. The attached one works, and the AI don't get borked. It starts with the four male AI circling the room on patrol. Each time you frob the left lever, one of them will go stand in front of the noblewoman at the lectern. If you frob it quickly several times, they'll all home in and form a more or less orderly queue. When you frob the right lever, the chap at the front resumes his patrol while the others move forward. I used the conversation entity itself to mark where the head of the queue should be in the map. Other positions are calculated from its origin. Also to keep track of which AI can queue. It has all the participating AI as targets. I don't have the right privs to uploads files other than images, so I'll have to paste them as text. slq.map: slq.darkradiant: slq.script:

Hi Sotha. Thanks for the link, nice idea I would still be using a map script to do the above. The "data container" entity would be populated by the script. The advantage of using the technique I was asking about is that you don't need to know in advance how many global variables you need, and the final code will be shorter. Made up example: say I wanted to keep track of which AIs had passed through a trigger so I could make them all drop down dead (or whatever) later. I don't know when writing the code how many will do it, so I don't know how many global variables would be needed. I might also want to store some extra info like when they did it or in what order. Rather than create a set of global variable flags for each and every AI in that part of the map, I could just have the trigger fire a script that stores some info in the trigger: void main() { mytrigger.setKey("ai_count", "0"); } void mytrigger_activated(entity someAI) { float num_ais = mytrigger.getFloatKey("ai_count"); num_ais++; mytrigger.setKey("ai_count", num_ais); mytrigger.setKey("tracked_ai"+num_ais, someAI.getName()); } Then later on, I can just cycle through all the tracked_ai1 ...2 ...3 keys and retrive the list of AIs that had passed through the trigger in order. And any other info about it that I want to store in there.

Hi guys. Is there any reason not to attach extra spawnargs to entities at runtime? At first glance it looks like a very useful technique, which avoids having loads of global variables and that could even make up for the lack of dynamically-sized containers in the scripting language, but there could be plenty of disadvantages I haven’t thought of. I’ve found I can spawn a target_null or some other entity in my blueroom and then add any keys I want to it, and retrieve the values later. Easy to see how you could implement a variable-length array or dictionary object that way, and pass it between functions. There’s probably no way to recover the memory used of course… but do you think anything else would go horribly wrong if I used that technique in a real map?

Thanks for the reply grayman. My code isn't quite thread safe though is it? If two AIs hit the trigger simultaneously, both could perform the check on someoneDoingX before either of them updates it. I guess the chances are vanishingly small.

Great, thanks for tracking them down

Is there an accepted way to enforce concurrency in TDM scripts? For example, the kind of situation where you want to share a single scripted procedure between many AI, but want only one of them to be executing the procedure at any given time. Naive example: float someoneDoingX = 0; void doX(entity ent) { if (someoneDoingX == 0) { someoneDoingX = 1; // make ent do something; someoneDoingX = 0; } } Obviously this code can run into trouble if entity A starts to doX, but then entity B starts to doX too and changes the global flag in between entity A's flagcheck and entity A's first update of the flag.

Ack, sorry, you're right. I remember Sotha had a similar problem a few pages back in the newbie questions thread: scripted instructions or animations don't suspend the AI's 'normal' behaviour and get interrupted by the AI's next move. [@Sotha: I can confirm the problem with kneel_down still happens when you use PlayAnimationOnce from a scriptobject, by the way]. Conversations get around it -- they suspend the AI's activity. And a conversation can hand control to a script. I have a similar general problem of wanting AI to do their stuff except for certain scripted events... If I find an easily portable/cloneable solution, I'll share it.

Thanks both for the performance tips. I'll try them when I get home

Hi guys, a couple of questions on fps: Does the console command showfps show game frame rate or video frame rate? Do we need to worry about both? And if so is there any way to display the other when testing performance? I use a gaming rig so thought I'd better check fps on an old laptop when adding detail.

Could you also use ai.goToPosition? Can't test it till after work but I think patrolling ai just stand idle after you interrupt their patrol with a go to, after which they can be restarted with another scriptevent, resetPatrol or restartPatrol I think it is.

Thank you!

link <-- tutorial on the wiki Good tutorial but it's missing something essential -- a link to the maps it's discussing. The later sections don't have illustrations and need the map files. Does anyone know where to find them?

Sounds like 2 contests: one for beginners like me, one for you guys who can make small missions fairly quickly. Or maybe some kind of collaboration project for beginners, given that people won't all progress at the same rate. I've spent the last 3 weeks messing around with unnecessary modifications to AI behaviour in DR, so a reason to focus on delivering something would work for me

The syntax is fine, it's just the data type is wrong. Make abstand a float instead of a string and it'll work.

I for one am very much looking forward to T4. It looks gorgeous. It might not be Thief but it'll be a rich visual experience that'll almost certainly permit a stealth gameplay style for those who want it, and that's as much as we can ask of a game nowadays. The vids up top show an action approach but I bet it'll be fully ghostable. Like others have observed, I can't believe how close it looks to Dishonoured. But I enjoyed ghosting Dishonoured. It won't replace TDM for sure, but that's a good thing too.

Loved it! I'll work my way through this series in order so it'll take me some time. I was chuffed when I finally worked out how a slow lockpicker could get at the special loot and pulled it off