Frost_Salamander
-
Posts
898 -
Joined
-
Days Won
26
Posts posted by Frost_Salamander
-
-
56 minutes ago, Wellingtoncrab said:
I am having this exact issue as well. I have to restart DR periodically to keep the copy/paste shader function working properly.
It's been fixed for the next release it looks like. As a workaround, make sure the 'Media' tab isn't selected when you do the 'copy shader' operation: https://bugs.thedarkmod.com/view.php?id=6151
-
1
-
-
44 minutes ago, SeriousToni said:
There's a favourite feature?
Yeah for entities, models and textures. If you right-click them there is an 'add to favourites' option. Then the next time you go to use them, you can click 'show favourites' instead of 'show all' in the chooser window, or use them from the Favourites tab in the properties window.
-
1
-
1
-
-
6 minutes ago, MirceaKitsune said:
Not that badly, sorry if I'm overthinking it. It's mostly that the same window models are used for static decorations that go into nothingness, as well as interact windows connecting buildings. What did help is functional windows were left semi-open by default so you could see them, that made it better.
nah no worries, I'm probably the one overthinking it. Any and all feedback is appreciated, just want to make sure I understand it!
-
1
-
-
Feature request: expand favourites trees
I'm presuming that the benefit of the favourites feature in DR is to save time and clicks by presenting them in a separate view. However whenever you click the 'show favourites' radio button, the tree view is always collapsed, meaning you have to search/expand/click anyways. And that's if you can remember what is in your favourites.
Suggest that the favourites trees be expanded by default (or alternatively, an 'expand all' option). it would be much easier to see at a quick glance what's in there, and there would be less clicks involved. I don't know how having hundreds of favourites would affect it - but I'm guessing most people have a couple dozen of each type at most?
I kind of realised I don't use the favourites much, and this is one of the reasons why.
-
ok thanks. Yeah the first point is probably too specific to that single group use case.
I'll raise the other 2 things in the tracker. If feature 2 is implemented, it would make adding stuff to a group easy anyways and feature 1 would be almost redundant.
-
I'm going to ask about a couple of things here because they are related to grouping - feel free to tell me they should be part of a different discussion/feature instead. Perhaps they may factor into how this works.
- with selection focus on, grouping information is ignored. Makes sense as you want to manipulate the individual objects. But what if you want to clone one of the objects and include it in group (if it is in fact a group you are focused on)? Say you are working on a staircase and need to add a couple more steps. Could cloned objects just be automatically added to the group?
- I kind of wish there was an 'add to group' or 'merge groups' command in the mouse context menu. Unless you want a bunch of nested groups, you need to select all the objects, then 'ungroup' followed by 'group' to do this.
- (probably a separate thing but will ask anyways): Is it possible to disable drag select in the camera view? Frequently I'll be selecting objects one-by-one in the camera view to add to a group. The mouse will drag very slightly and all of a sudden loads of stuff in the background will get selected. You then have to press escape and start all over again. Gets tedious.
-
1
-
53 minutes ago, greebo said:
As a workaround I can suggest pressing Alt-Tab since that will re-focus the ortho views to the selection OR the focus area if nothing is selected. So hitting Ctrl-F and then Alt-Tab should bring the ortho view into place.
Did you mean Ctrl-Tab (next view)? Because that worked. Alt-Tab for me switches between windows (in Windows 11).
55 minutes ago, greebo said:What about aligning the ortho view automatically to the focus once activated? Is that always desirable?
Yes this is what I suggested above ("..automatically focus the ortho view onto the focus group"). I think I would want that - but maybe need to find out of everyone else would want that as well.
-
3 hours ago, greebo said:
I got a feature in the works, allowing to select and manipulate only "focused" items, which should hopefully be useful for manipulating grouped items without having to disband the group. There's a demo video here:
https://www.darkradiant.net/images/videos/selection_focus.mp4
It works like this:
- You select some items in the map. It doesn't matter what it is, it can be a group or many groups or just two unrelated brushes.
- Hit Ctrl-F to enter focus mode (the command is called "ToggleSelectionFocus" if you want to bind your own shortcut)
- Your actions will be restricted to just that selection
- You cannot select other items that are not in the group (unless you use Layer or Filter selections, or Invert selection)
- You'll get a visual indication about the focused items in the ortho view
- Grouping information is ignored while in focus, you can select single parts of any group
- You can select, move, rotate, delete, edit vertices etc.
- Hit Ctrl-F again to exit, or (maybe more intuitively) hit ESC until you left the focus
- The previous selection (before entering focus) is now active again, you can proceed manipulating that
I'd appreciate if you folks could have a go and try it and then give feedback about it. There's no release yet, but you can grab a portable release from Github: https://github.com/codereader/DarkRadiant/actions/runs/3403010325
This is super-handy, loving it already. A couple of minor things:
- I couldn't download the release from Github until I signed in - does everyone have a Github account?
- ToggleSelectionFocus wasn't bound to Ctrl-F by default - it was unbound.
- When you enter selection focus mode, because all the colours change to white/black it sometimes hard to find the focus group in the ortho view if there is a lot of stuff in the map. I see the light highlighting around it, but it doesn't help that much. If it's an existing group of items I want to manipulate, I would probably select it using the camera view, and manipulate it using the ortho view, meaning I have to find it. Some suggestions to help might be to change the focus group items to a brighter colour (blue/red/green?), or automatically focus the ortho view onto the focus group. I'm using 'Super Mal' colour scheme as well which is grey background, so maybe that combination of black/white/grey doesn't help.
I've only just started using playing around, will leave more feedback in future comments if I have any. But yeah this is great!
-
1
-
11 minutes ago, Wellingtoncrab said:
I feel you there!
I have found attempting to participate at least a very good way to get something focused and rolling even if it is somewhat undermined by the inevitable impossibility of it ever being ready in time.
Which is to say participating in spirit is still participating in my book!
Well the main problem is really that it's kind of big, and I'd have to totally change the 'story' to fit with the theme.
Maybe I'll 'participate' by downloading and using your cobble pack regardless
-
1
-
-
26 minutes ago, MirceaKitsune said:
You need to guess which windows open and are required to go through
That was a critique during beta, so I went around and opened most of the openable ones. Was it really still an issue?
-
33 minutes ago, Wellingtoncrab said:
-=CONTEST COBBLER PACK=-
Need a SPOOKY street for your DRACULA or WOLFMAN?
Mileage may vary but we got a variety of sepia stained sooty, grungy Pavers, Kerbs, Cobbles & More!
I'll probably never finish my contest mission in time, but hopefully this helps you finish yours!
wow these look great! I always wished there were more/better choices for these in the base game. I have an FM in progress but there is no way it'll be ready for the contest, I'm too slow :-(. One of these days maybe the timing will be right.
-
7 hours ago, MirceaKitsune said:
A very nice and quality FM. The design is definitely interesting: I like how navigation is based on jumping between buildings and going through spaces connecting different locations, even if some are difficult to find and I needed guidance from here a few times. It's a difficult FM in general as spaces are tight and well lit, it's one of the maps I couldn't imagine going through without reloading nor getting spotted at any time.
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
-
1
-
-
4 minutes ago, datiswous said:
Hi, ultra newbie question here:
If I make a visportal and I stick it in an opening in a wall, but the direct surroundings, which touch the visportal are an entity, does this work for sealing? Or does the visportal have to be set toward a brush to work?
And I guess for patches the same?
The face of the visportal with the 'Vis Portal' texture must be touching a brush on all sides. Entities and patches don't seal.
-
1
-
-
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.
-
1
-
-
11 minutes ago, joebarnin said:
I've seen a technique for doing this, in The Painter's Wife. I borrowed the code myself for a WIP. The technique is basically to override the multistateposition object (defined in tdm_movers.script) and implement the onMultiStateMoverLeave method, which stops the elevator before it gets going, tries to close the door(s), and then starts up the elevator again. The code is something like this:
void multistateposition::onMultiStateMoverLeaveEffector(entity mover) { door.setFrobable(0); if (door.IsOpen()) { door.Close(); tdm_elevator elev; elev=mover; sys.waitFrame(); elev.stopMoving(); while(door.IsOpen()) //wait for door to close { sys.waitFrame(); } elev.activate(elev.lastTriggeredBy); //once door has closed, set the elevator in motion once more door.Lock(); } else { door.Lock(); } }Take a look at that FM to see how it's done.
ah nice - I've already overridden that script object for a different purpose (but for the arrive event). Thanks!
-
2 minutes ago, SeriousToni said:
Gosh.. Since when did the image upload in the forums stop working... Anyway.. I tried out the new view setup - thanks a lot for all the advices.
I positioned a little "attribute bar" to the right. So as soon I select an entity I can see its spawnargs. However what did not matter as it opened as a new window before does come to light now that it is just a small bar: The size of the spawnargs view is really small and there's lots of empty space that could be used for it instead - however I cannot enlarge the attribute / value part of the window - it just stays by a few rows. Maybe I'm doing something wrong - maybe it is a possible new feature in the next update - here is the screenshot: https://ibb.co/PcSmFT2
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.
-
1
-
-
11 minutes ago, AluminumHaste said:
Ok I tried the same two spawnargs, stop when blocked to 0 and interruptable to 0, but I still don't take damage.
Interuptable 0 means players can't frob the door to stop it.
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.
10 minutes ago, AluminumHaste said:Might be better to use a script and area brush to see if the player is still in the way of the doors, then set them to close when they leave.
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...
-
6 minutes ago, Geep said:
Also, maybe try setting def_damage to "atdm:damage_none"
I thought you were onto a winner here, but nope, still does damage
-
47 minutes ago, AluminumHaste said:
I just set up sliding doors to auto close and stood between them, they stopped upon touching me, and I didn't take any 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.
-
20 minutes ago, Geep said:
Does setting the following on the doors help?
"push_player" "1"
Maybe combined with setting the auto_close_time to slightly different values on the 2 doors
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.
-
20 minutes ago, SeriousToni said:
Just download the Windows installer and use the same directory?
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.
-
1
-
-
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?
-
1
-
Newbie DarkRadiant Questions
in TDM Editors Guild
Posted
Does anyone know what this means (from DMAP output):
Is it bad? It's not a warning, just informational it seems. I have a feeling it's something to do with some irregular worldspawn shapes, which I have but try to minimise. Also is there a way to track down what that 'zone' is?