First you lead us to the dark side of the progs, now you advertise methods of preventing the use of hacks... I can't map without them!

But yeah, mod/version conflicts are a potential problem indeed. Take the differences in model/precache handling in Quoth 1 and 2 for example. I had to come up with a crude way of progs detection in my 768 map in order to make the backpacks in the end arena appear correctly in each version. 

Preach is working for an antivirus program provider company: those guys are hackers one day, and the other they sell you the latest update of their tool... swindler !!! 

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.