Is there a copy of chickens that is abstracted from a game?

[Forboding Angel]

I tried using the BA one. It's a hot mess but I cleaned it up and was bugfixing all over the place, but I got stumped when it started failing to read tables from the config even though the config seemed to be getting called correctly.

Long story, I think It's not 103 ready. The problem is that there are a TON of moving parts to chickens, so it's not as though it's an easy thing to just copy and paste. But some people expressed the desire to have legit chicken defense in Evo, so I'l looking into it.

Is ZK on 103? Do you guys have a repo of chickens separate from ZK? If anyone wants to help abstract it, I'll help and we can set up a communal repo for it?

[Silentwings]

Strictly, no, because there has to be interaction in minor parts such as modoptions, LuaAI defs, spawning, game end conditions, loadscreens, etc. Aside from that, afaics BAs chicken mutator is pretty much standalone and I don't think you'll find anything significantly easier to start from.

But (speaking as someone who once did it) transfering chickens into a new game would be easier if the main body of it was not one huge gadget. I once read it through and wrote a plan for modularizing, but didn't implement it - maybe useful http://imolarpg.dyndns.org/trac/balatest/ticket/910.

[Forboding Angel]

Strictly, no, because there has to be interaction in minor parts such as modoptions, LuaAI defs, spawning, game end conditions, loadscreens, etc.

Look at what I did with controlvictory... In comments I put a copy pasteable modoptions set. Same could be done for the luaai defs (it's just a table/set of tables anyway -> copy pasta). All that you list there is pretty trivial for the most part.

One of the largest issues with the one for BA is the fact that it is so entertwined with BA. It uses move classes from BA, weapons from BA, it even uses sounds from BA.

And the modoptions sets are terribly messy.

I can fix most of this. Could you help me figure out why loading the config in this manner seems to not work in spring 103?

Code: Select all

do -- load config file
  local CONFIG_FILE = "LuaRules/Configs/spawn_defs.lua"
  local VFSMODE = VFS.RAW_FIRST
  local s = assert(VFS.LoadFile(CONFIG_FILE, VFSMODE))
  local chunk = assert(loadstring(s, file))
  setfenv(chunk, gadget)
  chunk()
end

Edit: Please refer to this thread: viewtopic.php?f=23&t=35518

[Silentwings]

It uses move classes from BA, weapons from BA, it even uses sounds from BA.

To my eyes this another trivial issue: extract the shared media/defs from BA and copy in. What matters is that there is essentially no interaction between BA and BAC code.

And the modoptions sets are terribly messy.

They are BAs modoptions (which are tidy but would be overwritten if they were not duplicated there -> interaction is required here) plus chickens own modoptions (which are not tidy). Since it is clear from the names which is which, you can simply delete the non-chicken ones, 1 minute job I think.

Tidying the chickens modoptions is more difficult, since selecting which ones to keep is likely to not to be game-agnostic.

Could you help me figure out why loading the config in this manner seems to not work in spring 103?

Those same lines of code do their job in Spring 103 with BAs chicken mutator (using latest svn), so without knowing what it is you're doing and what you're expecting to happen, I can't say anything here.

[Forboding Angel]

Implementing it resulted in the spawner claiming that the tables in the config are nil.

As far as the other stuff, in the git repo I made, I have already done the above. It's a lot of grunt work, and a serious pain in the ass, but it works.

I suppose I'll use BA to implement it into (directly) and see what happens. Ideally that repo I made can house a copy for anyone to use that they can implement within a few minutes time.