not really directly editing, but it would be awesome if you could both assign a bitmap image as a light pattern on a spot light as well as be able to specify 'noise' on both sunlight, minlight and normal lights. 

Probably the best way to create a program for editing the lights would be a custom engine. Just add the ability to "paint" by applying a dynamic light to the scene which gets written to the lightmaps fully. Then add the ability to save those back into the bsp. Only problem is that you'd have no way of restoring those edits to the bsp next time you compiled. Unless you recorded a demo of yourself doing it... 

 

Whenever someone says, "wouldn't it be cool if quake had..." chances are decent that pOx's eUtils has done it.

http://quake.chaoticbox.com/

I quote from the readme:

Tyrlite+ contains support for OpenQuartz ( http://openquartz.sourceforge.net ) LIGHT noise extensions. These allow you to apply noise algorithms when lighting a level to break up common color-banding problems, or acheive more "organic" looking lightmaps. The following attributes have been added to the eUtils Quiver defs for all lights:

"Noise Level" (_noise) accepts a floating point value from 0-1.0 (0 is no noise). You can "overexpose" the noise with values greater than 1.0, but the effect is usually undesireable (values of 0.5 or less are best for subtle effects).

"Noise Type" (_noisetype) can be set to 0 (Random), 1 (Smooth), or 2 (Perlin).

"Noise Resolution" (_resolution) controls the size or scaling of the effect. Higher numbers make the end effect larger (lower detail).

"Perlin Noise Persistence" (_persistence) This controls the perlin noise decay per octave.

You can use the "-noise" switch from the commandline to add random noise to all lights, but note that you cannot currently use noise on Global lights (Sunlight or Minlight).

Too bad it doesn't do noise on sunlight, pretty sweet otherwise though. Presumably you could get the code straight from OpenQuartz, but their hasn't-been-updated-in-five-years website wasn't terribly helpful. 

i guess you could rephrase my above post as 'wouldn't it be cool if someone haxored pox's stuff into aguirRe's utils? :P 

wouldn't it be cool if it was cross-platform? 

I thought all the id code handled byte swapping, could be mistaken though. 

we've discussed this before, but i have no idea where it went...

i wanted to implement this for my next map, and i was thinking:
send console command save ne_autosave
and in a config file bind f8 "load ne_autosave"
f8, afaik, doesn't do anything and it's both close and seperate from f9.

opinions? 

can you use stuffcmd to load the game as well as save it? that would be better. (i.e. when user hits "jump" or "shoot" while dead, instead of doing the normal thing, the quakec would trigger a load then.) 

this is for quoth, so no qc modifications.

but yeah, i don't see why you couldn't do that.

in void() respawn:
if (coop)
{
// make a copy of the dead body for appearances sake
CopyToBodyQue (self);
// get the spawn parms as they were at level start
setspawnparms (self);
// respawn
PutClientInServer ();
}
else if (deathmatch)
{
// make a copy of the dead body for appearances sake
CopyToBodyQue (self);
// set default spawn parms
SetNewParms ();
// respawn
PutClientInServer ();
}
else
{ // restart the entire server
localcmd ("restart\n");
}

it would just be a matter of replacing the restart command at the bottom. 

I need someone with UnrealED3 (the UT3 version) installed to take a brief look over a map I have been slowly working on for a loooong time now to help me decide whether I should continue slowly building upon it or whether I should just put it out of it's misery.

Download it HERE. 

As I'm making a frogman model I'm confronted with a strange qc compile habbit.

I reconstruckted the model on the enforcer qc, this means I used the shoot section to evaluate its harpoon action.
As I compiled the arrow suddenly blasts to the sky.
I couldn't find a reason for it, so I changed the
org = self.origin + v_forward * 30 + v_right * 8.5 + '0 0 16';
from the model_fire section into
org = self.origin + v_forward * 30 + v_right * 8.5 + '0 0 -24';
and now the model shoots somehow left to the player, but not exact aiming its goal.

What I don't get is that they both seem to harm the player.
Also if I change the -24 a measure further the arrow shoots in the ground.
It seems impossible to aim it straight to the player.

Another strange habbit occurs on the model that's in the water.
It is the same subroutine I use for as the land model.
Only the land model shoots an arrow, the watermodel only shoots but there doesn't appear an arrow in water.
Does this mean the conditions for a model to spawn is different than on land? 

have you called makevectors(self.angles) before using the v_ unit vectors? 

as I thought this part was the positioning of the shooting angle of the model itself, it didn't make sense to me the arrow shoots straight to the sky.

void() harpi_fire =
{
local vector org;

self.effects = self.effects | EF_MUZZLEFLASH;
makevectors (self.angles);

org = self.origin + v_forward * 30 + v_right * 8.5 + '0 0 -24';

Launchharpi(org, self.enemy.origin - self.origin);
};
 

ok, that bit looks fine, now you need to check if launchharpi is correct. 

It's the same as the enforcer, but I must admit it is not a usual qc.
It is a combination of two models, who will be going to be melted as a water and a land model.
So the problem might as well lay in another part, although both of the models use the same Launchharpi.


void(vector org, vector vec) Launchharpi =
{
local vector vec;

if (self.classname == "monster_enforcer")
sound (self, CHAN_WEAPON, "enforcer/enfire.wav", 1, ATTN_NORM);

vec = normalize(vec);

newmis = spawn();
newmis.owner = self;
newmis.movetype = MOVETYPE_FLY;
newmis.solid = SOLID_BBOX;
newmis.effects = EF_DIMLIGHT;

setmodel (newmis, "progs/pioen.mdl");
setsize (newmis, '0 0 0', '0 0 0');

setorigin (newmis, org);

newmis.velocity = vec * 600;
newmis.angles = vectoangles(newmis.velocity);

newmis.nextthink = time + 5;
newmis.think = SUB_Remove;
newmis.touch = harpi_Touch;
};
 

i see a potential problem here. you have a variable 'vec' being passed into the function, and you also have a local variable 'vec' being declared at the start.

remove the local variable and that may fix your problem. 

I'm not so familiar with the stats although I'll believe you.
Remove the local variable, is that

//vec = normalize(vec);  

No, this:

//local vector vec;

Then you'll be using the variable you passed in rather than the local one. 

yeah, the normalize(vec) is actually very important. normalize makes whatever the vector passed in a unit vector.
that is to say, the vector is reduced from whatever it was so that it's total length is 1.
this is how you can then multiply vec by an arbitrary number to create consistent velocity (ie: projectile always travels at 600 units per second). if you didn't normalize, the velocity of the projectile would change in relation to how far apart you and the enemy are. 

I included it in the qc, but I wondered. I always thought that the

org = self.origin + v_forward * 30 + v_right * 8.5 + '0 0 -24';

positioned the point of shooting from the monster, where the last three numbers were the actual position of its gun.

With these coordinates I get a shooting frogman which shoots its arrow 24 units above its gun, but the arrow goes left above me.

http://members.home.nl/gimli/frogman.jpg 

org = self.origin + v_forward * 30 + v_right * 8.5 + '0 0 -24';

assuming makevectors has been run, the above line will set org to a position 30 units in front, 8.5 units to the right and -24 units up (all monsters are 24 units above the ground, so -24 will make it right on the floor).

the reason it's shooting nuts is because when you call launchharpi, you are calculating the trajectory with self.enemy.origin - self.origin but your spawn point is at org.

in order for it to work correctly, the function call should either be:
Launchharpi(org, self.enemy.origin - org);
or:
Launchharpi(self.origin, self.enemy.origin - self.origin); 

It might as well be above my hat but it seems to work.
I just get a little confused by the -24 as it still shoots above the players head.
It reminds me at the moment I placed the new monster in game and it flew 24 units above the ground.
I decided to lower all frames. So it is this difference that shoots the arrow overhead. Can't think of a way to overcome this now. 

 

just take -24 off.

it's shooting up because you are doing:
self.enemy.origin - org

think of it this way:

self.origin = '0 0 0' (you)
self.enemy.origin = '128 0 0' (monster)

this would be both the monster and you being at the same height.

but now, you are calculating:
self.enemy.origin - org
let's forget about v_forward and v_right for now.
that makes org = '128 0 -24' because the math is: '128 0 0' + '0 0 -24' = '128 0 -24'.

so think of it like the enemy.origin is the gun which is -24, so it has to shoot up towards 0.

removing -24 from the vertical element will make the monster shoot straight horizontally.

remember shamblers, how their lightning goes downwards or droles shoot at the player's feet. the drole shooting at the player's feet was completely unintentional and was a by-product of the spawn point of the drole missile (which is above the origin of the monster, so it shoots downward at the player which is the opposite of what's happening to your monster).