Lua request.

[Argh]

Um, has nobody considered that using a Widget like this would be complete fail, in many cases? Your enemies could just blow up a building on the edge of your base, set up their arty to destroy your repairing cons, and repeat

Not to mention the economic costs. In trouble? Near-stalling? This Gadget will start resurrecting your Bert while you're trying to steer your cons to assist getting more resources built.

Oh, and what about judgment? How's this nifty Gadget going to "know" which cons you have "reserved"? Gonna check all of the Guard commands every few frames? If ~= Guard and within SomeRadius, then go rebuild stuff? Wait... but what if you wanted to wait a bit? What if you've just self-destructed a useless windfarm, because it's time to tech up? What if you're idling some cons, because you're pushing out a static-arty somewhere, and you don't want to see your econ go to shambles?

And what about priority of replacement, if you've just lost a chunk of a base? Gosh, that's such a lengthy topic, and so situational...

Let's definitely make this a Gadget, so that this kind of automated stupidity is mandatory

I think, LordMatt, you massively underestimate the real problems involved writing anything that does particular task at all adequately. I wouldn't be too scared about this getting written and taking over the world, if I were you.

[Forboding Angel]

Nanotowers...

THink not jsut for *A mods

As an added thought... I would like this for Evolution because I would make a special unit for it limited to one, that would essentially rebuild shit that got killed.

I would like to have it at least, which is why I suggested gadget. FYI resourcing in late game in Evolution si generally not an issue.

[Argh]

Um, if you just need a one-time thing that resurrects... build a standard resurrector TDF, give it the distance you want, turn off anything you don't want it to be able to do, such as assisting, set UnitLimited to 1, and voila...

[Forboding Angel]

Doesn't work, cause stuff gets resurrected for free == not cool.

[Argh]

Then just assign a cost when it's running, via Lua.

[Forboding Angel]

WHy are you so worried about it? I'm talking about a gadget here...

[Argh]

Meh, I'm not worried about it. I'm saying that you should do it. You can do this one, it's not hard. After you get this working, then meh, if you want it be fancy, and take the proportional worth of the thing that's being resurrected into account... then it's time to learn about Tables, which is the hard part. What I was describing is very easy, though.

Read this over, start trying to get this working.

1. You can know when a given Unit has started "building", when StartBuilding() is called, in BOS. Therefore, you have an Event you can build from, and cause things to happen.

2. You can then run a given LUA script.

So, in your BOS:

Code: Select all

lua_MyNiftyLua(arg) { return (0);}

Code: Select all

StartBuilding()
{
  call-script lua_MyNiftyLua();
}

3. Then you'll need a LUA Gadget, that is called by this event and does something useful.

Therefore, in a synced Gadget script, you need something like this:

Code: Select all

function MyNiftyLua(unitID, unitDefID, TeamID)
  --[[do stuff here, probably just change a variable]]
end
gadgetHandler:RegisterGlobal("MyNiftyLua", MyNiftyLua)

This script probably needs to tell another function, using the GameFrame callin, to then make changes to your team's Metal / Energy values, by changing a variable state.

4. When the Unit gets done with the resurrection, it needs to then call LUA again, and tell your script to stop (pass that GameFrame code an argument that causes it to loop on the first condition).

Give it a go... this is a really good first project to try and learn some LUA with, because (in this simple example) it doesn't involve Tables. All you need to do, given what I just gave you, is learn how the GameFrame callin works, and how to pass it a variable. If you can only have one rezzer, like you're describing, then this is totally adequate. For multiples, that gets a little harder, but not much.