The error is in wocat_die, and it's something that the function is missing. Compare it line by line to shalrath_die and see what is missing in your function. 

forget statement, me donkey. 

To change a func's ability can be easy done with target & targetnames.
What if I want to change the ability of a static entity?
I can't use the target arguments in game as it is a static.

So if there were four kind of animation frames, how would I add a qc, that defines the static entity for its specific argues in game?
So I could use the certain animations from one entity by togling?

Or does a static stays a static, except killframed. 

When you make an entity static, you are giving up the ability to change it in any way. You can't even killtarget it!

But with the right QC code you can make a model appear without needing it to be static. Most entities in the game have models and are not static entities. For example, if you make a map in Quoth and add a mapobject_custom, you can see that it does most of what you need it to do. If you trigger it, the model will switch from frame 0 to frame 1. Trigger it again and it goes back to 0. If you killtarget it then it will disappear.

The QuakeC code for this entity is really simple, it's basically copying the code for func_wall and func_wall_use then deleting the lines that make it solid.

To go from 2 frames to 4 frame, the difficult part is planning how you want it to work. Can the mapper decide which frame should appear next each time they trigger it, or do the 4 frames always cycle round in the same sequence? When you have a clear plan of what you want out of the entity, I can help with the coding parts. 

Is it possible to use some of dwere's new weapon models (for example the shotgun) in Arcane Dimensions and The Forgotten Sepulcher? 

 

I making and testing map with gamma 0.75 in quake. Thinking i have some dark places and more middle-dark places.What gamma do you play and is the recommended value of gamma?
tnx 

...for me. Open Quake's Start map (start.bsp) and compare your map to it's lighting. That's how I tell id things are too dark. 

interesting thing... me too comparison my map with enter map and other originals q1 maps 

gamma 0.75
Uh, why? Gamma is not something you want to mess with as a mapper: your map will look good to you but too bright to everybody else. 

because i like gamma 0.75, but you not answer for deal. 

im try to avoid make too-dark map. In real option my map is bright! 

what about xld - this is bright map (like im understand)? 

If you want to use Dwere's models you just replace them in your AD progs directory. 

no no, Berzerk, sorry i mean a map Xlarve's dream.
It is too bright - guys - who played? 

Thanks for confirming that it is possible to just replace the files. Managed to replace those that I wanted. :) 

I've made a tool to convert two quake models into a single model.
This tool works where, for example qME does not, due to correctly supporting the texture coordinates for models that do or do not have backfacing triangles with onseam vertices.

Please read the enclosed readme.txt

I'd be interested in any feedback

https://mega.nz/#!g2w1kaRb!V2KX1gsn7vrVzT3eqxXE6WYlmr_Ha8kJyGs4wya51X8 

You fucking stud. Nice work. I'm not a modeler but new tools are always welcome. Cheers. 

Hi c0burn, been playing with your tool and it looks really promising. Few things I've noticed from a quick look at the source and a play with it:

If you run a merge where model1 is small and model2 is large, the second model doesn't merge in all that well. See for example

modelmerge.exe g_plasma.mdl player_capnbubs.mdl

I think that your code to translate the model2's coordinates into model1's space misbehaves. Possibly only in the case when the second model is larger than the first, not sure about other cases. In generally I think there aren't any "really good" ways to tackle this problem, only "less bad" ones.

Is there a reason why you chose to extend the skins horizontally rather than vertically? I'm sure it would be a lot easier to cope with front/back splits when stacking vertically - if the skins are the same width it's practical free regardless of the model's UVmapping type. I have a feeling I know why QMe chose to do it that way, and I'm wondering if that's your concern too.

Have you considered an "overlay skins" option for the tool? The case I'm imagining is where you might want to clone an object but have the same skinmap for both copies. For example, making a multi-strand vine model with four copies of the geometry but one skin, by inputting the same model twice on the command line.

I have some ultra nasty UV tricks up my sleeve that probably thwart most attempts to merge models, but I'll spare you those. For now. 

Isn't the reason to extend horizontally for skins that there's a height limit but not a width limit for mdl skins? (or has everyone been talking about the 480 height limit with the implicit understanding that it's the same for width?? D: have i been living a lie?!) 

Thank you for the feedback.

I can't remember now why I solely did it horizontally. Skin height limitations was a concern certainly, but there was something else as well. Some extension horizontally is unavoidable, as internally the engine will move onseam backface verts += skinwidth / 0.5. So you need to fudge it so both models behave.

This thing was coded at 2am on a weekend so some details of my choices are fuzzy. :)

I need to revisit the coordinate code so it's less of a fudge. It certainly only works correctly at the moment if model2 is "smaller" than model1. 

all animation data (frames) from input2.mdl are discarded apart from the first frame

Too bad there isn't any model merging tool that preserves the frames of the imported model. Back when I did modelling, this is something that could have saved lots of hours of work.

Something simple like "if both models have the same number of frames, merge each frame individually" could work. 

I tried to use the programm, but I got the VCRUNTIME140.dll error.
I liked to see how it would work with some earlier models I had construckted from Q3 models.
(and the hazard ways I had to make the top, midle and leg parts together)

It must be a VisualBasicStudio update I don't have.
After downloading the dll I ended up in obscure sites with the warning the dll alone won't be enough. 

Install the Visual Studio Redistibutable from here:

https://www.microsoft.com/en-gb/download/details.aspx?id=48145 

You might need the 2017 one actually, that's here: https://go.microsoft.com/fwlink/?LinkId=746571