Spring RTS Engine

Spring.EmitWeapon(weaponName, x,y,z, dx, dy, dz)

Just a call to fire a weapon as though it was fired by a unit at a designated point in a designated vector.

INBEFORE KNORKE SAYS HACKY SPAWNING OF A UNIT IS ACCEPTABLE. It isn't.

Can we please have this? As it stand right now certain things we cannot cleanly do without such a call and resorting to hacks which result in a menagerie of sideeffects.

it can be weaponname or weapondefid I don't care.

No, you can't have it in this proposed form because firing a weapon requires an instance and weapon instances are owned by units.

EmitWeapon(unitID, weaponID, ...) would be possible, but not much more useful than what you imagined knorke's response to be.

can we at least get it for unit scripts? Those are part of a unit but in order to emit a weapon it has to be part of a unit def.

How were meteors spawned in OTA? Meteor is a weapon and not a unit, so I assume the functionality to emit weapns without having a unit already exists somewhere in the code, but maybe it has fallen into oblivion?

The weapon can be found in weapons.tdf, line 5420.

smoth wrote:can we at least get it for unit scripts? Those are part of a unit but in order to emit a weapon it has to be part of a unit def.

Unavoidable, a unit can not have a weapon (let alone fire it) that is not listed in its unitdef. I suppose EmitSfx doesn't meet your needs either then...

Kloot wrote:

smoth wrote:can we at least get it for unit scripts?

Does EmitSfx not meet your needs?

It doesn't. Say I have a unit ability(firing a missile salvo from a pod). This means I have to go in the script and put 2048+num in the script. This is bad because it makes generalized scripts a problem.

Kloot wrote:

smoth wrote:Those are part of a unit but in order to emit a weapon it has to be part of a unit def.

Unavoidable, a unit can not have a weapon (let alone fire it) that is not listed in its unitdef.

So this is some engine limitation?

Jools wrote:How were meteors spawned in OTA? Meteor is a weapon and not a unit, so I assume the functionality to emit weapns without having a unit already exists somewhere in the code, but maybe it has fallen into oblivion?

I can't say how OTA did it (probably by spawning hidden units equipped with that weapon). I can say there is no OTA code in Spring to have "fallen into oblivion".

smoth wrote:Say I have a unit ability(firing a missile salvo from a pod). This means I have to go in the script and put 2048+num in the script. This is bad because it makes generalized scripts a problem.

I either don't understand what you have in mind fully or why you think it is a problem. The '2048' is a named constant in Lua (COB.FIRE_WEAPON), and you can easily create a table that holds which weapons are "special abilities" for each unit type. Hardcoding 2048+num anywhere is not necessary.

smoth wrote:So this is some engine limitation?

It is simply a use-case that has never been thought of or designed for.

Spring.UnitEmitWeapon(unitID, weaponNum, [targetID | {x, y, z} [, aimAnim]]) would still be useful imo.

FLOZi wrote:Spring.UnitEmitWeapon(unitID, weaponNum, [targetID | {x, y, z} [, aimAnim]]) would still be useful imo.

Could we do Spring.UnitEmitWeapon(unitDefID, weaponNum, { originX, originY, originZ } ,[targetID | {x, y, z} [, aimAnim]]) instead reasonably easy?

UnitId would be what is needed because it it is for a specific unit

Kloot wrote:

smoth wrote:Say I have a unit ability(firing a missile salvo from a pod). This means I have to go in the script and put 2048+num in the script. This is bad because it makes generalized scripts a problem.

I either don't understand what you have in mind fully or why you think it is a problem. The '2048' is a named constant in Lua (COB.FIRE_WEAPON), and you can easily create a table that holds which weapons are "special abilities" for each unit type. Hardcoding 2048+num anywhere is not necessary.

because having the weapondef in the unit def seems silly when it is part of an ability. the original request was not so limited in utility.

that's nice, detail what you did and how you did it rather than posting a tantalizing image. Otherwise the solution you are proposing might as well not exist.

Kloot wrote:No, you can't have it in this proposed form because firing a weapon requires an instance and weapon instances are owned by units.

Why DO weapons require an instance anyway?

Seriously Car, mind explaining how you pulled that off. I know you've been working on chain lightning for over a year now, but does it use some kind of invisible placehoder unit or something else?

Spawn fake units. It's ugly.

Jools wrote:How were meteors spawned in OTA? Meteor is a weapon and not a unit, so I assume the functionality to emit weapns without having a unit already exists somewhere in the code, but maybe it has fallen into oblivion?

The weapon can be found in weapons.tdf, line 5420.

Dude... Spring was not made from the OTA source. Spring was coded from scratch. Assuming that something that existed in OTA would exist in spring simply because of the abundance of ripped off OTA content in spring, would be folly.

smoth wrote: Why DO weapons require an instance [to fire] anyway?

You are a programmer familiar with OOP concepts so that really should be obvious...

Every weapon is an object with its own internal state (which unit owns it, what is it aiming at, etc) and associated logic (aim / fire / etc) to change that state. You cannot apply said logic when there is no object aka instance present. It's like asking "why do units require an instance to move?"

Rephrasing the original feature request as "emitProjectile" probably would get somewhat closer, but of course wouldn't emit bursts or timed beams.

I'm pretty convinced i had made a continuous-fire laser back in 2009 which was lol because used some emit thing to just keep shooting as it aimed, hilariously scything foe and friend alike (intentional).

Can i hijack this thread with a request for a call to change a projectile target? Like Spring.SetProjectileTarget(pID, unitID|{x,y,z})? Dauntless guidance for AA missiles for the win, yes?

So it has to do with the way the weapon class is defined as part of an inheritance chain? can that NOT be refactored to allow for an alternate class like a unit to be spawned with less methods and features?