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. 

"And you could call it mdo! "

Well, sure, but usable on a Mac. :) 

 

I might have asked this before, but didn't get an answer or at least can't find it anymore.

Is it possible to use the activatable trigger hack for teleporters and pushes? It doesn't work the regular way (use classname/touch SUB_Null) and I couldn't get it to work by experimenting with the related fields/functions in triggers.qc, so maybe I missed something important - or does it just not work at all with these two?

A func_door can't have it's owner set to the player (1), or what? Works for all funcs I tested but not simple doors. Is there a work-around, am I just too dumb or do I have to use something else here (train etc)? 

Teleports don't activate until triggered if they have a name - ?

I've experimented with the push before but can't remember how it ended up. 

The thing that makes trigger_teleport and trigger_push fail is that both functions precache sounds during their spawnfunctions, an action which is illegal after the frames begin.

As luck would have it, there is a very easy fix in the case of the trigger_teleport. Set spawnflag 2 on your info_notnull. This is the SILENT flag, which means the file will not be precached. This does mean that you lose the ambient sound of the teleporter, but not the sounds when you actually teleport from it.

trigger_push is not so fortunate, so we have to work a bit harder. What we do is directly set the touch function ourselves, and then make the use function perform the trigger initialisation instead. The only other things that the trigger_push spawnfunction does is precache the sound, and set a default .speed on the entity.

The fields should look like:

use InitTrigger
touch trigger_push_touch
speed 1000


The problem with func_door is that .owner is already used for doors - it points to the master door. Even if you could construct an entity which has all the settings of a door except .owner equal to the player, you'd cause crashes as soon as you tried to open it. So a func_train or func_plat is probably the best bet. 

I didn't think it was that easy. There are other teleporters in the map already, so I assumed the precaching was taken care of. It wasn't supposed to have a sound anyway (and if it had been, a train_wait/noise entity could have done the trick).

The door is supposed to ensure that monsters can walk across seperated platforms - since they're skip-textured, it doesn't really matter which kind of func is used.

ijed: A trigger_teleport with a targetname only teleports if it's triggered (=by the player, unless another hack is used). However, I wanted a cleaner, or let's say, less dirty solution which also allows monsters to be teleported. 

The trigger_teleport is functional, however, since it has a targetname (inevitably), it has to be fired again in order to trigger the teleportation (like a regular one). I tried InitTrigger and teleport_touch, but to no avail. Is it even possible to have an activatable touch-teleporter with this setup? 

I think you should be able to hack around that it by setting nextthink to 999999, or a similarly large number. Then it should work until that time is reached in-game. I imagine that 999999 seconds is long enough that something else breaks first, so it's a fairly safe, if ugly, hack. 

And now I finally understand what nextthink in QC. 

*does 

Issues start happening at 9.7 days, where the floats get big enough lose accuracy at the 0.1 seconds order of magnitude. There are 86400 seconds in a day, so that should be high enough, albeit hacky... 

... 

would it be possible to get monsters mad at something like a hurt trigger or something [like say zombies] so that they attack it? does what i just typed make sense? anyways, it would be cool if i could do that without mod, using quoth for mod btw :O 

i think you could haxor the edict number of a trigger_hurt into a monster's .enemy field when building the map, but the monster will just go after it right at map spawn time. this isn't great since the player might not be there yet to see what happens.
you could maybe hide the monster away in a monster closet or something i guess and open it up when the player is in the right spot.

but you can't do anything more complex without changing a fundamental thing about the AI.

specifically, the damage/combat reaction and sight reaction. the only way for a monster to get angry at something else is if it's 'found' via searching (which normally only looks for clients, which is even more selective) or being hurt.

except that when being hurt, all sources except players and monsters (.flags = FL_MONSTER) are discarded. besides, it'd be a cheap hack to make the monster attack a trigger_hurt by first having the trigger 'damage' the monster.

so that leaves sight.
adding it in there wouldn't be a big deal, but you'd need to add it in after searching for players, and then as either a find loop or a findradius.
still, that doesn't really make it useful since if the trigger is in sight, the monster will just go attack it regardless of if the player is around to see it happen.

so what's left would be making some kind of script object that, when triggered, makes the monster angry at a specific entity.
that sounds like the best bet here.