Page 1 of 1

adding CEGs in unitdefs_post.lua, good idea?

Posted: 12 Aug 2011, 07:17
by knorke
Atm I do ceg effects like this:
in the unitDef there is always some list like:

Code: Select all

	  sfxtypes            = {	
	    explosiongenerators = {
		"custom:smokecloud",
		"custom:muzzleflash",
		"custom:ejectshell",
...
...
	    },	
	  },
and then in the unit script there is basically the same list again:

Code: Select all

local smokecloud = SFX.CEG
local muzzleflash = SFX.CEG+1
local ejectshell = SFX.CEG+2
so that EmitSfx(flare, muzzleflash) works. blablub I think that is how it usually is done.
Now this numbering system with the +1,+2 etc is imo stupid c&p work and supercumbersome if you remove/add effects. Also you end up making the same lists over and over again, in script and unitDef.

So I was thinking to simply add all CEGs to all unitDefs via unitdefs_post.lua like

Code: Select all

for name, ud in pairs(UnitDefs) do
	ud.sfxtypes={
	explosiongenerators = {
	"custom:smokecloud",
	"custom:muzzleflash",
	"custom:ejectshell",
	...
	...
	},
}
end
(dunno if {} are correct like that, doesnt matter)

Then there would be a file CEGnumbers.lua which holds all the

Code: Select all

smokecloud = SFX.CEG
muzzleflash = SFX.CEG+1
ejectshell = SFX.CEG+2
That file would then be included by every unit script.

good/bad? would that be slow or something?
Only limit I think is that SFX.CEG is 1024 and from 2049 or so it continues with projectile numbers instead. (?)
So the number of CEGs would be limited to 1000 but I assume that is guess.
Also I was wondering how CEGnumbers.lua and unitdefs_post.lua could be made to be synced so numbers only need to be changed in one place.

Or maybe just dont use the EmitSfx and use
Spring.GetUnitPiecePosDir & Spring.SpawnCEG?

Re: adding CEGs in unitdefs_post.lua, good idea?

Posted: 12 Aug 2011, 14:50
by FLOZi
Battletech mod does something similar but less extreme;

Each weapon has a customParam cegflare which is the intended muzzleflash, then in weapondefs_post.lua:

Code: Select all

for unitName, ud in pairs(UnitDefs) do
	local weapons = ud.weapons
	if weapons then
		if not ud.sfxtypes then
			ud.sfxtypes = { explosiongenerators = {} }
			table.insert(ud.sfxtypes.explosiongenerators, "custom:JumpJetTrail")
			for weaponID = 1, #weapons do
				local cegFlare = cegCache[string.lower(weapons[weaponID].name)]
				if cegFlare then
						table.insert(ud.sfxtypes.explosiongenerators, "custom:" .. cegFlare)
				end
			end
		end
	end
end
So the jumpjet CEG is always SFX.CEG, and a weapon's muzzleflash is SFX.CEG + weaponID

Re: adding CEGs in unitdefs_post.lua, good idea?

Posted: 13 Aug 2011, 06:54
by knorke
also interessting.
ill give it a try then.

Re: adding CEGs in unitdefs_post.lua, good idea?

Posted: 25 Dec 2011, 18:56
by CarRepairer
I'd still like a solution to this. Adding effects in unitdef files is very tedious and hard to keep track.

Re: adding CEGs in unitdefs_post.lua, good idea?

Posted: 29 Dec 2011, 09:21
by Rafal99
Note that to use UnitDefs in weapondef_post.lua you must add a line "local UnitDefs = DEFS.unitDefs" at the begining.
But generally you can add Cegs or whatever data whereever you want (like in unitdefs, weapondefs or in other separate files) as long as you add a short lua code to put them where Spring wants them.

The code Flozi posted looks needlessly complicated, how about:

Code: Select all

for unitName, ud in pairs(UnitDefs) do
   local weapons = ud.weapons
   if weapons and not ud.sfxtypes then
      ud.sfxtypes = { explosiongenerators = {} }
      local expGens = ud.sfxtypes.explosiongenerators
      expGens[1] = "custom:JumpJetTrail"
      for weaponID, w in ipairs(weapons) do
         local wd = WeaponDefs[w.name] --name should be lower case already
         expGens[weaponID+1] = wd and wd.customparams.muzzleCeg or nil
         --assumes ceg already contains "custom:" part
      end
   end
end
No need to cache the cegs or whatever, you can simply read them from weapondef customparams if they are added there.


In unitscript you can simply do

Code: Select all

EmitSfx(flare, SFX.CEG + weaponID)
instead of assigning names to cegs again.

Re: adding CEGs in unitdefs_post.lua, good idea?

Posted: 29 Dec 2011, 09:41
by CarRepairer
Flozi's code only addresses muzzle flashes. There are many more uses of CEGs in a unit script, such as effects when hit by weapon, etc. I've already went ahead and implemented knorke's solution in my game - but I didn't add all CEGs to the two files. Just the ones I needed for scripts. I can add more as needed.

Re: adding CEGs in unitdefs_post.lua, good idea?

Posted: 30 Dec 2011, 03:19
by smoth
CarRepairer wrote:I'd still like a solution to this. Adding effects in unitdef files is very tedious and hard to keep track.
^ same.

Re: adding CEGs in unitdefs_post.lua, good idea?

Posted: 30 Dec 2011, 04:27
by knorke
Another idea would be replace EmitSfx with something like that:

Code: Select all

function effectAtPiece (pieceNumber, effectName)
   local x,y,z = Spring.GetUnitPiecePosition (unitID, pieceNumber)
   local dx,dy,dz = Spring.GetUnitPieceDirection (unitID, pieceNumber)
   Spring.SpawnCEG (effectName, x,y,z, dx, dy, dz)
end
:arrow:

Code: Select all

effectAtPiece (exhaust, "blacksmoke")

Re: adding CEGs in unitdefs_post.lua, good idea?

Posted: 30 Dec 2011, 18:00
by CarRepairer
knorke wrote:Another idea would be replace EmitSfx with something like that:

Code: Select all

function effectAtPiece (pieceNumber, effectName)
   local x,y,z = Spring.GetUnitPiecePosition (unitID, pieceNumber)
   local dx,dy,dz = Spring.GetUnitPieceDirection (unitID, pieceNumber)
   Spring.SpawnCEG (effectName, x,y,z, dx, dy, dz)
end
:arrow:

Code: Select all

effectAtPiece (exhaust, "blacksmoke")
I imagine that's a bad solution. I'm now maintaining a list of CEGs in unitdefspost and in the file I include in each lus. It's what you suggest in the op. But I add CEGs to the lists as needed.

Re: adding CEGs in unitdefs_post.lua, good idea?

Posted: 30 Dec 2011, 19:38
by FLOZi
Not sure why it'd be a bad solution? Worried about speed?

Re: adding CEGs in unitdefs_post.lua, good idea?

Posted: 02 Dec 2012, 05:42
by smoth
FLOZi wrote:Not sure why it'd be a bad solution? Worried about speed?
m-m-monster bump.

honestly, I am debating about knorke's or flozi's approach right now. On one hand, the function knorke suggests would give greater freedom but then again, it is getting the piece location and direction via requests to the engine.. so I am not sure about the speed vs emitsfx which is 1 call to the engine.