the +=4096 boundary is purely a network protocol limit, not a limit in the quakec interpreter or map/bsp format. 

If your editor has the 4096 limit hardwired into it, then that sucks. Both Quest and Radiant let you build wherever you want, so I'd be amazed if an editor actually limits you to that area o_O

hack the editor?

oh wait, would need source.

RMQEngine has that limit removed, too, and is Fitz-based.

One thing to remember with engines that use floats for coordinates is that when you have something very far away from (0 0 0) you can have floating point inaccuracies, or so ISTR. But ask a real engine coder ;-) 

i don't think floating point inaccuracies will be a problem unless you are very far from the origin. Regular quake protocol precision is 1/8th of a unit. To reach precisions that low in floating point, you would need to be about 1 million units from the origin.

(reasoning: 23 bits devoted to the floating point value, 3 bits are fractional part if we want 1/8th unit precision, leaving 20 bits, 2^20 is about 1 million.) 

Would anyone know off hand why Gtkradiant wont work under Ubuntu 10.04? When I run it I get this error:

Gdk-CRITICAL **: gdk_window_get_window_type: assertion `GDK_IS_WINDOW (window)' failed

(process:1680): Gdk-CRITICAL (recursed) **: gdk_window_get_window_type: assertion `GDK_IS_WINDOW (window)' failed
aborting...
Aborted

Any ideas?

Also can anyone suggest any alternative map editors? (Ideally one that will run under Linux.)

Cheers!


This is the solution:

http://ubuntuforums.org/showpost.php?p=9919688&postcount=9

Compile Radiant manually after doing an SVN checkout.

Find the file in the sourcecode and switch these two lines around in a text editor. Then build.

There is a file COMPILING included with Radiant that lists the dependencies and tells you how to use scons to build it.

It works now (switched to ubuntu recently and had same problem).

My Radiant is hack'd anyway, so this wasn't a big problem. 

and the explanation: It seems like a problem with Gnome, possibly a Gnome update b0rked this, not Linux as a whole. 

I'm still in trouble with creation of a DAMN CAMERA for cutscenes !

A static camera would be enuff for me so I studied info_intermission code from client.qc

..this is my (wannabe)(not working)cam.qc:

// CAMERA BY MIK //


float cam_running;
float cam_exittime;

/*QUAKED info_cam (1 0.5 0.5) (-16 -16 -16) (16 16 16)
This is the camera point for the intermission.
Use mangle instead of angle, so you can set pitch or roll as well as yaw. 'pitch roll yaw'
*/
void() info_cam =
{
};

/*
============

FindIntermission

Returns the entity to view from
============
*/
entity() Findcam =
{
local entity spot;
// look for info_intermission first
spot = find (world, classname, "info_cam");
if (spot)
return spot;
}


void() Exitcam =
{
// skip any text in deathmatch
if (deathmatch)
{
GotoNextMap ();
return;
}

cam_exittime = time + 1;
cam_running = cam_running + 1;


self.view_ofs = '0 0 22';


}

/*
//
// run some text if at the end of an episode
//
if (cam_running == 2)
{
if (world.model == "maps/e1m7.bsp")
{
WriteByte (MSG_ALL, SVC_CDTRACK);
WriteByte (MSG_ALL, 2);
WriteByte (MSG_ALL, 3);
if (!cvar("registered"))
{
WriteByte (MSG_ALL, SVC_FINALE);
WriteString (MSG_ALL, "As the corpse of ");
}
else
{
WriteByte (MSG_ALL, SVC_FINALE);
WriteString (MSG_ALL, "As the corpse of t");
}
return;
*/


/*
============
IntermissionThink

When the player presses attack or jump, change to the next level
============
*/
void() camThink =
{
if (time < cam_exittime)
return;

if (!self.button0 && !self.button1 && !self.button2)
return;

Exitcam ();
};



void() execute_cam =
{
local entity pos;

cam_running = 1;



pos = Findcam ();

other = find (world, classname, "player");
while (other != world)
{
other.view_ofs = '0 0 0';
other.angles = other.v_angle = pos.mangle;
other.fixangle = TRUE; // turn this way immediately
other.nextthink = time + 0.5;
other.takedamage = DAMAGE_NO;
other.solid = SOLID_NOT;
other.movetype = MOVETYPE_NONE;
other.modelindex = 0;
setorigin (other, pos.origin);
other = find (other, classname, "player");
}
};


void() cam_touch =
{
local entity pos;

if (other.classname != "player")
return;

};


/*QUAKED trigger_cam (0.5 0.5 0.5) ? NO_INTERMISSION
When the player touches this, he gets sent to the map listed in the "map" variable. Unless the NO_INTERMISSION flag is set, the view will go to the info_intermission spot and display stats.
*/
void() trigger_cam =
{
if (!self.target)
objerror ("cam trigger doesn't have target");

InitTrigger ();
self.touch = cam_touch;
}; 

It's quite hard to diagnose your code if you don't describe the problem you're having with it, but I'll start with this:

void() cam_touch =
{
local entity pos;

if (other.classname != "player")
return;
};


This is the function that is run when an entity touches the trigger. It returns if that entity is not a player, which is sensible to prevent monsters or rockets setting off the camera. The problem is that this is the end of the function, so it doesn't do anything when a player does touch it.

Before you can start fixing the rest of the code, you need to call execute_cam after that if statement. I hesitated to recommend this though, because you've still got a lot of work to do for a feature that already exists in mods like custents... 

Problem is: I put info_cam and trigger_cam entities in my map but when I touch trigger nothin happens !

Do I need to edit other qc files beyond my cam.qc ?

Can you explain me better how much additional work is needed ?

ps: I know custents, zerstorer,... but since I've already successfully added things in my progs I'd really like to insist ! 

..With my cam.qc code above I obtained this:

When player touches "trigger_cam" the view moves to "info_cam" (as I wanted) BUT still there's player weapon, crosshair on screen and mouse-look active (I don't want these for a camera view obviously !)

..SoMe HElp ?? 

Some bits here may help (from custents code)

/* This routine short-circuits player turning movement while
in camera mode.
*/
void() look_ahead =
{
self.angles = self.enemy.mangle;
self.fixangle = 1;
self.nextthink = time + 0.01;
};

void() go_camera =
{
// Change the player into a camera
self.classname = "camera";
self.velocity = '0 0 0';
self.view_ofs = '0 0 0';
self.angles = self.enemy.mangle;
self.fixangle = 1; // turn this way immediately
self.movetype = MOVETYPE_NONE;
self.takedamage = DAMAGE_NO;
self.solid = SOLID_NOT;
self.weaponmodel = ""; 

Mike's code will help with disabling mouselook and the viewmodel. You need to set each player's think function to look_ahead for the duration of the cutscene. Make sure that players cannot attack during a cutscene either - that would be bad in it's own right but also resets their think function so breaking this section of code. Alternatively move the code from look_ahead into PlayerPostThink to be run only during a cutscene (this has the bonuses of allowing player entities other think functions and also working even if the player exceeds 100 frames per server second - which is possible if you start applying slow motion)

The crosshair is not possible to fix in a way that won't annoy some players. You could use stuffcmd to send "crosshair 0" to a player's console, but then if you blindly turn it back on you've reset the variable for players who want the crosshair off normally.

If you use cvar to try and read the setting, you'd run into trouble with players in co-op - cvar reads the server setting instead of the clients. I suppose you could compromise and use that method in single player so the crosshair disappears and is restored, then disable that code path in co-op.

The next problem is that you need to restore the player when the cutscene ends, which the code from info_intermission does not make provision for(since players go to the next map afterwards). This may be some work, or it may be simple depending on what state the player will be in after the cutscene.

I mentioned co-op in the crosshair part above - it's a corner case a lot of people forget about when coding things that affect the player - sometimes there are more than one at once! So you may need to review your code for other places where this assumption might break down. For instance, do you want to trigger the cutscene for all the players when one of them touches the trigger? If not, what does a player who's viewing a cutscene look like to players outside the cutscene, etc... 

I'm a beginner with qc and my maps are singleplayer only so probably I'll pass on that :(

After cutscenes how can I change level ?
..maybe with stuffcmd's ? 

If you want to end the map straight after a cutscene then you've saved yourself lots of work. You can adapt the original intermission code for that - just trigger the level change at a signal from the end of the cutscene rather than when the player presses fire. 

..What kind of changes are needed in qc if I want to restore player position/view after a cutscene ? 

You need to run through your code and write a list of everything it changes about the player. So you mentioned position and view angle in your post, add them to the list. viewmodel was reset by the code, so that needs to be included too.

When you have your list, you need to decide which of these things you need to remember the previous setting of, and which you can just recalculate. For instance, you probably can't know where the player used to be standing without storing it in some variable. But you know that the player's viewmodel can be worked out based on the weapon he currently has (stored in .weapon).

For the former category, you need to store the value in another field on the player for the duration of the cutscene - for instance create a new vector field called .prior_origin. Once this is defined, go to the place in your code where you first trigger the cutscene, and store the origin at this point in your new field. Repeat for all the other fields.

Finally, when you end the cutscene you need to restore all of these fields to their pre-cutscene values. One in particular to take care with is the origin - don't set it directly as this will cause bad things to happen in the engine. Instead call
setorigin(self.prior_origin);
which will do things right. For things like the viewmodel, recalculate it based off the player's weapon.

That's probably enough to be getting on with, so come back when that's done and I'll start throwing some more stuff to think about. 

..problem is I'm not sure on going on with 2nd part !

I'm indeed a better mapper than coder.. eheh

-My first idea was to use Nehahra progs.dat because of fog support, script actors,.. but I dont want people need another mod to play mine.

Question: if I mod for Nehahra what files I have to include in the final ".pak" for people to play it? Nehahra progs only? 

You just say "Nehahra Required", then the person can download Nehahra, install your map, run Nehahra, then run your map :)

You tell them to run Quake with the commandline "quake.exe -game nehahra +map yourawesomemap" 

You don't need an external progs, just set a key "fog" on worldspawn with the value "density r g b" where the density/r/g/b values are between 0.0 and 1.0. Most modern engines should recognise this.

I don't think anyone will object if you make a Neharah map :-) (e.g., a lot of recent maps require the Quoth expansion pack.) 

..but I liked the idea of having my mod requiring nothing else..

-Since my mod is a partial conversion I was thinking of make it standalone(selfinstalling .exe )

But I dont know how to do it.. suggestions ? 

 

in all my years of downloading and playing quake mods i have never come across one that required a self-installing exe. it just isn't the done thing. everyone should know how to install it manually from a zip file by now!

if you want to use the nehahra progs you MIGHT be able to get away with just requiring the progs.dat file depending on what features you use. try copying it into its own directory (eg. c:\quake\mymod\progs.dat) and running quake -game mymod, then whenever something like a sound or model is reported as not found, you can move it across from the nehahra dir to yours. but ask mindcrime's permission before distributing it! 

..my idea is to have in my map many different skinned monsters per class (4 or 5 soldiers with different colors, 4 or 5 knights, ..)

Easiest way to achieve this ?

-I'd happily skip the creation of every different skinned monster in qc code(since I want to change only clothes color for each!) 

You will have to make an mdl with several different skins included, and edit some qc so that you can add a different flag to each differently coloured monster.

Lol - I'm no coder, but a (very) long time ago I managed to make a mod which had painskins in it. inside3d.com will have necessary tutorials :D 

I know of your fame.. though I haven't played any of yours yet..

actually I've just finished with a giant dvd(8gb) full of whole Quake maps goodness, all sorted by authors(!) that I'm going to play in the ..next years

Back to my question:
yes what you say is right and I'm sure having seen somewhere a patch like that
but I'm trying to stay away from qc afaic :) 

As long as you do not want different action (AI) for different skins, just ensure that your mdl has skins and set "skin" "1" (or 2 or 3 or however many you have) from the editor. The default skin is "0".

If you set an incorrect number you will see the monster with a black/cyan patern but it will behave as normal.

There are many standard Quake monsters already out there with several skins per model.