http://necros.slipgateconstruct.com/temp/nowthatsafiend.jpg

Silly mistake... tried reading in verts on the frames directly. :P 

It's nice that that .plan stuff is archived. I never had internet back then (plus I was too young) but that seems very interesting now. :) 

Good stuff with the fiend. You gonna take this all the way and do texturing too?

The .plan archive is essential reading, it's a great window into the thinking behind why much of Quake is the way it is, and can be very informative for decisions of the "should I add/remove/change this feature?" kind. 

http://necros.slipgateconstruct.com/temp/yayskins.jpg 

I can see its eye in that shot :) 

Fiends don't have eyes. 

You guys don't do a whole lot of looking at things, do you?

http://www.lunaran.com/pics/fiends...

And now, shambler will argue that those aren't actually eyes: 

http://www.lunaran.com/pics/fiendshaveeyes.jpg
ZOMG! I've been wrong all this time!!! 

I thought those were nipples? 

Now that the RMQ project has split up, what's happening with the BSP2 format? Will it still be updated? Do any engines other than the RMQ Engine support it yet?

Also, is anyone willing to do some coding for new boss monsters? PM is currently cleaning up and debugging Drake, but doesn't want to spend time adding entirely new monsters/features/etc. I totally understand this POV but it'd be nice if Drake had a unique final boss of some sort.

Looks like eyes to me. Now the Shambler, on the other hand... 

With no eyes? This is horrible. 

Glases are fine, horns another question.

http://members.home.nl/gimli/gdemon.jpg 

maybe I'm just tired, but that was hilarious. :D 

Since I was linked here from IRC, I might as well answer to Tronyn:

FTE and Darkplaces (and Hmap2) support BSP2, but DP's version is slightly different.

I would guess that DirectQ also supports it, and Baker and Rook's engines might as well.

I have switched to Warsow's FBSP for my project, so BSP2 will get no updates from me. The Schism team would probably be the ones to maintain it now. Perhaps ask at their forum.

You should talk to MH, Spike and Lordhavoc to get the BSP2 support in those engines harmonised.

Quakespasm did not want to support BSP2 when I asked.

I don't normally read this forum anymore, but I'm willing to help where I can. Poke me per mail or IRC if someone wants to talk to me. 

http://necros.slipgateconstruct.com/temp/objdrawing.jpg

Thanks to preach for his pcx loading code in the md3tomdl converter. The runlength encoding stuff was confusing the crap out of me.
Also, I had to flip the pcx data on the x axis AND reverse the pixel array order after loading it... is that normal? If it's not then I must have messed up the UVs on the OBJ... 

actually, flipping x axis and reversing the order is basically just flipping y axis right? :P 

looks like it's a thing with obj... just flipped v component when loading the obj instead of goofing with the pcx. 

There is an issue to be aware of with "intuitive" coordinates and storage of data. The natural order of storing skin/image data (at least the one taken in the mdl format) comes about I think from their usual representation as a string (in the purest array of numbers sense). Since we are used to text flowing from left-to-right then step down a line and repeat (for english-speakers) we extend that idea to the order pixels should be stored in the skin.

The place where this begins to cause a conflict is when we start thinking about cartesian co-ordinates on the skin. The standard mathematical axes on a graph has the y value increase as you move upwards. So if you have something that wants to put the origin of the coordinates in the bottom-left of the skin, you need to reflect the skin in y to compensate.

Having said that, if you're actually going to render the 2d skin somewhere, you really ought to apply the reflection to the skin vertices rather than the image file itself. Otherwise you will cause a lot of confusion for the user who has an expectation on what their skin looked like. 

Having said that, if you're actually going to render the 2d skin somewhere, you really ought to apply the reflection to the skin vertices rather than the image file itself. Otherwise you will cause a lot of confusion for the user who has an expectation on what their skin looked like.

Yes, this is what I ended up doing. I want to be able to display the skin either for drawing on (probably not) or changing UV coordinates, so having the thing upside down is not an option.

Turns out that this is a common thing with the OBJ format as many of the loading examples I read had a bit of code involving flipping the v component of the texture coordinates. 

OBJ -> MDL perfectly functional! FUCK YEAH.
Still can't import more than 1 frame, but I don't think that's going to be a big deal. 

Suppose that we have the following functions:

is_first_player: returns true if self is the first player in the server

is_last_player: returns true if self is the last player in the server

toggle_func_playerclips: finds all func_playerclip entities in the map and toggles them between SOLID_BSP and SOLID_NOT.

Your task: comment and critique the following scheme for implementing func_playerclip entities:
1) add
if(is_first_player())
    toggle_func_playerclips();
to PlayerPreThink.
2) add
if(is_last_player())
    toggle_func_playerclips();
to PlayerPostThink.

The main question for consideration: is there any way for a player to become 'stuck'? Extra credit for considering the implications if is_first_player and is_last_player are not available. 

Forgot to preview so the entities weren't encoded...

Your task: comment and critique the following scheme for implementing func_playerclip entities:
1) add
if(is_first_player())
����toggle_func_playerclips();
to PlayerPreThink.
2) add
if(is_last_player())
����toggle_func_playerclips();
to PlayerPostThink. 

You might not be able to change .solid like that without setting model.
Might be safer to do the func_togglewall trick where you translate the clipmodel far away when 'off' and put it back into place when 'on'.

Beyond that, at first glance, seems like it would work? 

Hey, thanks for the response - helpful stuff. What's your email / how can I contact you? PS all the stuff on your blog looks amazing. Cheers. 

You might not be able to change .solid like that without setting model.
Might be safer to do the func_togglewall trick where you translate the clipmodel far away when 'off' and put it back into place when 'on'.

Yeah, I explained myself badly. The plan was to only describe abstract functions, so you could assume they were correct without getting bogged down. I leaked too many implementation details...

There's still one case I can think of where it breaks down though - the trick is to work out when the player moves other than within the player physics code. There's also a more philosophical quandary with pointcontents I meant to bring up in the first post.

I'm glad you mentioned togglewalls, because although they seem quite hackish with the far-away trick, it has some hidden advantages. The prime one is avoiding ever toggling solid status within a touch function - which can be a fatal error. Building a monsterclip with the same broad outline would now become feasible.

You do have to bind the toggling to calls to walkmove and movetogoal, because monsters don't have the simple physics-wrapping functions that players do. This means that the monsterclip is imperfect in a way that the playerclip is not: falling or jumping monsters will pass through monsterclip. Still, better than a kick in the teeth.