noTeamDamage

[Argh]

For weapons, it'd be nice to not only avoid damage to the Unit that fired the weapon, but to any members of the Team.

[Argh]

Nevermind, I'm stupid I'll have some Lua to do this in a minute.

[lurker]

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.

[Argh]

Voila.

Code: Select all

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

if (gadgetHandler:IsSyncedCode()) then

function gadget:UnitDamaged(unitID, unitDefID, unitTeam, damage, paralyzer, weaponID, attackerID, attackerDefID, attackerTeam)
	if unitTeam == attackerTeam then
		Health, maxHealth, paralyzeDamage = GetUnitHealth(unitID)
		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

I doubt if the engine's going to be a lot faster, since this pretty much relies on the engine to deliver the information used in the logic anyhow, but maybe I'm wrong, I haven't looked at that code. Whatever, all I wanted was to prevent my units from pwning themselves when they get into a fight in the middle of a city or other restricted terrain. This will really help with Resistance infantry, especially.

[KDR_11k]

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.

I think KP T has a dormant no-FF gadget because I wanted to use a ballistic AOE weapon as in Patch-Con for Reimu at first...

[REVENGE]

It would seem sensible to make this an engine addition.

[Pxtl]

It would seem sensible to make this an engine addition.

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.

[Pressure Line]

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.

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. Simple game behaviours (such as explosions not damaging friendlies) really should be engine-side imo, with Lua used to provide additional, customised stuff. Lua hacks to remove hardcoded retardedness shouldnt be required to make a game that doesn't precisely follow the TA model.

*edit* Argh, you should probably kill the "P.U.R.E" from the gadget description imo, since it isnt really P.U.R.E specific.

[zwzsg]

It would seem sensible to make this an engine addition.

No it wouldn't

Yes it would!

I see gadget more being made for very mod specific stuff, while something as universal as toggling friendly damage should be handled by engine and controlled by a single tag, or at this rate all the FBI and TDF will be replaced by LUA... or has it already happened?

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?

[Argh]

Whee. Lot of posts here, for one simple Gadget.

It would seem sensible to make this an engine addition.

No need. I really doubt if it'd be a whole lot faster engine-only, and this is 100% optional.

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

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

Moreover, this is exactly the kind of thing that should be Lua, or at the very least prototyped in Lua before being considered as an engine change, imo.

See the version below, for example- there's a new, non-trivial feature, I wrote it in far less time than it took to write all of these replies, and it makes this a lot more useful, and the possible extensions are, well, kinda obvious. And I didn't need to recompile Spring to do it.

For example, I could make a bunch of "spells" for P.U.R.E. now, and probably will.

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.

While I think that would be great in theory, it would require somebody willing to maintain such a repository, and make it useful enough that it was worth the effort, which requires knowing how things work well enough to provide useful information.

I suspect that we have enough people around here who would be willing to send in code under whatever license they thought was appropriate, but without maintenance by somebody willing to do it without needing a lot of hand-holding from game designers, I think it would fail.

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.

That's called a game-design mistake, and it happens no matter how carefully we think that we've tested stuff.

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.

It's just like COB, which is also a terrifying mess (from a newbie's perspective). While people can get help, mainly we expect people to read the existing documentation, crappy as it is, and go from there.

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

If they were both acting like this one, then yes, they would.

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.

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.

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

All of the pressure is entirely driven by game designers wanting to make the systems they actually envision, and being willing to put the work in to master the skills they need. Same as it always is, man- you want stuff, you frequently gotta build it yourself, if you can't convince other people to help.

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.

While I'm here, here's another version of this, that's a little more interesting. This makes any weapon with (teamdamage) in the name field of the TDF do damage to team members (good for nukes, etc.) while filtering out everything else. This could be extended in various ways, which those of you who know your Lua can probably already see from this example.

Code: Select all

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

BTW, is there a customParams table for Weapons now? I could see some really cool uses for that.

[zwzsg]

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

My awareness of it is the exact reason of my adding: "... or has it already happened? "

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

Already exists, and is nicknamed CA.

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.

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.

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.

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.

[Pressure Line]

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.

my point exactly.

[zwzsg]

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

In this thread alone, Pxtl and Argh are. And everybody else is too, in most feature request threads!

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.

- A single one of such gadget, ok.
- But as soon as you have two of such gadgets, I just proved and you just agreed it's not anymore install-and-you're-done.

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.

[Argh]

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).

Instead of arguing about it, I'd rather just release more optional, useful, powerful code.

Here's a third variant of this simple idea, that reads a customParam (i.e., a "tag") from a Unit, and if it's present, then the Unit always takes team-damage. So, there ya go- tags for weapons, tags that can go both ways for Units... and of course I'm not even really getting into the really powerful uses for this...

Code: Select all

function gadget:GetInfo()
	return {
		name = "TeamDamage",
		desc = "A Generic Team Damage System Example",
		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 = {}

local alwaysTakesDamage = {}

if (gadgetHandler:IsSyncedCode()) then

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

	for ud,_ in pairs(UnitDefs) do  -- search all UnitDef entries
		if UnitDefs[ud].customParams.always_takes_damage == 'yes' then
			table.insert(alwaysTakesDamage,ud,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] and not alwaysTakesDamage[unitDefID] 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

So, in a Unit FBI, you just need to put the following, to enable team-damage for a specific unit (otherwise, this Gadget assumes you don't want team-damage to occur):

Code: Select all

customParams
{
always_takes_damage=yes;
}

If you want a weapon to do team-damage to anything it hits, then just add the string (teamdamage) to the "name" field of the Weapon (which is about the only field that I know of where we can stick arbitrary strings in a Weapon, unless they can take customParams).

So, in a Weapon TDF, just write this:

Code: Select all

name=NameOfYourNiftyGunHere (teamdamage);

Since the only time we even see the contents of that value are when we're in first-person POV, it's not even annoying, for most game designs.

So, there ya go- flexibility in all directions, in one simple package, with instructions.

[Tobi]

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, so if only a single mod needs a tag and it takes a single if instead of a single LUA call, the total amount of CPU time spread out over all mods would probably be lower with engine-side tags

(Disclaimer: this doesn't say anything about whether I think this particular functionality should be in the engine or not )

[Argh]

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.

At any rate, if it becomes an engine function, great, but personally I'd still use this, I'm just barely scratching the surface of what it can actually be used for. I'm highly tempted to test your basic assertion, though, by writing a new method of implementing Armor tables, and seeing whether Lua's faster or slower than the current method.

[jK]

CA's synced lua total performance drop is 0.8%

-> it isn't lua that is THAT slow, it is just the lua rendering (too many glbegin .. glend).

[Tobi]

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.

This wasn't the point I tried to make. My point was that this hidden drag on the entire sim state when the feature is not used, is still lower - when summed over all mods that do not use the feature - then the "drag" of a single mod implementing it in LUA. (I'm sure that applies up to a surprising high number of mods.)

Main point follows from this: it's silly to bring in performance as argument for writing something in LUA
(And it's also silly to bring it in as argument against writing something in LUA, unless LUA becomes a measurable bottleneck ofc.)

Either way, lets get back on topic, didn't really mean to start a huge discussion about unmeasurable performance impacts which hence don't matter at all

[Pxtl]

A gadget can be well-designed to make it so the modder does not need to use Lua.

For example, I made a noselfpwn gadget that requires no knowledge of lua to use. You drop it into the folder and then set noselfdamage tags on the units you wish to be unable to hurt themselves.

The only drawbacks I see with that approach are
1) Gadgets fighting with each other.
2) Spring versions breaking old gadgets.
3) Possibly performance - but going after this one is premature optimization. C++ the slow stuff, and leave the fast stuff in Lua.
4) Documentation and availability. FBI/TDF stuff is all pre-available and documented in the wiki. Gadgets have no centralized locations for distribution and documentation. And no, CA does not count.

A good reusable gadget will perform one (and only one) task, and have any parameters that the user may need to edit clearly marked up top as well as a listing of any custom tags they may need to add to their units.

[lurker]

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.

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.

Right now CA has a gadget preventing self damage where noSelfDamage fails to run in the current spring. It causes the dps widget to give constant popups at the base of an orbital laser, because of the bouncing beam.