edict dump with the progs globals section in the beginning. It has nothing to do with the protocol, but everything to do with the progs version when it was saved.

Depending on the nature of progs changes, the sav file will be invalidated or not.

And sometimes, you don't even have to change the progs to get an invalid sav file. This is typically caused by non-deterministic precaching, so depending on random, the sav file will work or not. In this case, it's a bug in the progs and should be fixed. 

...vote for more gibbie. 

<Kinn^> whoa
<Kinn^> wtf, i just had the worst nightmare o_O
<Killes> tell us now
<Kinn^> ok, i dreamt that i was talking to shambler on msn messenger, and that somehow gave him secret control to reboot and bluescreen my computer, and i never caught on, so i'd keep walking straight into his little trap over and over and when i realised what was happening i felt so betrayed :{
<Killes> rofl 

~_^ 

Is there a problem with your email address? 

am I correct to infer that there's a 1:1 correlation between mesh verts and st verts in an .mdl, and that models have to therefore be physically separated along UV seams? 

been experimenting with that recently, and it's the only way to get a 'uvw style' skinmap in q1.

you were talking about q1 right? 

The only time you can get away with not seperating them is when you perform a planar map using the original ID method. Then you can get the same vertex twice on the skin without splitting them on the model. The problem is that it's very restrictive, as if the first vertex is at position (s,t) the second vertex has to be at (skinwidth/2 + s, t). Which basically restricts you to exactly the same style skin as the original quake models. It's possible you could do some parts of the skin like that, and some parts with seperated uv/mesh verts, but it'd be quite a lot of effort.

I'm looking at making a little command line tool to help models with split UV's like this. I've already done the nice easy things like fixing uv's out of bounds - if uv's aren't between 0 and skinwidth/skinheight they give an access error in QMe and display garbage on the skin in software mode outside the bounds of the original skin. In GL the skin tiles as you'd expect, but if you want compatibility with software you can't use that trick. Hopefully the next thing I'll add is to correct smoothing on split vertices. It'll look at all vertices that occupy a single point per frame, and recalculate the vertex normals for all of them. That way the split will be better hidden on the model by the shading. 

Preach are u the aerowalk maker? 

Got this name before I knew about Preacher, the author of that map, otherwise I wouldn't have gone for something so confusing : - ). 

hehe thks ;) 

and yeah, that uv thing is disappointing. do split edges show with obvious horror in-game, like with sparklies and etc?

I bet if you were smart about your character design (and exported a base frame that was terrifically mangled) you could make the id method work pretty well. Maybe I'll go with that instead of trying to fight it. 

but lighting doesn't get interpolated smoothly over the edges like it normally does. it's not really bad though. if you look for it, you see it, but it's not 'zomg, wtf ugly!' bad. 

It's not a big problem, it's just something that's fixable in theory, and shouldn't be too hard to put into the utility I'm writing anyway. Sometimes it might even be a desirable effect, for instance if you have two materials on a mesh that's all one piece to keep the poly count down. You can split the UV's along a polygon, get a nice solid edge between the two objects, and they get shaded differently to distinguish them. Of course, you can achieve the same thing by just building them as two seperate objects in the first place... 

The lack of vertex smoothing can be easily hidden by just placing the seams in intelligent places. Developers before us have already established a nice canon of tricks like shoulder pads and thigh bracers to mask such things. The details and elements you paint into the skin can cover up such things as well.

Is the 320x200 skin size limit imposed only by modelgen/lbm, or by software quake? I'm planning on rolling targalib into the modelgen code at some point merely for my own sanity. 

I've certainly had models with 256x256 skins load ing in winquake with no trouble, and I don't see anything bar memory being an upper limit. Best in fact to stick with power of 2 skinsizes for the sake of GL engines, as they'll get resampled to the nearest size anyway. 

I was thinking a 128x256 or a 256x512 for ease of acceptance with the half-shift thing.

Ok, this is going to be fun methinks. :) 

You're a fucking weirdo :)

The scary thing is, I am on MSNger a lot... 

"Left for dead"

Its a 4 player survival co-op game with 4 human players vs a city of zombie hordes, sounds pretty cool, also humans can play as the zombies as well if they like.

Some (not so legal) scans are here:

http://www.refugeecamp.co.uk/Files/l4d/page1.jpg
http://www.refugeecamp.co.uk/Files/l4d/page2.jpg
http://www.refugeecamp.co.uk/Files/l4d/page3.jpg
http://www.refugeecamp.co.uk/Files/l4d/page4.jpg
http://www.refugeecamp.co.uk/Files/l4d/page5.jpg
http://www.refugeecamp.co.uk/Files/l4d/page6.jpg 

That looks to have plenty of badass potential... 

 

will see... 

I do remember quite a buzz around here for a multi-player coop game and it seems that is what valve is doing, it sounds really interesting anyways! 

Looks interesting, looking forward to seeing how that plays... Only thing I regret, is that those shots don't seem to be showing any real anti-zombie weapons, like old vinyl discs, golf clubs, and lawnmowers, seems to be only fire arms at the moment, and for me any good zombie film needs to feature more... interesting, weapons (I think this is what Dead Rising did? haven't tried that). 

Here we go: http://shub-hub.quaddicted.com
The password is ilovetheshubhub
Let's see how it works :)