the new java version worked fine :) 

there are some here:
http://www.gamers.org/pub/idgames2/graphics/desktop/

but Trinca if you have some nice different ones please post them here. 

are alias .tri files ascii? 

http://trinca.planetaclix.pt/ico.rar only two :| 

You're welcome. Glad I could help. 

where are you, you little idiot? i miss the axially-designed mapping madness! 

winquake has a nice q-rune icon - i use it for my quest shortcut 

... 

I don't think so. 

was just asking to possibly be able to help this guy working on a quake NDS port:

Actually, does anyone here have any experience with the Quake engine? I've been playing Quake on the tube in the morning but upgrading the networking has somehow corrupted my save file! And I was nearing the end of the game! No fair!

http://forum.gbadev.org/viewtopic.php?t=11556&start=15 

Quake's .sav files are basicly dumps of the network, possibly specially formatted, I dunno, but the jist of it is, the engine must be able to speak whatever protocol the demos use.

Someone needs to confirm this to be sure, but I'm pretty certain of the above. 

i thought they were dumps of the server state, meaning they contain the entire level and not just the part that is sent to the client. But this is all speculation of course. 

Well, client demos are dumps of network traffic the client receives.

Server demos, I dunno... I'm guessing that as server demos are mostly compatible with client demos, that it's pretty much more of the same, but with info about more stuffs.

Of course, SP demos are different again, as they already know about everything. It's probably just yet another client demo... 

I thought we were talking about savegames, not demos. 

My bad :) 

You can "corrupt" a savegame if you change the progs.dat file in such a way that the order of precaches changes. Then things will get the wrong modelindex and look odd. I don't know if that's what he means by corrupted though, it sounds more serious than just this... 

But not sure about the save games. If you open a .sav file in a text editor they appear to just contain a dump of the state of everything in the map along with some unknown values/data at the start of the file. 

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.