Frost_Salamander

Sometimes I think I learned some lessons from the feedback I received from this FM, but other times I wonder. I definitely didn't make it 'difficult' on purpose, but I certainly didn't want it to be easy or not challenging. It's hard to tell what people find enjoyable. I guess my assumption has been that players expect stealth gameplay, since, well it's a stealth game. But it seems if it's too difficult to get a perfect stealth score then that might turn some people off. The funny thing is, I always write the FM with ghosting in mind (or at least, no blackjacking). With this one I didn't really test it with going around blackjacking everyone. It wasn't until I watched some playthroughs that I realised how easy that made it

The face of the visportal with the 'Vis Portal' texture must be touching a brush on all sides. Entities and patches don't seal.

I'm having this weird issue where copy/paste shader stops working properly. It will paste the texture, but not the position/scale from where it was copied. If you copy/paste between two surfaces with the same texture but different offset/scale, the result is it appears to just do nothing. If I restart DR, it goes away for a while but then comes back. Is there a setting for this anywhere? Anyone else getting this? Because it's random, a bug report probably wouldn't be very helpful without proper steps to reproduce. I don't remember ever seeing this before 3.5.0.

ah nice - I've already overridden that script object for a different purpose (but for the arrive event). Thanks!

You can in fact make that part larger. If you hover your mouse carefully on the line right under where it says 'func_static_295' or whatever, the cursor will change to a resize icon, and you can drag it down to enlarge the panel that shows the spawnargs. It's easy to miss, I think I remember someone else noting the same thing a while ago.

Odd - it's definitely happening to me. I saw the doors Wiki page about interruptable and figured like you said it only applies to frobbing, but like I said the doors will stop (edit: the auto-close no longer works, even with blocked set to 0) when damage is inflicted, and using that is the only way I could get it to work. Actually what I really want to do is override the behavior of the atdm:mover_elevator_button entity. My main requirement is actually just to not let the elevator move unless the doors are closed (hence all the auto-closing nonsense). But pressing that button causes it to move no matter what. I just checked and it doesn't have a script object. Is there a way to intercept the call that the button makes and insert custom code there? For example have an 'onPress' event that I could customize before sending it off to do its thing...

I thought you were onto a winner here, but nope, still does damage

it might be because I also set stop_when_blocked and 'interruptable' to '0'. The reason for this is because they are elevator doors, so I want them to be behave just like the would in real life. I found that just 'stop_when_blocked' alone did do enough - they would stop but if damage was taken by the player, they wouldn't then resume. If damage wasn't taken, they would resume. When I added 'uninterruptable' as well, they closed no matter what which is what I wanted (although you can now get trapped in them if you're not careful ). Also, there are actually 4 doors - one set in the elevator carriage and one set to close off the shaft. I didn't mention any of this earlier because it's pretty complicated and I got it all working the way I wanted, except for the damage part.

Not really, no. It does indeed push the player, but because it's 2 sliding doors you just get pushed into the other one and the damage still occurs. I don't really want to change the value of the auto_close_time either for 'gameplay reasons'

Does anyone know how to prevent movers from damaging the player? In my scenario, I have a set of double sliding doors that have 'auto_close_time' set so they close after a second or two. If both doors hit the player they receive damage. They are just doors so I don't really want that to happen. I see there is a 'def_damage' entity attached, but not sure how to override/get rid of it. I tried to set it to a nonsense value (e.g. 'none' or '-') but that didn't do the trick.

That's what I always do - I don't think there is a need to uninstall anything. If you look in your C:\Users\<username>\AppData\Roaming\DarkRadiant folder you'll see it has folders for each DR version which contain settings files. Every time I've installed a new version it picks up my settings. If you're worried about it, you can always back up that folder. Greebo could give a definitive answer on how all this works, but I think you'll be fine just installing 3.5.0 over the old version.

I love the layout changes - nice one However, on another note there is a difference to how commands are reflected in the camera view. It sounds really minor, but it's very noticeable when working. As an example, if you say had some objects selected and then pressed a shortcut key for 'hide', the objects would disappear immediately from the camera view. Now in 3.5.0 they disappear from the ortho view immediately but not from the camera view - you need to right-click on the camera view again before they disappear. It's the same for other stuff as well, like adding entities. If it's intentional, it may take some getting used to - but I can't say I like it. If not, I'm happy to raise a bug report? EDIT: I restarted DR and it went away, so ignore for now. I'll come back if I figure out what was causing it...

I just noticed that DR allows duplicate info_player_start entities in the map (you can just clone them). Is this intentional? If so how can it be leveraged? If not do we think this is a bug?

that's done it - thank you!

okay - I guess brushes it is then Thanks for taking the time to put that together!

I've tried that, but all that seems to do is just add more subdivisions, and doesn't affect the way the patch bends (at least for end caps). I've also tried adding/extending rows/columns but it never has the intended effect. Maybe it's not doable? I've admittedly done that before and although it's crude it's fine for a one-off, but I'm trying to figure out how to do it properly. It seems like the kind of thing that a video tutorial would help with, but I haven't come across any that do this. If anyone knows of one that shows this I'd be grateful

How do you create an inverted bevel end cap from a bevel that's been flattened slightly? In the pictures below, I want the end cap to cover the space entirely, and avoid that gap being created after I drag the verts. Is there a way to make the patch stretch to the upper corner so that gap doesn't appear?

Yes that was it. It was enabled in 3.2.0 and disabled in 3.3.0. Where is that preference stored? For some reason, I thought user preferences were shared across DR instances (i.e. stored in user home directory). Or is that not the case? Only asking so I can rule out different settings in multiple instances of DR before raising something in the forum/bug tracker...

In DR 3.3.0 if I try to resize a light attached to an entity, the light model itself moves. This doesn't seem to happen in 3.2.0. Is this a setting somewhere, or has something changed? dr_light_resize.mp4

I agree the feedback hasn't been great, which is a bit of a shame. However, reading that other thread it's not obvious what's changed (at least on the surface). As far as I can tell there are 2 things: The new indicator animation Changes in the way the actual knockout works (a new 'trace' method instead the previous 'collision' method). That's about all I understand about that. Also, it doesn't appear there has been any changes to the rules, correct? So, the implication is that perhaps (unintentionally?) something in change #2 has made things 'more difficult'. If that's the case, the people that have noticed it might want to try to narrow down what's changed and provide better feedback to @Obsttorte. I think the animation is a nice feature and it would be a shame to bin it after all that effort. Maybe we need a more organized beta test - just get a few people to commit to playing through an FM with and without the new feature to try an narrow down any issues? I'd be happy to help.

If you don't want the lamp to cast shadows, set the spawnarg 'noshadows' to '1' on the lamp model. If you don't want that light to cast shadows on anything, set it on the light itself.

Why not go one further and make that the theme? I think that's a great idea - there has been a lot of discussion recently around tool availability/use and their relation to mission design. Maybe a contest to showcase how they can be used creatively would help remind us all how useful (or not LOL) they can be?

yeah can confirm, also on 3.3.0

As far as I'm aware, changes in difficulty are purely up to the mission author. TDM itself doesn't adjust anything automatically. As for your other questions, I'll answer the ones I know something about. Others can chime in or correct anything that's wrong. pass Peeking through keyholes is a mission-specific thing that the author needs to implement not sure you can do any more than what you are already doing - that's about all I ever do not that I'm aware of I learnt as I went along. If you are thinking of trying it, I highly recommend Springheel's New mappers workshop. If it wasn't for those, I probably wouldn't have started. The modules he mentions in the tutorials are super handy for beginners. Just try to build something yourself, and you gain confidence as you go along, then you can decide if you want to shoot for something to release. My first FM took about 4 months, but that was working on it almost daily and it turned out a bit larger than I originally intended. But that was a result of gaining confidence as I went. I was a total n00b as well - no previous experience at all with this kind of thing (not counting a Quake map I did like 25 years ago).

OK thanks - you've helped my identify the problem regardless so I know what to look out for in the future now