Projectiles

[Argh]

Ok... so we now have ProjectileCreated / Destroyed. We can get projectile IDs, and in theory Do Stuff. However... there's a problem. Without the relevant weaponID, we can't do anything useful- no game is going to want every single projectile to use the same effects or even to run code based on their existence.

So... how do we correlate them with weaponIDs? The projectile owner ID is always set to the team ID -1 (i.e., team 0 returns -1). The projectile IDs seem to just be an integer value that just ratchets up when each weapon fires, so we don't have any data at all to draw upon. We can't just guess, or even use Lua callins triggered via COB whenever something fires- I suspect that won't work, because of concurrency issues.

So... how's about a UnitFired() callin, that gives us the projectile ID when a weapon fires, and the relevant weapon ID? Then we finally have all of the pieces we need, to track the projectile and generate effects at its current location. We don't need the unitID or the allyTeam (which projectileIDs get assigned to right after they're created by the given Weapon, IIRC)

Then all we need, for really awesome LUPS stuff besides really generic particle effects... is to get the orientation of said projectile, and probably a named Piece would be good (so that we can do things like attach effects to them).

I know projectiles don't currently care about Pieces at all, and all current effects are generated from their center. It's even cruder than OTA, where you could at least spin the propeller, and I honestly wish that every Weapon that had an associated model also had a COB script- we could do some pretty amazing stuff then. I asked for that awhile ago, and it's still on my wish list. But having the orientation of the Projectile, not just its position and velocity, is a start. However, it's still basically useless until we have WeaponIDs to associate with the Projectile. I guess that means that Piece projectiles need a weaponDef, among other things. It'd be cool if we could define that, although the ability to attach CEGs directly to such events is mighty nice already.

[Gota]

Does this new feature means we can make a dbz game for spring with controllable energy balls?

[Kloot]

The projectile owner ID is always set to the team ID -1

Engine bug, it was always set to -1 regardless of team. Gone as of now.

Weapon ID's are harder to get at, hence why the call-in doesn't provide them (yet).

[Argh]

Meh, I know, providing a backwards route is not going to be fun. Just sayin', that's the key there, along with having the projectile's vector in worldspace...

[lurker]

Can't you ping from luacob when the shot fires?

[Argh]

Sure I can.

But when two different weapons fire on the same frame... since I don't have a teamID, a unitID or a weaponID... I have an integer without context.

And I can't exactly use it to do the cool stuff unless I have enough information. I could use the current system for, say, a global Lua-generated blur effect on particles, but I can't get the specifics- is this is RocketA, or CannonB?

[lurker]

Frames are merely an arbitrary framework. If you run code mid-frame, it happens mid-frame. Use ShotX or whatever, and if things are set up happily it'll either be the projectile directly before or directly after.

[Argh]

I already use shot for everything.

It's that either / or that's the problem, lol! And last time I checked, weapon events were still frame-bound (and were actually limited to fewer than 32 frames / second). Has this changed recently?

[lurker]

I'm not making my point clearly enough. Everything in a frame happens in order, there is no concept of simultaneous in spring. ShotX happens in the MIDDLE of a frame, and if ProjectileCreated also happens in the middle of the frame, then you get a projectilecreated, a shotx, a projectilecreated, a shotx, a projectilecrated.

[Argh]

Even if I trigger Lua as part of Shot... I do not have the projectileID.

So, I can have the WeaponID via the UnitID. And I can see a projectileID through projectileCreated.

The problem is, that there is no 100% certain way to match them up. You can't use a timestamp, for example, because it won't match. You can guess, and most of the time it'll be right, but it can be wrong... and then your Uber Super Giant Anime Deathbloom just got used by an Itty Bitty Teeny Peeshooter. Not a feature

However, if ShotX returned the projectileID that was created, then I'd have all of it there- the weapon's ID, the unitID, the projectileID. Send it to Lua, and voila, no mistakes.

But that's just the semi-immediate problem of generating dynamic effects.

To get to the really interesting stuff, we need to be able to manipulate projectileIDs more in the future- create them, destroy them, retarget them- and that cannot be done within this framework, so we're going to need to have a given projectileID have an associated weaponID.

Can't the weaponID just be stored along with the projectileID, as a second entry in a table? It seems the easiest way to solve this- keep the two things bound, but force people to use Lua to determine what it means and how to manipulate it. All I need is information that's reliable, after all- the problem here is that the information that's available is not reliable enough to use just yet.

[lurker]

How is this unclear?
Don't use a timestamp. If the ProjectileCreated callin triggers midframe then it will either come directly before or after ShotX. Directly means in the next few lines of code, and nothing else will happen.

Stop thinking in terms of frames. Frames are a completely arbitrary scale. It would be like saying you can't tell what unit won a fight because it happened between chat messages.

[Argh]

What if two weapons fire at the same time, though? Are they going to go run the LuaRules code and return before the next ShotX... and will the projectileID exist yet?

Meh. I'll test that.

[Pxtl]

@Argh: he pretty specifically said no.

@lurker

While I understand what you're doing, I've worked with similar paradigms while developing sites in ASP.Net (another application where the event handling is heavily focused on order-of-events).

Down this way, madness lies.

[lurker]

same time

No.
Such.
Thing.

Are they going to go run the LuaRules code and return before the next ShotX

That's my 'if'. The answer is probably yes. It would be strange to make a list and then call later.

will the projectileID exist yet?

It clearly exists when ProjectileCreated is called, and that's the only place where you get ids from, so yes?

[Argh]

<comes back from test>

I've already found a showstopper. BeamLasers don't create a projectileID, lol.

I'll test with something that uses a LaserCannon here in a second...

[Argh]

Ok. Need to look over the results, but it appears that the projectileID is created before ShotX. Yay, that keeps things simpler.

To test:

COB

Code: Select all

lua_TestShot(arg) { return (0); }
Shot1()
{
	call-script lua_TestShot();
}

Lua

Code: Select all

function gadget:GetInfo()
	return 
	{
		name = "ProjectileTest",
		desc = "Testing projectiles.",
		author = "Argh",
		date = "March 20th, 2008",
		license = "(C) Wolfe Games",
		layer = 1,
		enabled = true
	}
end

local a,b,c
if (gadgetHandler:IsSyncedCode()) then
-----------------------------------------------SYNCHED
----------------------------------------------------------------
------------------------------------------------------------------------
local function TestShot(u, ud, team)
	a = u
	b = ud
	c = team
end
gadgetHandler:RegisterGlobal("TestShot", TestShot)

function gadget:ProjectileCreated(proID,proOwnerID)
	Spring.Echo(a, b, c, proID)
end
------------------------------------------------------------------------
----------------------------------------------------------------
-----------------------------------------------END
end

Results:

Code: Select all

[    510] 157, 141, 0, 1
[    513] 157, 141, 0, 2
[    516] 157, 141, 0, 3
[    519] 157, 141, 0, 4
[    522] 157, 141, 0, 5
[    525] 157, 141, 0, 6
[    528] 157, 141, 0, 7

So, in theory, just pass a fourth argument via COB, if that argument == A, then put the projectileID into someTable go through someTable to generate FX at whatever interval.

[KDR_11k]

I've already found a showstopper. BeamLasers don't create a projectileID, lol.

That's because they're not projectile based, the beam projectile is just a graphical effect that's added in addition to the firing. If you want a weapon effect for a beamlaser you have to track the explosion, that's how the connection arc beam works in KP.

[Argh]

Yeah, I know, or generate an effect based on the Piece orientation in worldspace, etc.

Just sayin... it'd be nice to have consistency. If a given weapon just generates an explosion, then you need a totally different method to track it. Giving out an "projectile" ID that gets removed next frame would be consistent behavior- that's all I'm saying.

[lurker]

If you want explosions, use the explosion callin. If you want projectiles, ust the projectile callin.

[Argh]

I want a unified, streamlined solution that's easy to present to modders. Exceptions are the bane, and Explosions require WatchWeapon.