Hi,

I just started mapping again after many years gone. I've been working on a re-mix of my Quake level "Well of Wishes" (original map was lost in a hard drive crash) and I ran across an odd thing. I uploaded a map to quaketastic to illustrate, but basically I am able to push items through solid geometry, but only from certain directions. I was trying to find a way to add items as the player progressed using the fewest possible entities/brushes, but without resorting to a custom progs.dat and When I first came up with this I didn't realize the item bounding boxes were so tall


I may not use this method because it seems like might be more of a bug in the engine than anything else, but I was wondering if anyone knew why this happens. In the map I uploaded there are 4 alcoves with nails and health in each. The wall above the alcove is low enough that the player can't pass and get to the items. In the actual level the alcove would be hidden by a func_illusionary and when triggered they would be pushed into view by the func_door.
The only engines I've tried are fitzquake085, winquake and glquake, but it does the same thing in all three. The door will push the items through only from the north and east, from south and west the items fall through the floor when they pass through the wall.

If anybody wants to check this out, the example map is here:

http://www.quaketastic.com/upload/files/misc/doortest.zip

Shoot the buttons above each alcove to trigger the pushing door.
Turn on r_showbboxes in fitzquake for a more interesting view.

Back to mapping for now. 

That's because the wall is too low - the items' bounding boxes are 64 units tall. I don't know why it works - albeit with a visible clipping glitch - on two sides but doesn't on the other two (probably related to the bottom right back corner origin thing of entities). Since you're going to use two funcs anyway, you could make the illusionary an addtional door or wall and killtarget it, or let the items drop from a closet in the ceiling or in the floor. 

OK, I can't seem to get the time stamp field to do anything in either frame groups or skin groups -- is it used at all or does the engine lock that stuff down to a specific frame rate and that's the end of the story?

I'm changing values in my model editor but it's not having any effect on the speed of either kind of group. 

Yeah, I realize why it won't work, I was just baffled as to why it ever did in the first place. It must be some quirk in the engine code. I widened the alcoves by 64 units in each direction and items still drop out in only 2 of the 4 directions, so I don't think it's bounding box related.
Anyway, it's not a big deal as I was already using ceiling doors and floor doors in other places. 

The alcoves are fine, otherwise the items would drop out right away. The openings are not high enough - raise the brush under the buttons by 16 units and you'll see that all items are pushed out correctly. 

Really could use some help here. If someone could direct me to a tutorial for arched doorways in Radiant 1.5 for Quake III Arena, that'd be great. I've tried looking myself, and the one I did find was outdated and vague besides. If anyone has a video tutorial, that's even better. Thanks in advance!

Clock 

Do you mean the value that's meant to set duration of each frame? As I recall, they work correctly in software quake, and in glquake based engines, the value in the first frame in the framegroup gets applied to the entire framegroup. Recommended setting is to set all of them to the same value so that the behaviour is the same in all engines. But you could make the framegroup-wide setting modifiable like that... 

Well, I currently have it set up where you edit them all and I guess I'll leave it like that as the file format supports it even if the engine doesn't. Heh, oh well... 

Try this:
http://www.wemakemaps.com/doorway.htm 

 

Hi !

I was just wondering, is it possible to have transperent textures in quake? By that I mean textures which contain the image which is fully visible, but areas of the texture which are not rendered. A good example of this would a fence of some sort or barbed-wire.

I did hear that quake renders texures with the color value 0 (in the 8bit quake palette) as transperent, but I think this only works for sky textures.

Any help/advie is appreciated. 

Stock Quake doesn't do transparency in any way with the sole exception of the sky (as you noted). I think more advanced engines may support textures with alpha channels but I'm not sure. 

Ok, I'll see what I can do instead of using that then. Maybe I'll just model the fence, lol. 

You can use sprites to do that, if you don't mind the fact that they won't be lit by static or dynamic lights(which really limits you to placing them in bright locations or having them look quite odd. Quoth has a few examples of this. 

Cool, I;ll trya few different things and see how it goes. 

as long as you make the width not to far and keep a little distance it wont matter, it can even give a magic touch...
http://members.home.nl/gimli/sprite.jpg
but when you change your view it will also change.
http://members.home.nl/gimli/sprite1.jpg

For transparant texture colour look for Wally:
http://www.telefragged.com/wally/index.shtml
trabsparant colour RGB 159 91 83 ColourIndex 255 

Is there an understanding in the Quake modeling community that you won't be loading/saving MDL files over and over with any success? I'm struggling to get my model editor to load and save MDL files repeatedly but float drift and precision issues are causing it to eventually end up with the wrong number of vertices and blam, down she goes.

Do people just rebuild MDL files scratch each time they write them out or do editors typically allow you to load and save the native MDL file format repeatedly? 

That issue come up just recently somewhere. Might have been at Inside3D. 

Yes, meaning that people don't expect to be able to work natively with MDL? 

Oh, no idea about that. 

When I make models, I keep a copy in gmax for any editing, and just export to mdl when I need to. I try to ensure that the only edits I do once it's exported are to the skin and the flags. Last time this topic came up was http://www.celephais.net/board/view_thread.php?id=4&start=8259&end=8283

Since then, I have thought of an analogy for it. If you're making an image/texture in photoshop, you might export it to jpg or tga format in order to show it to somebody. But you'd keep a copy with all the layers in PSD format if you wanted to go back and edit it later. 

"Since then, I have thought of an analogy for it. If you're making an image/texture in photoshop, you might export it to jpg or tga format in order to show it to somebody. But you'd keep a copy with all the layers in PSD format if you wanted to go back and edit it later."

Fantastic! Yes, this is how I've come to think of it now. I'm going to create my own file format that can hold the model and it's frames in high precision and you can export to MDL as needed from there. This will basically act as a project file, holding the frames and skins together in one place until you are ready to export. 

And you could call it mdo!

:-p

QMe actually had two approaches to this. The older versions, 3.0 and earlier, used to store higher precision vertex information at the end of the mdl file, after all the stuff that the quake engine would look at. 3.1 onwards had it's own model format with the extension MDO, which stored higher precision vertices, bone information, etc. 

Is the �official� version of Qme - the one from Quake Terminus?

That one doesn�t seem to support skin groups, though the older MDO versions did - but they f-up UVW�s a fair bit (hit and miss).

Willam, the newer version does only have one format, but it also has two save options - �Save� and �Save as Quake model� the second version skimming off all the extra data.

Confusing, don�t know why they did that.

The Photoshop analogy is perfect �Save for Web�. 

From memory, I think that the full version you get from Quake Terminus is QMe 3.0. If you download the QMe 3.1 demo from somewhere, then it comes with a patch that will upgrade 3.0 full to 3.1 full. So if you do that, you'll have the most recent version, which has the previously mentioned MDO format.