Spring RTS Engine

lurker wrote:I thought you actually wanted it as an engine feature so it would be faster. >_>

CA has it already coded in lua in unit_nofriendlyfire if you're okay with gpl. If you're coding yourself remember to take paralyzation into account.

REVENGE wrote:It would seem sensible to make this an engine addition.

Pxtl wrote:No it wouldn't. It would make sense to make a well-organized repository of gadgets so modders can filch this code easily. In cases where gadgets are high-performance and effective, engine stuff is a waste of everyone's time.

It would seem sensible to make this an engine addition.

No it wouldn't

It would seem sensible to make this an engine addition.

or at this rate all the FBI and TDF will be replaced by LUA... or has it already happened?

It would make sense to make a well-organized repository of gadgets so modders can filch this code easily. In cases where gadgets are high-performance and effective, engine stuff is a waste of everyone's time.

I am also concerned by what happens when you have several gadgets modify the damage recieved via that LUA gadget:UnitDamaged, and the modder doesn't pay enough attention to the layers.

For instance, if you have two different gadgets to counter damage, do units get healed by shots?

If you have something like KP firewall and some nodamage widget, do units explode for shooting units they didn't hurt?

That assumes that anyone who is modding is sufficiently versant in Lua to identify the required part(s) of a lua gadget(s) and configure/modify it/them to produce the required behaviour.

function gadget:GetInfo()
	return {
		name = "TeamDamage",
		desc = "P.U.R.E. Team Damage Prevention",
		author = "Argh",
		date = "December 10th, 2008",
		license = "Public Domain, or the least-restrictive rights in your country of residence",
		layer = 0,
		enabled = true,
	}
end

local Health, maxHealth, paralyzeDamage = 0,0,0
local SetUnitHealth = Spring.SetUnitHealth
local GetUnitHealth = Spring.GetUnitHealth
local exceptionList = {}

if (gadgetHandler:IsSyncedCode()) then

function gadget:Initialize()
	for i=1,#WeaponDefs do
		if string.find(WeaponDefs[i].description,"(teamdamage)") then
			table.insert(exceptionList,i,1)
		end
	end
end

function gadget:UnitDamaged(unitID, unitDefID, unitTeam, damage, paralyzer, weaponID, attackerID, attackerDefID, attackerTeam)
	if unitTeam == attackerTeam then
		Health, maxHealth, paralyzeDamage = GetUnitHealth(unitID)
		if not exceptionList[weaponID] then
			if paralyzer then
				SetUnitHealth(unitID,{paralyze = damage + paralyzeDamage})
			else
				if Health + damage < maxHealth then
					SetUnitHealth(unitID,{health = Health + damage})
				else
					SetUnitHealth(unitID,{health = maxHealth})
				end
			end
		end
	end
end

end

Argh wrote:It's already happened, you just aren't aware of it. Spring uses a TDF-->Lua parser now, it's all basically Lua.

It would make sense to make a well-organized repository of gadgets so modders can filch this code easily.

There's no way to prevent stupid kids from stuffing their games full of Gadget code that they don't understand, that they can't fix, and screwing up their games, zwzsg. All we can tell people is that if they don't know what they're doing, then they probably should lrn 2 Lua.

If you have something like KP firewall and some nodamage widget, do units explode for shooting units they didn't hurt?

Widgets cannot do this stuff. That would be a cheat.

zwzsg wrote:I was led to believe a strength, and aim, of the Spring engine was its moddability. But it appears the direction has been steered, and the new goal is to ditch all the C++ code to replace the whole website with a link to a LUA interpreter and a "Lern 2 prgm ur own game, n00b!!" message.

Nobody's putting a gun to anybody's head and telling them that they have to learn Lua, or use it.

That, and stuff like this is practically idiot-proof. Install it, and your team's weapons will never cause damage to your team's units. Period.

Argh wrote: I'm guessing that further philosophical debate's entirely pointless. If you want to live in a Lua-less world, be my guest, nobody's forcing you to use this, unlike engine-side tags, which are not optional, eat CPU even if you're not using them (that infamous if-->then stuff that KDR thinks I'm so stupid for mentioning, it's still not free, and every new tag adds another one to Spring somewhere, often in multiple somewheres).

One if in C++ is still a million times faster then executing a single LUA call

Argh wrote:

One if in C++ is still a million times faster then executing a single LUA call

Well, that really depends. If it's C++, then it's a hidden drag on the entire sim state, whether or not the game designer's making use of it. It's an opportunity cost, basically.

Yes, any C++ vs. Lua comparision will show you that, in isolation, Lua's a lot slower than C++. This is absolutely true.

However, when you look at something on the order of complexity of Spring, I think that it's very arguable and situational.

zwzsg wrote:Sorry I wanted to type gadget, but mind was getting clouded from having to restrain myself to add question about what if there's also widgets relying on that call, as I knew people could retort that widget happens in a seperate stage.

zwzsg wrote:Since nowadays more and more gameplay mechanic have to rely on this meddling with damage received ugly LUA hack, the probability of having a mod aggregate two of such gadgets and then splode rise greatly.