Engine streamline suggestion

[AF]

Currently we have a lot of behaviors and unit logic that runs even though it isn't necessary in all situations. Sometimes it would be advantageous to strip a lot of stuff out and have only whats needed to run the simulation actually running.

Then there's the problem of having to recreate those behaviors in lua and have them running twice if they need to be modified.

So I suggest we start moving the TA unit logic out of the engine C++ code, and into lua gadgets. These gadgets would be bundled along with the OTA base archives. This way they can be overriden and modified if necessary, and those games that do not need them can simply not include them.

This should allow for small gains in performance, possibly negligible, but the added flexibility both in content development and in cleaner engine code should outweigh that immensely.

It would also allow people to fix behavior bugs without requiring a whole new release of the engine, and it would increase the pool of potential contributors since you would not need to be able to compile and understand the engine in order to modify things.

An added benefit would be that it can be done incrementally and not all at once.

Examples of unit logic that could be moved into lua gadgets:

• Air repair pads
• Construction animations & wireframes
• Compound commands such as patrolling

[smoth]

Others:
Com ends
Limit d-gun
Resource sliders
Diminishing metal maker
(and made to work as mod options)

Why remove patrol/airbases af?

[AF]

not remove, but move. This way the logic can be modified by games without duplication.

It also means games that do not have aircraft or repair pads no longer need the behavior running

[smoth]

ok so what about patrol?

[Pxtl]

ok so what about patrol?

"Patrol" is really just a looped group of "fight" commands, isn't it?

[smoth]

"Fight" was added later wasn't it, but to be honest I am not sure pxtl. Sorry. I need to go grab the source again, I have some lingering curiosities about the engine.

[AF]

fight is a patrol command that doesnt repeat, and patrol is the same as a set of fight commands with repeat turned on.

[ILMTitan]

Fight was added later, but Patrol was rewritten (if I remember correctly) to do the looping part, and then transform the currently executing one into a fight command. Most of the code in fight was originally in patrol.

[el_matarife]

I was under the impression that Lua code was orders of magnitude slower than native compiled C++ code. I'm sure most of these features aren't too CPU intensive, but it would suck if we traded some unused code that slightly slows you non-TA mods down for some Lua code replacements that REALLY slow down the TA based mods and anything else that use those features.

[smoth]

It would suck if it slows it down but from what I understand the direct call-in stuff was pretty quick.

[Argh]

Um, from most of the studies we viewed, Lua's pretty fast- remember, it's being compiled at runtime.

Just like anything, there are pitfalls, but they're well understood.

And during the process of moving things, it's quite likely that things could be modularized better and otherwise streamlined. I think that this might be a winner of an idea, for everybody.

That said... who in the heck is going to do it? I'm not really qualified, and we're talking about a huge amount of work here. Do we have enough guys who know Lua and C++ well enough, and do they have enough interest to see this through?

[AF]

Its not as hard as one would think, nor does it need to be done all at once.

[lurker]

Each patrol command acts like a fight command with a special repeat feature. This is different than a unit that's running actual fight commands and on repeat because you can mix in normal commands into a patrol route and they won't be repeated. (Though it would be nice if they went next in line instead of at the end.)