you probably already know this, but i thought i'd mention that it's best if your skins are in powers of two dimensions, like textures are:
64x64, 128x128, 512x256, etc...
otherwise, glquake needs to resize them itself, and the results aren't usually pretty.

cheers (though i still can't see the website :P) 

its actually best if you do them by increments of four, it seams to work out better, and is compatible for more custom engines. 

i was finally able to access the monster page!!! those are some damn impressive monsters! i like the spikey fiend!
also, lots of detail on the skins is a major plus as well.

roxors! 

i hate lil jon.

any way thanks for the compliment. 

OOOOOKKKKAAAAAYYYYYY 

put up some more stuff and got the "pinky" like thing i created, or at least created upon as much of the original pinky as i could remember and quite frankly there arent that many classic doom pictures available now that the new one is out.


http://buckmontgomery.tripod.com/models 

I went ahead a sent some pinky pics that may help you. They are actually the in game sprites.

I've been replaying Rouge lately (thanks Tronyn!), and I can't help but think that the monsters on the first two pages in particular would look good for a Hell Fortress styled episode. 

Not too sure about that pinky. It'd be better if you based him off the Doom3 pinky, but without the silly "cyber" bits. 

I really like it. I don't know if it suits the project, but if it's completely animated then I wouldn't mind fiddling around with it!

... not that I have any time these days, but it still looks cool. 

i checked out cyberquake, its pretty cool concept. i sent you an .mdl of a player model i had laying around that might fit that mod, and i currently have no use for. 

I still have some issues with the alt-weapons (Rogue stuff, chaingun etc.) Not only that, but I still have to implement explosive shells too, but that shouldn't take long once I find Painkeep and some other ammo model for the slugs - one that works.

Trigger_read is causing me to scratch my head. What the hell was I thinking when I coded it!?

I'm also preparing some prefabs for the rebuilding of Tower of Yoth in a more outre style, but until I figure out why FitzQuake is going all psychedelic, I'm going to concentrate on preparing the graveyard map. Depending on how complex the "topside" turns out, I might break it into two.

(Both the library/start map and the graveyard are "contemporary", so I'll use radiosity lighting. For some reason FQ renders those sorts of lightmaps properly. Sigh... I'd rather be modding in Morrowind.) 

can you send me the drone animations again, i cant remember where i saved them to. 

I can get that to you tommorow afternoon.

Cheers, 

tomorrow. 

And shoot me out into the sea.
You got me there, Captain! 

I still don't understand what exactly trigger_read is.
Does it simply display some text to the player or is there anything more? 

trigger_read entities, when touched, allow the player to "open" books (or any other object bearing gobs of textual information) and "page through" them.

The trigger itself is actually a point entity about the size of an info_player_start, which the player has to not only touch, but be facing in the right direction to use.

The text itself is held in multiple info_page entities with the same targetname as the trigger's target, with the sequence marked by the count key.

The overall effect is: player sees an open book, or plaque on the wall, and goes over to it. He should at first hear a beep and see a message top left; "Reading matter here" or somesuch. Impulse XXX presents the first page, which is persistent until either he moves away (which closes the "book") or impulses again to go to the next page.

This has been causing me some grief to get working, but I think I may have cracked it by having the trigger be far more pro-active now. 

sounds hard on edicts...

would it not be better to store all the strings in the same entity via say, message1, message2, message3, message4, etc... up to maybe 20 (surely no book can have more than 20 pages...) or whatever... otherwise, a 10 page book will use up 11 edicts, one info_page for each page plus the trigger itself...

just a 0.02$ contribution... :) 

sounds good. I have a perfect place in my map to use it.
But as necros said, will edicts be a problem then? 

You might have a good point there, but then every entity would have twenty strings allocated to it. Wouldn't that bloat the in-game data enormously?

(I have to admit it would make paging much easier though...) 

would be to use existing string fields that are either unreferenced in the C code, or would have no side-effects anyway - .message, .netname, .noise, .noise1, .noise2, .noise3, .noise4, .wad, .map, .deathtype...to name just ten.

It might look a bit ugly, but it's better than declaring new entity variables. 

it might have mattered on a 486.

as far as i know, there aren't any hard limits in qc that prevent one from making tons of new variables.

god knows i must have added at least 3 times the amount of vars into this one project.

sadly, one cannot use arrays... :\ 

This sounds really cool.. One could make a somewhat deeper plot than usual for Quake ;)

How is the actual text displayed on the screen? Is it just using the centerprint function?
I guess the only other way would be using a modified engine with fancier a 'book' background and nicer font. 

just spawn a sprite which behaves like the weapon model in that it tracks the player's viewpoint. i'm not sure exactly how to do this, but i know it's possible.

it could be as simple as temporarily replacing the player's viewweap with the book sprite then putting it back when the trigger is turned off. 

sprites can't be used as weapon models. Crashes the game (at least, it crashes glquake.)