mrwonko

The important part for rotation is the PAN setting. You have to target your ref_tag to a target_position. You can also make the camera follow an npc, or export a camera animation as a .rof animation from the modelling tool of your choice (as long as that choice is either an ancient 3ds max with an official exporter or Blender, for which I wrote one). But for now, simple ref_tags will suffice.

My message wouldn't show up so I clicked some more. Ooops. Edited the duplicates out. Also, the name highlighting is bugged - it certainly should not highlight stuff in blocks.

//(BHVD) rem ( "Enable cutscene mode, move the camera to the position/orientation of the ref_tag with targetname camera_ref_tag_name" ); camera ( /*@CAMERA_COMMANDS*/ ENABLE ); camera ( /*@CAMERA_COMMANDS*/ MOVE, $tag( "camera_ref_tag_name", ORIGIN)$, 0 ); camera ( /*@CAMERA_COMMANDS*/ PAN, $tag( "camera_ref_tag_name", ANGLES)$, < 0.000 0.000 0.000 >, 0 ); rem ( "Tell the NPC with npc_targetname npc_name to go to the waypoint_navgoal with targetname navgoal_name" ); affect ( "npc_name", /*@AFFECT_TYPE*/ FLUSH ) { set ( /*@ SET_TYPES*/ "SET_NAVGOAL", "navgoal_name" ); // Without the space after the @ - but the name-mention-highlighting is overly aggresive here. rem ( "Or, to pause script execution until he has arrived:" ); task ( "unique_task_name" ) { set ( /*@ SET_TYPES*/ "SET_NAVGOAL", "navgoal_name" ); // same } dowait ( "unique_task_name" ); print ( "!npc_name has arrived at navgoal_name!" ); }

Correct me if I'm mistaken, but you're asking how to know which part of the 2d texture you paint will end up where on the model? There's software that allows you to paint directly on the model - I think recent versions of Photoshop support it, as well as the freeware Blender and others.

Rotate the *blade tag sounds about right - tags are triangles representing directions (the blade's one in this case), though as the direction is determined by the indices (i.e. order) of the vertices which is kinda hard to find out how it'll turn out so you usually have to experiment until it points in the right direction. You can take a look at the model (and other sabers) in the glm viewer ModView with "Show actual tag surfaces" turned on to get a better idea of how it works. The second problem is related to surfaces being one-sided, i.e. they have a visible front and an invisible back, like patch-meshes in maps. So you'll have to select those topmost polygons and do something like "flip normals" - I have no idea what it's actually called in gmax though as I do not use it. Oh, after re-reading part of your post I just saw you're using Blender - just stick to it! There's an md3 exporter for it that works just fine, although it hasn't been updated for the latest versions yet (I'll get around to that eventually), and I did some on creating a saber with it.

I am indeed the same guy, and I did think of the jk3files post, but just answering seemed faster than looking up whether it was yours.

First of all: misc_model does not animate, period. That _frame setting, like all settings prefixed with an underscore, is for Q3Map2. It selects which frame of the animation the model will be in - forever. For animated models you'll want something like a func_static with model2 and a script with SET_STARTFRAME and SET_ENDFRAME or whatever they're called. Affect the func_static (via its script_targetname), set those and it should animate (once).

Official builds have since started appearing, incorporating all of my personal changes except the display for target2, npc_target etc. links, as well as other improvements: http://icculus.org/gtkradiant