Ne_tower by Necros was Quoth-based and had a body dragging. He should be able to fill you in. 

as for the knight drag, it's actually from when preach coded in model support. previously, you couldn't assign a model to a func_ because the game would complain about not having it precached.
there was supposed to be a func_train_point made specifically for assigning models, which is what i would have used, but that entity is actually broken, because it's still coded to set the func_train_point as SOLID_BSP which is not allowed with a .mdl (or external bsp afaik), so the dragging knight is actually a func_rotate_train (which is never solid).

http://celephais.net/board/view_thread.php?id=60352&start=36 

was made with a func_rotate_train.
preach added the ability to assign a model to (i think?) every entity.

unfortunately, he didn't allow for models on entities that have SOLID_BSP (ie: func_train) which is why you can't use a func_train for this.

it's been a year, so i don't really remember the specifics, but essentially, you set up a func_rotate_train + path_rotate entities exactly like you would if you were building a rotating train path, except you don't specify any rotation (but you could, if you wanted to-- the model will rotate just like it would if it was a bmodel).
once your rotating train entity and paths are set up, just set the 'model' key to the path to your custom model. finally, on your func_rotate_train, set the target field to 'null' (or anything that is not used). this is because the entity does not work unless target is set, but since we have the model directly on the train, we don't need to target anything.

you can also tie custom models (via mapobject_custom) to bmodel movers via rotating entity functionality as well. you could, for example, make a lift with torches attached to it. note that you'd need to use mapobject_custom instead of the normal torch entities because torch entities are made into static entities and static entities cannot move and they also automatically emit the fire sound which may not be good since they will be moving around.

as you know, you target a func_rotate_* entity to rotate_object entities in order for those to rotate.
you can also target any other entity in the game (including monsters!) and the rotating entity will also move them as well. for an example of this, check out sm156: http://celephais.net/board/view_thread.php?id=60375 for a map which uses this behaviour.
there are two boats that drive around with rocketeers stuck inside them with the rotate_train trick so they don't fall out as well as droles attached to a flying airplane type func_rotate_train.
i posted the map source for it in post #10 of the thread (or just get it here: http://necros.quaddicted.com/temp/sm156_necros_map.zip ). 

that when you attach mapobject_custom entities to a func_rotating_train, you can't rotate it. this is because entities attached to the rotater this way won't change their angles when they rotate, they only change their position.
so you'll have models that just slide around. 

if i had read the responses, i would have seen purple's post and wouldn't have had to retype all that. lol. ^_^ 

Heh so it is a bit more complex than I was hoping. I was trying to avoid rotating stuff as its such a pita :p
Still, the amount of fun I've been having playing with various triggers and relay sequences, it was kind of inevitable it would come in at some point...
Thanks for the posts though will try it out.

Nice to be reminded of the exact map I saw it in too :) 

Is it possible to use some func_moving_object with skip textures applied to not-quite-all sides of it to simulate dragging a model? I recall levitating a Shambler once in one of my speedmaps using a similar technique. But, then again, my recollection isn't what it used to be :) 

well, if you are using hipnotic or quoth, you can just use func_movewall with func_rotate_train as they are fully invisible.
but i don't see why you couldn't put skip on a normal func_train. 

I'll admit that at the time of release I knew that using custom models on func_ type entities was tantalizingly close. However, it was actually a side effect of code that guarded against unprecached models on the first frame (where it could be prevented). The main application I had in mind was to combine it with the newly added fixed-angle sprites for alpha transparencies, to make lifts with mesh floors or similar.

I probably could have added a 'NON_SOLID' flag to the func_ entities quite quickly, but I wanted to convince myself first that there was no way to automate the process. The uncertainty remained, so the idea was left unfinished.

As a quick straw poll: What would be the preferred implimentation?
� Create new classes for non-solid entities
� Add a flag which sets such entities non-solid
� Add the flag, and set it by default in the fgd file for _point classes
� Add a flag, and create a new wrapper class which sets the flag then calls the regular code(aka throw it all at the wall and see what sticks)
� Break all existing maps by making func_ non-solid with a flag to make them solid again

I also have this idea of fiddling with the modelindex so that you could create a BSP hull model to make it solid and still have another model visible using just one entity, if I can just sort out the entity issues. That might change the whole plan... 

well, my first instinct is that _point versions should automatically be SOLID_NOT because i was surprised when the func_train_point failed with a model. the thing is this would be an inconsistent behaviour because things like trigger_*_point MUST be SOLID_TRIGGER.

ideally, it would be better to just make a func_train_entity instead of having to abuse func_rotate_train. oh and i'd also update the hipnotic rotation code to take entity angles into account when being targetted by rotaters. (possibly with a flag to toggle that behaviour). 

The _point versions are supposed to be exactly identical to the regular version, so much so that they even strip the classname of the _point extension. They only exist because of limitations in worldcraft which prevent creation of a point entity with the classname of a solid one. I'm pretty sure changing them now would break maps. 

I don't see why you couldn't make rocks in Doom 3 the same way you do in Quake.

When you're finished, turn the entire terrain into a func_static and turn the simple room around it into caulk.

For parts that the player can't interact with, there is some key that lets you make the func_static nonsolid which supposedly saves RAM because no clipmodel is needed (I think).

You can then export the stuff (obj) and tweak it in Blender all you want, but for rough terrain, just to get the rough outline and scale, I don't see why you wouldn't want to use triangles or patches. Just to approximate it in the editor and get a feel for it.

You asked me to share my expert doom 3 mapping knowledge (lol) so here is other random stuff I found out while mapping:

- Shaderparm7 is used to set green/red lights on the door frame models. 0 is red, 1 is green.

- I ripped the frame and door models from id maps and tweaked them to my needs. All the doors are models as far as I can see, so are the matching frames, all nicely on the grid and on the Z point. The glass inside some func_doors is a func_static hooked up to the func_door with the "bind" key, like "bind" "door1". This makes the glass follow the door's movement in a master/slave way.

- Like Necros said, two ways to make consoles. a) models (in the mapmodels/com folder I think, look at the communications map - com1 or similar); b) brushes for the straight parts, patches for curves, small brushes for the guis.

- GUIs: For the model consoles, keys gui1, gui2 and so forth point to the gui files... for handmade guis, simple patch mesh turned into a func_static with common/entitygui texture and placed roughly 1 unit in front of the physical screen, can target stuff it should activate and "gui" points to the gui file like guis/comm1/sentrybot.gui is the panel that says "Activate sentry", for example. There are a lot of those.

- Mapmodels can have different skins; for example, skmachines/skcube.lwo can have "skin" set to skins/skcubedirtred to create the red version of that thing.

- Sounds are placed in maps using the speaker entity.

- Glass is simply a material.

- Two ways to make sky: a) like in Quake, slap one of the sky textures on brushes and b) portal sky, still looking into this last one.

- Lights; brightness results from the size of the light volume, as well as the color, where white is full brightness. You can assign textures to a light source, such as "texture" "lights/xray02".

- Entities under "movable" are physics objects, these drop to floor automatically. So do monsters, but not weapons for example. You need to place the weapons and ammo in the position you want them to appear.

- Decals are put on simple patch meshes of the desired size and shape and placed roughly 1 unit above the surface.

- Textures can be resized pretty freely without looking bad, so you don't have to build gui screens or decals at a certain size. Rather click "fit" in the surface inspector.

- The scale of everything is comparable to Quake, so is step height etc.

- You can load different mapmodels by creating a func_static and choosing models/mapobjects/whatever.lwo (Radiant will pop up a file browser).

I'd be interested to exchange testmaps and knowledge, hit me up on irc maybe.

http://kneedeepinthedoomed.files.wordpress.com/2010/09/sotox2.jpg

http://kneedeepinthedoomed.files.wordpress.com/2010/09/sotox3.jpg 

My knowledge of Quake C is zero and I'm still learning the ropes entities wise, but for the kind of stuff I'm thinking of doing a func_train_model kind of entity would be great :E

For stuff like making it rotate or whatever though I'd wouldn't know what to suggest, I don't know what the technical limitations and such are really. 

A map can have a script assigned whose main() function is executed at level load. Scripts can directly address func_movers for example by their name. Some GUIs (shutters gui for example) can execute functions from the script when clicked (called via shaderparmX, usually documented in the GUI script itself).

It's a lot like QuakeC. Tutorial worth reading:

http://www.doom3world.org/phpbb2/viewtopic.php?f=4&t=3144 

Guys, quick question:

In Q3 I saw .md3 player models in maps as statues. I've tried to put a knight.mdl in a Q1 map but it doesn't appear because I basicly put in a monster_knight with the editor and then replaced that with knight.mdl in notepad. But (ofcourse) that doesn't work. So how do I tell the engine to just put in the .mdl file?

Also: what if I create a custom .mdl and want that to appear in a map? Ofcourse I'd need a similar line of code (whatever it is) and aside from that, would it then be enough to tell players to put the .mdl in id1/progs folder? 

i forget how that works but you could find it in the teaching old progs new tricks thread.
you can use this for models that are already used in the game.
afaik, it is impossible to use custom models unless you REPLACE a stock model with a custom one. at that point, you should make your own mod because it is unrealistic to ask a player to overwrite a stock model with a custom one and then delete when they're done playing your map. 

Thanks. That reminds of wanting to create non-solid snow. Isn't the Func_illusionary used to make a brush non-solid? I suppose that would do the snow trick.

And ofcourse, I'd never ask anyone to overwrite anything. Ideally, you could just put the new.mdl into a pak file or in id1/progs and the engine would just always check that progs folder if the map file dictates it. But I guess it's too easy to think that way :) In Q3, you can just add all your stuff into a pak file, whether it's models, textures, sounds, or whatever. 

The difficulty is not so much that quake doesn't offer pak files and things to prevent you overwriting somebody else's models. The standard quake progs doesn't offer any way to specify a model to precache from the bsp file. So the only conceivable way of loading a custom model is by using one of the existing filenames, which would of course overwrite something.

The suggestion is not meant to be a serious on(I think), so you need a modified progs.dat in order to load ANY custom model sensibly. By that point you need your own mod directory and there is no danger of overwriting other's files. Unless you decide to use somebody else's mod which supports custom models, in which case conflicts may need to be considered. 

Thanks for the answer. The problem is that I want to make a deathmatch level that people can download automatically from the FFA server. So a mod is out of the question. I guess that's not possible then... 

A thought I had after replying there...

Problem: Map releases that take advantage of a mapping-centric mod like remakequake or quoth may have other custom resources outside of the traditional bsp files, for example custom sounds, models and skyboxes. The pak file sounds like a great way to distribute all of these things without risk of dozens of file conflicts. However, the system of loading consecutive pakN.pak files means that users have to jump through renaming hoops to pop the new map at the top of the list and risk clobbering a custom map when a patch for the base mod comes around.

Proposal: add a "-pak name" switch to engines. This would place the named pak file at the top of the search path for any files, allowing overriding of all models as well as supplying the location of new files.

Players using an engine with this feature would be able to leave maps distributed as pak files with an identifiable name in the directory, and load straight from them as they wished. Older engines would not be left out, although they would have to rename the pak they wanted to use to pakN.pak.

It might sound like this adds bloat to a command line that already needs -game and +map specifiers. Correctly designed mods could eliminate this though, by ensuring that quake.rc calls autorun.cfg, a config file with a dummy implimentation in the mod's pak files. Loaded pak files could then override this with their own autorun.cfg - containing a command to load the (first) map in the pak.

(Custom map paks overriding quake.rc directly should be avoided, since that file may be updated by future patches to the mod. Supplying the autorun.cfg is basically saying "this one is ours, and that one is yours".)

Extension: The command line could accept "manifest" text files listing a collection of paks rather than a single pak. However, this might be overkill, and it certainly should be in addition to rather than instead of the single pak loading system. 

for quoth at least, fitzquake and aguirre's engines have a -quoth switch that works the same as -hipnotic and -rogue, so you can effectively load your own mod on top of quoth.

Darkplaces does even better and has the ability to specify multiple gamedirs, so mods can mod mods ad infinitum. 

I'm working on a map that will use only the original Quake textures. I want to apply a texture to a cylinder (actually it's an hexagonal prism) that will make the cylinder look like a screw. Something like in this image : http://upload.wikimedia.org/wikipedia/commons/7/78/Screw_bolt.png

Any ideas what texture I might use ? (cropped, rotated, etc) - just to get that effect. 

any texture with ribs -- then just rotate each face the same amount and slide them around until they line up. You might have to adjust rotation to get them to line up all the way around. 

Wow, that was fast :)

Thanks metlslime.

Yes, that's what I was thinking about, I need something like this : http://farm2.static.flickr.com/1111/1069643021_01b41ff384_o.jpg

But how to get it from standard Quake textures ?
I searched the metal textures, I didn't see anything suitables, everything is too flat or with "bubbles" 

Yeah, metlslime, I had them in mind before I posted. I was trying to come up with something inbetween the effective but hardcoded -quoth switch and the overly elaborate darkplaces stuff.