Spring RTS Engine

I know I am not the only one who would like to see this. It is a FBI tag that will limit what a con unit cannot repair based on category.

If the unit cannot repair instead of a repair icon you would get one like:

and it will not move to repair etc.

Now before someone derails it with some random other feature request.... that they feel would augment this.. this is all that I am asking so please do not derail this thread.

Agreed. The repair/assist/reclaim/resurrect actions are stuck in TA-land right now, and a lot of those details need to change - and this is a good place to start.

I think if a unit can't do one thing it just shows the next possible order, if a unit is canrepair=0 it just guards the target (but doesn't do any repairs as part of that guard duty). Wouldn't the same work for things it can't repair, reclaim, resurrect, etc? I know the reclaim cursor just turns into the select cursor if you try to issue a reclaim order on a reclaimable=0 target.

it is a construction unit, what else would it do on a guard order.. it cannot really do anything but construction

no, all I am asking is just this little tag. They do not have to do the (/) symbol but the tag would be very usefull.

fwiw, you can now add and replace mouse cursors dynamically (LuaUI)
Of course, if it was added as an engine feature, the (\) symbol could be
added at the same time.

smoth wrote:it is a construction unit, what else would it do on a guard order.. it cannot really do anything but construction

Well, it stays close to the other unit. Dunno why you'd want that with a unit that can't do anything to help but I guess it may be useful to keep them together or for some kind of widget.

I agree that the tag would be useful but I'm not sure if it should be including or excluding (i.e. cantrepaircategory or onlyrepaircategory).

KDR_11k wrote:Well, it stays close to the other unit. Dunno why you'd want that with a unit that can't do anything to help but I guess it may be useful to keep them together or for some kind of widget.

S:1944(aata) medics who can only heal inf and mechanics who can only heal tanks.

Gundam could have construction units that can only repair buildings and nanotower like buildings than can repair mechs but cannot conassist..

EE could have hubs that can heal buildings but not tanks and hangers that units can go in to be repaired(again similar to nanotowers)

Ulitimately it would allow us to limit the unit to not repair X thing and still repair what we have not eliminated. In my mod I would just add repair categories label "repaira"(repair aircraft), "repairm"(repair mech) and "repairb"(repair buidling). However, I may just do my own odd thing. The categories will probably be anything ranging a-z with no obvious convention because this mod will not leave my control, other moders can do the same or use meaningful names.

Also as a note, many moders have used up their categories and need to elminate MANY useless categories(TA:S moders I am looking at you)

The point is that there is a need to limit what a unit can repair and in certain situations... i.e. a damaged tank.. a surgeon is useless. However, having a medic and a mechanic in a squad would mean you can heal either and it would mean that they would be units that you want to protect in a squad.

as far as can or cant it makes no difference to me which tag we have I just want to be able to limit what can be repaired by what. A giant crane healing infantry is asinine.

I like the tag too and would like for some limit on reclaiming, resurrecting, etc as well. An idea I had was to make buildings die into features that are basically the building but devoid of any personell, infantry would be able to revive the building (would also need some way to make resurrection cheaper and faster, it's ridiculously slow and expensive right now) but they couldn't repair e.g. a tank wreck.

Really, all builder actions need to be limitable, from what they can assist with to what features they can reclaim.

LuaRules and LuaCOB can limit anything you want with AllowCommand... if you don't care about AIs. But you knew that already - or have seen it coming, didn't you?

Let's just rip out the whole unit code and tell people to implement it themselves in LUA.

imbaczek wrote:LuaRules and LuaCOB can limit anything you want with AllowCommand... if you don't care about AIs. But you knew that already - or have seen it coming, didn't you?

Not helping.. and it would be more efficient if it was hard coded.

Fucking tag forest. So annoying.
LUA should just come in and save everything. It can, after all. Current efficiency be damned, COB is hopelessly outdated and it would be easier at some point to simply integrate and optimize LUA for Spring rather than keep adding random tags.

At that point we may as well tear everything out and start from scratch using a standard VM like the DotNet interpreter. Hey, how about we get half the top-level developers to abandon the Spring project and try to do that!?

/sarcasm.

Seriously, there's a set of trade-offs associated with tags vs. script - tagged stuff behaves in a consistent manner that the AIs can comprehend. Scripted stuff confuses the hell out of the AIs. Lots of things that should be done as tags are done as script, and vice-versa (the Immelmann is a good example).

Dragon45 wrote:Fucking tag forest. So annoying.
LUA should just come in and save everything. It can, after all. Current efficiency be damned, COB is hopelessly outdated and it would be easier at some point to simply integrate and optimize LUA for Spring rather than keep adding random tags.

FOR THE LAST TIME!

LUA WILL ALWAYS BE SLOWER THEN COB OR HARD CODED FBI TAGS YOU ARE NOT A MODER YOU HAVE NO USE FOR EITHER SO STOP TRYING TO DICTATE WHAT METHODS ARE AVAILABLE TO US!

oh and the antiquated cob scripting system is very powerful, I am sorry that you cannot grasp that.

I think the slowdown wouldn't be noticable here since it would only be called when the engine has to check if an order is valid which shouldn't be that often. A tag would still be more consistent than a Lua script, though. I think Lua is inapproriate for "static" solutions, i.e. ones that will always return the same value for the same input, independent of the game state (e.g. repairing the wrong category will always return false, no matter what else is going on while ordering an orbital attack would return true or false depending on factors like when the last one was ordered). Same as I don't like the idea of using Lua for making mobile factories if the factory is ALWAYS supposed to be mobile. Imagine what if someone decided that since you can COB the decloaking code you have to do it yourself or that upright can be set in the COB and thus doesn't need to be read fromt he fbi?

i agree with dragon. For the sake of engine design, it is much better to implement such things in lua.

I don't think LUA is an ideal solution, though I'm a little thin on the specifics. What I believe would be most effective would be an entirely new, powerful scripting language with good documentation and low overhead. It would draw from a number of models, take far too long to produce, and then we would have to code converters to move the current COB and LUA scripts into it regardless, because it is just cruel to ask modders to learn an entire new language to run anything.

Much easier said than done.

CE tries to find middle ground by using .NET for it's scripting. There are powerful scripting languages that target the CLR, so it's a good choice -- but it should also support mono.

Other than that, Lua is as fast as it gets in sane, small scripting language domain. I'm a Python guy, but Lua is an understandable choice because it's so small and integrates so cleanly.

wrt new scripting languages, don't. It's a good exercise to make one but f***ing hard work to make a good one.

JC, the problem is that trepan himself stated that lua can be a bit on the expensive end.

However, I'd rather use lua for augmentation and these sort if tags can be written in patch.

As a curiosity, how would you suggest this sort of thing be handled via lua? It seems like you would have to do a check on all repair orders including patroling units etc.

consider all the behaviors that have to be monitored for repairing orders.

I've never used springs lua interface, but i can imagine the only thing that happens is a callback from C++ to lua whenever a command is given by a user/AI. That means the slowdown caused by lua is totally not noticable, because users give max 3 commands/second or something.

The check for repair orders should be done just once when given, so lua doesnt need to iterate through all units every frame.