Modding Requests from SupCom Modders

Hi Uber, just want to see I'm really glad to see you guys taking up this project and I hope the Kickstarter surpasses your Funding Goal! I'm in for 1K, so I've done my part! xD

Anyways, I'm hoping for this thread to serve as a collection point for Modding Requests from Ye' olden SupCom Modders, they're already a few of us posting(Myself, BulletMagnet, DeadMG, FunkOff) and you'd got the GPGNet Off-Topic Forum buzzing with more activity than we've seen in months ;p

Now, Obviously PA isn't using the Moho Engine, but considering the similarities between SupCom and PA I think we'll have a unique perspective on things we'd like to see regarding modding.

For me, I'd like to see you guys stay away from licensed tools as much as possible.

Someone at Uber might remember my(and Hawkeye's) dismay during the Demigod Beta that we wouldn't be able to do any models for Demigod modding due to the Granny tool being used, not that it mattered in the long run but hey.

Same goes for sounds if possible, me and Hawk had a heck of a time figuring out the sound stuff for SupCom, we got it eventually, but it'd be nice if it was easier.

Well, that's all I got right now, I'm sure Dead and BM will have a few things in mind, thanks again for believing in Epic scale RTSes and Good luck!

Mike

Have a working ^ operator? (Link)

Those are good points. I have a few, but they all revolve around things in TA that couldn't be implemented in Sup Com, so as long as TA can be replicated, all my requests are covered.

Proper API/modding documentation would also be awesome.

Might be too expensive to develop before hand thought, I'd be fine with what went down on GPGNet, after release the Devs helped out a LOT with getting modders off on the right foot, but who knows, rare to have a project like this with modder "involvement" so early on.

Mike

I would think that a [bare-bones] API could be documented during development... presumably they'd be documenting their work as they go already.

Here Sorian.

Mike

Hi Sorian! That would be nice. There were ways to load content from other directories in SupCom but it required to edit a settings file. It would be nice if we could hook directories and stuff without screwing around with the engine.

Maybe there could just be a PA launcher that acts both as a splash screen/assets-loader as well as a "hit esc"/"press button" to pause / edit settings... (of course, with a safe-mode switch and shortcut..)

I'm hoping mods will be permission-based and sandboxed, which would allow for mods to request permissions such as "Alter menu graphics" etc..

Ideally, the modding API would let this be a fairly seamless process....

Hmm.. it's been a long time since I've tinkered with the FA engine, trying to bring back to mind some of the more prominent headaches..Overall the engine was fantastic in terms of mod support. The biggest frustration I think was the lack of exterior programs to *manage* the mods - keeping everyone up to date with the correct mod version was always a bit of a pain. Supplemented later by 3rd party programs I know, but still, having the mod management built straight into the game would have made it available to so many more people.

As for modding, some things that would have made life a lot easer:
1. Biggest thing I can think of is - In-Game Debugger!
2. Second biggest would be open access to the tools used by the developers - I don't care if it's complicated or a pain in the *** to figure out how to use.

As for engine mod improvements, I suggest some of these might be relevant (obviously up for grabs depending on how things are handled)

1. Control over the overlay system (range circles) - would have been very helpful to add your own / show more.
2. Control over the system that told the player where they could/could not build (which would show you the green / red outline of the building when you tried to place it.
4. Better unit awareness between the layers (especially while transiting between layers)
5. Support for more unit events to be hooked into (Supcom was good, but there were a few missing)

What I'd most like to see is the relatively seamless transfer of new mods. One of the biggest headaches in SupCom was having to tell people to go download the mod, and etc. Having some mods be server-side only will relax this headache at least a bit.

Another is simply more power. Irritated me no end that I didn't have any I/O.

Yeah, I think adding the ability to join a lobby and then automatically download any mods/custom maps in use would be really fantastic - similar to the way that Source games handle it. It's rare that my friends play with mods or player-made maps because of exactly this reason.

It's also something thats been happening since the original starcraft. Probably why it has such a large following for custom maps.

Join game, get map, play map. Don't see why it wouldn't work for mods.

Size.

If you have a 500MB mod that adds 30 new units and textures, you're going to hold up the lobby for everyone else.

StarCraft maps are small. Everything in them comes from existing resources, so all your map is a list of places and locations to paste things.

Ah... well don't I feel silly for not realising that... especialy having made mods...

The internet is getting very advanced though. Hardly a good solution but it makes 15 years ago's 500k todays 50mb.

I suspect a good way of distributing mods/maps would be via a file host that isn't actually hosting the game. Basically, the host knows where to download the mod from (say, a URL, or a BitTorrent link) and gives that to players that join. They then go download it from where-ever, and re-join the lobby.

It doesn't bog-down the host in the slightest.

It does require extra servers, and dicking around, so it's certainly not a perfect system.

Most mods wouldn't (and shouldn't) end up being 500 mb...

If you're downloading a unit pack with 50 new units, especially without needing textures, the bandwidth required should be really manageable. Asides from storing the 3d models, you'll just be storing code that goes along with each unit... given the complexity of each unit, this should be no bigger (if not strictly smaller) than TA units... so, under 100kb/unit. AFAIK, the TA units required textures to be stored with them.

Combined with caching, it should be really manageable to enter servers and auto-download mods and enable them.

The main problem I see with this approach is that mods will need to be run sandboxed to prevent malicious (or buggy) code from affecting users -- assuming that's taken care of, I think you could easily see a thriving modding community, like that with Source, Starsiege, or Tribes (especially).

Well BM's are a bit exaggerated, but the point is right, BlackOps:Unleashed for Forged Alliance(Link in my Sig) features close to a hundred new units(forget the exact number) and it was still like 150MB or so compressed I think.

So they still can get pretty large and is worth considering.

Mike

I haven't seen your mod yet (I never bought SupCom 1 -- but maybe I will soon) -- but assuming that it's as detailed as your signature (and as SupCom 1 models)... I would expect it to be fairly large. Also, textures

Judging from unit-universe... just looking at 15 units selected at random from the front pages (excluding obvious unit packs):

• 21.7 kb
• 26 kb
• 276 kb
• 38.4 kb
• 45.6 kb
• 11.9 kb
• 12.5 kb
• 30.1 kb
• 14.9 kb
• 35.8 kb
• 21.3 kb
• 94.8 kb
• 256 kb
• 435 kb
• 469 kb

That's 1.75 megabytes for 15 units (~119.3 kb / unit) -- with textures. I'd expect that without textures, we'd see something similar for the average unit in PA as well. If you want to put in an overestimate, maybe ~250kb / unit. This would mean that a 50-pack of units would be 12.2 megs on the upper estimate -- and on the lower end 5.82 megs.

If you can cache individual units client-side, assuming that the best modded units will also be the most popular, I think that any initial delay will be offset by both the ease and the future benefits (e.g., in other games) of both downloading units in-game as well as caching them for future play (online or offline, as well as on different servers).

Obviously, anything larger (let alone much larger) than a few megabytes might be a hassle for a non-dedicated server on a lower-band connection, but that isn't any different from other games -- and obviously, an alternative means for downloading mods should always be available. That said, I think this would be a nice feature in the general case.

Edit:

Regarding I/O ... filesystem I/O, or just "storage I/O" ?

If a sandbox and permission-based system is implemented for general mods, I'd like to see some form of storage I/O made available for mods... (maybe like google chrome's extensions)

I'm assuming those numbers are pulled for TA units? if so I think they are probably very inaccurate to the file sizes PA would end up with. When I get home after work I can take a better look at all the BlackOps stuff, that could form the upper end of the estimate while TA can fill in the lower estimate.

Mike