Spring RTS Engine

Posted: **21 Aug 2007, 19:03**

To not derail the BA thread:

Argh wrote:[talking about BA for SC] The real question this little episode brought up for me, folks, is how long before the SC people can rip 3DO and use COB. S3O will be a little harder, I suspect. Does anybody know what the progress on the porting tools for this looks like, at this point in time? I suspect that Smoth, Fanger, TRO, and others, who have built large mods for Spring or OTA should probably be concerned about the wholesale rip of their content soonish.

That won't be a trivial affair. I suppose an algorithm that would convert a COB file into an animation file plus lua code could be reduced to the halting problem so they'd need the user to analyze the code (unless they can handle ALL turn stuff in Lua which would be awfully slow).

Just for the heck of it:

Code: Select all

static-var ulamVar;

Walk() {
 while (1) {
  turn lleg0 to x-axis <90> now;
  sleep 100;
  turn lleg0 to x-axis <0> now;
  sleep 100;
  if (ulamVar == 1) turn torso to y-axis<180> now;
 }
}

Ulam() {
 ulamVar = rand(1,1234566789);
 while (ulamVar != 1) {
  if (ulamVar & 1) ulamVar = 3 * ulamVar + 1;
  else ulamVar = ulamVar / 2;
  sleep 100;
 }
}

StartMoving() {
 start-script Ulam();
 start-script Walk();
}

Try converting that animation to a static animation file. In fact, you can probably stuff a Turing Machine into the Ulam() function instead of the Collatz conjecture.

Posted: **21 Aug 2007, 19:19**

while (ulamVar != 1) {
if (ulamVar & 1) ulamVar = 3 * ulamVar + 1;
else ulamVar = ulamVar / 2;
sleep 100;

<3 that algorithm. Here is the link as best I can find it. http://spring.clan-sy.com/phpbb/viewtop ... &start=243

Posted: **21 Aug 2007, 19:21**

Rip the cob interpreter from Spring, and start feeding it commands. Intercept function calls and use them to create animations.

Imperfect for units with complex scripts, still a colossal pain-in-the-ass, but not as viciously nasty as trying to convert directly from COB.

Posted: **21 Aug 2007, 19:33**

Pxtl, that'll fail badly since you won't even know what reactions are just for aiming and sometimes parts of the unit will be in different states. E.g. a unit that opens and then you make it walk to capture the walk script, suddently you get the wrong animation.

Of course, if the script is ABSOLUTELY simple and you can intercept the aiming direction and stuff it might work but that's still only a small number of units.

You COULD implement the COB engine in Lua but... uh... Good luck.

Posted: **21 Aug 2007, 19:39**

KDR_11k wrote:Pxtl, that'll fail badly since you won't even know what reactions are just for aiming and sometimes parts of the unit will be in different states. E.g. a unit that opens and then you make it walk to capture the walk script, suddently you get the wrong animation.

Of course, if the script is ABSOLUTELY simple and you can intercept the aiming direction and stuff it might work but that's still only a small number of units.

You COULD implement the COB engine in Lua but... uh... Good luck.

Obviously, that kind of primitive simulation environment would fail, but you could do it in other cases. For example, you could use an all-flat-map, and note when the unit starts moving. Particularly since you can read the COB variables to figure out which ones are cyclic. Yes, it would take some tricky reverse-engineering, but it'd probably be the best approach if you wanted to use SC animations.

Posted: **21 Aug 2007, 22:31**

AFAIK, Xon was already making TA units -> SupCom units converter before even SupCom was released. Both for the 3do and the cob. I don't know what's his current base of operation, so no links, you'll have to look for him yourself on all SupCom sites.

Posted: **21 Aug 2007, 22:40**

Er, and don't forget, COB can be decompiled with Scriptor and other tools and converted back to a high or low-level language, depending on your preference, for translation back to LUA.

And most mods ship with all BOS included, in Scriptor format. I see no real reason to change this, based on my rather-vague worry about people ripping the mods to other engines wholesale.

Posted: **22 Aug 2007, 01:12**

I was working on a TA2SupCom conversion toolset which currently spits out a baddly skinned model and some pseudo-lua for a TA unit. It is not complete since I've just started working as a programmer and simply dont have the time anymore.

KDR_11k wrote: Try converting that animation to a static animation file. In fact, you can probably stuff a Turing Machine into the Ulam() function instead of the Collatz conjecture.

SupCom supports animation commands from scripting.

There is almost a one-to-one mapping between COB animation commands and SupCom animation commands.

The real challenge is in the extraction of static keyframe animation data, how short are you willing to make the runs of animation commands before you generate a keyframe file. Dependancy tracking of the arguments is also something which needs doing.

Posted: **22 Aug 2007, 04:50**

Just making sure everybody understands that we don't want Supreme Commander script hacks stealing from Spring content makers.

Posted: **22 Aug 2007, 08:57**

neddiedrow wrote:Just making sure everybody understands that we don't want Supreme Commander script hacks stealing from Spring content makers.

Isn't this more of a copyright issue?

Posted: **22 Aug 2007, 09:26**

Yes, primarily. However, there's always the issue of means, and then there is motivation. Since we have seen that there are people with the motivation to start taking some of Spring's innovation and porting it, this is an issue we should continue to watch, but given what Xon had to say, I think it's safe to assume that we're not going to see this happen any time soon, because the technology doesn't exist yet.

Not to discourage you, Xon- I think it's fair to say that if you want to port 3DO stuff (with the notable exceptions of EE and Gundam, rather), nobody cares. S3O, our "modern" format, is a lot more prickly of an issue, since most of the S3O games are still copyrighted to their respective owners. In my case, the only publically-available game, NanoBlobs, the models are GPL'd, so by all means, feel free to experiment with them if you want to, and IIRC, all of the models in Kernel Panic are CC'd, so I don't think that anybody will get upset at all about that.

And SupCom, like any closed-source game engine, is going to be constrained in terms of what people can do with it anyway, and unless the modding community there has more legs than it looks like, the halflife is almost over... so we're probably reasonably safe from having our work taken outright.

In short, now that I've reviewed what's up, I'm not terribly worried about it at this time.

Posted: **22 Aug 2007, 22:21**

After all the Spring features that were stolen from SupCom, and all the content that was stolen from Cavedog, you're now getting worried some SupCom modders might reuse content from Spring mods?

Posted: **22 Aug 2007, 23:31**

Hey, I've always been for stripping out Cavedog content. Also, you can't really steal a feature from an unreleased game - you still have to design and implement it yourself.

Posted: **23 Aug 2007, 00:40**

zwzsg wrote:After all the Spring features that were stolen from SupCom, and all the content that was stolen from Cavedog, you're now getting worried some SupCom modders might reuse content from Spring mods?

my thoughts

Posted: **23 Aug 2007, 14:46**

Forboding Angel wrote:
zwzsg wrote:After all the Spring features that were stolen from SupCom, and all the content that was stolen from Cavedog, you're now getting worried some SupCom modders might reuse content from Spring mods?
my thoughts

+1

Posted: **23 Aug 2007, 21:17**

OOmiz wrote:
Forboding Angel wrote:
zwzsg wrote:After all the Spring features that were stolen from SupCom, and all the content that was stolen from Cavedog, you're now getting worried some SupCom modders might reuse content from Spring mods?
my thoughts
+1

amen

Posted: **23 Aug 2007, 23:05**

TheRegisteredOne wrote:
OOmiz wrote:
Forboding Angel wrote:my thoughts
+1
amen

eloquent as usual

Spring RTS Engine

Ripping Spring -> Supcom

Ripping Spring -> Supcom

Re: Ripping Spring -> Supcom

Re: Ripping Spring -> Supcom