So here I am, mapping away happily in WC 1.6. I make a wall, it has Texture X on it. I replace it with Texture Y. I save, and close WC for now. Upon re-loading the map in WC, the wall that I replaced with Texture Y, still has Texture X on it.

Apparently, this certain wall does not want to change its texture, no matter what I try. I mean, I can change the texture to Texture Y during my current session in WC, but once I save and re-open it, the texture reverted itself back to Texture X. What black magic is this?

Anybody else experience something like this, and have a solution? 

You've got to rename texture X or Y to fix it, inside the Wad. I'm not sure what the proper convention is so that Worldcraft doesn't revert your textures. Alot of Kell's metal textures have the same problem, just for the name, though its not something that was possible to forsee.

Its an irritating bug but can be easily solved in TexMex. 

Renaming the texture in the wad file was not helping. Here was my situation.

I have 3 textures. wbrick_egy wbrick_egyv1 and wbrick_egyv2.

The wall that was reverting its texture was the texture wbrick_egyv1. So I went into Wally and renamed the 2 textures to wbrick_egvn1 and wbrick_egvn2.

So back into WC, the texture name of the wall was wbrick_egyv1. If I changed the texture to wbrick_egvn1, it would look like it changed, but in reality, the texture name was still wbrick_egyv1. So no matter what texture I could have put on that wall, the texture would have always been wbrick_egyv1.

So the only thing I could do to fix it was to delete the wall and make a new one with the correct texture. 

I believe WC 1.6 only uses the first 8 letters of a texture name when matching names. 

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.