Jump to content


Photo

DarkRadiant 2.5.0 available


  • Please log in to reply
55 replies to this topic

#26 LDAsh

LDAsh

    Member

  • Member
  • PipPip
  • 78 posts

Posted 26 January 2018 - 03:52 AM

I think, if I'm the only person that seems to care or even notice, and I don't even use it for TDM anyway, then better for you to spend your time on other things. Maybe if others chime in about it, maybe, but I will just use the keyboard shortcuts and external software to browse textures.

#27 greebo

greebo

    Heroic Coder

  • Root
  • 16010 posts

Posted 26 January 2018 - 05:39 AM

Well, I don't have a problem looking into it, but you need to give me some pointers. Tell me what texture you apply to where and how, or maybe give me a test map, this increases the chances of it getting fixed in the little timeframes I have for working on DR.



#28 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1087 posts

Posted 26 January 2018 - 07:17 AM

I think, if I'm the only person that seems to care or even notice, and I don't even use it for TDM anyway

 

*Facepalm*

 

So you're bothering the DR coder to fix a problem just for you, and that won't even result with you contributing something to the mod. Brilliant.


  • Anderson likes this

#29 greebo

greebo

    Heroic Coder

  • Root
  • 16010 posts

Posted 26 January 2018 - 09:39 AM

Keep in mind, while DarkRadiant's primary goal is to make TDM mapping easier, it still can be used for other game types (Doom 3, Quake4, Prey, XreaL, perhaps Unvanquished). Let's not shut ears to what folks from other communities have to say.

 

I don't bend over backwards trying to support every other game, but if changes fit in and are compatible with the code design and stuff, I don't mind input from mappers using other games. I try to support users in their workflow, since more active users means more feedback and testers for me, and I don't have too many of those.

 

As long as people are polite and somewhat grateful for my work, I'll try to do something for them, even if it's seemingly helping just one single person. It's my personal decision since it's my personal free time and I'm working alone. Not everyone will get what they want, of course. The words of some people might have more weight when wishing for features than others. I certainly listen to what veteran mappers have to say, especially the ones who have released one or more missions in the past. That said, I also listen to newcomers around here - I usually know the difference between trolls, greenhorns and someone who knows what they're doing, even if they didn't publish a TDM map yet.



#30 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1087 posts

Posted 26 January 2018 - 10:18 AM

That's fair :)

 

I wonder though what's your take on more interesting issues, like the way you select objects in 2D views. I mean, is there a reason DR displays objects by faces, not by wireframe?



#31 greebo

greebo

    Heroic Coder

  • Root
  • 16010 posts

Posted 26 January 2018 - 10:57 AM

Yes, the reason is that the selection intersection code is the same for both view types, and it happens to ignore backfacing planes.

#32 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 36896 posts

Posted 26 January 2018 - 03:29 PM

Yes, the reason is that the selection intersection code is the same for both view types, and it happens to ignore backfacing planes.

 

I have no idea how hard something like that would be to change, but I can lend my voice to Judith's that it does cause some awkwardness occasionally when trying to select and move around models that don't have a back face.


  • Bikerdude and Judith like this

#33 LDAsh

LDAsh

    Member

  • Member
  • PipPip
  • 78 posts

Posted 27 January 2018 - 05:36 AM

I wasn't trying to bother anyone, and feel sorry it was perceived that way.  I had a (clearly now false) assumption that these issues of mine might be shared among other mappers, especially considering how it's changed compared to how all other Radiants had always worked, since I first used QERadiant shortly after Quake II was released.  I wouldn't waste bytes unless I thought it would also benefit others.

The post I made with the big GIF on the previous page pretty much covers everything, you can see the button and its function, and how the texel scales are now inherited instead of automatically natural, but again, if I'm the only one who cares, then merrily merrily I deal with it and stop bothering people. :)


Edited by LDAsh, 27 January 2018 - 05:51 AM.


#34 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1087 posts

Posted 27 January 2018 - 05:28 PM

 

I have no idea how hard something like that would be to change, but I can lend my voice to Judith's that it does cause some awkwardness occasionally when trying to select and move around models that don't have a back face.

 

The only workaround I know so far is to select a model in perspective view and use Alt + arrow keys to position it.

 

IMO the biggest problem is that you can select some bigger brushes (caulk, skyportals etc) while trying to move smaller stuff. You won't even know that until you get a leak message. That's why I use layers to hide them. I have no idea how hard it would be to change that behavior, but basically every 3D software I know allows objects to be selected in 2D view only by clicking their wireframe. This way you wouldn't select and move anything else by accident.


Edited by Judith, 27 January 2018 - 05:28 PM.


#35 HMart

HMart

    Advanced Member

  • Member
  • PipPipPip
  • 628 posts

Posted 08 February 2018 - 07:17 PM

Hello greebo, don't know if this was already talked about but if you use the floating windows theme the 3D window stays up even when you diminish DR, and doesn't matter if you click out of it, the only way to hide it is to click on the windows 10 bar in the bottom right. 

 

Also if you arrange the windows including opening the extra entity list window and making it part of the work-space, if you close DR and open it again the entity window is not there and you need to open and move it to place again. 

 

Also would be hard to make it so when you chose entities to put them in a new layer, pops a window asking if you want to remove them from the default layer? Is not essencial but would save some clicks and imo would be cool option to have.

 

cheers and continue the great work.

 

DR 2.5 x64

 

Windows 10 x64 



#36 greebo

greebo

    Heroic Coder

  • Root
  • 16010 posts

Posted 09 February 2018 - 02:13 AM

Hello greebo, don't know if this was already talked about but if you use the floating windows theme the 3D window stays up even when you diminish DR, and doesn't matter if you click out of it, the only way to hide it is to click on the windows 10 bar in the bottom right. 
 
Also if you arrange the windows including opening the extra entity list window and making it part of the work-space, if you close DR and open it again the entity window is not there and you need to open and move it to place again.

The Floating layout has always been a bit problematic, as it's using a lot of Top-Level-Windows to make it happen, and those happen to behave differently on every possible window manager.
Not sure if I can fix any of this since I'm using wxWidgets, so I'm not directly accessing the Windows API. It was problematic in GTK+ too, so maybe it's just this Top-Level-Window approach itself which is causing troubles.

Also would be hard to make it so when you chose entities to put them in a new layer, pops a window asking if you want to remove them from the default layer? Is not essencial but would save some clicks and imo would be cool option to have.

Can you elaborate on this? What are the steps and when exactly should the popup window appear?

#37 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1087 posts

Posted 09 February 2018 - 02:31 AM

IMO that would be most annoying, if I had to dismiss a popup window like that every time I want to move stuff to another layer. That said, I think the distinction between Add to layer and Move to layer should be communicated somehow. First option adds selected entities to a defined layer but it also leaves them on the current layer, which is confusing. I bet most people would expect Add to layer to behave like Move to layer.



#38 greebo

greebo

    Heroic Coder

  • Root
  • 16010 posts

Posted 09 February 2018 - 03:48 AM

What would be a better name for those menu items?

#39 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1087 posts

Posted 09 February 2018 - 04:19 AM

This is only my experience, so please speak up if you have other ideas. What I would do is either:

 

1. Remove current Add to layer option entirely, and leave Move to layer only. Right now I can't think of a practical situation, where the former would be useful, especially since you can't expand the layer to see what's on it. Typically, objects can exist only on one layer at the time, at least in all other programs I use.

 

Optionally, to make it more consistent with other apps, I'd rename Move to layer to Add to layer. That's how this option is called e.g. in 3dsmax. But then again, this is my experience, other mappers please speak up if this is too confusing.

 

2. Leave Move to layer as it is, but rename Add to layer to something else, like Clone to layer, maybe? Maybe someone who really needs that function will have a better idea on how to call this.


Edited by Judith, 09 February 2018 - 04:40 AM.


#40 Destined

Destined

    Advanced Member

  • Member
  • PipPipPip
  • 1411 posts

Posted 09 February 2018 - 07:15 AM

I also stumbled over the names of these options, but after the first confusion I found the names describe what they do quite well. I frequently use "Add to layer", for transition points between two layers (e.g. the staircase between two floors, so the staircase is visible with either layer turned on), so I would not entirely remove the option. I am not sure what best to call it, as well. Maybe "copy to layer" conveys that a copy of the entry on the original layer is kept. I would keep "Move to layer" as this better conveys that the entry in one layer is completely transferred.



#41 HMart

HMart

    Advanced Member

  • Member
  • PipPipPip
  • 628 posts

Posted 09 February 2018 - 06:57 PM

The Floating layout has always been a bit problematic, as it's using a lot of Top-Level-Windows to make it happen, and those happen to behave differently on every possible window manager.
Not sure if I can fix any of this since I'm using wxWidgets, so I'm not directly accessing the Windows API. It was problematic in GTK+ too, so maybe it's just this Top-Level-Window approach itself which is causing troubles.

Can you elaborate on this? What are the steps and when exactly should the popup window appear?

 

Petty about the floating layout, is annoying but i can live with it. 

 

About the layers i don't know how much can i elaborate, i just used the layers feature for the first time and was confused why, even tho i hid the layer, the items where still visible, i then realized they where also on the default layer and i add to manually remove them from the layer, is like Judith says i'm just used to objects being unique to particular layers, in other tools, but i'm not against the ability of them to exist in more then one. 

 

IMO that would be most annoying, if I had to dismiss a popup window like that every time I want to move stuff to another layer. That said, I think the distinction between Add to layer and Move to layer should be communicated somehow. First option adds selected entities to a defined layer but it also leaves them on the current layer, which is confusing. I bet most people would expect Add to layer to behave like Move to layer.

 

Yeh, i agree pop ups are indeed annoying i just didn't think it well when i said it, but it could had a option to never show it again if needed.

 

Reading Destined reply i realized he is right, moving does indeed denote removing from a layer to another layer and adding denotes adding it to another layer (making a copy), but that needs people to really grasp well the English language, that is not my case, google helps me here more then anything and even tho is nothing greebo can control, people use other tools and sometimes even tho the stuff is well explained our "muscle memory" makes us assume things work here how it works on other places. :)

 

To solve this i'm also of the opinion that add could be renamed to copy so it becomes less ambiguous.  


Edited by HMart, 09 February 2018 - 07:00 PM.


#42 Abusimplea

Abusimplea

    Member

  • Member
  • PipPip
  • 276 posts

Posted 09 February 2018 - 07:57 PM

What would be a better name for those menu items?

The real problem seems to be that other modelling tools use names that are just plain wrong (calling a move an addition).

"Add to layer" should mean, adding an element to be (additionally) on a layer.

"Move to layer" should mean, that the element is removed from the current layer and added to the other.

"Copy to layer" should mean, that a duplicate of the element is added to the other layer. It implies that, after the action, there are two independently editable elements (the original and the copy).

 

The meaning should be obvious as the menu items are placed together.



#43 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1087 posts

Posted 10 February 2018 - 10:27 AM

 

The real problem seems to be that other modelling tools use names that are just plain wrong (calling a move an addition).

 

In virtually all modelling programs, objects can only exist on one layer, so that's not a problem, as there's no other command like that. Only DR allows objects to be on several layers.



#44 Destined

Destined

    Advanced Member

  • Member
  • PipPipPip
  • 1411 posts

Posted 10 February 2018 - 11:16 AM

Still, I would suggest "move to" and "copy to". That way, the apparently often used "add to" gets avoided and cannot lead to confusion.


  • Judith likes this

#45 ERH+

ERH+

    Advanced Member

  • Member
  • PipPipPip
  • 675 posts

Posted 10 February 2018 - 11:45 AM

I'm not even sure if its related to 2.5 but noticed that my old small scale f_s models deform and are virtually useless.

Try to make square cylinder at grid 0.5 and resize it down by .125: in one axis it make it lose one corner and become triangle shaped, resizing down in other axis it will lose two sides. Bigger models change shapes like this:

 

9rh7xFD.png


S2wtMNl.gif


#46 Abusimplea

Abusimplea

    Member

  • Member
  • PipPip
  • 276 posts

Posted 10 February 2018 - 12:18 PM

Still, I would suggest "move to" and "copy to". That way, the apparently often used "add to" gets avoided and cannot lead to confusion.

I would expect "Copy to" to copy the element. Imagine the surprise when a user - after hours of editing - realizes, that the original element got changed too.



#47 HMart

HMart

    Advanced Member

  • Member
  • PipPipPip
  • 628 posts

Posted 11 February 2018 - 12:32 PM

IMO to solve this problem the default behavior should be making the items unique to a single layer, unless chosen otherwise, if someone wants them to be in more then one layer at the same time, they say so or by coping the items to another layer or checking a checkbox in the layers window that could say "keep items in original layers", in that way imo there should be no confusion.

 

 


I would expect "Copy to" to copy the element. Imagine the surprise when a user - after hours of editing - realizes, that the original element got changed too.
 
I don't think that applies here because we all should know that we are working with single entities, we are not really copying or making instances here, the layers option is just a way to "group" entities for easy hid, that is why imo logically items should be unique to a single layer.  

Edited by HMart, 11 February 2018 - 12:48 PM.


#48 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1087 posts

Posted 13 April 2018 - 06:17 AM

I'm not sure if this is particle editor bug, or just me not using i correctly, but it looks like the editor preview and the ingame version require different values. In my case, I needed two particle cards, intersecting each other, like here:

obraz.png

 

But to make them look like that, I actually had to create something like this in Particle Editor:

obraz.png

 

Particle definition, in case I did something wrong:

	{
		count 				1
		material 			textures/do/fx/candle_flame01
		time 				999.000
		cycles 				0.000
		timeOffset 			0.000
		bunching 			1.000
		distribution 		rect 0.000 0.000 0.000
		direction 			cone 90.000
		orientation 		y
		speed 				"0.000"
		size 				"2.500"
		aspect 				"1.000"
		angle 				90.000
		rotation 			"0.000"
		randomDistribution 	0
		boundsExpansion 	0.000
		fadeIn 				0.000
		fadeOut 			0.000
		fadeIndex 			0.000
		color 				1.000 1.000 1.000 0.000
		fadeColor 			0.000 0.000 0.000 0.000
		offset 				0.000 0.000 0.000
		gravity 			0.000
		entityColor 		1
	}
	{
		count 				1
		material 			textures/do/fx/candle_flame01
		time 				999.000
		cycles 				0.000
		timeOffset 			0.000
		bunching 			1.000
		distribution 		rect 0.000 0.000 0.000
		direction 			cone 90.000
		orientation 		x
		speed 				"0.000"
		size 				"2.500"
		aspect 				"1.000"
		angle 				90.000
		rotation 			"0.000"
		randomDistribution 	0
		boundsExpansion 	0.000
		fadeIn 				0.000
		fadeOut 			0.000
		fadeIndex 			0.000
		color 				1.000 1.000 1.000 0.000
		fadeColor 			0.000 0.000 0.000 0.000
		offset 				0.000 0.000 0.000
		gravity 			0.000
		entityColor 		1
	}
}


#49 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19654 posts

Posted 13 April 2018 - 06:26 AM

File a tracker if you think its a bug fella.



#50 HMart

HMart

    Advanced Member

  • Member
  • PipPipPip
  • 628 posts

Posted 13 April 2018 - 04:00 PM

I've also seen something like that where the particle in DR particle editor doesn't behave exactly like it does in game, but i always assumed it was just like the 3D window, it also doesn't render stuff like the game does.
   






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users