It was the first calling remove(self) in arrow_touch I came to.
I didn't realize it had to be the second one on the end of the script.

It's working well now, thanks! 

But shouldn't just adding 'nextthink X' and leaving SUB_remove have this work?

The projectiles would still do damage while waiting to be removed, but not if their touch was changed / removed.

Argh. The definition of complex - lots of simple. 

I followed the code of Dr.Shadowborgh to make a new weapon in Quake1. I added the Q2 g_rail gun and assigned it to the double shotgun.

So far so good.

Now my concern is starting a game with the g_rail.mdl.
Although this weapon is coded on the doubleshotgun (3) it loses its touch when I switch to the shotgun.
So when I still have enough cells to shoot, the game only offers me the railgun again when I collect the DS.
So stop shooting is gone gun.

I am forced to add a double shotgun too before I can acces the railgun again.

Is there a model-code to solve this?.
example:
http://members.home.nl/gimli/grail.zip 

assignement is 8
replacement thunderbolt. 

normally, i would just do a dxf export from qme and import that into 3ds, but for what i want to do, i need a fully animated model (with all it's frames in order).

i have a .mdl converter (mdl.exe) but it's about the dumbest thing i've ever seen as the program outputs all the frames as seperate meshes into the .3ds file it outputs. so when you import it, you get like 150~ duplicate meshes, all different frames.

am i sol for this? any utilities i'm unaware of? 

Post it.

I've been hunting but have drawn a blank so far. 

Don't you have the Q2MDLR9B, I searched for it but it's one old Q2 mdl converter with also Q1 models. It exports into 3DS very easily compatible toMax3D.
Here's a linkhttp://members.home.nl/gimli/q2mdlr9b.zip: 

http://members.home.nl/gimli/q2mdlr9b.zip 

no luck, sadly. q2mdlr exports each frame seperately as well. :S 

i think maybe the solution is in 3dsmax and not the exporters... there might be some way to create a vertex animation out of multiple copies of a mesh as long as the vertex # are consistent.

the thing that jumps out immediately would be to use the morph modifier with 1 channel for each frame, and to incrementally toggle each one on and off on the appropriate frames, but that would be extremely annoying and there might be a limit to how many morph targets you can have. 

Morph would do it, but be very time consuming.

A nastier problem would be that each model would be its own object, and so have the verticies number individually - there's no way to manage this in max.

Normally with morph you use instances of the same object so that the verts have the same numbers - different objects would most likely get interpolated all over the place.

Bones is the way to go - but that means recreating all the monsters as such :P 

It wouldn't take much time really - what's needed is a decent morph plugin that allows more vert control - morphing via position as opposed to number.

Will be looking around. 

My usual route is to convert it to md2 format using QMe, and then importing that with an import script(this is gmax, but I'm pretty sure that the same script can be found for 3dsmax). I do worry that some animation quality is lost in the conversion. It is potentially avoidable, by choosing the scale to be the same in each frame of the md2 you can get a lossless conversion, however I suspect that QMe does not do that.

If the fidelity of the animation proves to be a problem, then I might be able to knock up a python script or something which does mdl->md2 lossless conversion(modulo the skin, which would just get mapped index for index). 

the gmax md2 importer script here: http://www.scriptspot.com/3ds-max/quake-ii-md2-importer works with 3ds max 9. i was able to import some stock q2 models in with full animations in.

next i'll try converting to q2 from q1 format. 

success! thanks for the help! ^_^ 

 

If it works with 9 and gmax then in theory it'll work with all versions since gmax was discontinued a few years ago (?) so it should be alongside the .3ds format - one of the few things they don't fuck about with on a version by version basis. 

I have come this far with my amphibian monster.

It stands on land and in water and starts its attack as soon as the player is in vieuw. The landmonster will start shooting and follows it into the water where it turns into swim behaviour.

The watermonster will go into swim position vieuwing the player, but only starts its attack when agitated. Also it hardly shoots as its position is somehow dull.

Point is I can't get it out of the water.
I'm trying to see with my hard-egged qc cramp what's going on but must admit I'm a dumbass.
Here's an example of the model:

http://members.home.nl/gimli/harpio.zip 

didn't look at the code, but for the (uncompleted) monster that was supposed to do what you are describing, i settled on making special monster jump triggers.

essentially, you would make your trigger in the area you wanted the monster to jump out of the water and you'd just set speed and height just like a normal jump trigger.
the only differences were that:
1. it didn't affect any other monsters
2. if it was a 'get out of water' trigger, it would do nothing if the monster was on land (and if it was in the water, 'get in the water' triggers would similarly do nothing).
it makes coding it a lot easier, but it kind of takes away from the monster by making it dependent on the mapper. (imagine if fiends only jumped where mappers put triggers, for example).

you could take a look at the code that makes the player jump out of the water. this could work but it could be troublesome.
the player code is run every frame, so it doesn't miss chances to jump out of the water.
but a monster not only is running it's code slower (0.1 seconds) because of movetogoal, it will never really be flush with walls unless it gets lucky.

otoh, if all you mean is you can't get the monster to walk out of the water on, say, a ramp, the trick is to take off the FL_SWIM flag early.

every frame of your swim function, run a test of the pointcontents over the monster's head (say 16 units over the monster's origin) and use that point to determine when to swim or walk. 

i wanted to ask you how you combined the legs, torso and head of the skeleton from quake3 when you converted it to quake1. i can't think of a way to do that in 3ds max while preserving the animation. :S 

I must admit I have only converted one frame of the deathscene,
where it stands straight with all limbs in line.

From there I made a 3ds file of it, which I used as baseframe.
Then in am2000 it is possible to make the model act with sepperated limbs and export the 3ds.

Then I bunched against the 1000 verts limits of Qmle, and had to substitute the torso with all the fine parts for a much simpeler one,
and then I could import the 3ds into QMLE.

It sounds simple, but I tried the knight in Max3d and must say the way it handles bones is much more specific I could give my patience.

Which programm do you use to convert the model?
I searched, as it was in answer of my question
how to convert q3 maps to Q1.
Something like Q3map2 :

http://shaderlab.com/q3map2 

mapping help #6458 

after 2 days of trial and error, i figured out a way to do it.

http://necros.quaddicted.com/temp/hunterq1.jpg
(hunter was always my favourite ^_^ )

the process is roundabout and exceedingly headache inducing. :P
also, if you want to do this, read my whole post first.

step 1: we need to get the 3 q3 md3 files (head, torso and legs) into 3ds max (in my case).
for this, i used this script: http://www.scriptspot.com/3ds-max/quake-iii-md3-importer-public-beta
surprisingly, it worked in 3ds max 9 (usually most scripts this old would never have worked).

if you follow the instructions on that web page, it will work properly: use the script to import upper.md3 first, then lower, then head. this will make sure the tags link up with the body parts.

(pre) step 2: involved transfering the animation key frames from the torso tag onto the torso mesh itself.
the torso doesn't actually move, it only has vertex animation; it uses the tag to make sure the torso is properly oriented with the legs but in order to export the animation, both the translation and rotation must be on the torso mesh object.

step 2: select your torso tag and go to file -> save animation.
save the file with a name of your choosing some place convenient.
now, select your torso mesh and unbind the mesh from the tag.
go to file -> load animation and select the file you saved earlier.
you will get a message box "No tracks are mapped. Create map file?" and click yes.
you'll see 3 list boxes, two on the sides with the middle one empty. Ctrl+Click on both the sides the item that says "Exposed World Transform" then click the button with the arrow "<-"
this tells max to use the world transform from the save file on the selected object. Click the "save mapping" button on the bottom and save it somewhere (not really important, it just doesn't let you load the animation without saving first) then click "load motion".
if everything was successful, your torso should now be moving on it's own, without being linked to the torso tag.

step 3: redo step2 except for the head.

step 4: now you need to rearrange the uv mapping. originally, head textures take up the same spot on uv maps as the body does, but when you are combining all of this into 1 model, you will have overlapping uvs for the head on the body area.
for a quake3 player model, the body is 256x256 and the head (in the case of hunter) comprised of 2 128x128 textures (the face + the feather hat).
i chose to make a 512x256 texture, with the body on the left, and the face+hat stacked on top of each other right next to the body. this leaves a 128x256 empty area we can use for the weapon.

step 5: before we can export, there is one final step to do. the thing that drove me crazy for the longest time was that the head would never export any frames, even though it had keyframes.
the problem is that the tool i had to use to convert the 3ds max models back to md3s (http://www.quakeunity.com/file=481) only looks at *vertex* animation when deciding if there's a key frame there or not. so what you need to do is go into the head at vertex sub-object level and add a key frame to any 1 vertex at the end of the animation. (i just move a vertex an incredibly small amount).

step 6: delete all the tags (they aren't needed) and export the whole model as an ase file. make sure you have it set to export keyframes every frame.

step 7: open up npherno's md3 compiler (http://www.quakeunity.com/file=481). import the ase file but only select 1 component. export the single component back into md3. close, reopen the program and do the same for the torso and head.

step 8: use preach's md3tomdl converter (http://www.btinternet.com/~chapterhonour/md3tomdl.zip) to convert the 3 pieces into mdls.

step 9: (these next steps are the 'dumb' parts) open qme and open up the legs. then, using import object, import the torso.
qme, annoyingly, has no options with what to do with incoming object's skin mapping, so although the nice uvw maps were preserved from the original md3 files, they will be placed next to each other. 

step 10: open quark 4.07 (yes, really). load your combined model. you'll notice your actual skin now is absolutely massive (i think it was 1536x256) because qme just kept adding stuff on the sides.
what you need to do in quark 4.07 is select the torso verts on the skin mapping editing window and slide them way over to the left (where the legs verts are).
for the head verts, i wasn't able to slide them over next to the body verts because they were considered 'on the other side' and so werent' allowed past the mid-point of the skinmap.
so i slide them just to the right of the mid-point.
finally, (still in quark) go into the edit -> model properties menu. change the width to 512 (make sure the 'right' radio button is selected so it will remove stuff from the right side, not the left).
this should place the head verts right next to the body verts and everything should be perfect. if not, the gods have not smiled uopn you and you are SOL, sorry.
Save.

step 11: now all that's left to do is to name your frames which you can do easily in qme.

yay, you have a q3 player model in quake with uvw and animations preserved. :P

note 1: i'm not sure if you could skip the 3dsmax process for the legs and torso, since the only real modification we had to do was with the head (regarding the uv mapping change).

note 2: there may be a way to collapse all 3 components into a single mesh object. the problem is that simply attaching the mesh objects together discards their vertex animation with no way of reclaiming them.
the other method involves using boolean with unify operations but you can't export frames that way because the key frames of the boolean operands don't count and the md3 compiler will only see 1 or 2 frames. (although this method does at least preserve the vertex animation)


so yeah, anyway, in most ways, it's probably better to do it the way you did madfox, import a single frame, combine it all into a single mesh, re-weight the vertices with new bones and animate it again yourself. this is the more logical way, i suppose, but i really wanted the original animations as well. :P 

npherno's md3 compiler: http://www.quakeunity.com/file=481

preach's md3tomdl: http://www.btinternet.com/~chapterhonour/md3tomdl.zip