I just re-read your thing that answers #1.

BTW, I think your problem with winquake is that the graphic is so big tht it goes off the screen. Winquake can't handle that situation, if i recall correctly. 

well i'll try to reproduce it next week. It might be an access violation that windows is helpfully generalizing into "an error." 

Well, the thing is I am not changing the original graphic's dimensions, only the look. 

I thought it would work so, but by making one dxf frame in QMLE and saving it to mdl gives a rather strange map that won't load in Quark.
I tried the AC3D studio, and this made a Quake map.

Thing is that all the polyhedrons-strings were after each other, while in a quake map there are just 6 strings to define a polyhedron.
So I diveded them in 6 but still Quark crashes.

Thanks HeadThump. That could be a solution. Fact is that I only can work with Quake1.
Q2 and Q3 I never compiled for, so if I would try that I should make myself convienent with those compilers. And I once made some things with blender, but I can't say I can work with it. 

The engine crash bug loading the System4 gfx.wad is caused by a texture anum_0 with invalid dimensions. You can see this also by loading the wad in TexMex; it will refuse to load that texture. Many GL-engines will crash in this situation, but DarkPlaces (Oct 2004) reports correctly.

I've now added checks and messages with texture name to my engines.

As for the onlyents issue; just run:
qbsp -onlyents mapname.ent

If you don't specify extension, qbsp will look for the default extension .map and in this case, it doesn't contain the new changes.

OTOH since I assume that you have the map source, I'd recommend change that instead and rebuild, instead of using the BspInfo method. Use that only if you don't have the source. 

Thanks very much for your help :) 

Are you sure? Because I loaded the wad in Tex Mex, and anum_0 shows just fine. It's CONCHARS that never loads (whether in my wad or id's original wad). 

I replaced my modified anums with the original and it now loads. I won't doubt you ArguiRe ;) 

I misinterpreted TexMex' behaviour a bit. The wad is still invalid (including the anum_0 tex report from the engine) but as you say, it's the conchars tex that's not loaded.

After checking some more, I think I have an idea what the problem is. I read somewhere that the original gfx.wad is in fact invalid because they made some hackish addition to the wad and patched the header. This is why TexMex has problems loading the wad. You can check loading e.g. the Hipnotic gfx.wad instead and it will load properly.

However, there's also another problem. You seem to have created these new objects as mip textures (with mipmaps) and that's wrong. They should be StatusBar Pictures instead and definitely without mipmaps.

I've tried to figure out how to convert an existing mip texture to a StatusBar object (i.e. remove the mipmaps) but haven't had any success yet.

Maybe someone else knows how to do this? 

That my graphics have become MIPs is involuntary. What I did was export all the graphics to .PCX, opened in Photoshop and edited there. Then, whichever ones needed to be .LMP were converted. The ones inside GFX.wad were merely imported .PCX files. How they got turned into MIPs, dunno. Must be automatic. 

Dunno where one would get that nowadays tho... 

Use the evil folder deleting tool (or Adquedit) for importing into your gfx.wad. It should always save it correctly, it accounts for the wierdness of the conchars file and all that automatically. 

I have decided to use the 'sinking' monster route to get rid of my corpses.

I have created a simple SUB_Corpse_sink that lowers the origin_z value a unit at a time and lowers my corpse until it is out of sight. I then use remove(self). It works so far.

However, if I quickly no_clip to the floor below, I can see the corpse appear through the ceiling before suddenly disappearing altogether.

I am thinking that if a monster is on a walkway above the player and is then killed, the player could see all this happening. Is there a way to get the player to sink into the 'ground' by (effectively) removing it in layers. I have in mind a pack of cards that I keep removing the bottom card until the pack has gone.

I have seen this sinking effect in Lost Chapters although I do not know how it is achieved there. 

The corpse removal in Chapters works exactly as you appear to have implemented it yourself. If you check out any monster that dies on a walkway in Chapters ( the ogre above the GL in chapter_secret for example ) you'll see his corpse sink through the wooden boards and turn black before disappearing.

Preventing the model showing through is basically impossible in Quake as far as I can tell.
Trying to skim the bottom off the model like a deck of cards would require that the polys be rendered individually and relative to world polys, which Quake simply doesn't do. I think that would need an engine mod. DP could maybe do it.

re: chapters progs. No word from necros, guess I'll have to email him again. Unless he responds here. 

OK, thanks. I'll carry on the way I'm going. 

What you could do is make an extra animation sequence where the model itself sinks down, but that any vertex that is more than 2 quake units below the floor gets flattened. That way nothing would show through a floor more than 2 quake units thick. Of course, doing that kind of animation wouldn't be smooth on an engine without interpolation, so perhaps what you want is to move the model down as you animate it, flatten the vertices at -2, undo the motion downwards, then code it to move at the same rate you originally animated it at. Urrgh. But it should would.

Except...this kind of calculation is assuming the corpse is on a single flat surface. None of this would be valid on a slope. There would be work arounds to minimise that problem, like doing a traceline down, and using the trace_plane_normal to calcluate how far to put it down before playing the animation. And nothing you can do will help if the corpse hangs off the edge of a ledge. So yeah, it's never gonna be great, but it could work better 

nt 

I have tried to use the vermis from lost chapters in one of my maps.
It looks like the vermis dosn't respond to the flags 'delay spawn'. Since it is a void map the vermis is visible all over the map.
Is this a bug or haven't you given the vermis the spawn- delay/silent/alert flags? 

I'm working on a mod to help people who are pushing the limit of entites in maps. So far I've got rid of all info_player_starts, up to 16 of each of info_player_deathmatch, info_player_coop and info_intermissions. The entites are loaded in the map, but then the position/facing of each is stored in memory and the entites freed up.(thanks to the natural selection mod team for the idea of doing this, they do a similar thing to keep their mod running in half life). At this point I'd like to express my dislike for the original quake mappers who used info_player_starts as teleport destinations, it complicates the removal code.

Speaking of teleports, the mod also gets rid of info_teleport_destinations, by a similar method. Since you have another entity to store the location of the destination in, namely the trigger_teleport that sends you there, the method works for any number of teleports in a map. This is all automatic, build the teleport as you usually would and the mod does the fix. I'll probably get round to adding the teleporting monsters by a flag code soon.

I'm also hoping to add a few options for corpse removal. The options should be setable in worldspawn, and possibly per monster as well(overriding the general level preference). The options I'm considering are:

Never remove corpses(current behavior)
Remove corpses when running low on entites
Remove corpses when running low on entites, but attempt to make static corpses first.
Always remove corpses after x seconds
along with
Fade away on removal
Sink away on removal
Burn away(think doom3) on removal

The remove when running low on entites needs a bit more explanation. I now have an entity counter running in the mod, that will know when there are few entities left, and when you get close to the limit, the mod will start removing 'expendable' entites. This includes things like explosions, flying lavaballs(although not the spawners) and if you set the flags to do so, corpses. Corpses would probably be the only things to have an effect applied when removed, the others would just disappear. The list of expendable entites would be adjustable, so if you felt backpacks belonged on there, or had rubble spawned from an explodewall you added, then this could be made expendable.

The static entites for corpses is something else I just came up with. There are three reasons why you wouldn't just make every corpse static. One is that, in deathmatch, corpses disappear after a while, so they aren't static, although this only applies to players. The second is that there are only 127 static entities available, and some are already used for torches. The third is that sometimes corpses aren't static, for example if they are on lifts they should move.

The second problem is easy to fix, you keep track of how many static entities you make and stop once you reach 127. I thought the third wasn't fixable, but then I discovered a poorly documented feature in defs.qc - .groundentity. It tells you which entity another is resting on. So wait for the entity to land, then any that land on world can be made static safely.

The final thing is that freeing up entities afterwards isn't much help if you don't use them again. Some of them will be useful for projectiles and the like. To really take advantage of them though, I'll add group spawners like kinn did in Bastion, so you can spawn many monsters from a single entity 'in formation'. You'd have to make sure that enough monsters were killed in previous sections, but then it should work alright.

So, is there a demand for a mod like this? Or anything else that belongs in the project? The scope of it is making it easier to map/work around limitations in the engine without changing the gameplay. Like adding the option to set a player's starting ammo/health/armour/weapons from the spawn point, rather than putting entities on top of the spawnpoint to achieve the same effect. 

Well, what I thought was working last night, was not working last night as I thought!

With a SUB_Corpse_removal added to subs.qc I had what I thought was a nice gentle sinking of the monster: it looked real good. What I didn't realise at the time was that it continued sinking... on and on throughout the map.

When I introduced a SUB_Remove it removed the monster but so fast that you didn't see the sinking action.

What I have ended up with is this after the final monster death frame:-

{
if (!self.corpse_delay) // if no corpse delay set in map
self.nextthink = time + 120; // remove after 120 secs anyway ( may not want this???)

else
self.nextthink = time + (self.corpse_delay); // remove after corpse_delay seconds

{self.think = SUB_Corpse_sink;}

};


And this as the new SUB:-

.float counter;
void() SUB_Null = {};
void() SUB_Remove = {remove(self);};

void() SUB_Corpse_sink =
{
self.counter = 0;
{while (self.counter < 16)
{
self.origin_z = self.origin_z -(1);
self.nextthink = time + 0.1;
self.counter = self.counter + 1;
}

self.think = SUB_Remove;
}
};

The counter was supposed to give me a 'sink' of 16 units. Adjusting the nextthink time has no visible effect.

Are you able to spot my newbie mistake here? 

the while loop runs until it is finished. It doesn't pause at the nextthink line. What you should do is change the while to an if, and then put a return; after the self.counter = self.counter + 1; line.

Also, try to reuse an unused entity field instead of adding a new one. (.counter.) I believe there's a .count and .cnt field that monsters don't use.

Finally, you might have to call setOrigin on the monster, because I'm not sure the direct origin change is reflected in the game. 

Move the line self.counter = 0; to somewhere it isn't called everytime SUB_Corpse_sink is called. As it is now it is reset every time the function is called and the monster sinks forever. 

Add a self.nextthink = time + 0.1; before the final self.think = SUB_Remove; line. self.nextthink is already at time when it gets there. 

Thanks, I'm on to it right away. 

All done and working. Thanks.

I haven't altered the origin changing as I had already seen that that part was OK.
I had already been down the 'if/then' route but the two main errors were: resetting the counter wrongly, and the missing self.nextthink before the SUB_Remove.

Once again, thanks. Now, back to mapping...