Unused, pretty sure.

How about implementing the "ToMagazine" function so we don't have to do "ToMagazine = ToMOSRotating" in order to run scripts on ejected magazines?

A line in inis which allows for sprites to be flipped if they are going to be Ping Pong animated.

That would just be another SpriteAnim.

How about we generalize: more control over sprite animation modes, perhaps custom defined? eg specify a frame order and a loop setting if no preexisting mode works well

Also, MOSParticles animating properly on a setting other than lifetime. Framerate doesn't do jack ♥♥♥♥, and it's impossible to set frames through lua (they're constantly reset back to whatever their lifetime setting is telling them to be animated to)

Mostly unrelated to that, proper glows on higher level MOSprites, eg MOSRs, actors, AEmitters, without having to resort to flashes or glowing mopixels.

An absolute, in .ini setting, to completely disable movableman settling. As a general application to all mosprite classes, including devices.

An absolute Scuttles boolean on all craft, with no AI overrides.

assuming implementation of MOSRotating glows, multiple glow effects under the class of screeneffect, a bool on weather the glow oscillates between the start and stopeffectstrength or whatever theyre called, a vector offset for the glow, and a setting of weather the glow rotates with the MOSR or not (if not, the glow would "pivot" on its vector offset.
marvelous.
i'd prefer 3 options, no scuttle, player can scuttle, and whatever we want to call the current behavior, besides shitty. if no scuttle is set, the option vanishes from the pie menu.

The ability to zoom in within the actor editor, as one can in the gib editor. This, along with a basic grid in the background would make fiinding offsets much easier, without the need to make a whole new editor as others have suggested - just using preexisting features.

Ability to control the volume of a sound in .ini, as well as in Lua, preferably with a max and min range.
Fix gib editor to not save with a huge output if the gibs have gibs or emissions (or maybe it's just gibs)
Add reload x.rte option to editors menu. seriously, if that had been a feature before i had bought CC, it would have sped up the process.

-BUMP-

The variable for all actors:
Disposable
If that variable is set to 1, the actor's death won't count towards the kill count. Great for drop crates, drop pods, teleports, "transforming" actors and what not.

That's a pretty good idea, DSMK.

If I remember correctly, a simple script can do that, but making it ini moddable would be handy.


There should be an SpriteAnimMode for attachables that sets them to the same frame as what they're attached to.
This would make breakable limb armor possible, and could be used in some other situations.


I would love to see a better damage system.
MOPixels and MOSParticles [particles capable of causing wounds] should have variables that can modify properties of the wounds they inflict, both entry and exit. [perhaps multipliers for the wounds' defined variables].
Properties I have in mind are BurstDamage, BurstSize, BurstScale, EmissionDamage, ParticlesPerMinute, and ParticalCountLimit.

Damage and other wound properties should also be affected by the depth of penetration. There's a huge difference between two inches and eight inches of penetration. Obviously, ballistic penetration is a big damage factor on initial damage [BurstDamage], initial blood lost [BurstSize and BurstCount], bleeding damage [EmissionDamage], total blood loss [ParticleCountLimit], and rate of blood loss [ParticlesPerMinute].

Wound sprites could also have multiple frames that represent the magnitude of the wound. The visible entry wound inflicted from a BB and a .50BMG should look very different.
Old wounds could slowly animate backwards, disappearing and no longer contributing to GibWoundCount when they're done. That would make healing, and related gameplay mechanics, more feasible.

Damage from impacts could use some reworking too. I hate how impulse damage is in 10 damage intervals. There should be a minimum impulse at which you start to take damage, and a maximum impulse at which instant death occurs [100 health loss]. Between those, damage should be gradual. GibImpulseLimit is fine as is, being separate from damage.

The factor at which something takes damage should also be .ini definable. Right now, on AHumans, Heads take 5x damage, the torso/arms/legs take 1x damage, and other attachables take no damage. Instead of these hardcoded settings, there should be a DamageFactor variable that is a multiplier for wound damage inflicted on that object. So I could set the headshot damage to 6x, and arms and legs to 0.8x, without making multiple similar wounds for the objects.

Truth. I think it's kinda useless to add that to .ini modding but i suppose it could be pretty quickly implemented.

So custom wounds? Wouldn't it be better to just define the new wound? That way there wouldn't be anything you can do with normal wounds that you couldn't do with these wounds.

Then Browncoats would get hurt as much as puny little crabs.

Not quite: they'd lose health at the same rate.
Though I personally was thinking specifically about Lua'd wounds, once we get both custom wounds and Lua'd attachables; easy enough to scale damage to unit mass in addition to lots of other nice fun things you can do with Lua.