A StartDelay that actually works, like, no way of skipping it by pressing the fire key repeatedly. An extra variable to define the sprite animation acceleration on it would also be good.

after grifs input i'd like to revise and explain my suggestions. first the explaining bit, its short.
I apologize for my longwindedness in this post, but I had alot of things to say, and didn't quite know how to word them, so I did so in 2 or 3 ways for some parts. includes technical bits

.PCM is how they got audio samples, IE Recorded with a microphone, Into old cartridge based games. .wav is a step above .pcm, but PCM's are smaller than .wav, and most importantly they load really fast compared to .wav

As for the pitch change bit, I meant, "Slow down the audio, but not change the pitch" this is very difficult to do, and memory intensive, HOWEVER if it was midi-triggered audio, which might lag a *tiney* bit more, when it slows down for time-scale you'd only be changing the .mid's beats per minute, which means it still has the same pitch.

and as for this becoming an audiophile bored is not what would happen, at the sight of ".pcm? .MIDI?!" all audiophiles are scraping out there ears and eyes at that. I made those suggestions because its retro and this is technically a retro game. I'd suggest chiptunes, but this isn't *that* retro, this is like sega genesis up till the saturn kind of retro, and those wheren't chiptunes.



My Revised suggestions.

This is important to understand how it would work.

It requires 1 extra variable "DecompressStartupTime = 1 or 0"

DecompressStartupTime = 0, would mean all sprites are in .bmp format. DecompressStartupTime = 1 would mean that all the images are stored in .png format. on startup, it would read a.ini-file that has a list of all the .png sprites, and there proper directories. it would then re-save and re-format those files as .bmp with the same file-paths. you know, after initializing the .ini. after it converts to .bmp, it would re-set decompressStartupTime = 1, to 0.

This serves ONE purpose, Reducing file-size of mods on the forums, so that larger mods do not need to be hosted off-site. using.png would require the use of a set pallet to convert to, because .png only supports so many combinations of colors (for example it can't be 3-bit, but can be 4 and 2 bit) I suggest the pallets are all loaded into the same large 'super-pallet' by turning every used pallet into one big image, and then indexing the colors of THAT. duplicate colors would occupy the same slot.

Right now the pallet is 8 bit/256 colors. 9-bit would be 512, 10 would be 1024 colors, etc. formats that support 9-32 bit colors do exist. I suggest that the pallet is the ONLY file that uses one of those, and that all sprites are in fact 8-bit or less. If a sprite only uses 20 colors, there is NO REASON it should take up the resources of a 256 color image. so you *could* make custom mini-pallets. like do it in 32-bit color, reduce it down to say 4-bit 16-colors, and if thats to few to look right, 5-bit is 32 colors, make a 32 color pallet and only use 20 of them.

Now we've hit a bump here. .png does NOT support 3, 5, 6, and 7 bit indexed colors. that means for *those* sprites it would have to be a different format. you could .bmp and everyone will have it working, or you could save as something crazy like .iff and expect users to be able to convert properly.



Honestly even if data doesn't add a batch-converter of in-pallet .png to in-pallet .bmp, someone could make a batch-converter program seperatly, and the massivly smaller filesize of all mods would encourage people to use it, and encourage data to bundle it with the game. The only part of this that is a serious suggestion is the indexed color bits. if it means we have to use .ilbm or some crap that noone uses because its uncompressed (like bitmaps lol) that supports between 1 and 24-bit indexed color, in any combination, so be it, I wouldn't mind if sprites had to be in .ilbm if we had a converter that was either A) built in, or B) bundled as an external editor. oh, or C) publicly supported freeware from off-site.


Just go to wikipedia and look up indexed color. all it means is "a picture that uses a custom pallet with Xbits of color" right now we're using 8 bit indexed color, with only 1 shared pallet. if we combine all the pallets and end up with 600 colors, we know that a 10-bit pallet is required (1024 supported colors) the game only needs to take up the resources for what it can use. it could support up to 24-bit in this manor, BUT it would only do so if it knew ahead of time that it might need it. IE on startup checking all the pallets.


playlist options.

just like AddToGroup, you could do an addMusic = music, AddToPlaylist = playlist,

have a skirmish playlist, have map-specific playlists, and mission specific playlists. New playlist included with each map, it would just be a text file. It could include in the .ini file, how to arange, by .rte order, or by a fixed order. fixed order would be pre-set in the .ini, and any that are added later by song, would get tacked on afterwords, in order of .rte loading.

This means that say, I make a map, and include 3 songs of my own, and tell it to use those 3 songs, and the intro music.

Then say, grif makes a mission, that includes 2 new songs, and in the sound.ini for one of the songs it could say 'addtoplaylist = miles's map playlist' and, when you play on my map, his music would be added in addition to mine. he could also add a line to one of his songs thats says say denyPlaylistUse = 1 so that if someone had his mod, and made a map that said "AddToPlaylist = grif's track" it would either A) error, or B) skip it.

Supported music could include .mid, .wav, .mp3, .AIF, .OGG, and maybe more.




My last suggestion is a new one.

A NEW CLASS - MOSPoly
nothing special, it would be how we could do fluid movement. it would just take the shape of what it touches, you know, become form-fitting. if you dropped something in it, it would just wrap around. important notice. It is NOT a good idea to use it as WATER, you could not swim in it, and you would get stuck, like it was jello. I suggest this for flowing water that pushes things, and most importantly, Concussive explosions, that are more deadly in smaller spaces, that could actually push things out of the only openings.

Hmm, let's see...


I would rather have sounds be slowed down then a little more lag. But it could be changable in the Options Menu, so that might not be a big issue about processing power. I haven't seen a single .pcm fle in my entire life, so modders may have a more difficult time converting, finding, and/or making sounds.


What's wrong with hosting offsite? You're trying to solve a problem that doesn't exactly need solving. And if Data packages a palette convertor with CC, then the person who made it would get a cut of Data's income, along with the Dev team. Sure, it's not that much, but it adds up.


That is actually a sort-of good idea. I was also thinking you could have the music automaticly change depending on the situation (Example: More actiony/danger music plays when enemies are near your brain).


Possibly very laggy. CC would have to calculate where there is no surface on the polygon on each individual atom pixel and apply the needed amount of force on it. Then those moving atoms would make other atoms in itself move and then you have a never-ending mass of lag.

1) every wave editor i've ever seen supports .pcm, noone uses it because its old. you can open audacity, which is freeware, open ANY sound, and open your settings, and save as .pcm, of course by default it'd be a HUGE .pcm that has 20-44100+ hz with no gaps, as RAW data. you'd have to customize it. get rid of un-used frequencys, which for something like an explosion, is usually anyhing above 1K-2K hz. then reduce the bit-rate. suddenly you have a long-ass 8-second audio file thats like 8kb or some crap. it'd be craptastic sounding because that would require 1kbps bitrate which is like WOAH TALKING ON TEH SEGA GENSIS WTF quality

I always thought that for being retro we sure do have some realistic and wtf sounds.


2)Image converter. Add the creator to the dev-team, hire him, and while he'd get payed, he'd also have to keep making stuff. OR he'd be paid a flat commission. if they kept him on, he could work on making external editors, specialized map editors, map-oriented script editor that lets you see what would happen as you go, or offer suggetsions... no wait that'd be HUGE. they could make some sort of lua copypasta machine.


3) MOS Poly- we can technically do it with lua.

it would have 2 resolution values. 1. how many vertexes are there. (vetesies has no spell check O_O) and 2 normal resolution, the way that MOSR's work.

it would work like lua controlled MOPixels or MOParticles. They have to stay X distance away from eachother, if they are not that distance they get an amount of force to get back with, Dependant on distance and some variables. they would also have to stay so far from the 'central volume' or whatever. otherwise they'd just pile up, or turn into a squishy ball. It would also have a volume / density thingey. how much volume does the body of the MOSPoly take up, and how dense is it. If you compress it, or de-compress it, changing it's volume, it would get X force to correct it with. you could even control how it moves, like path of least resistance, every direction, or even reverse it and make it follow 'path of greatest resistance' which is backwards, it would touch something and then push it. the harder it gets pushed, the more it pushes back. but that's getting side tracked, thats a glitchy thing i'd try to do with it.

because you could set the resolution you could minimize/maximize how much it lags vs its effectiveness. I figure it wouldn't lag much more than some of the particle based force-fields people have made, for the same number of vertexes.

it would basically be like having 200 particles for a HUGE volume of the screen, making an outline, and it would treat the inside of that volume as a solid. if something touches it, the particles move, changing the shape of the solid. the problem is, if something sank, it would make a HOLE in the top, and it wouldn't re-seal. the only thing I can think of to do is make it re-seal and move the vertexes around, and dis-connect them, which would be the same as breaking the body of polygons into several smaller bodys. it would fix this problem, but I dont know how it would work.

This could be a good way for our sparkle-magic wizards to get in good with data. they could try to make it work in CC, and get it polished and shined and get data's attention with it, and maybe he'd recycle the code and add them to teh credits or something. maybeh get a t-shirt with a crab on it. I think that if all of our good lua users got together and really tried, they could make this work, and with the right tools, make a custom .dat that could add the class themselves. the problem is it would have to be in an rte. it would need a name like 0000MOSPolly.rte so that its the first thing to load. now if data used it somehow, it would be one of the first things in base.rte.

Its possible, and if it got done right it *might* not lag, at worst I figure it'd be lagy on any big changes. like if 300 particles hit it in the span of half a second. so don't throw grenades and missiles at the poor polys.

The question in my head is how much benefit you get from that much lag.
However you slice it, that much collision detection is going to be laggy. Why would it be better than, say, a shockwave of MOPixels? The only benefit I could see would be jello-like substances, which afaik nobody currently wants. It would be a lot of coding for what would only benefit a very few people.

enough MOPixels to get the same effects would A) only be TEMPORARY, B) does not follow path of least resistance, it goes out and then stops, and C) you'd need tens of thousands of them.

tens of thousands of instances, instead of one that lags about as much as a few MOID's with some attachables. and a little lua.

It would work kind of like the current forcefield mods, only changing shapes like a blob.

we honestly dont know how much it would lag because noone's tried this method.

1) I'll just keep my large, high-quality sounds, thank you.

2)

You want to (or more like make Data) do all that complicated stuff to just use up less space? Currently, all the vanilla .RTEs take up about 60 megabytes of memory, which doesn't seem that much to me.

3)

So don't play CC normally or else it will lag.

*sigh* Miles, I don't know how much programming experience you have, but I imagine it's about on par with mine. IE, two years of high-school computing science classes.
Flat, solid objects are VASTLY easier to calculate for than dynamic objects. Boxes are the easiest possible, and pixel-based shapes are the next step up. Dynamically updating, pixel-based, gelatinous shapes are more than a few steps up.
That said, I concur that we don't know for sure, but I would predict that it's not worth Data's or our time, since you're the first I've ever known to bring up the want for this feature. That is a very small subset of the modding community.

I inteded polygons to be used in specific situations, like an explosion, acid spray, flowing water, a blob, whatever. not something thats always there. if you chuck a bunch of grenades at it, how many collisions is that, and how much does each particle or pixel move the poly, and in how many different ways. its like chucking a grenade into a box of grenades. and since polys wouldn't have wounds, and all particles would keep going... it'd be at it for a while. even by CC's definitions of 'lag for a bit'

They're already going to be colliding with terrain. You wouldn't notice much of a difference in performance, since the collision group of a grenade or particle is much smaller than that of terrain.

Now, this is a massive derail of the thread. You've stated your reasoning, and we have ours, now let's wait for Data to give us an answer. Unless of course you have other ideas about simple annoyances that you encounter when modding, such as the other suggestions.

to reiterate, with a bit more emphasis:also, an addition: stop walloftextspamming what was a nice clean thread with CONCISE and RELATED suggestions. "add a sound format" does not make modding easier, uh, at all.
"add a new class that is a poly and deforms" is i suppose somewhat related, but pretty unreasonable.
you can control the music of a mission with lua, with this amazing thing called soundman. however nice all this map based playlist stuff is, its not making modding easier.
adding .png is stupid, does not make modding easier, adds bloat and generally sucks. guess what milesyboy, you can do this thing where you check a box as you save a .bmp in a proper image editing software and encode it. this compresses a bitmap quite nicely, taking what would be a 4MB terrain file and making it about 2k, maybe 20k if you have some crazy contours going on. so shut up about having a compressed format cause BMP ALREADY ALLOWS IT AND WE DONT NEED TO ADD NEW SETTINGS OR CODE OR ANYTHING, YOU JUST HAVE TO CHECK A BOX. and if you whine about paint not being able to open compressed bmps with paint, i may just slap you.
now, if you keep spamming here with random suggestions that only help you, i'll have to join the masses of people who hate you.
make some suggestions on things that will help in a smaller way, that wont require data going out of his way to facilitate your every whim.


that said, making wind up and wind down work better would be nice, as would a flash that is attached whilst winding up and down, maybe separate for each one.

Something to set the maximum velocity of an ACraft and ideally anything else. I hate using the AAL Arwing because you just end up crashing into crafts you're moving too fast to destroy

A CanLand = true/false function on dropships

Functional tracers on infinite capacity mags.

seconded, five times.
i think that exists.