GTKRadiant 1.64 error

(morphdoc) #1

Hi All!

So I unzipped GTKRadiant on dekstop, ran radiant.exe (as administrator), specified pathway to ET and here is the error:

No games setup, aborting
GetLastError: There are no more files

An unrecoverable error has occurred
Would you like to edit your preferences before leaving Radiant?

so I looked this error up, and nothing…

Im running on Vista.

(twt_thunder) #2

lay of the last one until they fixed the errors in my opinion…

download this intead:
http://svn.icculus.org/checkout/gtkradiant/trunk/downloads/1.6/GtkRadiant-1.6-20121007.zip?revision=17

and go here:http://www.thewolfteam.org/page.php?4 for tutorial how to install it

(morphdoc) #3

Jesus, I finally managed to get it working…I had to install ET outside Program Files etc etc…but now when I compile the map I get an error: BaseWindingForPlaneAccu: no dominant axis found because normal is too short …the list of errors is endless with gtkradiant…

(twt_thunder) #4

any experience with gtk at all?
or else is would say go here:http://www.pythononline.co.uk/et/tutorial.htm
read and learn how to do things and get it right… saved me a thousand times…

(morphdoc) #5

Yea, I learnt using GTK on 1.5. Learnt a lot in terms of making maps etc, but not about the errors.

I had issues with 1.6 since forever, hence I was using 1.5. But recently I wanted to try 1.6 as it has better parameters. But once I managed to set it up, the error while compiling the map comes up (one above).

I really do not know what that may be.

(twt_thunder) #6

is this to any help?

http://community.moviebattles.com/threads/29808-Common-GTK-Radiant-Errors

(morphdoc) #7

No, it does not. I do not understand this error. I opened adlernest source file, didn’t do any changes and when I want to compile, I get this errors.

the only thing I can find on this stuff is this

=================
BaseWindingForPlaneAccu

*/
winding_accu_t *BaseWindingForPlaneAccu( vec3_t normal, vec_t dist ){
// The goal in this function is to replicate the behavior of the original BaseWindingForPlane()
// function (see below) but at the same time increasing accuracy substantially.

    // The original code gave a preference for the vup vector to start out as (0, 0, 1), unless the
    // normal had a dominant Z value, in which case vup started out as (1, 0, 0).  After that, vup
    // was "bent" [along the plane defined by normal and vup] to become perpendicular to normal.
    // After that the vright vector was computed as the cross product of vup and normal.

    // I'm constructing the winding polygon points in a fashion similar to the method used in the
    // original function.  Orientation is the same.  The size of the winding polygon, however, is
    // variable in this function (depending on the angle of normal), and is larger (by about a factor
    // of 2) than the winding polygon in the original function.

    int x, i;
    vec_t max, v;
    vec3_accu_t vright, vup, org, normalAccu;
    winding_accu_t  *w;

    // One of the components of normal must have a magnitiude greater than this value,
    // otherwise normal is not a unit vector.  This is a little bit of inexpensive
    // partial error checking we can do.
    max = 0.56; // 1 / sqrt(1^2 + 1^2 + 1^2) = 0.577350269

    x = -1;
    for ( i = 0; i < 3; i++ ) {
            v = (vec_t) fabs( normal[i] );
            if ( v > max ) {
                    x = i;
                    max = v;
            }
    }
    if ( x == -1 ) {
            Error( "BaseWindingForPlaneAccu: no dominant axis found because normal is too short" );
    }

    switch ( x ) {
    case 0:     // Fall through to next case.
    case 1:
            vright[0] = (vec_accu_t) -normal[1];
            vright[1] = (vec_accu_t) normal[0];
            vright[2] = 0;
            break;
    case 2:
            vright[0] = 0;
            vright[1] = (vec_accu_t) -normal[2];
            vright[2] = (vec_accu_t) normal[1];
            break;
    }
(Mateos) #8

Try to perform a Brush Cleanup (the icon with reversed arrows in the toolbar).

(obsidian) #9

Windows (Vista and later) considers “Program Files” a write-protected directory. GtkRadiant needs to write files to it’s installation directory as well as your game’s installation directory when you initialize the program to work with your game. So the OS is preventing GtkRadiant from doing what it needs to do.

GtkRadiant 1.6.4 is still a release candidate.

Try this latest build (Dec. 13, 2013), it fixes some stability issues when compiling from within GtkRadiant and a bunch of surface inspector fixes.

https://s3.amazonaws.com/gtkradiant/GtkRadiant-1.6.4-20131213.zip

Otherwise, try compiling by launching Q3Map2 itself with a batch file, ruling out any dependance on GtkRadiant. If it doesn’t compile with a batch file and it still produces errors, then you have a problem with the map, not the program.

(morphdoc) #10

So I shall still have my ET installed outside Program Files?

(Mateos) #11

I’d suggest to have a separate folder for the mapping, so you can have a custom config (like sv_pure 0 for testing map freshly compiled in etmain/maps), just copy binaries and pak0/1/2.pk3, like C:\ETMap\ (usually short paths without spaces are nice).

(ailmanki) #12

[QUOTE=ailmanki;484019]You can find some of those files over there: http://www.simonoc.com/pages/articles/terrain2_1.htm
Specially the alpha ones.

the shaderlist.txt is to add shader files, not texture folder. So you would need a file scripts/dersaidin.shader and in that file those shaders defined.

And I just checked adlernest.pk3, there is a file dersaidin.shader
The alpha ones are not included since they are only used for display in editor, the compiler q3map2 does not need the textures, but the shader definitions of it.

These questions are probably not answered they way you asked for it, but it shows you lack some understanding of how shaders and all that stuff works. Maybe check the Shader Manual out… http://www.robotrenegade.com/q3map2/docs/shader_manual/index.html

edit: Good luck with your project, and maybe just ask again, if I wasn’t clear enough. While you surely should first try yourself solving something, you shouldn’t bang your head against the wall :D[/QUOTE]

You need to make sure the alpha shaders are correctly referenced from your map to the *shader file. Its not enough to just have the shader somewhere… it has to match. …Really read the shader manual. Make some tutorials… your missing basic stuff.