ZeroRadiant 1.6 Development Thread

[sock]

@Aeon, I stopped running the latest version of GTK years ago, I got sick to death of stupid things breaking and people submitting changes to the SVN editor base and screwing the default behaviour. I only use GTK 1.3.8.ET version (I think this is the same as 1.3.13) because I know what to expect.

[AEon]

Hmm... I use NK+ and NK- (height adjustment), and Alt+Cursor (movement) for items a lot, hitting those keys quickly when moving a model seems to crash the editor after some time. Movement via mouse drag in the 2D-views seems to be less of an issue. Copy/paste from one editor to another one, models + light entities, moving them around in the 2nd editor *very* quickly crashes it. After I had moved several plants into my map, cloning those, things have quietened down a bit, so I can work just barely. I save the map file a *lot*.

Hipshot, lucky you. Maybe it's the shaders on the models that are putting the editor on "edge" (though I doubt it). Or it could be that running 2 instanced of v1.4 is making them unstable. Or its my *really* old ATi drivers (about 2 years old on an ATi X800 Pro).

Well at least the plants are getting into AEdm7... after years of rock stable editing with v1.2.13 this is really a shock... welcome back to my Amiga days where it was totally normal for the machine to crash 5-6 times per day ... sigh.

[xpc]

Hi,

I'm an Urban Terror player and got interested in mapping some time ago and was also quite shocked with all the *radiant versions out there and their varying degree of fetures/stability/interface behavior.

I eventually settled on using GtkRadiant 1.5 but found some shortcomings and realized GtkRadiant 1.6 aka. ZeroRadiant had them fixed.

However ZeroRadiant in turn lacks other things I was so accustomed from 1.5 and eventually started out to bring some parts of those worlds together.

My fork of ZeroRadiant is on http://github.com/mfn/GtkRadiant , all changes I'm doing are in the NEWS file at http://github.com/mfn/GtkRadiant/blob/mfn/NEWS .

I've a more detailed post on the Urban Terror forums ( http://forums.urbanterror.net/topic/196 ... es-from-15 ) which also explains where to get Windows binaries or how to get things compiled on Linux.

If anyone has a reproducible bug or feature suggestions let me know. Either post here, in the Urban Terror forum or enter them in the github issue tracker at http://github.com/mfn/GtkRadiant/issues . I can also be found on irc.enterthegame.com #urbanmappers (look for rfx).

[xpc]

Hmm... I use NK+ and NK- (height adjustment), and Alt+Cursor (movement) for items a lot, hitting those keys quickly when moving a model seems to crash the editor after some time. Movement via mouse drag in the 2D-views seems to be less of an issue. Copy/paste from one editor to another one, models + light entities, moving them around in the 2nd editor *very* quickly crashes it.

I tried to reproduce this but wasn't able to (Windows), tried to move one or many entities, height adjust and nudge them with alt cursor all the way, no avail.

When quickly mixing various methods (I think mouse and keyboard) I saw the following message in the console: Undo_Start: WARNING last undo not finished., but no idea if hat hints something to a crash.

I fixed a crash bug with entities and texture remapping, but this does not sound related and the crash only occurred when the application was shut down or another map was loaded.

[AEon]

xpc,
first off, great that you are working on the editor. I never actually tested ZeroRadiant because I never was able to find a link to binaries...

The model nudge issues only happens to me with v1.4, v1.5 or v1.2.13 never show this problem. As Hiphot posted he never had those problems with v1.4... so it must be a problem with the old drivers I am using or something.

It might actually be good if you opened up a thread dedicated to your changes to ZeroRadiant... this should make is easier for you to follow feedback, and for us to give it.

[obsidian]

Instead of a fork, have you considered contributing to the primary project? They could probably use a hand.

[cityy]

I never actually tested ZeroRadiant because I never was able to find a link to binaries...

A test build can be found here: http://zerowing.idsoftware.com/files/ra ... per/1.6.1/

It seems to be a modified version of 1.4.

[Silicone_Milk]

I use GTKRadiant 1.4. Always have, always will. Controls make sense, navigation of the program is easy, and it's stable.

1.5 crashes on me. A lot. Haven't been able to find the 1.2 download in a while.

[obsidian]

Hmm... I haven't ever had 1.4 nor 1.5 crash on me. The old ones would crash occasionally.

[AEon]

Haven't been able to find the 1.2 download in a while.

I have the files GtkRadiant-1.2.11-All.exe and GtkRadiant-1.2.13-update.exe (53.6 MB total) right here on my HD, and I could upload them, but that would not be a permanent mirror. I'd rather not "overload" my provider's FTP.

[Hipshot]

Give them to me and I can host them.

I assume it's not "illegal" for me to do so, they are so damn hard to find some of these things. It's like it disappeard from the net.

[AEon]

Thanks Hipshot that will really help. Even if most folks will use v1.4, it can help to test things in an older version of the editor. Presently I have v1.2.13, v1.4 and v1.5 installed... looking into v1.6 as well. Will PM when it's up (only have ISDN upload speed... argl).

Will then update the links in our sticky.

[cityy]

OT: Omg, there are other ppl with only ISDN upload speed - I thought I was the only one

[xpc]

Instead of a fork, have you considered contributing to the primary project? They could probably use a hand.

I wrote to the GtkRadiant list about this and the updates I'm doing are available on http://github.com/mfn/GtkRadiant , if they're interested in them.

Fork sometimes sounds negative ... it's simply the branch I'm working on; it's not like I'm trying to create the ÜberRadiant project :-)

[xpc]

I use GTKRadiant 1.4. Always have, always will. Controls make sense, navigation of the program is easy, and it's stable.

1.5 crashes on me. A lot. Haven't been able to find the 1.2 download in a while.

Hmm... I haven't ever had 1.4 nor 1.5 crash on me. The old ones would crash occasionally.

As get as many different information on that topic as there are Radiant versions and users out there. E.g. never had 1.5 crashing on me, but load up the map in 1.6 and first thing it did was a crash. As long as I can reproduce things it should be fixable.

Actually, I'm currently also evaluating on whether it's worth putting energy into 1.5 and doing it they other way: putting things from 1.4/1.6 into 1.5 . I'm also keeping an eye on the forks, most notably NetRadiant and DarkRadiant (although the latter has already advanced to much and doesn't support idTech3 anymore).

It's not like that I want to create just the next version of Radiant to even more confuse users, it just started to add things I missed and crashes I had or was told about. Quoting McClane: Because there's no body else to do it right now, that's why

[AEon]

I could imagine that trying to add the real-time lighting and other idTech4 (DOOM 3, Quake 4) features to a much older editor source tree (here v1.4/v1.6), would be a real pain.

Question is what would the ultimate goal be... an editor that supports idTech4 and other games (e.g. Half-Life 2 support would go far, since WorldCraft/Hammer is complete crap). Or to concentrate on Q3A support primarily (idTech3), and drop all the other games.

Maybe it might be more constructive if I "selfishly" mention a few things in everyday editing that would really be nifty to have:

• More solid texture alignment on brush faces that get rotated. Most of the time even with texture lock this totally fails, forcing folks to turn the brushwork into an ASE model.
• A way to allow some of the texture alignment on brushes to work like on patches additionally. E.g. you angle a brush and the texture is "stretched" even at an angle to fit. Presently you have to use patches all over the place for "weird" texture alignment.
• Migration of the model rotation code (R-key), from the v1.5 tree into the v1.6 tree. I.e. letting folks rotate models in real time. I know models are usually not really used that often, but to have one editor that actually works in all cases (see _remap on ASE models) would help.
• Texture alignment code that makes it easier to continue a texture from a axial face into angled ones... imagine an 8-sided brush, one *axial fit* would warp the texture around that "brush barrel". Presently placing texture on an angle, continuing from a axial wall, "can" work, or you suddenly need to rotate the texture by 180° plus manually offset it and things like hat.
• Proper texture orientation by default on all *sides*. E.g. a crate texture with writing on it placed on a cube, then use fit will mirror half the textures.
• A way to consolidate how decals and transparency is handled in-editor, v1.4 vs. v1.5.
• A texture offset/rotation reset button in the Surface Inspector window.
• Ctrl+LMB-drag edge editing made possible for patches as well (mimicking the behavior we have for brushes in v1.4).
• Now this one is a biggie ... some way to work at a 45° angled grid. What I mean is... at right angles everything is very easy to do, but at the very trivial case of 45°, you basically have to vertex edit everything (Ctrl-edge editing as I recently learned partially works too) because the view do not "follow" the angled geometry. This would require a 2D view at 45°.
• A way to make it possible to assign shortcut keys to the plug-in menu entries. The icon-bar seems to be a step in that direction, but it's not as convenient.
• Some way to drop entities flush to the next brush ("floor" surface). I'd mostly use it for plant model placement, using it to place the origin right on the floor.
• In "free fly" camera mode (3D view) allow the usage of W,A,S,D as an alternative to the cursor keys.
• Bug: Texture faces that have been rotated by 90° will no longer with with the fit button, you have to delete the angel to 0, then fit works again. But often you need to have the angle set plus need to fit the texture.
• I'll probably come up with other ideas...

Sorry to be so selfish... but these are some of the things that I always wished would be enhanced or fixed. Alas, I have no idea if the consolidation of patch vs. brush editing and texture alignment can be done, or if this is in fact a special limitation of the engine, but such a consolidation would be very nifty, IMO.

Obviously, all this can be done by *hand*, and we have been doing it all the while... but time to dream a bit

[^misantropia^]

Instead of a fork, have you considered contributing to the primary project? They could probably use a hand.

In my experience, the GtkRadiant developers are not really responsive to outside patches.

[jal_]

Is zeroradiant being developed at all anyway? I update my local copy of the svn each couple of months and I've not seen a commit in something like a year.

I think people who want to contribute should look to netradiant. DivVerent is well responsive to patches and, while the actual editor hasn't really got much attention, the compiler has got a lot of improvement and fixes.

EDIT: BTW, I pretty much agree with AEon's list of wishes line by line. Specially better texturing on patches. If possible, adding the Quark way of "UVmapping" patches.

[Hipshot]

GTKRadiant would do great with an exclude option, however, this requires an updated (new) map format I think.

[AEon]

Ironic that Quark actually had the option to define/name groups (strictly for map organization, ignored by the compile)... but back then I never used it. Presently using func_group, though as we know this can mess up lighting.

After rediscovering Shift+A, I can now very quickly hide certain things, e.g. all skybox brushes (select face, Shift+A, H-key (hide)).

[Hipshot]

I used the group feature a lot back when I used Quark. I missed it so much when I turned to Radiant and Hammer.

Quark is in many ways a much better editor feature vise. But since it's not officially supported, it's hard to use for games newer then "quake2" kind of games, I think.

[jal_]

The groups in Quark own big time. Func_groups just can't be compared. Being able to copy out a whole room and keep it in there, disabled, while you rework a copy of it, or just being able to disable parts of your maps to test light compiles room by room... it's just another level.
But anyway, what I miss the most of quark are the texturing tools. Texturing patches in radiant is plain and simply awful. In quark you can project it from brushes, and in case of need, work with it as if was UVmapping, so, full control.

Doesn't matter much, cause I work too much with models to use quark now, and the 3d window is too slow for big maps. But in some things it's really superior to radiant.

[AEon]

xpc,
I downloaded and tried to run your version of GTKradiant v1.6.x MFN, from

• http://forums.urbanterror.net/topic/196 ... es-from-15

radiant-1.6.x-mfn.zip

I also installed the new msvcr90.dll (package)

• http://www.microsoft.com/downloads/deta ... laylang=en

vcredist_x86.exe

All this was installed over what seems to be the last full distribution

• http://zerowing.idsoftware.com/files/ra ... per/1.6.1/

GtkR-1.6-testbuild-20080901.zip


Even though I got some warnings with 1.6, the editor worked. But after unpacking your binaries into that folder I get this error:

• The procedure entry point g_dir_open_utf8 could not be located in the dynamic link library libglib-2.0-0.dll.

I seem to have version v2.16.3.0, 1,001,834 bytes... possibly I need a much more recent base distribution?

Update: Strange... I must have made a mistake with creating the radiant.exe shortcut to the desktop. Redid it "properly"... editor now works.

Though I still see this issue:

• The template project "D:/games/quake3/baseq3/scripts/default_project.proj" has version 1. The editor binary is configured for version 2.

Since I have several editors installed also v1.6.1, this may be the issue.

[xpc]

Instead of a fork, have you considered contributing to the primary project? They could probably use a hand.

In my experience, the GtkRadiant developers are not really responsive to outside patches.

FYI, all the crash fixes I told them have been merged into ZeroRadiant today.

I think it depends on what kind of change it is, what it affects, what its implications maybe.

They rejected to merge a patch which basically allows Linux users to work with model files which have mixed case letters without having to manually fix the misc_model. It's dealing with preserving case in one place but it's implications are hard to predict, especially since they still try to have it still working universally with ET, QZ, etc; and it's true, I can't possible test all of those games out there.

[obsidian]

Nice one! xpc, are you Rambetter? Noticed the chat on the IRC channel.