Make CEGS OO as well?

[gajop]

During LD34, I've realized having OO CEGs would be helpful, in particular when I was making the mordor effect: https://github.com/SpringCabal/Flove/blob/master/effects/mordor.lua This might just be my lack of understanding of CEGs, but I don't see how I could've achieved the same thing without copying the effect..?

@FLOZi as the author of OO defs may provide additional feedback on the sensibility/viability of OO CEGs

[ForbodingAngel]

I considered OO for a long time when I was doing my evo generic effects. You could, but frankly after thinking about it for a looooong time, I came to the conclusion that it would not be beneficial in the long run.

I love the idea of OO cegs. The throught of just calling a piece of script here and there is awesome, but the problem is that the subtle changes needed for each piece of the effect need to change enough from one effect to another, that any perceived benefit is lost. For example, simply changing the color map might necessitate other minor changes to values due to the fact that the new color you're using isn't as visible as others. For an example of this, green vs red vs purple. Purple is extremely difficult to make look vibrant. Green looks too vibrant almost all the time, and red is somewhere in the middle.

In the end I gave up that idea because it would honestly just be making a crappy problem more technical but not any less crappy.

Your mordor effect is extremely detailed though, so parts of it might benefit from OO. I'm not sure a blanket yes or no answer is really appropriate.

[gajop]

That still sounds like it's worthwhile to use it in some cases, although it might not be as common as {unit/feature}defs. Keep in mind that OO in this case mostly means data inheritance but with minor overwriting. It doesn't necessarily imply a deep class tree or the usual polymorphism that you have in programming languages.

PS: why do we keep using "lowerkeys" in the return value of most unit/weapon defs? Is there some Spring limit with case sensitivity or just some old habits? I dislike referencing things without case, e.g. "bigmushroomkingcrown"

[FLOZi]

My feeling on this has always been 'yes', the use of 'programmatic' CEG generation (for e.g. size variations of the same effect) seems like it should be possible and useful, Might require extensions to the basic inheritance we have now though. I am not au fait enough with CEG defs to really do it.

Pretty sure Lua table keys must be integers or lowercase strings.

[Anarchid]

There's already something resembling modularity or OO'ness in cegs: 1) There's a spawner CEG class which allows spawning other cegs, so if you have a multi-class smoke ceg, you can have it used as part of more complex cegs via the spawner thing. 2) There are damage and radius parameters available for the crazy regex voodoo that are ceg expressions, which can be given by the spawner to the spawned, so if you have a generic smoke, you can have it both big and large in different settings if you use those inputs.

[LebDooder]

Maybe I'm misinterpreting what you mean, but instead of copying a single table you could use a function that returns a 'default' table. You could then have the function merge a new 'obj' with the default then return it.

defaultTable = { circle =  {} } 
function mordor(obj) 
  return merge(defaultTable, obj)
end

function  otherClass(obj)
  return merge(mordor{ otherstuff  = stuff}, obj)
end

return {
  mordor1 = mordor{circle = { key = diffVal } },
  mordor2 = mordor{square =  { key = diffVal }, circle = { } },
  other1  = otherClass{ something = 'like that' }
}

Also, any reason for [[string]] rather than 'string' or "string" in CEGs ? or is that just a style thing that caught on.

[FLOZi]

Simply style - In MCL OO defs I use "for a real string" and [[R G B A]] or [[X Y Z]]

And that is basically what OO defs do, btw.

[gajop]

@LebDooder: As FLOZi said, that's what you get with OO defs, and I think it would be preferable to have a single way to do it.

[[ ]] is also applicable in some cases where " " isn't, most notably in multi-line strings

Regarding table keys, Lua has no such limitations. I'm not sure about userdata, but pretty much anything can be a key. It's advised to not use tables as keys, and it may cause issues in synced. I also think table (object) keys are bad style.

Example of various table keys:

> x = { ABC = 5, abc = 15, aBc = 10, abc = 14, [1] = 1, [10.15] = 15, [-5] = 4, [{}] = 5, [{12, 11}] = 12, [{x=5}] = 1 }
> for k, v in pairs(x) do print(type(k), k, v) end
table   table: 0x1444c50        5
number  1       1
string  abc     14
table   table: 0x1444cd0        1
number  -5      4
string  aBc     10
number  10.15   15
string  ABC     5
table   table: 0x1444c90        12

On a related note, I think I'm going to deprecate lowerkeys for this purpose (unless there's some weird engine requirement).