eezstreet

Because there's no models that are rigged to use cloth bones.

Could I see a full console log? That error only occurs when JA assets are used with this mod. Or basically because it could not find the file "strip/keynames.sp" which is in every JK2 installation, but not in JA.

I suppose the feature could be cvar'd.

Well, I can see what I can do when I have a sample, as was the case with ghoul2 viewmodels Although in this case the sample is going to be quite difficult I imagine to generate. As a side note, it might be a good idea to make an animation system where you can swap out specific animations on a per-playermodel basis. Like, jedi_trainer/special.gla might have some fancier looking taunts or something. Basically just a GLA with a few animations but the same hierarchy.

But....there isn't anything wrong with Radiant... ...for placing entities. I believe there is a .map exporter though for Blender. @@Silverfang has some kind of system in place where he is making maps using a combination of Blender and Radiant.

I'm still waiting on someone to help me finish the lost level for JK:Enhanced. If it comes down to it, I might have to do it myself. It's just super time consuming.

Those are for the first person viewmodels.

Use the game with JK2, not JA.

All listed things in the OP are things that I've done. I have been playing lots of the new Doom since then and haven't progressed much. On the plus side though, I've been a bit inspired by the Snapmap feature and might poke around with implementing an ingame kismet-ish scripting system for people to create scenarios with. In terms of content, there's no good Scouttrooper models for JK2/JKA so I haven't included that yet. I might code the Stouker Concussion Rifle in soon. Still no mapper found for the lost mission.

There is no maximum bone limit. There's a fixed amount of memory that is used for animation. You might hit that limit, but if you do, it's an easy matter of raising the memory cap or compressing the data to use less memory. I disagree that having all possible bones in one GLA is the best solution. Take the Reborn for example. It has a crotch flap and hood which should be animated separately. Kyle for instance doesn't have any room for additional bones. Jan might have an animated ponytail. However...rodians only have three (?) fingers and a totally different face structure from humans. Grans have meaty paws. It would be nice to be able to make more precise hand animations for these characters for sure. Yes, perhaps it might be feasible to have these extra attachments in one extra mega skeleton, but it makes more sense to be able to swap parts of one skeleton with another. In order for this to work, the GLM would be rigged to a temporary skeleton which represents the merged _humanoid with merged bones.

This might be doing it? Maybe try disabling joystick input in the game? and trying with mouse and keyboard. I'm just throwing ideas out atm because I have no idea.

Corpse removal time is hardcoded in singleplayer and no cvar can change it. However, the corpse removal time was greatly increased in this mod. sv_zombietime is not used in Singleplayer. You can remove the following from your config because they aren't valid: Your game is getting spammed with some kind of keyboard/mouse/text event. This is why you're getting bad stuttering (console spam = bad performance) You could maybe try disabling QEffects but I seriously doubt that's interferring. Nothing in your config would be causing this kind of behavior that I see anyway. Does the problem persist when you sit still for a bit? Is there a joystick plugged into your machine?

This isn't an added weapon, it's only a replacer for the existing imperial pistol model (and also kinda a fix for Haps' Imperial, which has a bugged MD3)

To clarify: my way doesn't involve bolting on a skeleton, rather it takes two skeletons (the _humanoid and the _face or the _humanoid and the _cloth or _breasts or something) and replaces an appendage from one with an appendage from another. I think the proper term would be "transplant" But either way, I think that this isn't quite the right thread to be discussing our plans.

Are you using Rend2? Did you set cl_renderer to rend2?

Maybe it's a matter of RGB channels mixed up? There are visible images in the save screenshot.

Maybe the new costumes can be unlocked at certain points in the game. Like when completing certain objectives or something. The floating droids not exploding is a deliberate design choice. They can still explode after death (either post mortem or while they are dying) from certain types of damage, like being hit with a rocket, sniper, or demp2. I might make this a toggleable feature. The probe droids don't have a "dead" animation yet though, so that is why they look weird atm. A compromise I am thinking of doing is just making their bounding box really tiny until animations are made, so they look like only the head is on the ground. There is code for the head to actually come off like R5 units do, but that is a tale for another day. Loading screen glitch is a known issue with the renderer, maybe @@ensiform knows how to fix it as he's dabbled with that code. Snowflake shader is a new one, I can investigate that. I haven't actually tested this with the demo mission (shame on me!) but that's something to look at. Doom_shields not loading music is an issue that @@mrwonko introduced to the game, you can blame him for it. I will look into fixing it though. I can assure you that it's not your game though. Most of what you describe is stuff that I know about already and/or am in the process of fixing. Well, I received a request to make the lightsabers ignite faster ("like in the movies"). If you look at the anatomy of a lightsaber though, it's not a button that you push to turn on/off the lightsaber, it's actually a slider that you flip up/down (or a dial, in the case of Obi Wan Kenobi's lightsaber). I think the ability to turn on a lightsaber should be more analogue then and less digital. Of course that will impact gameplay negatively and make it clunky to turn on/off the lightsaber. One compromise is to make one style turn on the saber faster (blue), one to turn it on normally (yellow) and one to turn it on slower (red). Keep in mind that this is an alpha mod, so it's very expected to find bugs at this stage. Keep letting me know about the ones you find!

Err...but how would you change clothes? Maybe an option in datapad?

JA has a simplified skeleton. All of the models that are weighed for JKA therefore contain less skeleton information than in JK2. It's easy to toss out that data for a JK2 model to work in JKA, not so easy to go the other way around.

If he can't go below 1 health, he's probably hardcoded that way and there isn't anything you can do.

Don't worry, I know of the issue with SFX sabers. They will look much better in Alpha 2.

Err..have you tried spawning him ingame? Pretty sure he's not immortal by default.

Ok, so I've started a bit on this. The structure is going to receive some pretty major changes. All of the renderer code (with the exception of rd-dedicated) is moved to /shared/<rd-type>. All code in code/ghoul2/ has been moved to shared/ghoul2. The following files have been moved into shared/qcommon: disablewarnings.h matcomp.cpp matcomp.h MiniHeap.h q_math.c q_math.cpp q_shared.c q_shared.cpp q_shared.h qfiles.h More files might get moved there as well (huffman.cpp, etc). Basically anything which is like 90% the same on both SP and MP will be moved there. The big question is what will happen with q_shared because a great portion of that is different between SP/MP. I am thinking that maybe the code which is SP dependent will move to sp_shared and the MP dependent stuff will go to mp_shared. So stuff like forceData_t, playerState_t and entityState_t will likely be moved to those files. But like 70% of q_shared is fine being shared between games.

The following is a short list of things which have been implemented in the next version: TrueView (and TrueView 2.0)SFX Sabers now look correctSaber ignition flares now use the correct originFixed an issue where loading from a savegame would give you incorrect battery charge and force powerDifferent saber ignition speed, depending on which stance you have equippednav delete now properly deselects the node you deletednav link can now accept two arguments, for selectionless node linkingnav delete now accepts an optional argument to delete a node without selecting it first