Rollin' 

I've installed WC 1.6 to keep things old school.
Something blocking the oldschoolness of my map making is the fact that my copy of quake now resides in my steamapps folder. Perhaps this is why I get this message when I try to compile my map?

nput file: C:\Program.map
Output file: Files\Steam\steamapps\common\quake\id1\maps\square01.bsp
---- LoadMapFile ----
*** ERROR 34: Failed to open C:\Program.map: No such file or directory

Elapsed time : 0:00

Peak memory used : 0.0 MB

** Executing...
** Command: Change Directory
** Parameters: C:\Program Files\Steam\steamapps\common\quake


** Executing...
** Command: C:\Program Files\Steam\steamapps\common\quake\quake.exe
** Parameters: -window +map square01

Hope I'm not retardedly missing something obvious.
Thanks! 

I'm guessing it's upset about spaces in path names so that "C:\program files\..." gets truncated to "c:\program". Try installing into a path without any spaces in the name.

Or, if possible, try to surround your paths with quotation marks but that's probably not going to work in this context. 

just keep everything inside c:\quake\id1\maps and nothing can go wrong. tools, source, everything. 

What you have to do is make the path name absolute - with a " at the start and end, that way it forces the spaces to be visible to shitty windows.

So

C:\Program Files\Steam\steamapps\common\quake

Becomes:

"C:\Program Files\Steam\steamapps\common\quake" 

You're suggesting I add quotes on either end of the directory in the 'game' tab, correct? this isn't working.
I didn't have these problems with the steam version of half life, but I was the newer version of hammer, not worldcraft. Maybe I'll try wc 3.3... 

Worked for me . . . 

Now its working, though worldcraft is telling me that my map wasn't built.

Whatever. I can play my maps now, thanks guys! 

Is there any engine whose software renderer works in WinXP? 

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.