Morph Gadget needs fixing. It expects some changes to main.lua, and it does not play nicely with projects that do not expect it to be altered.

This version doesn't require modifications to any of the base Lua files; IDK whether it will sync 100% correctly, but it operates correctly in single-player mode.

I'd also like to urge you guys to quit distributing modified versions of Spring base files in general, since that means that projects that borrow your code tend to break when newer Spring versions introduce changes, and it certainly makes integration with other code that does not have that expectation a huge chore. It also means that people who don't really know much about Lua are dumping your base files willy-nilly into their games because they can't figure out which "mystery meat" code is breaking the feature they want to use.

Surely this one Gadget (which, so far as I can tell thus far, is the main reason you're doing this) can get modernized- if what I've done doesn't pass some MP testing, please figure out another way.

Sorry if the above sounds grumpy; it's just that after seeing various versions of this code break stuff in Savegame and the weird problems that ensue after fixes were written to try and avoid these issues, I am kinda tired of dealing with this one piece of rogue code.

I'd like to say the gadgets you guys have put together are great, and it's a testamant to their good design and features that they do get used so much.

But I myself have gone through the exact process Argh described to set up Bob for Blood and Steel (and indeed, it was the morph_gadget he wanted to use). I can't say I have a clue on what kind of stuff you do in the custom lua base files, and I wouldn't go so far as to suggest you do away with them (for all I know, you might rely on them heavily). But it'd be nice if the gadgets depended on it as little as possible, or there were a version made "sans requirements".

Hmm, this is leading me towards a related suggestion I had in mind, which would be a "gadget-repository" similiar to the widget-database we have... maybe I should start a thread on that, and the issue Argh and I are raising might be better addressed in that manner.

Patches are welcome.
Please provide them in the following way: a modification of the current version or a diff against the current version.

main.lua is part of the mod and not some base file.

CA is mostly multiplayer game.


Mod files. We are modifing mod files.

If new spring versions break our code then we will fix that in CA. So just borrow it again.

They should probably learn about lua anyway.

Mods are different even on the technical level. There is no reason why CA should provide and maintain working gadgets for other mods. This is similar to widgets - not all work with all mods.
If you have specific question, we'll try to help.

It was attached to that post, all you have to do is take a current SVN rev, delete the base files, put that version of the Gadget in, and see what, if any, errors occur

Main is a base file; it is distributed with Spring. You guys ship CA with an older version that was modified at some point to operate with morph gadget; it's not necessary any more (or if it is, then there's something important missing from Spring's distribution).

The only reason you have to even distribute main is because of morph gadget, so far as I can see. I'd have to double-check that vs. your current SVN rev., but my guess is that it's still the only reason.

You don't need base files for newer things- some of the stuff trepan put into morph_gadget has been addressed in Spring's base files at this point. So basically you're distributing code that's legacy stuff, without good reasons, and it makes your code less portable and transparent to newbies, because they can't be expected to understand main (which is, let's face it, not the best-documented code ever written). Or there's something legitimately missing from Spring's base (which I kinda doubt, after fixing what was wrong with the gadget).

Lastly, having the expectation that if you're distributing code that's causing havoc when newbies stick it willy-nilly into their projects because it requires legacy dependencies that could be done away with is a bit of a reach. We all know it doesn't work like that. Newbies, at best, will figure out the config.

The main.lua of KP reads:

The draw.lua of KP reads:

And these are the only two files in /LuaRules/

Guys, guys, before things get any more inflamatory here, lets cool it!

Both sides here have a point. As I hinted at above, I suggest we set ourselves up with a gadget database, which I think will solve some problems without putting requirements on anyone. How does that sound ?

Go to new thread here - in case you somehow missed the first link...

That is an version old version and missing many changes. As I said:



Spring doesn't ship a main.lua for LuaRules. It calls the mod's one.


You still haven't pointed out exactly where. I'm not going to read 36kB of source code line by line.

zwzsg: There have been made some changes to CA's main and gadget lua files, most of the changes seem to copy spring changes. Can't say yet if and how easy a change would be.

I was merely pointing out how despite being mod files, /LuaRules/main.lua and /LuaRules/draw.lua can use base files.

It shows that a mod can include just its own gadget, and not the entire gadget handler. It is nicer that way, as every mod automatically benefits from the improvment of the gadget handler in base, instead of having a hundred modders having to independantly maintain their gadget hanlder.

Argh & me say it would be nice if CA could stop using custom gadget handler, as CA has become the de-facto gadget repository, many mods are drawing gadgets from CA, and find themselves forced to pull the whole handler instead of one gadget. And then a year later we find ourself having outdated custom gagdet handler lying in many mods.

Understood but low priority.

Someone could upgrade gadget handler in CA too.. contributions are always welcomed.

Well, that's fine, but until you address this issue, World Builder will not operate for you.

I'm not a lua dev but lets try and preserve compatibility guys, we want to encourage development.

I don't imagine it's that hard to merge Argh's changes into the current rev using WinMerge or SVN compare...
Only reason I'm not doing it is because I don't fully understand the morph code and might break something.

First thing I tried was to make the diff myself to see the changes, but only output I got was 2 different files (everything was marked as change).
Now I know why: windows encoding.
Still 300 lines of changes.

Why don't you just start from the obvious place, and just drop the gadgetHandler and then keep fixing Morph / other stuff that gets broke until it all runs again? Morph Gadget may not be the only thing that's been made dependent on the gadgetHandler since whenever that version I fixed was written.

The obvious place to begin is here, to convince you to stop requesting changes so that there won't be any work to do.

It's the real problem. Start there, work through the problems. The real goal here isn't some minor fix to gadgetHandler, it's proper interoperability.