aguirre's winquake should work in winxp 

winquake.exe 

has a software engine. You get two executables in the file. A GL engine and a software one. It works pretty good IIRC. 

Hmmm, must be something with my setup. Every engine crashes right after creating the window, with some variation on the "illegal memory write" error.

I wonder if the assembly code doesn't quite work on AMD? 

JoeQuake and stuff should work no problem, perhaps you should update your graphics card drivers? Or DirectX.

I'm quite sure your AMD CPU is 100% compatible with the assembly code in SW Quake. 

Had to turn off Data Execution Protection - apparently the sw renderer uses self-modifying code. I remember now I had to do the same thing to get Unreal to run. 

Shouldn't it be possible to manually define the volume of a point (notnull?) trigger with absmin/absmax/size ? 

Thinking of that for triggers without models. 

All the important setup for a trigger is done in the qc function InitTrigger in subs.qc. Half way down this function is:

setmodel (self, self.model); // set size and link into world

Any call to setmodel will reset the values of absmin and absmax from the values read from the map. If no model is set, they go back to equal the origin of the entity.


What you can do here is specify any other precached model in the model field of the notnull in order to give it that size. For example, using progs/player.mdl will give a trigger with the dimensions of the player.

If you set the model field to be *2, it will use the second brush model in the bsp file for the extents of the trigger. This is valuable if you already have a trigger of the desired size in the map, but want to create another without using a precache. Be warned that in order to get the trigger in the right place, you need to set the origin of the notnull to equal: the offset of the desired location from the position of the original trigger. 

That's absolutely sufficient (more than I hoped for). A map's standard item loadout already offers a good variety of possible sizes then. From weapon models for small triggers to Ogre/Shambler models for larger ones.
In my case, I can simply use the model of the very item the trigger is supposed to encompass (Quad) - saving precaches is vital here. 

That'll probably get you a similarly sized trigger, but it might not be exactly the same size. This is because the notnull bases the size on the extents reported by the model file. But the quad itself follows up setmodel with

setsize (self, '-16 -16 -24', '16 16 32');

which gives it nice integer dimensions. Also, it has the FL_ITEM flag, which makes it slightly easier for players to collide with it (I'm being vague about that because I've never bothered looking up exactly how that works).

As a final warning, the size you get from setting a model may not be consistent across engines. Certain custom engines (*cough* *cough* darkplaces) have in the past reported different dimensions to regular quake. Admittedly, I've only noticed this with a sprite, but it might bother you. 

DP seems to handle mdls differently, indeed (though I didn't do much testing, either). What definitely works is using the model of a large ammo pack.
I couldn't get brush models to work for some reason. The offset thing means bottom/right/back corner, right? Or across the entire map?! I tried to use the model of the func_door beneath the item, but it wouldn't spawn anywhere near it (if at all). And triggers are not even assigned a model number?! 

Too bad powerup_touch + items 4194304 + super_damage_finished 360 doesn't work except for the status bar change. 

When you touch the quad,it sets another variable. Take a look in items.qc

But there's no way to pass this onto the player when they touch it... 

Suppose that the minimum point of the existing brush model is at posA, and that you want the new entity to have it's minimum point at posB. You need to set the absolute origin of the info_notnull to be (posB - posA)

eg: existing entity has minimum at '2048 128 0' and you want a new one at '2048 256 0', then place the info_notnull at '0 128 0'. Notice that the origin of the notnull is nowhere near either the new or old triggers.

Another way of thinking about it is that the existing brush entity has it's origin at '0 0 0', so you need to place the new one relative to that offset.

Triggers are assigned model numbers, although they lose them pretty quickly in the code. If you make a quick mod where the last two lines of InitTrigger are commented out then you can see where they are. You might find it easier to look up the model numbers in the ent file that from the engine though. 

Thanks for clearing that up.

The ent file has all model numbers indeed - I only looked at the edicts list before. 

As there's still not a modeling help toppic, a bit underestimated job I suppose, I'm caught with the next error.
Made a model, fixed the base skin frame, and after texturing the model starts mirroring the back and forsight.

The only thing I can do is deleting the triangle, and merge the vertices back again in the hope they'll return back in order.
Sometimes this works, sometimes not. But as I started the same model from start, I end up with a large collektion dummies with all kind of failure. And as long as I have no correkt base frame for texturing the rest of modeling is useless.

What do I do with triangles coming back up, but are divided in a lot of thin texture lines? Does QMLE scale the triangle so small the original text grid is lost, or am I looking at the inside if the triangle?
Or what to do when the model keeps mirroring the skinfile? 

In order to save some more edicts, I changed a monster teleporter room from individual teleport ents to a monster-drop setup. Ran into trouble, wasted hours, changed stuff around and eventually managed to get it into a semi-working state.
Anyway, just to get an idea what the problem was: the original setup had the monsters move down on a func_door until they touched the teleport ents on the floor. However, instead of teleporting to their destination, they would somehow got caught in a loop, creating a tfog fireworks, took damage from the door (block) and died. What could have been wrong here? 

They got their fat asses stuck in the transdimensional netherlands. 

That's quite a stumper, I have to admit. Unless it's some weird case in the engine physics, setorigin being called in a touch function being called inside MOVETYPE_PUSH physics, but that must occur under other circumstances...

Have you tried reversing the direction of the setup, with the teleporter in the ceiling, and the func_door moving upwards? Setting it up this way round also means the monsters can't all fall straight into the teleporter one after another. 

Of course, that won't work because then the pile of monsters are just stuck, forget that. 

but I tried a monster stack once and they had to be triggered in order to fall onto the teleport. Otherwise, they just stood there in thin air. 

They only run physics once you wake them up and they try to move. So I wonder if running a monsterjump trigger pushing 1 unit downwards would be enough to make the monsters respond to falling physics correctly? Since firing a teleport sets force_retouch, they should all try to jump again the frame after a monster succeeds in teleporting. It does add another entity to the count though... 

generic: Stacking monsters (add a self-removing func_wall for neatness, to avoid walkmonster-in-wall-related issues) and waking them up to drop has downsides: the player can't here their wakeup sound and there's a risk of telefragging - which is why I'm slowly lowering them on the teleporters. 

I live in the netherlans..,
now looking for my threedimensional ass.