mrwonko

Does target_play_music work in mp? Might want to give that a try.

There's TORSO_WEAPONIDLE3/TORSO_WEAPONREADY3/BOTH_STAND3IDLE1 for most weapons, TORSO_WEAPONIDLE2/TORSO_WEAPONREADY2 for the pistol, TORSO_WEAPONIDLE10/TORSO_WEAPONREADY10 for thermal detonators and TORSO_RAISEWEAP4/TORSO_WEAPONIDLE4/TORSO_WEAPONREADY4 for zooming with the Disruptor, as well as BOTH_SABERDUAL_STANCE, BOTH_SABERFAST_STANCE, BOT_SABERSLOW_STANCE, and BOTH_SABERSTAFF_STANCE for the lightsaber, as far as I can tell. Not sure about medium saber stance.

Doom 3 BFG did, don't know about the normal one. But it doesn't support mods for the original Doom 3. And to make matters worse the original has been removed from Steam when the BFG arrived. Yeah...

Still, that's 14 or so cycles out of what, a couple million? Sure, it's unnecessary, but probably also irrelevant.

Hmm... if cvar setting is done via trap call, and SP works like MP, it might be possible to have a proxy DLL that forwards most calls to the original jagamex86.dll, except for those you'd like to change. That's pretty advanced stuff... I'll take a look at that, I'm intrigued.

I've had a brief look at the source. g_ICARUScb.c is of interest - cb = callback, the file contains the vm-specific icarus parts. Don't you think you could modify the Q3_Set and Q3_GetFloat/Q3_GetString functions in there to allow the set()/get() commands in ICARUS to access cvars? e.g. treat everything with a cvar_ prefix as a cvar.

Use a misc_security_panel with a unique "message", add an npc_imperial set to COMMANDER with the same "message", ???, profit.

Use 1.6.

So this is about console commands for map (entity) creation in singleplayer? I didn't even know that was possible (beyond npc spawning), but I suggest you simply edit the bsp file (or rather, edit the entity part and do an -onlyents compile).

I'm not entirely sure what you're trying to accomplish and what you've tried to accomplish it/how it does not work. You're trying to add new Spawnflags to an entity - like, say, an invincible flag that turns npcs invincible on spawn? And you've done it by editing the part you've quoted there? Are you working in the sourcecode or the mp_entities.def? The latter is necessary to get it to show up in radiant, but you'll also have to code the changes you want in, and the part you've quoted is only the comment describing how it's supposed to work. But just as you can't make a coffee machine make tea by labeling it "tea machine", you can't change a function by changing the comment describing it. I suggest you take a look at how it works - there's lots of entities, after all - or wait for people who know more about the specifics of Jedi Academy coding than me.

Only thing that sounds suspicious from that list is the script, maybe you could post it. If nothing else helps you can always bisect the map - remove one half, see if the error persists, if not, remove the other - repeat until you've narrowed it down enough.

Once again shows that good art design > good graphics. Looks great! (Despite JA's limitations is what I'm saying, not that it's particularily bad tech-wise.)

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