ZeroRadiant 1.6 Development Thread

[AEon]

I need binaries to get this working right? Tried just using the .ini with my old bins, didn't really work...

Yes, you need new binaries. xpc was here a few hours ago, he fixed an issue with the undo (Ctrl+Shift+Cursor was not working on brush faces)... hope he has time later to merge in my commits. I wanted to release my own binaries today, but it's better for xpc to consolidate everything first and release the binaries himself.

As a side note looking through the code, this can be tested with any v1.6 version:

• I noted that

  Code: Select all

  {"NextLeakSpot", 'K', RAD_CONTROL|RAD_SHIFT, ID_MISC_NEXTLEAKSPOT, "menu_misc_nextleakspot"},
  {"PrevLeakSpot", 'L', RAD_CONTROL|RAD_SHIFT, ID_MISC_PREVIOUSLEAKSPOT, "menu_misc_previousleakspot"},

  the NextLeakSpot is bound to K and the PrevLeakSpot one to L... we all read from left to right, so the left key L should be the PrevLeakSpot and right key K the NextLeakSpot? Or am I not getting something? I am thinking of swapping the keys internally.
• I noted that the More End Caps, Bevels - Square End Cap function actually calls ID_CURVE_MOREENDCAPSBEVELS_SQUAREBEVEL and that More End Caps, Bevels - Square Bevel uses ID_CURVE_MOREENDCAPSBEVELS_SQUAREENDCAP... IOW the exact opposit.
  
  Alas I never could keep endcap and bevel apart... is Square End Cap presently creating an square endcap, and Square Bevel a square bevel?
  If the editor menu does the right thing, then it's an internal naming issue, if not then the IDs were simply accidentally swapped.
  Update: The editor was creating the correct content, was strictly an code internal variable naming issue.
• Presently you can change the grid via 1-0 *or* KP1-KP0... alas this binds two keys to each SetGrid<x> command, this "hack" prohibits rebinding. So I am wondering:
  1. I could create command name aliases named SetGrid<x>Alt (10 more commands), that let you bind the grid setting commands via two different keys... so you could set the grid via 1-0 *or* KP1-KP0 or 20 totally different keys.
  2. Or would those folks that *want* (Hipshot ) the set grid to work on the key pad, be OK with rebinding the 1-0 keys to KP1-KP0 (via shortcuts.ini), thus deactivating the normal 1-0 keys?
  Personally, even though it is a bit redundant, I'd actually want to have 1-0 *and* KP1-KP0 work and rebindable (case 1). This would be a relatively clean implementation, and less of a hack.
• Several of the menu entries are dead, or have functions that never worked (unfinished). I was wondering if it would not be better to comment them out (remove them from the editor menu):
  • File menu, Check for GtkRadiant Update (Web) - function unavailable.
  • Edit menu, Brush Scripts... - function not implemented.
  • Curve menu ,Sphere - was never implemented it seems.
  This is not really a big deal, but personally I doubt any of those will ever get implemented, so removing them from the active menus should be OK.

Note: Sorry, this post did turn out a tad colorful.

[Hipshot]

[*] Presently you can change the grid via 1-0 *or* KP1-KP0... alas this binds two keys to each SetGrid<x> command, this "hack" prohibits rebinding. So I am wondering:

1. I could create command name aliases named SetGrid<x>Alt (10 more commands), that let you bind the grid setting commands via two different keys... so you could set the grid via 1-0 *or* KP1-KP0 or 20 totally different keys.
2. Or would those folks that *want* (Hipshot ;)) the set grid to work on the key pad, be OK with rebinding the 1-0 keys to KP1-KP0 (via shortcuts.ini), thus deactivating the normal 1-0 keys?

Personally, even though it is a bit redundant, I'd actually want to have 1-0 *and* KP1-KP0 work and rebindable (case 1). This would be a relatively clean implementation, and less of a hack.
[/size]

I didn't get all that, a bit confusing, but I think you should do it the way you feel is the better. I want both keys too, I just want the possibility to rebind them =) I have great respect for people who doesn't want any changes to the keys in the editor.

And, yes, your colors, to many. My brain connects the colors wrongly when you have to many. I'm a bit retarded when it comes to that...

[AEon]

Latest changes:

• Previous Leak Spot is now bound to Ctrl+Shift+K, and Next Leak Spot to Ctrl+Shift+L (swapped keys).
• You can now freely rebind the SetGrid keys via shortcuts.ini... works quite well. Here a test:

  Code: Select all

  [Commands]
  SetGrid1Alt=F1
  SetGrid2Alt=F2
  SetGrid4Alt=F3
  SetGrid8Alt=F4
  SetGrid16Alt=F5
  SetGrid32Alt=F6
  SetGrid64Alt=F7
  SetGrid128Alt=F8
  SetGrid256Alt=F9
  ToggleGridAlt=F10
  SetGrid1=F1+Ctrl
  SetGrid2=F2+Ctrl
  SetGrid4=F3+Ctrl
  SetGrid8=F4+Ctrl
  SetGrid16=F5+Ctrl
  SetGrid32=F6+Ctrl
  SetGrid64=F7+Ctrl
  SetGrid128=F8+Ctrl
  SetGrid256=F9+Ctrl
  ToggleGrid=F10+Ctrl

[AEon]

AEradiant 1.6.x 2010-01-19 - Binaries

Alas, all the changes I added specifically concerning the shortcuts.ini cannot be tested without new binaries, so I am releasing my own. The code is not up to date to xpc's latest fixes, this means Ctrl+Shift+Cursor is still broken on brush faces. But you should be able to bind almost everything from the main menu to keys now.

Download:

• AEradiant-1.6.x-20100119.zip (6.86 MB) @ hugelaser.com

Installation:

• Make a duplicate of your working MFN radiant v1.6.x folder (or last full install of v1.6.1), name it e.g. AEradiant (just to keep versions clearly apart).
• Unzip the file into the folder, it should overwrite all the necessarily files.
• Create a shortcut to AEradiant\radiant.exe, and launch it.

Included:

• Latest
  • shortcuts.ini.sample16
  ... read it for details on were to install the shortcuts.ini (this is not trivial since the path is project dependent). The sample file lists all the new commands.

Changes:

• Almost all the main menu entries can now be bound to keys.
• ... (sorry too lazy presently)
• For other changes see my last few posts above in this thead.

I hope at some point xpc will merge my changes into the main editor tree, but this will probably take some time, so in the meantime those interested can test things out and give feedback if they like.

Feedback on nifty keys you are binding to "new" functions would be interesting to hear of. I might then create a "shortcurt.ini.q3w" (favorite file for the most popular bindings).

[xpc]

Delta NEWS Update (see http://forums.urbanterror.net/topic/196 ... bug-fixes/ for more details, downloads, etc.):

New:

• Added CTRL-SHIFT cursor keys to shift and CTRL-SHIFT PageUp/PageDown to rotate textures always by one grid unit (patch by AEon)
• Added Support to numeric keypad keys for changing the grid (patch by AEon)
• Add undo protection to texture rotation, scaling and shifting

Changes/Fixes:

• Possible fix for ghostet out "Misc / Select Entity Color..." menu (patch by AEon)
• [Windows] Fixed redundant empty lines in commandlist.txt (initial patch by AEon)
• Fix some torn off menus loosing their bindings in their label (functionality was still there)
• Lift undo limits: max undo = 2048, default = 1024; max undo memory = 16MB
• [Windows Vista/W7] Disable desktop composition (ported from NetRadiant rev. 311)
• Fix snapshots always being truncated to zero length

Those who have been using radiant-1.6.x-mfn-20100107-153436 before are advised to upgrade, as this version unfortunately introduced a bug were single selected face textures could not be shifted/rotated with cursor keys and newly created brushes could not be nudged with cursor keys.


What's the radiant-shift-mouse1-select.exe inside the archive ?


There's also something new in the latest zip archive I'm only going to announce here in the delta, as it's an exception: bundled is a separate radiant-shift-mouse1-select.exe inside, with these additional changes:

• Changed the mouse selection rectangle in vertex mode from filled to outlined
• Use this same rectangle when doing "select complete tall" brushes with the ALT-MOUSE1 drag combination (the drag combination was there, just no visual cue)
• Added "select complete partial" brush selection with SHIFT-MOUSE1 drag (like it's available in 1.5)

These changes required touching quite a bit logic and thus are not included in the main line, even not optional, because of their size. The idea is to have people test it separately, get feedback and eventually integrate it into the main line once it's stable.

Currently known issues:

• Whenever starting a new SHIFT or ALT -MOUSE1 drag, there's a visual glitch at the beginning with the rectangle. It doesn't affect the actual operation in anyway and disappears once the operation is done (or on the next window redraw)

[xpc]

Hi,

I hope people not get too confused with AEon and me posting around the binaries, but I'm positive that if people are motivated, good things will come out in the end. Although I'm not participating that much ATM, I'm reading and thinking about all of it what's posted here.

@Obsidian: I've integrated a patch from NetRadiant which should make manually disabling the Desktop composition on post WXP system unnecessary, hope you can test it (I can't, no such system available)

@AEon: have been very busy lately due work, I hope we'll catch us soon again on IRC . I haven't really integrated much of your work yet, because it takes time to verify all the changes and, especially, the re-organization (on the source level, e.g. the commands re-ordering) make future tracking of problems via history very problematic. I try to make source changes as minimal as possible and even try not to screw up whitespaces. Also I'm a bit reluctant to introduce minimal changes with no visible benefit or changing existing keys. Have to think about these things.

I'm trying to get more information on Windows 7 issues, e.g. from http://www.splashdamage.com/forums/show ... hp?t=20283 there's a description that simply saving maps does not work at all. Are people here experiencing the same? I'm not sure I can fix it anyway as I've no such system to test, currently I'm just doing fact-finding.

Thanks for everyone's feedback so far,
cheers

[obsidian]

xpc: Yeah, if you have the new binaries I can give them a run in Windows 7 and report any errors.

On Windows 7/Vista file saving:
I'm almost completely certain this has to do with Windows administrative security features (User Access Control) which prevents applications not running under administrative access from creating or modifying files within certain core directories like C:\Windows and C:\Program Files. That is why most applications have logs and setting files stored somewhere in C:\Users\[UserName]\AppData\.

In this case, if you have Quake 3 (or any other game) installed in C:\Program Files\Quake3\, Windows may prevent you from creating files in that directory unless the program is elevated to run with administrative privileges, or if you have disabled administrative security (not recommended).

Personally, I have my entire development directories stored on a completely different drive, so Quake 3 is on D:\GameDev\Quake3 and I have never run into this issue since the entire D:\ drive does not have any access restrictions.

[xpc]

xpc: Yeah, if you have the new binaries I can give them a run in Windows 7 and report any errors.

Please, the binaries can be reached via http://forums.urbanterror.net/topic/196 ... bug-fixes/ (linked from the above post), thanks!

[obsidian]

The good: I no longer need to disable desktop composition, it does so automatically.

Get an error, "WARNING: Could not delete". It's a bit cryptic so I don't actually know what it's doing. Clicking okay and it looks like I can safely ignore it. It only appears if Radiant is installed in Program Files and running without administrative privileges, so again, something to do with Windows UAC. Perhaps trying to delete old log files?

From the open CMD window I get some errors. More UAC problems with local.pref and game.xlink. Global.xlink is missing from the installation, I can probably copy it from another install. I think the global.xlink is just the links file in the help menu to various resource documents. Not critical:

I/O warning : failed to load external entity "file:///C%3A/Program%20Files%20(x8
6)/GtkRadiant%201.6.1/installs/Q3Pack/game/local.pref"
I/O error : Permission denied
I/O error : Permission denied
I/O warning : failed to load external entity "file:///C%3A/Program%20Files%20(x8
6)/GtkRadiant%201.6.1x/global.xlink"
I/O warning : failed to load external entity "file:///C%3A/Program%20Files%20(x8
6)/GtkRadiant%201.6.1/installs/Q3Pack/game/game.xlink"

Also in the console (and it is indeed missing from default install):

Looked for a 'C:/Program Files (x86)/GtkRadiant 1.6.1/installs/Q3Pack/game/shortcuts.ini' keyboard shortcuts file, not found

Also as long as Radiant is installed in C:\Program Files (Or "C:\Program Files (x86)" in Windows x64), or you are running it without administrative privileges, you can't edit the preferences file.

Reloading global prefs from file
Opened XML property file: 'C:/Program Files (x86)/GtkRadiant 1.6.1x/global.pref'
XML I/O
XML warning :
XML failed to load external entity "file:///C%3A/Program%20Files%20(x86)/GtkRadiant%201.6.1/installs/Q3Pack/game/local.pref"

XML property file 'C:/Program Files (x86)/GtkRadiant 1.6.1/installs/Q3Pack/game/local.pref' invalid/not found, creating blank properties tree
OpenGL texture compression enabled
ATI bug workaround disabled
Saving local.pref with default pref values
XML Permission denied
Error occured while saving global prefs file 'C:/Program Files (x86)/GtkRadiant 1.6.1x/global.pref'
XML Permission denied
Error occured while saving local prefs file 'C:/Program Files (x86)/GtkRadiant 1.6.1/installs/Q3Pack/game/local.pref'

I would recommend following what GtkRadiant 1.5 does and store program data (q3.game, global.pref, prtview.ini, radiant.log, etc.) in C:\Users\[UserName]\AppData\Roaming\RadiantSettings\[Version#]\ (shorthand: %AppData%\Roaming\RadiantSettings\[Version#]\) on Windows Vista and Windows 7.

[wattro]

I'm trying to get more information on Windows 7 issues, e.g. from http://www.splashdamage.com/forums/show ... hp?t=20283 there's a description that simply saving maps does not work at all. Are people here experiencing the same? I'm not sure I can fix it anyway as I've no such system to test, currently I'm just doing fact-finding.

Thanks for everyone's feedback so far,
cheers

Thanks for the updates =)

I'm one of those people with a windows 7 machine that can't possibly save (except for the painful saving into the autosave.map work-around).

I've tried to save in folders with no spaces, save on other drives, run as administrator, fiddled with admin settings... all with no success.

Any fix for this would be awesome, and I agree with obsidian that it seems admin-related.

[obsidian]

wattro, where is your Quake3 installation folder located? I suspect C:\Program Files\Quake III Arena?

Right-click on radiant.exe and choose "Properties" > "Compatibility" tab and under "Privilege Level" check the "Run this program as an administrator" and see if that helps.

I don't this should be really filed as a bug, because not being able to make changes in protected directories is a "feature" of Windows Vista/7. It makes sense 99% of the time. Ideally, you should have a Q3 development install somewhere else on your computer.

If you have the time, maybe you could see if you can reproduce some of the Windows 7 bugs:
http://github.com/mfn/GtkRadiant/issues/labels/windows7


One other bug is that when saving a map, the ".map" extension is omitted by default, I have to manually type "mapname.map".

[obsidian]

Posted this on the bug-reports, but thought I should share here too. Here is the comparison chart for the GtkRadiant selection controls.

[lvlshot]http://robotrenegade.com/temp/radiant16/gtkradiant-selection-controls-comparison.png[/lvlshot]

Updated first post of this thread with links to files that people would need if they want to help with bug testing.

[wattro]

wattro, where is your Quake3 installation folder located? I suspect C:\Program Files\Quake III Arena?

You might find this funny, but I don't have the actual quake3 (or any other games) installed on my laptop. Radiant's install did set up some files in C:\Program Files\Quake III Arena

Radiant is installed in C:\Program Files\GtkRadiant-1.4

Also, did as you suggested (I've run as administrator before) with no luck. Even tried saving C:\mapname, C:\mapname.map, D:\mapname.map.

[xpc]

Updated first post of this thread with links to files that people would need if they want to help with bug testing.

That's nice! The last link, "report bugs on the mfn/GtkRadiant SVN", could be improved in two ways I think. It's not "SVN" but it's the github issue tracker and the link specifically links to issue 20 .. maybe it could be just linked to the issue tracker overview. thx

[AEon]

Yeah, stumbled over those two things as well... fixed them.

[AEon]

Hmm... not really sure how to continue here... my own radiant branch has already diverged from MFN's... and integrating his main branch's changes should not "simply" patch his changes into my version, this would lead to a total mess. On the other hand I cannot or should not continue working on my own branch because that would lead to more and more code divergence...

Does not seem anyone is using or testing the expanded shortcut.ini functionality, i.e. letting you bind any menu entry to a key, finally.

[Hipshot]

I am!
But I don't have time 24/7 anymore to build. Sometimes not even a single hour a day... it's weekends mostly these days.

Your shortcut ini fix and the texture shiftting thingie is really good. If it can't be merged with xpcs then I might as well use yours for these fixes only.

But this was pretty much bound to happen....

[Pipex]

Could a lightning preview mode be added for jka too? Please

[xpc]

Just wanted to say Hi again to everyone who participated here about the radiant improvement effort I was working on. I was abruptly pulled away due private issues and slowly catching up with things going around outside in the world, but it's unlikely that I can continue the work I started anytime soon.

This is partly due private reasons, partly also that improving the code base, based on 1.6, takes an enormous amount of time I simply cannot further afford.

I made the decision to work off from ids 1.6 trunk because it was the last public thing which seems to have had been worked on by id and it seemed natural that way for me.

Currently I think that technically the effort done for NetRadiant, based on 1.5, is already far more mature then anything I produced and if I would find time to spend on radiant in the future, I'd rather invest that into NetRadiant code base.

I'm sorry if people now feel upset because you also spent your time filing reports, creating patches and discussing things with me on IRC, but I wasn't really prepared what happened to me in RL.

[^misantropia^]

No hard feelings, these things happen. And it wasn't like we were paying you for your time, right?

[CZghost]

I need Radiant to create Quake Live maps, or edit them (I prefer first). I also want edit my maps into QL format, but GTK Radiant 1.5 isn't for this creations I think. So I want try ZeroRadiant in mind, that can make maps especially for QL.

Know somebody, that ZeroRad. is or isn't for QL editing? Where can I download it?

[obsidian]

The formats for Q3 and QL are the same aside from some small trivial differences: TGA vs. PNG textures with alpha and encrypted PK3 files.

GtkRadiant 1.4, 1.5 or 1.6 will all work. "ZeroRadiant" (1.6) is just the development (beta) branch of the editor and is based on the 1.4 code.

Files are listed in my signature.

[dghost77]

I've downloaded the svn repo of zeroradiant and I was going through the folder and I wanted to take a look at the documentation with doxygen under the \ZeroRadiant\Doxygen_files\ folder. When I open the file : doxygen_index.html from that dir, I get redirected to a file that doesn't exist under the Doxygen dir. ZeroRadiant/Doxygen_files/html/index.html. That html folder doesn't exist in the repo.

[Pat Howard]

Can it be that v1.4 of GTKradiant is *extremely* unstable concerning models? I have been testing copy/paste between POM and my map regarding vegetation as a test, and the editor keeps on crashing, after moving the plants around a bit. WTH?

Sock, did you use v1.4 back when you were building POM?

I was hoping to be able to properly align models in v1.4 but these crashes make it almost impossible ... *range*

AEon: did you ever figure out what was causing sock's plant models to be so buggy? i am trying to use them now (copy-pasting from his plants_soc_final.map) but they keep crashing the editor in both 1.4.0 and 1.6.4. i usually can't get away with more than one or two crashes before my whole .map file is corrupted and i can't even open it anymore.

this is really shitty because i was planning on making heavy use of those plants for my map's theme. i noticed the models are using some commands that i am not familiar with, such as remapping (which is actually quite useful), and modelscale_vec. maybe this could be it? i've never seen a model crash radiant like this before.

[AEon]

Yeah, the remapping was one of Sock's clever tricks... I used it on boxes as well IIRC.

Alas, if you want to use models and properly orientate them I'd suggest you also install Radiant 1.5, that is better with model rotation (interactive), and IIRC does not crash as often. I am always very suspicious of changing the editor on a project, fearing texture offsets and the like... and there seemed to be some between 1.6 and 1.5.

Idea: You could load your map into 1.5 place the models where you need them... and then save that out as a file (new file name version, just as backup). Then delete all geometry keeping only the models (Shift+A helps select all of a kind)... save only the placed models under 1.5. And then go back to 1.6 load your map, then load/merge the 1.5 models into your map. That way texture issues should be avoided, but your models are in there.

As long as one does not move around models too much, 1.6 from then on should work fine.