Modding Requests from SupCom Modders

Howdy peeps!

I suck at most technical stuff (I usually change random variables to random values, and then smash my face into my keyboard, and then upload my mod), but I just want to throw in my voice that I would also love to have mods loaded before the UI, or at least before the MP/SP lobby. Or perhaps the UI stuff could be refreshed after the user changes the selected mods from within the game UI.

I think this game will get me back into modding =3

Thanks, that's kind of my thinking - binary code execution is not necessary if the other modding possibilities are broad enough. My wild guess is Uber will probably end up using a decent multi-platform scripting language like Lua (meh) or Python (yay) or something that has an LLVM compiler. A lot of us modders would probably be very happy with either.

Why is Lua 'meh' in my personal opinion? Seeing what was done in SupCom with Lua was both an inspiration and sheer horror. The whole game was this intricate clockwork that somehow seemed to work even though the scripts looked like someone had simply poured a pillowcase full of gears into a shoebox. Not insisting that was entirely Lua's fault, though.

I said streams, not sockets. Meaning actually abstraction would be desirable (and routing it via the server if necessary). By clients and servers I implicitly meant PA clients and PA servers.

I think many, many mods in SupCom failed because it was impossible for the clients to properly exchange information in arbitrary format without it affecting the Sim somehow. Strategic Whiteboard mod comes to mind.

Still, I believe even sockets have a place (but it might be a very marginal one), and if you have HTTP requests, all "IP protection" will go out the window anyway (assuming you are running a mod you don't trust). Generally, hiding the IP of people on the internet through intentional software design restrictions is a bit backwards thinking and against the idea of that very network. There are some advantages (DoS protection in ranked games, etc.), but ranked games shouldn't be using mods that the users don't trust.

Howdy yourself! Turning out to be some kind of SupCom Modding Reunion! xD

Mike

Hi, you might remember me from mods such as AFS Nukes, AA ACU, LABWars or my all time hit the LD Unitpack. I aspire to eventually make everything fire nukes. Why? Just 'cause!

LLVM IR would be a good choice. It can be JIT compiled nicely and can support the source language of your choice, *and* can be sandboxed relatively easily.

It wasn't, but it didn't help either. There were some very basic violations in there, like two different coding styles in a file, little documentation, the API was completely haphazard in general (lots of functions just dumped in the global table, for example).

However, I'm simply not sure that Python would do any better. There aren't any mainstream scripting languages, as far as I'm aware, that offer the really sweet RAII and strong typing that you can find in C++. And no language can prevent you from making your APIs a haphazard mess

However, I think that at the most basic level, it's going to be a simple question of ensuring that we have the capacities we want by discussing it with the devs and having them listen, which is exactly what appears to be happening, so I'm feeling quite confident here. At least in PA, if I want to write a mod that plays music over the game and I can't because I can't read arbitrary files on the user's hard drive, I know it was an explicit choice by the developers not to allow me to do that.

But I personally would prefer virtually anything permitted if the user allows, with simply sensible defaults. I mean, for one, some mods I simply write for my own personal use, like that maphack I wrote for FA so I could laugh at my friends over a LAN.

On that note, I don't know what you have planned for the UI/Sim communication architecture in PA, but you don't want to follow SupCom's model. The UI didn't get enough information from the engine legitimately to implement many useful mods. An example is simply a list of the focus player's current units, and being able to query ALL THE THINGS about them. That would be ideal. But since it was actually very difficult to learn about the game state in the UI, it was difficult to implement many tasks that basically summed up as "Display information X in a way more efficiently than the native UI".

And then because it didn't synchronize information being sent from the sim to the UI through script, you could simply fork a thread sending it all the information about ALL THE UNITS instead of just the player's own, leading to a nasty information leak. Now if PA is server/client rather than P2P then you won't have to worry about any player-side mods doing that, which is fortunate.

Finally, you'd have to decide on the thin blue line between "UI mods can issue orders for you to, I dunno, implement build templates/build a nice square wall/work around some ordering deficiency and other perfectly fine things" and "UI mods can bot".

I wonder what the reasons for not using Lua are... Personally I love the language.

http://lua-users.org/wiki/LuaVersusPython

.. even if it's on a Lua site, it does give an overview.

Overall, I like Python more than Lua since it's widely used and, despite claims otherwise, it's actually really easy to embed. Plus, in my case, I'd just rather not learn yet another scripting language when there's no need to.

Other than that, JavaScript might be a good embedded language, perhaps better than Python from many POVs.

JavaScript is basically Lua but with a bunch of very bad things, like semicolon insertion and horrifically weak typing, added.

That Python vs Lua discussion isn't bad, but there are some things I would add. For example, the more features come as Standard, the more the developers would have to work to sandbox. It's not really a big advantage because games simply don't need that kind of functionality. Also, ctypes wouldn't come into play. And Lua's very simple and easy to learn.

Lua is basically Python but with a bunch of very bad things, like arbitrary indentation and horrifically weak typing, added.

Lua is okay to learn, Python is a LOT easier to understand and it's pretty much self-documenting, has very clean typing (but doesn't force itself on the developers), and has a shitload of really awesome functionality built in.

Disadvantage of Python will be to properly sandbox it, which is most likely harder than with Lua (not sure, Söldner did it...). And LuaJIT is pretty good, but I don't know what became of Psyco (might be a part of Python 3.x). Python has evolved quite a bit, too.

I will learn whatever the devs choose ,

though I have not worked with LUA yet and only worked with python for 2 days, I actually found the lack of {} in python very annoying. (especially when 3 spaces are not equal to a /t character) But I guess that is a trivial issue.

I'll weigh in for lua because it is what I know (although I'm sure I could learn python quickly). But I don't even know if I'll do modding. From what I hear FA modding sounds quite limited and annoying.

Not been my experience, there are very few ideas I've had that couldn't be implemented in FA.

LuaJIT is super fast, easy to integrate and has a convenient and low-overhead FFI for C.

I doubt the current generation Python implementations can compete with LuaJIT for game scripting.

An interesting alternative for game "scripting" might be using Mono, the open source, cross-platform implementation of C# and the .NET CLR. Mono is also used at the core of the Unity engine. Of course, distributing parts of Mono with PA would probably require a commercial license from Xamarin.

Another option might be to try to support cross platform native code in a sandboxed environment with something based on Google's Native client project.

Well, I was not trying to say anything against Python by claiming Lua to be my favorite language - in fact I think Python is probably the best language for learning to program and some quick standalone coding - but Lua is so nice and compact, got just what you need, easy to embed, easy to sandbox... I wouldn't complain too much if Python got used, it works very well for Blender, but personally I think Lua is a more natural fit for games.

Yes, and tabsize is an editor setting, not a language setting.

It took me a few days to fully get used to it (20 years of programming experience in a number of languages). Now Python is one of my favorites, and sometimes I find myself wondering if curly braces aren't obsolete. (and I code for a living in Java, Objective-C, C, C++ and, rarely, in C#)

Lua irks me, but maybe it's just the random nature of other people's Lua code. Or in particular, SupCom's code.

>>> RANT WARNING <<<

The problem with SupCom's Lua code base was that it is so convoluted and full of really long, wildly nested, randomly indented, or outright unreadable blocks that at first I thought it was machine generated. Then I saw that some poor soul actually left a few and far in-between comments in the code between beatings and the small rations of moldy bread the other programmers would feed them.

It seemed like the people who wrote this were massively overworked and/or had the complexity of what they started go way over their heads. I also glimpsed from a few header comments that the Lua code base was in development for a surprisingly long time. Some of this smells like heaps of crunchtime and dinner at the keyboard to me.

Seriously, as awesome and as complex as the games are, the majority of SupCom's Lua code base is a gargantuan mess, a wildly mutated mix of design patterns, code styles, redundant functions, hard coded sections, and defunct detritus.

Just ask anyone still trying to fix bugs in it... or add new features!

<<< RANT OVER >>>

So, if it's any use, I'd prefer a language that wouldn't allow code to be so inherently unreadable. You can write garbage in any languge, true. Just some languages, like Lua or Perl, have more garbage potential. The jargon term here is 'write-only code'.

As for communication between client and server, why not use some type of nosql-database like mongodb or such?

Its rather easy to replicate such a database on the server and all clients. Also almost any information can be stored in such db, on contrary to strict relational dbs like sqlite. Add the possibility to hook code on the change of specific keys (like the key under which the index for a collection lies) and you've got yourself a propper tool for synchronisation too.

I also see one minor problem with LUA: No propper multithreading support. You can't seriously expect LUA to scale well on a 4 or 8-core machine. This might be irrelevant for simpler tasks like displaying leaderboards or adding HUD. But the singlethreaded AI was allready a problem in SupCom as it made the game scale very bad with mutlicore processors and you can't expect things to get better when we actually have battles with 50.000 units or more. On the other hand C-bindings are much easier with LUA...

Fair point. Well, there's a certain degree of multithreading support, but... let's say some assembly required. You can have multiple Lua threads at the same time, but I don't know how communication between them would work, I've never tried it myself. Man, now I feel like giving that a shot...

--edit--
That was pretty simple, actually. Here's some test code for multithreaded Lua. It lacks the safeguards against memory being accessed from two threads at once, but it shows that Lua is completely capable of multithreading.

Here's to hoping that we can have units that can switch from Land to Air, so that we can have some transformer-style units that can swap modes.

Like RA3's imperial's units ?

http://cnc.wikia.com/wiki/Mecha_Tengu/Jet_Tengu
http://cnc.wikia.com/wiki/Striker_VX/Chopper_VX
http://cnc.wikia.com/wiki/Sea-Wing/Sky-Wing

but yeah, that would be nice to have

There's nothing fundamentally encouraging about Lua to garbage code. It's no PERL. You just need to get over the fact that SupCom's Lua code wasn't very good. It's not a representative sample.

Threading is the bigger problem. AI code could sure use the extra juice, for one thing. That's another reason I'm in favour of LLVM IR. We could even use a tool like Cling to interpret C++ code. Then we could use some of the most awesome tools like Intel TBB.

Also, your sample does not show anything of the sort. Toy examples never mean correct functionality; but especially where multithreading is concerned, trivial examples *never* show anything.