With netradiant-svn-354 I have no more troubles with Preferences dialog . Is it solved now?

Yes, or rather, worked around. Gtk reverted the change that caused this, by the way.

Anyone have a linux binary of netradiant?

No, as a binary made on one distro won't work on other distros, I don't compile any.

With Ubuntu 9.04 I don't have any textures, they're all white now. I assume this is because of the new XServer?

I suppose something like this will do magic for linux aswell

ChangeLog wrote:2009-04-08 Rudolf Polzer divVerent(at)alientrap.org
* radiant: force disable composition on Vista (should fix "white 3D window" issues)

Edit: Uhm, seems like it works now. I don't know whether this is due to r365 or since I fiddeled with the settings, but it works

I doubt compiz provides an interface for that like Aero does.

Well, I could do "killall -9 compiz", but that's sure not good.

Eh, wait! Like I said in the edit of my previous post, "svn up && make" did the trick, it works now (even with default settings).

I tested the old version with metacity and no composite effects and it didn't work either, but that's nothing to worry about since the new revision works flawlessly

Hello
I'm happily using netradiant to start mapping for Q3A and all is going pretty well except for the "common" textures (caulk, full_clip, ...).
All textures of this section but invisible have "shader image missing"
I triple-check all pathes and paks and all seems ok to me.
Please let me know if someone has a clue about this.
Thanks in advance

ps: i use the Q3A gamepack found at http://ingar.satgnu.net/gtkradiant/file ... e3Pack.zip



edit: add a screenshot

I found a way to fix my "shader image missing" problem for the common textures.
In case it could help other, here is what I've done:

• grab the "common_files.zip" archive from http://www.clanopener.com/catalyc/common_files.zip and extracted it in a temporary place
• copy the "common-spog.pk3" archive in the .../quake3/baseq3/ dir

First thanks so much for taking this up! It's great to be able to map for q3a finally

I'm on 10.5.7 intel and I had to make a copy of NetRadiant.app/Contents/MacOS/install/q3map2.ub to NetRadiant.app/Contents/MacOS/install/q3map2.ppc to be able to compile maps. (I have had a couple of crashes from q3map2 but restarting NetRadiant seems to fix it).

I guess nobody is maintaining bspc? I'm probably going to have a bash at getting it to compile but I don't really imagine I'll succeed..

What is q3map2.ub? I did not provide such a file.

The q3map2 I compile is named .ppc, but actually is Intel only (because radiant expects it like that, don't ask).

q3map2.ub came with the binary I got and .ppc was missing so I had to copy it. Today I downloaded Nexuiz and the NetRadiant that came with that doesn't have the same problem.

I created textures for the common shaders to use in Warsow a long while ago. I don't know if netradiant is really missing them, tho, but if this is the case, I don't mind making them GPL (or any other license). If you are interested, just let me know.

These normally are part of the game pack. But it would be nice to have them.

Did you delete my post or did I do something strange and never came to post the url?

We had database trouble. So maybe it got lost.

Oh, ok. Here it is again:

http://www.warsow.net/dev/jal/editortextures.pk3

GPL license text is inside the pk3.

I just tried to do a OSX PPC build for the first time in a while with 383. Wild speculation, but I think something may have gotten messed up with OpenGL by Apple's recent system update to 10.5.7. I wouldn't believe it's a library/dependency issue, since this is actually the first time I've ever seen the compile die at the exact same place while building with Fink and with MacPorts. And it shouldn't be a issue introduced with new code, since I went back and tried to compile 294– the last version I had successfully built previously– and that failed at the same point too.

Any thoughts?

Code: Select all

radiant/qgl.cpp: In function ‘void QGL_sharedContextCreated(OpenGLBinding&)’:
radiant/qgl.cpp:1017: error: invalid conversion from ‘void (*)(GLenum, GLint, GLenum, GLsizei, GLint, GLenum, GLenum, const GLvoid*)’ to ‘void (*)(GLenum, GLint, GLint, GLsizei, GLint, GLenum, GLenum, const GLvoid*)’
radiant/qgl.cpp:1018: error: invalid conversion from ‘void (*)(GLenum, GLint, GLenum, GLsizei, GLsizei, GLint, GLenum, GLenum, const GLvoid*)’ to ‘void (*)(GLenum, GLint, GLint, GLsizei, GLsizei, GLint, GLenum, GLenum, const GLvoid*)’
make: *** [radiant/qgl.o] Error 1

The full console output is here.

The following patch makes the executable extension for radiant and the tools
configurable from Makefile.conf, just add EXE=ext to use a custom extension.
It also fixes the problem with the build menu looking for tools with the wrong extension.
netradiant-389-executabletype.patch

It's a bit confusing to have 64bit binaries with a .x86 extension
or OS X intel/universal binaries with a .ppc extension.

After compiling the latest revision I noticed brush manipulation
(plain scaling and moving brushes) is broken. It's probably GTK related (2.16.5)
but atm I have no idea where to start searching.

No idea, but it works for me. But I'd need to upgrade the distro on my system...

Did a system update and it's working again. The culprit was probably
an evil gcc package. I also fixed a warning in the zip library
netradiant-392-pkzip_warning.patch

update:
it seems it was actually gcc 4.4.1 and -O3. It works fine
if I remove -O3 from the CFLAGS. -O2 doesn't work either.

I've been reported the last packaged binaries of q3map2n have troubles (as in crash/exit) when using the -lomem switch. Unfortunately, I can't test it myself right now, so I can't give more information than that.

I did lately compile a map with -lomem, so that seems to work... it probably is one of the many crashes still left in q3map2 that always was there, and has to do with the map's complexity.

ingar wrote:it seems it was actually gcc 4.4.1 and -O3. It works fine
if I remove -O3 from the CFLAGS. -O2 doesn't work either.

I found out it is sufficient to add -fno-strict-aliasing to CFLAGS.
NetRadiant is quite sluggish without -O3, especially on larger maps
(+10K brushes).

Update:
Fixed some more warnings:
netradiant-393-qdata_heretic2-warnings.patch

Hi,

It seems the _patchMeta entity key is not working for func_group entities, but it's reserved only for brushmodel entities. For getting it working I had to use a func_static. It does the job, but it's not as pleasant as func_group because it's one more entity added to the transmission. Would it be possible to get it applied to func_groups?

Thanks in advance.

No, this won't be easily possible to add, but may be a suggestion for VorteX to implement.

Hi again,

I just found out that picomodel is enforcing the bitmap name as shader name on ASE model load. This doesn't make much sense to me, because 3dsmax uses absolute file paths for the bitmap names. The code which puts the bitmap as shader name is a hack and easy to locate and remove, but I'm wondering why did ydnar do this originally. Do you know what could be the reason?

And if you see no reason for it, what would be your opinion about removing the hack?

Is there a possibility to toggle lighting?
I have seen it somewhere but it doesn't work

I made a repository on googlecode for a version which runs on Snow Leopard..
For me the advantage is I can easily provide the code and changes.. and maybe get some feedback how dumb my changes are.. hehe. Which they are probably - yet I can finally start it, open and save maps.

I have first committed revision 402 from NetRadiant, and started to modify on that - so all changes are easily visible.
I hope this ain't a to bad Idea, but I somehow wanted to share my changes.
And last radiant for OSX is at rev. 295.. or something.

Actually I started mapping on Linux, and it was very easy to compile NetRadiant, but under OSX its a pita.

I still have to test stability and all.. but its great to be able to use my favorite editor again..
http://code.google.com/p/osxnetradiant/

I had various problems using the existing versions, either they did not start. Or they did, but then crashed on open/saving. Some fixes I found helped to make it start.. but not more. I suppose I have there some serious error with the libraries.. But I have honestly no experience at all with OSX.

I figured out that there is already a newer download for osx, even though it does not work either at first.. it did after removing the dynamic library for xml. (r402 for intel osx)
http://www.icculus.org/netradiant/files/

At first I thought it works perfect.. yet there is still the Problem with Invalid Chars on Save/load files..
If the line which triggers the error msg is commented out, it works fine - I suppose it crashes on some of these invalid chars.

Spliting Patches did often crash or only partially work, I thought first its a library problem.. but yahey I fixed.. and add split only cols or rows in menu.
http://code.google.com/p/osxnetradiant/ ... etail?r=52
(There is also a change for Macports, and filechooser .. please ignore, but the changes to BobToolz is really usefull I believe.)