is it possible to teleport weapons in ID1? 

 

Didn't stop the Reaperbot... impossible CHEATAR! 

I have a map file for quake that I have created with Hammer. I would like to continue working on this map using the QuakeED editor. Is there a tool to convert the map file to the right format? 

Hammer. :P 

.map? there's an export to .map option in hammer. 

The exported map is in a different format. Aguirres tools can handle it but other editors can't I guess. 

 

It's a pain in the nuts.

Export to .map and use a notepad++ find / replace function?

Probably a long shot though. 

possibly try using aguire's map converter utility? if you pass the .map through without actually doing anything, maybe it'll strip out the extraneous data when it parses the file? 

Between the two and it wouldn't work - not only is there more data, but its also rearranged, and alot of it is single numbers.

Convmap might be worth a shot, yeah, otherwise I'd suggest just continuing with WC for now. 

Is there a way to get a func_door to close regardless of what it's hitting? Say I want 2 doors to crush anything passing between them - at the moment, the one door immediately retreats back it's starting position while the other works as normal.

Is this fixable? 

is to set:

'wait' '-1'
'toggle' '1'
and manually retrigger to close after opening. 

isn't there a "crusher" flag that prevents doors from reopening on impact? 

 

The crusher flag is called "dmg" and should prevent the door from reopening if the value is high enough. And if not, give both doors the same "team" field. 

The "team" field didn't seem to work. The "dmg" is set at 10,000 so that should be high enough.

I dunno, I added a new spawnflag (SF_CRUSHER) and added a quick IF condition to the "door_blocked" function. That seemed to do it. 

Necros had it right first time about the crushing behaviour, it comes from setting wait to a negative number. Quoth the source(door_blocked):

// if a door has a negative wait, it would never come back if blocked,
// so let it just squash the object to death real fast
if (self.wait >= 0)
{
if (self.state == STATE_DOWN)
door_go_up ();
else
door_go_down ();
}

So as long as self.wait is less that 0 the door doesn't change direction. 

After several bumps in Quake modelling I won't get used to the fact a modelframe exported to dxf has a unique vertice and trianglecount.

It may be my poor knowledge of triangles and vertices but when I import this file in another editor and try to export them back to Qmle the vertices turn out higher and triangles are doubled.

I know it has something to do with triangles turned into quads and vice versa, but why doesn't these counts stay the same?
I don't add anything so that can't be the reason.
Is it the 8bit configuration, and nowadays 3Dstudio's 16 or 32bit? 

I've never had the issue, to be honest, but many do.

If you're working with editable poly then the 7 key isn't showing you a valid vertice / face count - change to mesh while working and the number practically doubles.

As a typical safety thing I'd export the model, open it, select all verts and do a weld within a distance of 0 then export and see if it opens.

If not then the model is bad from the start - having a vertex spike, multiple vertices in the same position etc. 

you're using 3ds max? make sure when you export that you only export the mesh.

3dsmax will export your bones as geometry without telling you. these may not show up if you import the frame alone into qme3.1 (ie: when they're inside the character mesh), but they will change the vertex/face count preventing you from combining the frame with the original model.

it's important to note that the reason it does this is because bones actually are just geometry. in fact, you can make your own bones out of boxes, spheres, splines, etc. the bones that max makes just have a premade shape to make it easier.

this also means that adding bones will increase the polycount in max's built in counter, so you should completely ignore that counter.

i've successfully used both custom rigs and biped in quake, so keep at it and check everything because it is possible. 

&startI'd really suggest that you start by not thinking of the .mdl format as the best container for your model. mdl format is not a robust way to store information about a 3D model, so you're always going to run into problems with this kind of thing. Repeated saving to .mdl while making changes can make the vertices wobble more than they need to, etc, although we love them because they render in quake engines we must accept mdl is bad.
(see also: http://www.celephais.net/board/view_thread.php?id=60097=155&end=180 onwards)

The way I think of it now is that you make your model in another editor, in a better format like .max (substitute a format of choice for the rest of this post), and then EXPORT to .mdl right at the end of the editing process. If I then decide that I want to add another animation to that model, I chuck out the .mdl format copy that currently exists, make the changes in the .max version, then export the .mdl again.

It's usually helpful if your pipeline to convert from .max format to .mdl is short and hands-off, you don't want to have to rotate/reflect/move the model at all during this process, in case you need to do it many times. Adding stuff like skins is a bit of a hassle, and you certainly don't want to be changing animations! Ideally, you don't even need to open the mdl during the conversion process, just export and then drop it in your progs directory. This might require a bit of trial and error in your main editor to get the model correctly scaled and rotate in game, which again is easier once the pipeline is short.

The problem often arises at the starting point, if you're trying to modify an existing .mdl file. It can be tempting to just keep working with the .mdl format, because it's "practically there" already. Even so, I think it's best to just import the model into .max format right at the start of the project, and make sure it matches up when you export it again. From there you can edit as normal.

(This post brought to you by 3DMax Studio, a piece of software Preach doesn't even own...) 

Ijed - I supose you're working in Max3d? As long as I use Qmle and Quark4.07 nothing goes wrong, but I'm tightened to only use manupulating tools like vetice change and rotating. Every output like the Qmle's dxf, or Milkshape's 3ds are the only way to keep the model clear. If I import to Max3D I haven't got the knowhow yet to even ad bones.

Necros - As I said I'm using the Am2000 studio I bought because it is the one that uses mdl files. Bad enough it is an other extentions then Ol'Quake uses. But it can import the dxf/3DS files. If it would be the creepy bone addon count I can't imagine 12 bones with 5 counterparts would end up in a double vertice count.
There the thing goes wrong and I can't get a grip on it.
Exporting them to one poly by count brings me the same model in QMLE, but I cant get up to the double verticecount.

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

Preach - I'm trying in the Max3D studio, but as I have hardly experience with it I can't make a thing of it. Max3D can't import mdl files I thought? I tried most extentions for in and export but I don't know how that double layer triangles appears. 

Ok, here's the pipeline I work with in gmax, and I'm pretty sure that it can be replicated in max3d.

Import:

MDL
use QMe to save it as
MD2
import into 3dsmax ( http://host-a.net/getfile.php?usern=Game_Genius&file=md2Importer.ms is a plugin for this step, which I haven't tried out)
MAX

I'm pretty sure that the mdl->md2 conversion doesn't do any harm, since in theory this conversion can be done exactly. If it turns out I'm wrong and it does wobble the vertices more, I'll probably write a quick program to do the conversion in this direction without the wobble. (*)

Export

MAX
export to MD3(there are loads of plugins which do this)
MD3
convert to MDL(I used to use quark for this, but since it's a pain to get working, I wrote http://www.btinternet.com/~chapterhonour/md3tomdl.zip for this step)
MDL

And the job is done.
_________________________
(*) I've moved the whole technical discussion from this post into a footnote. Ok, here's the deal with MD2. It still compresses vertex coordinates into a single byte like MDL, but the scale factor is slightly different. Instead of having one scale factor for the entire model, like quake 1 does, MD2 has a scale vector per frame. This gives you more control, but is often counterproductive.

For example, you might look at your source model, calculate the bounding box of the vertices in each frame, and then use the corresponding scale per frame. This affords you as fine a grain resolution as one byte can carry in each frame. The problem is that it can create much greater "floaty vertex syndrome", because the grid that all of your vertices snap to is changing every frame. If you had a sequence where the arm of your character waves, but the body remains mostly still, then the body ends up wobbling as the extent of the arm is changing the size of the bounding box.

It could be argued that the MDL method has an equally bad problem, that vertices can end up not moving at all from one frame to the next if the movements are slight. But I'd disagree on two points there. One is that the motion is more regular in time for MDL, stop-starts is compensated for by the brain better than random noise is. The other is that MDL motion is more controlled in space - if the head is just bobbing up and down during this wave animation, the vertices won't move left to right in the MDL. However, if the arm is changing the width of the bounding box in MD2 then the head might wobble from side to side, and the rounding effect might even make vertices go in opposite directions as the grid changes, some left, so right (or worse, some up and some down!)

If you agreed with me, then you might try and write a more sophisticated MD2 exporter. It could first look through all the frames in a sequence, and try to create groups of frames where the bounding box stays within 10% of the max in the group. Then it would use the same bounding box for that whole group. You might even relate bounding box changes to the amount of movement in the whole model, rather than just changes in the limits.

In any case, I've been a bit dishonest there contrasting MDL to MD2 because you can exactly replicate MDL behaviour with an MD2. Just set the same scale in every frame in the model! This is why during the import, it should be safe to convert from MDL to MD2, no information should be lost. Of course, going the other way you can't get an exact replica of every MD2 as a MDL, which is why we have MD3 as the intermediate format in that direction.