Quake3World

Hipshot wrote:Another very annoying bug, you guys must as well have come across this many many times. That textures offsets them selves a unit or two, sometimes by 10th of a unit or so. Very very annoying, could this be fixed? I guess it has something to with rotate and the target coordinates or something... don't really know, I just know it's a pain on small things...

AEon wrote:Hmm... I noticed even under v1.4 that texture alignment on small brushes, even with texture offset/rotation lock turned on will simple not stay locked properly. Hipshot, maybe you could create a mini-map (.map) file that let's us reproduce the issue. And also add a step by step list that would let us try this out. That should help xpc track down the problem.

My guess is this is some sort of precision cropping happening (i.e. the number of "significant" float digits get cut off somewhere in the code. Or that a conversion from an initial double to float happens).

Hipshot wrote:# Paste to camera doesn't work (didn't work in 1.4 either) or I'm using it the wrong way? alt-v?

//  {"PasteToCamera", 'V', RAD_ALT, ID_EDIT_PASTEBRUSHTOCAMERA, "menu_edit_pastebrushtocamera"},
//	Alt+V (0x02) would open the View menu, if that worked... using Shift+V (0x01)
  {"PasteToCamera", 'V', 0x01, ID_EDIT_PASTEBRUSHTOCAMERA, "menu_edit_pastebrushtocamera"},

Hipshot wrote:# Doesn't work to change the grin size on the numeric keypad.

  {"ToggleGrid", GDK_KP_0, 0, ID_GRID_TOGGLE, "menu_grid_toggle"},
  {"SetGrid1", GDK_KP_1, 0, ID_GRID_1, "menu_grid_1"},
  {"SetGrid2", GDK_KP_2, 0, ID_GRID_2, "menu_grid_2"},
  {"SetGrid4", GDK_KP_3, 0, ID_GRID_4, "menu_grid_4"},
  {"SetGrid8", GDK_KP_4, 0, ID_GRID_8, "menu_grid_8"},
  {"SetGrid16", GDK_KP_5, 0, ID_GRID_16, "menu_grid_16"},
  {"SetGrid32", GDK_KP_6, 0, ID_GRID_32, "menu_grid_32"},
  {"SetGrid64", GDK_KP_7, 0, ID_GRID_64, "menu_grid_64"},
  {"SetGrid128", GDK_KP_8, 0, ID_GRID_128, "menu_grid_128"},
  {"SetGrid256", GDK_KP_9, 0, ID_GRID_256, "menu_grid_256"},

Hipshot wrote:Does the lock button in the surface inspector need to be enabled by default? Isn't that just stupid, why is it even there?

Hipshot wrote:# Isn't it possible to add a button that makes you texture nudge by one(1) unit no matter what the Step value says? Like also holding CTRL when nudging, so it becomes ctrl-shift-[direction arrow]

Hipshot wrote:Instead of displaying the path to the level in the task bar, show the name of the level? Very practical if you have more than one instance open (Yes I know about the tool tip thingie).

Hipshot wrote:Isn't it possible to add a button that makes you texture nudge by one(1) unit no matter what the Step value says? Like also holding CTRL when nudgeing, so it becomes ctrl-shift-[direction arrow]

• mainframe_aerad_1u_texshift.zip (57.7 KB) @ hugelaser.com

• SelectNudgeDown key shortcut entry, moved to where SelectNudgeLeft and the others reside.
• Added the new Ctrl+Shift+Cursor shortcuts.
• New functions (e.g. OnSelectionTextureShiftleft1u) and calls to them added.
• Removed dead variable *b2 in OnSelectFuncGroup() to fix compiler warning.
• Updated header file.
• The keys on the numerical keypad 1-9 and 0 now also change the grid.

AEon wrote: xpc,
I used your latest code and merged my changes into the mainframe.cpp and mainframe.h files: ...

• Protected more operations via undo (nudging selection, changing entity key/values from dialog)
• Clear undo history when loading or creating a new map.
• Always mark a map as modified after an undo-able action has been recorded.

• Disable color scaling when changing entity color from color chooser.
• Sync main window title with undo/redo and on disk saved states.
• Don't clear undo history when opening preference dialog.

Hipshot wrote:Maybe there could be a marquee box when using alt-mouse1 to drag select. Now there is none and there was no one in GTK14 either... very strange that there is no... an idea is to give it a blue color compared to the regular red one, so you know you're not just draging out a brush...

• Set Grid Size via NK Pad 1-0 additionally
• Ctrl+Shift+Cursor Offsets Textures by 1u

xpc wrote:Why not let (the proposed new) mouse1 drag select behave like select partial tall ?

Hipshot wrote:Here's a test level:
http://zfight.com/misc/files/q3/coord_test.map

It's units I actually use for my current level, but the lamp fixture uses compatible textures here.

If you select these and duplicates them, both units will have various errors with the some faces.
Most notable is the angled lamp, which will become very strange when duplicated.
But it's totally random, doesn't happen all the time, not the same error, etc, sometimes it works doing a duplicate and then another one, etc, super random, hard to repro.

• Loaded your map into GtkRadiant v1.6.x MFN (xpc's latest build).
• Texture lock for shifts and rotations had been already activated from a previous session.
• Using Ctrl+Shift+LMB selected each of the 2 brush groups.
• Used Clone (Space), and Copy/Paste, and nudged the groups in the XY View (LMB-drag).
• I also used NK+, NK- to change height, and even rotated them via rotate icons (90°).
• I saved the file and reloaded it.
• I then loaded the map in v1.4 and did some more tests.

xpc wrote: I think adding a marquee box is absolutely necessary.

Why alt-mouse1 and not simply mouse1?

I see the behavior of alt-mouse1 is, that you've to "fully" select objects.

Why not let (the proposed new) mouse1 drag select behave like select partial tall ?

I'm suggesting this not out of creativity, but because learned it from 1.5 and it speeds up things (unless I missed something obvious that we can't map mouse1 drag select :/ ).

AEon wrote:I am not quite sure about this... it might conflict with normal dragging... but I am guessing the code will check for anything selected, if so, no LMB-drag will work.

Hipshot wrote:Yea I feel that too. But it's like, I mean, xpc is doing his things and now AEon his things, so it's a fork from a fork, it's bit annoying... because it's a bit personal, I can see that xpc don't wanna do everything everyone else wants, the same with AEon. It's a personal interest (I guess (??)). Because Now I use Aeons version but then I don't get XPCs changes that he's doing.

Hipshot wrote:Yea I feel that too. But it's like, I mean, xpc is doing his things and now AEon his things, so it's a fork from a fork, it's bit annoying... because it's a bit personal, I can see that xpc don't wanna do everything everyone else wants, the same with AEon. It's a personal interest (I guess (??)). Because Now I use Aeons version but then I don't get XPCs changes that he's doing.

• Yesterday right into this morning xpc and I spent setting up git (Source Control System) to make it work for me. Both of us (me a lot more obviously) are still learning to get more out of http://github.com, so this took up a lot of time.
• xpc is only human, just because I happen to have added some commits (coded out version change suggestions, basically), does not mean that xpc will not add them in his main (the real) branch. It's just a matter of time.
• I am *not* planning on my own version - it is only a test to try out ideas. The primary version will be that of xpc. And I don't really see us having different ideas, those are more or less just a discussion of possible implementations.
• As ^misantropia^ pointed out the GitHub is set up for me to "suggest" code snippets, that xpc can then very easily add to his main editor build (after some testing), so we are *not* diverging in code per se - just temporarily.
• For those confused about how Hipshot could test "my" version, I PM'ed it to him as a favor, though I do not really want to do that on a regular basis. It's not really a public version, the public versions come from xpc's releases. Personally, I don't fully trust my version, because I am still seeing disappearing clip brushes from time to time on map load.

• The changes are listed in the NEWS file when you download the latest binaries (see xpc's post above), and also mentioned on the 19651-zeroradiant-featuresbug-fixes page where you also get the binary updates.

• Yes, it is getting a bit confusing, largely due to my feedback in this thread, alas.
• It would greatly help if those interested in suggesting ideas would get an account (for free) over at github.com to then explicitly suggest the idea on the mfn/GtkRadiant/issues page - by simply hitting the Create Issue button.
• Then the ideas can be suggested and discussed on a per idea basis there, making it easier to keep suggestions apart, and also get an overview what is planned.
• I had a talk with xpc, and I will be updating the "Issues" list on that page with the various suggestions from other folks and those I made - from *this* thread, spread out over separate issue posts there.

Hipshot wrote:AEon, your texture shift change was excellent, incredibly usable feature [...]. The thing is that now I don't need to go into the inspector and change the step value to 1 to adjust a texture slightly, I can keep it at 8 and just nudge it a bit when ever I want.

• Setting the Grid Size should be defining the texture shift stepping (much like nudge Alt+Cursor works)? I thought that when you set the grid to 1u (1-key), that the texture shifts would then also be 1u (via normal Shift+Cursor). And that this used to be an option in Prefs. Under v1.6 I don't see any of this though. In theory implementing this could make the Ctrl+Shift+Cursor redundant, because you only need to change grid to set the shift you prefer, e.g. 1u, 2u, 4u, 8u...
  
  Update: As a test I implemented this for Ctrl+Shift+Cursor, now the texture shift is defined by the currently set grid size (1-key to 9-key). Seems to be quite convenient, question is would you folks out there want to change the grid size and back often, for this to work?

• That brings up the idea, of creating such a key combo, Ctrl+Shift+PgUp/PGDn, to fine-tune the texture rotation. Question is, would 1° be a fine enough rotation change, or go to 0.5°?
  
  Update: Implemented... the smallest rotation angle is 1°, if you set smaller values they are reset to 0 (rotation angle is an integer in code).
  
  Reminder: You set the rotation angle for Shift+PgUp/PgDn via Prefs (P-key), Interface, Editing, Rotation increment, 45 (default)

• Seems that Ctrl+Shift+keys can be developed into a set of texture manipulation related fine control shortcuts. So far we have Shift (GridSize controlled) and Rotation (1°), IMO trying this with Scale might get ugly? Hmmm.