A ticketing/bugtraq system would likely make the interface between PR and the public much more fluid, instead of counting incidences by hand. Just a suggestion

Well there's a bugtracker of sorts, but it's for devs only, which is just monstrously useful (not)

but anyways

Piggybacking on Geti's suggestion, a Lua variable .Parent, since object already have inheritance, we just can't read it (and therefore have to use hacky, slower, methods)

EDIT: kinda getting past what I really should here, but
Fire settings for guns would be really grate. Not necessarily selectable, but the ability to set them in .ini (and change them in lua?) would be really nice. FullAuto = 1/0, and then also BurstFire = 1/0, with a BurstCount variable?

More sprite animation options in inis. Reloading animations would be great, for instance.

Control over the frequency the AI decides to take cover. Been going on about it.

X = items lifetime.


we don't need a variable for that, all we need is to be able to self.sometimer:IsPastSimMS(lifetime.variable) Note, I do not know if we can do that, but the reason for that is for random lifetimes/lifetime variation.

SPOILERS: DOING SOMETHING WITH Lua IS NEVER GOING TO BE AS FAST AS DOING IT WITH .INI AND THERE IS NO REASON FOR IT NOT TO BE ABLE TO BE DONE WITH .INI CODING

THE LIST OF THINGS POSSIBLE WITH Lua IS VIRTUALLY ENDLESS DOES THAT MEAN NOTHING ELSE SHOULD EVER BE ADDED TO .INI CODE (NO)

WRAP YOUR MINISCULE BRAIN AROUND THIS ONE MILES: JUST BECAUSE YOU THINK YOU KNOW SOMETHING DOESN'T MEAN THAT YOU'RE THE ONLY ONE WHO KNOWS IT. IRONICALLY THAT CODE WAS ALMOST RIGHT, BUT DETRACTS NOTHING FROM MY ORIGINAL POINT; WE SHOULD NOT HAVE TO ENGINEER WORKAROUNDS TO PROBLEMS THAT WOULD BE BETTER AND MORE EASILY SOLVED WITH FIRST PARTY ADDITIONS

TERTIARY ADDENDUM: EVERY SINGLE TIME I WRITE A POST CONTAINING ANY KIND OF ABSOLUTE YOU FEEL OBLIGATED TO POST A FAR TOO LONGWINDED COUNTERSTATEMENT. I WILL SAY THIS ONE FINAL TIME, AND PLEASE MULL OVER IT WELL:
NO ONE CARES WHAT YOU THINK ABOUT ME
ESPECIALLY NOT ME

this post on request from Geti kinda therefore I consider myself justified (doing things for others is the definition of selflessness, after all)

QUATERNARY ADDITION TO POST SCRIPT OF ADDENDUM:
WHICH IS REALLY GOING TO BE EASIER FOR THE CRETINS WHO MAKE CC MODS: AN EIGHT LINE MINIMUM Lua SCRIPT OR A SINGLE EASILY NAMED VARIABLE

pentaddition: I swear to god if someone makes a post saying anything about my capitalization of lua within this post I will eat them

Actually, that code isn't 'almost right' it IS right, I've used it. replace X with a number.

Second, 2 sentences and a piece of lua, a long winded counter-statement does not make.

3rd - Nothing in the world that is not explosive simply 'breaks into pieces' after x amount of time, aside from radioactive isotopes. therefor, Only explosives should have a gib-time anything else involving gib after time, can be handled with lua, OR Null AEmitters attached that are able to destroy parent.

That is not to say that any other statement in this thread is null and void, yes, you could probably control individual emitted particles with lua, but it'd be a pain. yes you *could* use a bunch of AEmitters with no variation and make them overlap to get things at specific angles, but that's ALSO a pain. I agree on the AEmitters bit needing expanded. I also think that pixels and particles should be gib-able just to be complete. also, if they can't be, particles and pixels should be able to be Pinned, or attached.

the rest of this post is not aimed at grif!


Other suggestions include Rotating and animating glows. allow glows to have X number of frames over Y MS time, allow glows to rotate, align to velocity, and align to MOS Rotation... this way we could have Glows in things like muzzle flashes that aren't only areas of light that goes through things.

.PCM support for audio, just because.

Sprites in .png format instead of .bmp, to save space.

Backdrops not needing to be in pallet

allow sprites to be non-specific 255 color, and then allow for a "pallet = pallet location = mod.rte/whatever.bmp" this way you don't have to use specifically the CC pallet, but you would still be restricted to 255 colors to save lag. also it means you could do actor = actor copy of coalition heavy, pallet = pallet, and simply do easy re-colors of existing actors. so that if you want to do a mission and do something like coalition vs coalition they could be like, green vs i dunno pink.

This also means if you actually make a new unit, you could then make a new head for it, do copy-of, and only change the pallet, and get a totally different looking new unit, so you can have your different colored elite units, with LESS FILE SPACE, and not be restricted on color. you'd just have to tweak a few variables on top of that, but thats .ini code and 1 .bmp, not 40 .bmp's bloating up the .rte AND not always looking right.

In addition to custom pallet.bmp's you could do a .ini based indexed-color pallet (pallet.ini) where you would have color 1 = RRGGBB, color 2 = RRGGBB, till Color 255 = RRGGBB, and color NUL = RRGGBB.

support for .mid triggered .wav/.pcm music, using basic midi synth, and replacing specific notes (like drums) with samples. you know, RETRO, since this is a retro game it should support old-skool retro music, Amirite? sure it might lag if done wrong, but thats why it would be *optional*, you know, enable .mid music.

I mean, sure you could always go out of the way to record the .mid w/ triggered samples and export it as an .mp3, or .ogg or whatever, and it would sound the same, but I suggest this because of time scale. By using midi, when it slows down the game, the music would slow down without changing pitch. you could even add alternate for low timescale samples, so that the samples get stretched or something.

I also suggest with that, custom music as a playlist, so that in any given mode it will draw from a list, either at random, or a fixed order. you could have map-specific music, and music that is only on some maps. this isn't exactly a MODDING suggestion in the sense that most people won't even bother but it means that it would support the growth of a retro-music making community, within the mod-making forum. Plus, who doesn't like old-school boss music?

If you had many other proper nouns in caps for comparison I would consider it.

Anywho, optional centrifugal force for gibs and emissions at offset positions from their rotating parents.
It'd be great.


Also, here's my take on Grif's firing mode idea. Simplify!
Instead of FullAuto = Boolean
FiringMode = Number
0 = Full Auto
1 = Semi Auto/Manual/One shot per trigger pull/etc
2 = Two round burst
3 = Three round burst
4 = For rou-- you get the point.

Also, reloading mode. Very similar to firing mode, but for reloading.
ReloadingMode = Number
0 = Reload/Replace the entire magazine at once
1 = Reload one cartrige at a time, EG standard pump action shotguns
2 = Reload two at a time, EG small revolver moon clips
3 = Reload three at a time, EG big revolver moon clips
etc

Okay, maybe the moon clip representation is a tad excessive, but I still want a decent representation of reloading a cylindrical magazine. Without it, pump action shotguns just don't feel right.

being able to track what key the AI is going to press would be extremely useful for the creation of a hovering vehicle or anything along the lines of custom controls.

So you want glows to basically be an MOSParticle of sorts? It'd be neat but I'm not sure it's even possible with the way Data does alpha overlay.


What? Who the hell uses PCM? What the hell is a .pcm file?


That'd actually end up taking longer, as I've explained before. Importing .pngs would require every single object's sprite to be loaded in RAM, since decompressing an image is going to take longer than directly reading it out of an uncompressed file (.bmp)


That'd be neat but isn't exactly a "needed" feature


But the game would still have to have a way of displaying well over 256 colors at a time, which would end up causing as much lag as not having the palettes at all.


That would just be longwinded and take years to make.


Again with the .pcm ♥♥♥♥. We know you're an UBER LEET COMPOSER type, it's okay to not bring that up every thread that has anything to do with audio at all.



The pitch changing isn't due to the file format it's due to Data's sound library. Look in the credits for the game. It'd be (I'm assuming, but it's likely) quite easy for him to remove the sound pitch changing. As a matter of fact, he could probably make it a setting on all playable sounds. That'd be neat (as in, a variable like LoopSetting)



Again with the music stuff.
While it would be nice to be able to create playlists for custom scenes (without just making one gargantuan music file), I don't see the need for this forum to turn into an audiophile forum.

Ability to add attachables to arms without them rotating.
Just make the arm thingo rotating thing only apply to hands and guns.
Arm armour go!

Not sure if I'm saying the same thing again, but arm armor that instead of being one frame, is multiple frames that stay at the same frame number as the arm. Really, an overlaid, nonfunctional arm that extends to the same offset as the original arm.

Pretty much like sleeves <it'll be pretty much adding an extra arm>? Though I'm thinking stuff like large pauldrons and... From reading Allstone's post.

Did so, but thought I'd post it here.

• Proper support for DrawAfterParent

random frame on spawn function for any mosprite.
access via lua to what an actor is currently holding. inventory() only returns what the next item in the actor's "pack" is.
.Parent would be marvelous too.
miles, active modders only, kthxbai.