ZeroRadiant 1.6 Development Thread

[AEon]

I still can't start this. I already had the MSVCR pack. But do I need to install it ower another radiant version? I don't really wanna over write my 1.4, so what of all versions do I need? I have 1.5, I rather not destroy that one, since I use it (rarely).
But I would love to test this 1.6 for my new level, I don't like cross mapping...

Well... I installed... v1.2.13 in one folder, then v1.4 in another, finally v1.5 in a third, making sure all those actually work (properly setting paths to the engine etc, choosing the proper gamepack). Finally as listed in the above post above "simply" unpacked v1.6.1 (GtkR-1.6-testbuild GtkR-1.6-testbuild-20080901.zip) into a separate v1.6.1 folder. I did not touch any of my valid previous installs, they are all still there. Once that worked, created a duplicate of v1.6.1, named the folder v1.6.x and unpacked xpc's updates into that folder.

So if the gamepack was installed with v1.4, then v1.6.1 should already have all the necessary files, after an unzip... not requiring an actual installer. Alas I cannot re-test all this without deinstalling my working system.

[xpc]

xpc, have you considered porting the build system from scons to make? scons is pretty antiquated and doesn't play well with e.g. mingw.

This question comes up a lot.

No, I haven't considered it. Old or not, currently it works well for me to develop and test for Linux and Windows in parallel. VC ++2008 Express being my main IDE (I would prefer Eclipse though), but the integrated debugging in VC gets me quick into it.

Maybe I should take a closer look at NetRadiant, afaik the got rid of scons and did the switch to make/mingw; but ATM the build environment is stable for me.

Note that your latest binaries radiant-1.6.x-mfn-20100104-105320.zip are actually still pointing to the previous version radiant-1.6.x-mfn-20100101-145648.zip

Ach mist, fixed, thanks

[rgoer]

if I want to install the latest and greatest gtkRadiant to start messing with q3 again, is this the thread to find it in?

[AEon]

rgoer,
in part yes, if you consider the latest/greatest to be xpc's current fixes and additions to the ZeroRadiant dev tree = the better v1.4 GTKradiant. Though experimental. For stable mapping you'll probably want to stick to v1.4 (see links in my posts above or in our sticky thread "Getting Started...) though.


xpc,
drat I thought I had W,S,A,D camera movement licked (instead of Cursor keys), by "hacking" e.g.

Code: Select all

{"CameraForward", 'W', 0, ID_CAMERA_FORWARD, "menu_camera_forward"},

in mainframe.cpp, alas it turns out that the HandleKeyUp() function does not seem to "deactivate" (toggle) the "CameraForward state"... this works for the special case of the cursor keys e.g GDK_Up, but not for normal keys it seems. Possibly normal keys do not send a proper "key up" signal? But this would explain why the shortcuts.ini file key remapping for the camera movement never properly worked. "Scheissendreck ".

Anyway it's still nifty to play around with the source to quicky try out things, alas one seems to require a deep understanding of system programming... never did that.

[-=skOre=-]

The temptation... it never fades...

Edit: This got me far enough to get a Radiant error - "Didn't find any game file descriptions". But I did checkout the game files to GtkRadiant/games! Yet too stupid to figure that last bit out...

[Hipshot]

Got it working. I don't know why it was so problematic before.

However, I now get an error, that my default_project.proj is version 1, not two. And that it will run as it is for now, will this affect the editor in a bad way, what happens with 1.4 if I fix this error?

[Hipshot]

Alt+4 doesn't filter trans for me (?).
In 1.4 alt+4 filters everything trans more or less, all clips, etc....

[Silicone_Milk]

hehe so have we moved from everybody using AEon's template textures to everybody checking out the Radiant source to tinker with?

[^misantropia^]

Maybe I should take a closer look at NetRadiant, afaik the got rid of scons and did the switch to make/mingw; but ATM the build environment is stable for me.

That is sort of the point. make makes it easier for new developers to get up and running. On the off chance that I have some time to kill, if I clone your project and convert it to make, will you consider merging it? And I suppose you will want a Makefile that works on both MS Windows and Unices?

[^misantropia^]

VC ++2008 Express being my main IDE (I would prefer Eclipse though), but the integrated debugging in VC gets me quick into it.

You can get scons to run from within Eclipse with a little tweaking in the project properties. But VS is a fine IDE too, of course. Say what you want about MS but they do know how to build great developer tools.

[AEon]

Got it working. I don't know why it was so problematic before.

Finally ... hope the steps I described actually were correct.

However, I now get an error, that my default_project.proj is version 1, not two. And that it will run as it is for now, will this affect the editor in a bad way, what happens with 1.4 if I fix this error?

I simply edited the

• Quake3\baseq3\scripts\default_project.proj

file and changed the line from

• <key name="version" value="1"/>

to

• <key name="version" value="2"/>

AFAICT v1.4 still works, i.e. does not complain. But I'd recommend you keep a backup of your old file just to be safe.


Incidentally... I still get two I/O warnings when starting v1.6.x... have not looked into those yet:

Code: Select all

I/O warning : failed to load external entity "file:///D%3A/Games/aeRadiant%201.6.x/global.xlink"
I/O warning : failed to load external entity "file:///D%3A/Games/GtkRadiant%201.6.1/installs/Q3Pack/game/game.xlink"

I am not quite sure why "my" dev version of the editor I run from aeRadiant 1.6.x\ would actually look into a previously unpacked folder version GtkRadiant 1.6.1\. I duplicated and renamed that folder to aeRadiant 1.6.x\, maybe that leaves some paths set to it.

Fixed the former issue by copying Games\GtkRadiant-1.4\global.xlink to Games\aeRadiant 1.6.x\global.xlink. And copied Games\Quake3\Radiant-1.4\game.xlink to Games\GtkRadiant 1.6.1\installs\Q3Pack\game\game.xlink.

My install may be a lot more "messed up" than I thought.

Note: I only use the name aeRadiant 1.6.x for my tests, if you should have issues this will normally be a folder called GtkRadiant 1.6.x or so.

[AEon]

Alt+4 doesn't filter trans for me (?).
In 1.4 alt+4 filters everything trans more or less, all clips, etc....

Yep... does not seem to work in v1.6.x MFN... I use Alt+7 on clips usually.

Side note: I cannot see any clips in aeRadiant v1.6.x at *all* (clip, weapclip, botclip), and I cannot make them show in the map. Hmmm... almost like a permanent clip filter. I thought I was using the latest source tree (mfn-GtkRadiant-f025eaf.zip)... oh well.

[xpc]

Alt+4 doesn't filter trans for me (?).
In 1.4 alt+4 filters everything trans more or less, all clips, etc....

What was it supposed to filter exactly? All shader with surfaceparm trans?

I cannot see any clips in aeRadiant v1.6.x at *all* (clip, weapclip, botclip), and I cannot make them show in the map.

I'm on the run ATM, do you think you can try the stock ZeroRadiant binaries from http://zerowing.idsoftware.com/files/ra ... per/1.6.1/ ? If not I'll do it later. thx

FYI, I've like four or more installation at certain times to test things ... 1.4,1.5, stock 1.6, my 1.6, NetRadiant, ...

[AEon]

I cannot see any clips in aeRadiant v1.6.x at *all* (clip, weapclip, botclip), and I cannot make them show in the map.

I'm on the run ATM, do you think you can try the stock ZeroRadiant binaries from http://zerowing.idsoftware.com/files/ra ... per/1.6.1/ ? If not I'll do it later. thx

Sorry about the confusion... *your* latest binaries (radiant-1.6.x-mfn-20100104-105320.zip) do not show this problem... this is an issue with my local dev environment (and my locally compiled binaries), so you can ignore my "issue".


Choose Color dialog bug (radiant-1.6.x-mfn-20100104-105320.zip):

• Open a map, add a light entity, then open up the Choose Color dialog via K-key.
• Set the RGB numbers to 90,60,30 respectively. Hit OK, then K-key again. The color settings have been completely ignored.
• Set the HSV numbers to 90,60,30 respectively. Hit OK, then K-key again. The Hue and the Saturation values have been "remembered" but the Value is *always* reset to 100.
• Set the Color name field to #5A3C1E (= RGB 90,60,30). Hit OK, then K-key again. The field gets reset to #FFAA55.
• In other words Choose Color dialog is completely broken.
• Please note this is *not* your (xpc's) fault, this has been an issue with v1.4 as well. Alas I don't seem to be able to find the appropriate source that is not working, possibly this is a broken predefined GTK package module (as in simply calling .dll functions), that radiant "simply" calls. The color "picking" worked just fine with v1.2.13.
• Just tested all this with v1.4, here the Value field is reset to 255 instead of 100. But it's just as broken.

[xpc]

Choose Color dialog bug (radiant-1.6.x-mfn-20100104-105320.zip):
... snipped great description ...

I've transferred your description over to http://github.com/mfn/GtkRadiant/issues#issue/13 . It would be great if you could add further comments there. No problem if you don't want to, I try to keep track of all things (irc, forums, mail).

[AEon]

I've transferred your description over to http://github.com/mfn/GtkRadiant/issues#issue/13 . It would be great if you could add further comments there. No problem if you don't want to, I try to keep track of all things (irc, forums, mail).

I am usually a bit slack with these things, but once I get *into* it all is well ... will post future bug reports in the bug DB you mentioned above, because these very much help programmers get a quick overview. And I'd ask everyone else to do so too, to help xpc.

Update: Sigh... for some reason the font on that site is totally messed up (encoding probably totally off), so that I cannot read what I type in the bug report dialogs. This is under Firefox 3.5.6, with IE8 it works, argh. ... Alas "AEon" was taken as account, using AEonZR instead.

[-=skOre=-]

I have now figured why I couldn't get the game data into the editor - seems like the latest revision doesn't supply the /tools and so forth. Checking out an earlier revision does the trick though:

svn checkout -r29 https://zerowing.idsoftware.com/svn/rad ... ack/trunk/ ./games/Q3Pack

It's very weird. I started looking at the commands, but decided I would just try whether I can remember them without cheating. They were still all there. Every single one of them. Even the strange camera navigation works like I never took my hand off the keyboard.

Edit: I also needed to install q3 from here and move my old baseq3 into ~/.q3a - I'M TRIPPING THROUGH MEMORY LANE!

[xpc]

... Snipped another painful story about settings up radiant ...

Yes, this is also one main issue I'm having with the concept how 1.4/1.6 is set up. To me it's really non-trivial and I can't remember the steps either and once I got it working I basically don't want to touch it again. No solution yet, though. Afaik 1.5 solved this the smart way.

[obsidian]

It crashes running Windows 7, 64-bit. I had to enable WinXP compatiblity and disable desktop composition. (I should also mention that I only need disable desktop composition with GtkRadiant 1.5.0, XP compatibility is not necessary)

Some small issues:

On initial setup, it asks me to configure games by finding the engine directory. GtkRadiant 1.6 is installed on C:\ but my Q3 dev stuff is on D:\. The interface won't let me browse to the D:\ drive of my computer, listing only the subdirectories on the C:\ drive. I can manually type in the location and it works, but a little annoying none-the-less.

Also an error message that doesn't seem to break anything:

The template project 'D:/GameDev/Quake3/baseq3/scripts/default_project.proj' has version 1. The editor binary is configured for version 2. This indicates a problem in your setup. I will keep going with this project till you fix this.

May be something left over from previous installs. It tells me this every time I start up the program.


BTW, was textools ever included with GtkRadiant 1.5.0?

[AEon]

obsidian,

However, I now get an error, that my default_project.proj is version 1, not two. And that it will run as it is for now, will this affect the editor in a bad way, what happens with 1.4 if I fix this error?

I simply edited the

• Quake3\baseq3\scripts\default_project.proj

file and changed the line from

• <key name="version" value="1"/>

to

• <key name="version" value="2"/>

AFAICT v1.4 still works, i.e. does not complain. But I'd recommend you keep a backup of your old file just to be safe.

obsidian no reading my posts above

[xpc]

BTW, was textools ever included with GtkRadiant 1.5.0?

It's in the sources, alas it's not distributed in the binary packages from http://www.qeradiant.com/cgi-bin/trac.cgi .

Btw, do you maybe have a clue about the issue at http://github.com/mfn/GtkRadiant/issues#issue/13 I created from AEons description here?

I found that the source explicitly finds the highest of the three RGB values (be it 90 it that case), scales it to 1.0 on the normalized range and scales the other values too.

E.g. you can never enter a non 1.0 color on any of the RGB values from the color dialog.

[obsidian]

I can also confirm the same bug with GtkRadiant 1.5.0. In other words, it's a bug affecting ALL versions! I can set the correct manually calculated values in the entity inspector, but editing them again with the color picker screws them up again.

And yeah, it looks like it's taking the highest value and setting that as the ceiling normalized values and then scaling the other values based on that. It is correct that normalized values should be in the range of 0.0 and 1.0.

(R90 G60 B30) is being incorrectly normalized to ( 90 60 30 ) /90 = 1.0 0.6666 0.3333.


The correct formula should be:

( R+1 G+1 B+1 ) /256

So:

( 90+1 60+1 30+1 ) /256 ~= 0.355 0.238 0.121 (assuming 3 places precision)

A flat gray would be R127 G127 B127 = 0.5 0.5 0.5


In summary, it shouldn't be a normalized value from itself, but a normalized value from the total range of colour values.

[Hipshot]

Anyone else having the problem that the editor moves down a bit on the screen? The main windows (menu window) that is, not the blueprint or any other view.

[AEon]

As a test I removed the code that was doing this extra normalization, and the Choose Color works exactly as it should.

My guess is someone tried to port the code initially used for shaders (that get their color values automatically normalized) into the editor code, for some weird form of consistency. But that thinking would only be valid - if at all - if you could specify any RGB color values you wanted. But since these are 0-255 restricted (in the dialog), you *never* get into an "out of bounds" situation.

BTW, all this works fine in v1.2.13... lets hear it for old-school editors

[Hipshot]

This might be really heavy (or not), but is it possible to make it so that you can undock the texture and ent inspector from each other so that they are two seperate windows and also, make an option to put windows always on top. So that I can always have the surface inspector where ever I want it and always open? =) Now I need to resize windows and shit to keep that "open" else it falls behind.