i *think* the way it works is that when you're replacing the texture, if the first ~8 or so digits of the new tex's name are the same as the old one, it doesn't save properly and reverts to the old texture when you reload. next time it happens try renaming your new texture to w_brickegbnv1 or something like that 

 

In the mapping contest thread you wanted to know how hard it was to add monster spawning to the standard progs. There's a tutorial on how to do that at:
http://www.inside3d.com/showtutorial.php?id=171

It might not be exactly how it's done in quoth, but it will probably do what you want. 

i'll just go step quietly back into my corner.. 

a so called spawn64 progs for JPL's CDA map, it has basically the same spawning as Quoth (or Zerst�rer actually).

If you wish, I can update it to my latest std id1 fixes and you could check it out. 

i don't think the quoth spawning is that good... in fact, it's probably the worst way to do it. preach's looks a lot lot better and a lot simpler too. 

would it be possible to change it then? without b0rking maps using the previous method? remember, when it comes to code I know nothing 

just delete all the spawning stuff and use preach's nicer method, replacing spawnflag values where appropriate to keep it from breaking existing maps.

i really only skimmed his method though, and it may not be any better. :P

it looks like all the spawning stuff goes through the same function, unlike how i did it which was to have a seperate function for each monster.

preach's method looks more streamlined and... uh.. unified, i think is the term.

it's just that it's really boring and long to do cause you gotta open up 20 or 30 something monster qc files and change the same lines of code over and over. 

If you change spawning method, I will have 3 maps to rework entirely !

And what about back compatibility ! Please don't do that Kell ! 

wtf do you think I was asking about? backwards compatibility is exactly what I want to keep 

i would have said yes but judging by the previous few replies, preach's technique looks more like the option to go for. what other fixes are incorporated in your progs?

i've been slowly grappling together bits of code from various sources to come up with my own progs.dat for the episode i'm working on. i'm no coder by any means but i'm starting to understand some of the qc basics & have gotten a few new mods to work ok. i actually browsed the inside3d tuts before but somehow missed that one.. dammit 

mention ...

As for spawning simplicity, how can it be much simpler for the mapper to just add 64 to the spawnflags and a targetname for a teleporting monster? 

aguirRe is right i use in Quoth and real easy what�s the big problem? 

Sorry, I misunderstood the subtelty of your sentence... and I also think that spawn64 method is really good. it is very simple to use, so please don't change it.
Maybe coders have another point of view... but I think the sipmpliest it is for users, the better it is.
My 2 cents... 

Works well, and is very simple to use. The func_hordespawn has an issue but nothing killer.

As far as I can see the only way it could be improved is spawning entities with preset variables, targets or killtargets, for example.

HL1 had this but from the (very) little I know of QC it's none too simple. 

quoth spawning lets you set targets and killtargets no problem. In fact, enemies you choose to spawn can be set up exactly as if they were regular unspawned enemies because that's what they are. The spawnflags just delay their spawn. You can even have them spawn and go to path_corners and it works no problem.

Unless you are referring to the hordespawn. I guess it would be cool to be able to set enemies spawned with that to have targets so you could unlock a door after the player kills 10 monsters spawned from it. I've never tried to use it though, so maybe there is a way. 

The open a door thing is a bit straightforward, I was thinking to make some of the more complex horde battles a la Serious Sam - the arena spawns thirty fiends, after you kill ten of them it spawns twenty scrags, once you've killed a total of twenty monsters of either type it spawns ten shamblers and once you've killed all the shamblers the door opens.

And then, if the player runs away they live to fight another day, but if they kill all the monsters a MH unlocks. 

...I could use a hand finishing a DM level if you've got the time and the inclination. Your email in the "people" section seems suss. If interested send to my gmail :) 

So, after a long discussion with aguiRe, apparently WC 1.6 likes to misalign my brushes. What I mean is, I could be working in the .rmf adjusting wedge brushes with the vertex tool. The vertices of the wedge brushes might look perfectly aligned in the .rmf, but in the .map, some vertices are misaligned, sometimes but 8 units or more.

Has anybody else experienced this before? If so, how do you go about working around this?

I'm currently doing my mapping in the .map, but I want to go back to mapping in the .rmf. But with this vertex mishap, I simply cannot. 

It is sometimes necessary to break wedges diagonally into two separate "spike" brushes, like when trying to create a spiral path ala CZG's curves tutorial. 

wc does that because it doesn't check to see if your brushes are valid or not. If you use vertex manipulation, you can totally fuck up the validity of a brush if you so desire, so you need to be careful to keep faces planar and brushes convex. As generic mentions, you can build more complex shapes by splitting brushes with the clipper tool. An interesting feature of worldcraft is that if you split an invalid brush with the clipper, the misaligned vertices will change position.

You can actually create REALLY huge problems with the clipper if you aren't careful though. When clipping multiple selections, be sure not to clip along the face of a brush, as WC will create an infitely small brush that will stop compilers but can be a total nightmare to find. 

Avoid long thin triangles, or ones where the centre handle is close to an edge. 

...split the wedges into 2 triangles with the clipper tool, then readjusted them. Surprised to say, that did the trick. So, for every brush I'm going to adjust with the vertex tool, I should split into triangles first? 

Basicly. It's slow but that the way brushwork is. It depends on how complex the shapes are, for simple terrain you can get away with wedges as long as the centrepoints are fairly central to the brush.

For complex stuff you'll most likely have to break it to four pointed brushes. 

So, for every brush I'm going to adjust with the vertex tool, I should split into triangles first?

not really. providing you keep your faces legal then there should be no need for this.

if you can't figure out what a legal face is then imagine 4 points laid out in a square, like so:

1____2

3____4

and imagine you have a square sheet of thin metal that sits on top of it, meeting each point at the corners.

now, imagine raising point 4 by 5cm or so, and trying to lift one corner of the metal sheet to align with it.. you'll see there's no way to do it without bending the sheet. this is the equivalent of creating an illegal face in your map, so WC ends up trying to correct it when exporting. in order to make it legal yourself, you could either a) raise points 2 & 3 by 2.5cm each, or b) saw the sheet in half diagnonally (clipping equivalent) so you end up splitting the face into 2, which gives you more flexibility (as has been said, 3-sided faces are always legal)

i'm not sure legal/illegal is really the best term but it works :p ..i guess than had it right with 'planar'