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.) 

i hadn't know that.

hm... well, you could do this instead:
restrict the player's movement and viewpoint until the player presses a certain key (send a impulse) to quit from reading.
spawn the book sprite in front of the player at the appropriate distance.

i think there'd be problems with this method though, because the sprite might get spawned too near to walls and get clipped inside...

you could make the entity turn the player to an exact angle to get rid of that though... this would need a lot of fine tuning, i suspect... probably more work that it's worth...

oh wait! you could just have a .mdl which was a flat polygon with the skin of the book on it... then just load up different skins on the same model and cycle through them as you 'read'. 

The original idea was to use good ol' centerprint, while the player stayed more or less still and impulsed as required, and could just turn/back away at any time. After all, if something decides that reading player is the dish of the day, you want to be able to run away.

Besides, how many 'pages' of text is a player willing to page through? My personal suspicion is about eight. What do the rest of you think? 

1 or 2.

depending on how much text there was. quake is all about action, so unless the book was fairly interesting, i doubt i would read more than a couple of pages. 

for the mod. If it is a Quake based Action\Adventure game, the way The Demon King was, fairly detailed text may be necessary to fullfill sequences of quest and such.

I tend to lean to the position that you can have narative driven episodes that donot take volumes of text to accomplish the goal like in the Rune of the Space God.

The most brilliant example I have seen of this is in a Half-Life map called Someplace Else where the player is directed on his mission located on a remote Xen based floating isle by a hyper intelligent alien hiding from the Xen creatures.

(I would also recommend it for its map design -- it is an interesting mixture of Sock_tech and Xen.) 

and heavily inspired by Aliens, not that that's a bad thing. 

my work has begun to slow down due to taking on duel employment. i was curious how much longer i have, to try to minimalize the allnighters if possible. 

I've been pulling all nighters with school alone lately. But thankfully I have December basically off, so I hope to get some done. I think the spring/summer ish period is still a good release date.

As for the concept, I don't think it will be really ultra-coherent, but it would be fun to tell a simple but dramatic story through the project. Still not sure how many maps I'll have (1, 2, or 3). How's everyone else's stuff going? 

The trigger_read still won't work properly, I'm getting sick of my Arcane map, the goddamn fargnaxing Library is still too damn dark, and the Graveyard just isn't cohering at all.

What I might do over the weekend is release a version of the resource set without a few things. At the very least it'll give you lowlives something to play with while I fix up the rest of it. 

While I said I would release a version this weekend, bear in mind that there's still a lot of stuff that doesn't work properly. However, it should be enough to help build/populate your maps with guns and things to test 'em on. Damn this fine weather!

http://www.planetquake.com/fatty/smile/betas/arcane_v0-9.zip 

2500 brushes, 410 entities... still going. Can't send a sample yet, as my floppy drive shat itself (and I'm not "connected" at home). I'll get a new one sometime soon. Are standard ogres and zombies staying in? 

I haven't removed any monsters.

I've also decided to dike the directional part of the trigger_read for convenience; now I have to figure out how to make the impulse detection less scattershot.

/me peers at reference to figure out what needs doing next 

...didn't the Demon King (TDK) mod have a working "read" function? 

I'll see if I have it, or can find it, or something. I was disk-diving just before trying to find a suitable ammo model for the chaingun's slugs. I just hope any decompiled code is easy to understand.

(Incidentally, the reading stuff actually works fine, I think. I just have to tweak my test sample first...) 

I just came up with a random idea the other day that might be neat. I've been looking into how one could make it possible to pick up objects the map... a la half-life 2. An impulse command would trigger the closest object the player is facing to lift up.. and be 'carried' by the player until the object is set down. The difficulty might be preventing the object from clipping through walls? I dont know.. my quake c is pretty weak ;)

Say, the player would have to find some objects such as candelabras or other magic items around the map and arrange them to perform some sort of ritual, perhaps something they could read about in a book using the 'trigger_read' :)
There could be triggers to detect if the objects were placed in the correct places.. 

wouldn't work with quake.

theoretically, you could continuously set the object's velocity to the player's velocity, but you'd need to do it almost constantly. if a player got bad framerate (say 10-20fps) the velocity updating wouldn't be smooth, and the object would get out of sync. so you'd also need a check to reset the position in relation to the player every so often or if the object moves to far out of sync.

overly complicated for very little returns... i wouldn't bother with it.

'course, it ain't my mod. :D 

on the other hand, you could just keep setting the object's origin in relation to the player's taking into account the player's angles as well, but that would still succumb to unsmooth movement...