InsideQC Forums

JasonX wrote:I see that, but how do i position this cuboids in the world?

In the code I posted, there are six coordinate variables:
lx : low x coordinate
ly : low y
lz : low z coordinate (bottom of cuboid)

hx : high x coordinate
hy : high y
hz : high z (top of cuboid)

Prefabs seem like a complication, just write a solid brush for a solid spot and two brushes (floor and ceiling) for a clear spot.

The following code to write a cuboid brush into a file may be helpful:

void T_WriteBrush(brush_c *B)
{
fprintf(text_fp, " {\n");

int lx = VX(B->x);
int ly = VY(B ...

By MD5 you mean the message digest algorithm (not the model format), right?

One place is in Quake3: code/qcommon/md5.c

I've written a C++ class for it:
http://edge.svn.sourceforge.net/viewvc/edge/trunk/edge/epi/math_md5.cc?revision=6497&content-type=text%2Fplain
http://edge.svn.sourceforge.net ...

frag.machine wrote:Poor man's fake glass: use a oriented sprite. Will work even in software DOSQuake.

Woah, I never knew Quake could do oriented sprites.

That means that grating or fence textures are actually possible in vanilla Quake.

HL BSP does not require textures to be in the BSP, they can be external referenced from WAD3 files.

I guess it depends on how the BSP you have were compiled, whether the textures are external or internal. If they are external, you should (in theory) just need to supply the different ones in a WAD3 ...

Man, the scripting language code (compiler and execution) looks familiar.......

Spike wrote:you've 3 weeks after its release to at least double its speed, or I'm never trusting you again!

Hah, the gauntlet has been thrown

you've mucked something else up, probably because the 'color' variable got modified by the VectorScale() call.

Maybe something like this, find in RockThick() :

self.velocity = dir * 250

and change to:

self.velocity = self.velocity + dir * 25

Hmmm on second thought that wouldn't really do what you want, you would need to convert the 'dir' vector to angles and slowly turn the current angles -- which is ...

My guess is that velocitymultiplier defaults to zero, hence your velocity parameter is effectly ignored. It moves in the Z direction due to velocityoffset which has 80 in the Z component.

Try adding the following line to the EffectInfo

I think by stack it means remembering the last 4 (for example) waypoints that the bot visited.

Something like these fields:

.entity lastway1;
.entity lastway2;
.entity lastway3;
.entity lastway4;


You can check if the bot has visited any of those places before to decide where to go next.

When ...

OneManClan wrote:NO
This is pointless nitpicking, a waste of time, and won't really make that much difference

That.

It would save a bit of memory, but I doubt it will be any faster (it could even be slower due to extra bitmask operations).

I think these are mainly SEO : make a site seem popular (to google etc) by adding links to it on lots of other sites.

OneManClan wrote:OPTIONS
......
3. When a bare handed player is needed, make the code bypass the VWEP stuff
......

That's what I would do.

Find the mechanism used to attach a vwep to a model and unset the vwep when necessary. I have no idea what that mechanism is though -- perhaps it involves calling a builtin?

daemonicky wrote:

Spike wrote:Hexen2 actually has the client tell the server the light level where the player is.

Do You know where he gets it from?

Same way as entity lighting, by sampling the lightmap underneath via R_LightPoint()