regardless of its origin, I'm sure Kinn coded the QuakeC for it so you'll need his permission though you could simply have the end user download the map into their Marcher directory so there would be no need for rebundling the pack file. 

Thank you for trying but when I place a monster_gauroch in the map it does not appear in the game.

The monster spawning works but exploding walls do not. I have other THINGS in my map that are not in Marcher Fortress. I have built my own progs.dat file from things I have found in the public domane.

I must try to talk to Kinn.

Kinn, are you there? 

The Marcher Gauroch, Imp and Spider are models originally from Hexen. Kinn reworked the skins and wrote entirely new code for them.

As a n00b mapper you can't always expect experienced members of the community to deliver their content on request.
Custom code is made available only at the discretion of the author, so unless it is explicitly stated somewhere - in a readme, webpage or tutorial - it is unlikely they want it available for other projects.

If you want to try making your own monsters by the same method - i.e. taking an existing model from a Quake-engine game ( such as one of the old mission packs or Hexen ) and writing new code - you'll get some help here from coders etc.

If you haven't made and released a map before though, it is adviseable to make your first project using only id content i.e. the stuff that originally comes with Quake. You'll avoid tripping up on a lot of technical problems and the like. Once you are more familiar with the basics you'll be in a better position to seek detailed assistance or, better yet, to start working on your own custom content :)

HTH 

I understand your explaining.

I will take the monsters from Hexen and will write the code and will ask for help here if I stuck on code. I have demo of Hexen2 and will take it apart now. Thank you for patience with me. 

IIRC, out of the custom monsters seen in Marcher Fortress, only the Imp is present in the Hexen 2 demo. You'll have to "take apart" the original full game to get the others. 

Thank you. I could not find the gauroch so thought it may not be in the demo. I will not buy the game so I will not get the gauroch. The imp is in the public domane already also the spiders. I am looking at the archer as he might be good for throwing different missiles but I would need to take the bow away or maybe change it.

I have to learn qME first and I have to learn coloring. Does anyone know of sites to learn about converting Hexen to Quake - Google knows nothing. 

Does anyone know how to get lightwave's vertex color or weight map into q3 maps via q3map2 and use them for rgbgen vertex or the like ? 

With ASE models with vertex alpha and vertex colour. I don't think it works. 

...I'm not sure anyone got back to you, but why not use two target_speaker, one that stops then one that starts? 

anyone one interested should look here http://www.quake3world.com/forum/viewtopic.php?t=4764

thanks for the input shallow. 

I using 3dMax7 at work to make models for Quake1SP. They good I think. When I load those into qME I get a "numbers of triangles" not matching error message.

Can any one tell me how to convert from 3dsMax7 to qME? If no can you tell me the best ways to make new models or do I have to use the qME. 

I suspect what you're doing is using the import frames command, which isn't what you want to do when starting a new model. There are two commands for importing into QME, "import objects" and "import frames"

Import objects adds the triangles in another file to the current model. It takes the pose it reads from the file, and puts the triangles in that pose in every frame in the model's animation.

Import frames takes the pose it reads from the selected file, and creates a new animation frame in the model. It then moves the triangles that are already part of the model to match the pose that it has read. Obviously, this will only work if there are the same number of triangles in the current model as there are in the file.

So, when you create a new model, there are no triangles, and so you'll get the error message you mentioned if you try to use import frames. Use import object and it should work.

However, be warned, QMe will not import any animation or UV mapping that you did on the max model, just the triangles and the pose at time 0. To get the rest of the animation in, export each frame to a seperate .3ds file, and use import frames(not import objects) to load them.

The UV mapping is another matter, QMe has no support for importing a UV map, and only allows you to create 2 sided planar mappings in the editor. This is because that's the way the original quake models were made, and when QMe was written nobody knew .mdl supported anything else.

So, how do you get a model with a nice UV map into quake? Well, it's a bit more complicated. Track down a copy of the pop'n'fresh MD3 exporter for max(polycount is a good place to start). Now, rather than export the finished model from max to .3ds, export to md3. Finally, open it in the latest version of quark and save it as a classic Q1 model. You should end up with one mdl, with identical skinmap and animations as the md3.

I make the last step sound easier than it often is, Quark seems to have immense difficulty loading the skin with the md3 if you don't set up the directories exactly right. I've been intending for ages to write a detailed tutorial on making this md3 to mdl conversion, so if you get stuck here just say and I might actually get round to it! 

so .mdl DOES support more than just two-sided planar mapping of a speciall-deformed baseframe?

Hmm, if you set every edge to be a border edge, i guess that means you could map each triangle seperately... would that work? 

From what I understand of the .mdl format through my own recent fiddlings, the UV map will appear in Quark because it must be splitting the verts on the model for each actual animation frame in order to correspond to the pseudo-UV map. The .mdl stores not only the location of the verts for each frame, but their relationship to each other in the mesh as a whole ( which is why changing an existing model cause the .ms2 to look utterly screwed ingame ).
What I suspect you're left with is a .mdl with many more verts than it actually appears to be made of, because any vert that has been split for the UV map must be made of 2 or more verts occupying the same coords in the animation frames as well.
I think.
Preach, would this be the case? 

go finish what should be finished

^_~ 

ya, what vondur said 

I know I am just a greenhorn in this case...but

Making new models in QMLE gave me a rather strange experience in extentions in which the models are imported and exported.

I used a AM2000 animation studio, which gave me the intention it would work good with Quake models, as it used the *.mdl extention.
This was not true, because one has 1-4-16 polygons per patch. I couldn't load them in the animator. So I went searching for a manner they would.

First I tried excisting Quake1 models to change in extention so they would be campatible.
The first attempts I made was with the Q2mdlr9b modeller. This was capeable to import Q1
models and export them to ASC and 3DS. This 3DS I imported in Milkshape and exported again to DXF. This was the right extention to import it in the AM2000 animator.
Then I could manupilate the model, give it bones, so I could give it all the animated frames
it needed to export them to 1 spline dxf frames to import them in QMLE.
To my advantage I could make a skin base model and tear it totaly apart, because theanimated frames were already made. This gave me a good oppertunity to skin the model at the best.
I know Milkshape has it own way of doing these things. I have tried, but never succeeded.
In this way I managed to transport the Q2 model grrll to Qmle for Quake1.
I could transport the Q1 models to Q2, although it would tale some time.(and *.qc knowhow!)
http://members.home.nl/gimli/Q1grrl.jpg

So what I intentionally mean is, why not try the extention import and export of the Q2mdlr9b
and Milkshape to transport your model from Max3D to Qmle? 

Yeah, that's pretty much it, the number of vertexes in your model is exactly equal to the number of vertexes you can see on the UV map. This could potentially cause a problem, as the original GLquake vertex limit is only 1000. If you're making a model that has that nearly that many verts already, you may be stuck with the two sided planar mapping. It also makes the file that much bigger, but generally the animations are smaller than the skin every time. I suppose if the model had lots of frames you might notice.

On the plus side it doesn't seem to hurt rendering by a noticable amount, so it's just a matter of making sure you don't ever break the vertexes when you're editing/animating. There are two ways I can see of safely doing this. One is to animate the whole thing as an md3, before you convert it. The other is to have two copies of your model, one with the uv splits, and one without. Since QMe imports triangles not vertexes, you can animate the non split version, then import the animations into the split model. You just have to hope that the order of the triangles doesn't change...go for option 1 is my advice.

But it's very much worth it by my reckoning, the skins are much easier to paint and they use the skin space far more efficiently.
Finally, very important skin tip of the day: Make your skins in power of 2 sizes, like 256x256. You might object and say that none of the original quake skins are like that. This is because they were made before the advent of glquake and all that. Opengl/your graphics card will resize your skin to a power of 2 size when it loads it, so your skins will be sharper ingame if you make them the right size to start. 

Preach: thx, that's cool. Though the issue with animating in Max and having higher vert counts is already relevant to much of what necros and I have been doing ( note: necros now does all our animating in 3DSM then exports the frames - one by one - over to qME ); many verts, many many frames...
Also, re: powers of 2. Right off the bat I endevoured to make our model skins PoT, mostly out of habit from tex0ring. FitzQuake, afaik actually solves non PoT skins by initially 'padding' the skins out the next PoT and using those. metl r0x0rz y'see.

Von/PuLSaR: mapping etc. is done. I'm just waiting on necros getting his elven ass out of WoW and back on the hotdog - I need my codemonkey to fix0r some things. 

preach: actually it's the application's responsibility to resize the texture before passing the data to opengl, but you're correct that you get much better results with gl engines if you make textures powers of two.

kell: correct, fitzquake pads the skins instead of resampling them, because they don't have to tile like world textures do. I also do it for graphics like the console background and menu images and status bar images, since those don't have to tile either. 

damn this blizzard fuckers! argh 

Um...talking of both Chapters and FitzQuake...
Since there are a few skyboxes used in the chapters maps, is FQ 0.8 likely to be released soon? It would be unwise for players to be using 0.75 due to the skybug, but I really want to recommend FQ as the engine of choice for Chapters.

Von: I know. Bastards. Curse them for making addictive games! 

he'll never get his pool open at the rate he is going. My summer social life is screwed. Damn, Blizzard. Damn them to Hell. 

He'll be so into WoW in a few weeks, that he'll end up selling the pool on eBay to buy some rare item he needs in the game. 

well, maybe... i'm really close, but things are also going kind of slow. Maybe after E3 i can wrap it up.