Realtime Dynamic Weapon Change!

[KDR_11k]

I was thinking about all that talk about modular units and stuff but while the graphical part and all has been figured out, what about the weapons themselves? AFAIK there's no way to add or replace weapons on a unit (except by doing so when the unitdef is created) so all weapons a unit needs have to be part of the unit already. Would be much more useful if we could replace the weapons on a unit, preferrably at any time but if necessary only when the unit is created.

[Masure]

Should this help ?
viewtopic.php?f=23&t=12262

No code provided but, you could pm Zpock

[Zpock]

I gave up on using normal spring weapons and coded my own in LUA. The project is nowhere near finished yet. I really wish you could mess with weapons directly in LUA tough, and I guess trepan might someday get us that.

[Argh]

Why not do this via slaved weapons, and control their states via LUA? Use a "real" weapon to handle aiming conditions, fire the slave. Heck, since we can fire any number of weapons from COB (typical unit in PURE right now has 6), for most weapons you could get away with just emit-sfx, frankly.

[Zpock]

Havn't tried that, but I think you would run into problems with aiming? Esp for missiles?

I think the best way is have to set it up with fireplatform and little slave onboard units.

[smoth]

lol.... egg with spikes and a crab.

[KDR_11k]

I could do a whole lot with multiple weapons but the thing is that that fails on several accounts. For one the units behave differently depending on which weapons they have and don't care if they are enabled and having every possible weapon on every unit that might need it is a maintenance nightmare and might get you in trouble with the weapon limit (e.g. if a unit has 5 hardpoints with 6 possible weapons each...).

[Zpock]

Yes, exactly, and there's no callbacks or anything from the weapons in LUA so you can't really do anything with weapons either. Plus the unit's behaviour is really stupid as KDR say, not at all intended for this kind of thing. Hence why I skipped using engine weapons altogether for doing this.

[AF]

Implementing the components using attached units rather than OGL drawn objects would solve this along with the cob animation problem. It would also make the whole system far more flexible.

[lurker]

Not really. It's a hack that adds its own host of problems.

[Pressure Line]

Implementing the components using attached units rather than OGL drawn objects would solve this along with the cob animation problem. It would also make the whole system far more flexible.

the OGL pieces can very easily be attached to a piece of a unit, (be that an empty piece or not) COB animation of the drawn pieces is a non-issue. changing them in a dynamic manner... thats a different story, best left to someone who knows what they are doing or until i know what im doing.

[Argh]

The big issue is that there is no way to communicate with weapons. If they could be sent a message, changing the UnitID that they should attempt to aim at, then it'd be one thing, but they can't do that- we can pass that information to the COB, but it doesn't really change the weapon's behavior, once it has determined that a target is within the TryTarget cone, or if it's always squelched from completing the circuit via COB or FBI values. This is the major issue with missiles and cannons, which need a valid target to do their math correctly. With direct-fire stuff, it's not much of a problem.

[yuritch]

The big issue is that there is no way to communicate with weapons. If they could be sent a message, changing the UnitID that they should attempt to aim at, then it'd be one thing, but they can't do that...

Wrong, there is a way. Taken straight from CobInstance.cpp:

Code: Select all

#define SET_WEAPON_UNIT_TARGET   106 // get (fake set)
#define SET_WEAPON_GROUND_TARGET 107 // get (fake set)

Those new COB get constants can retarget a weapon to a given unitID or a given pair of XZ coords on the ground. I'm not sure when they were added (i.e. are they in 0.76b1 or not), but they surely are in current svn.

[Pxtl]

I'm curious, on a related subject - if you have a unit that does change weapons, will it intelligently realize the firing ranges of it's active weapons? If it has a long-ranged artillery and a short-ranged shotgun, and you use some Lua hacking to disable the arty and arm the shotgun, will it realize it's now firing range (and similar weapon limitations?) Or will it still try to "attack" with its primary weapon, firing the secondary (and now armed) weapon only incidentally at the target when it is capable of doing so?

[KDR_11k]

Nope, it'll always use the range of weapon1. That's the reason the deployed bug in KPDZ is a separate unit from the regular bug. There's currently no way to mark a weapon as disabled.

[Pxtl]

Nope, it'll always use the range of weapon1. That's the reason the deployed bug in KPDZ is a separate unit from the regular bug. There's currently no way to mark a weapon as disabled.

Suck. That just killed dozens of neato ideas I had. And transformation is a lousy workaround, for reasons I'm sure you know all too well.

[KDR_11k]

You sure you can't use morph?

[Zpock]

Some guy was messing around with the weapon range approach and I said it was a must to set it by LUA but noone listen...

[Pxtl]

You sure you can't use morph?

When you morph a unit it loses its queue and standing orders, doesn't it? At the very least, it has to stop. Not exactly something you can do while a unit is on the move - I was hoping for something more like "on/off to enable the long-ranged energy-intensive ICBMs instead of the pew-pew lasers".

[Archangel of Death]

You can save the original unit's queue, its standing orders (at least I think thats accessible somewhere...), its position, and its velocity, then assign these to the new unit. Just leaves the issue of animation position... which is a lot harder to solve... but for some uses (low animation units like tanks, or if the unit would only switch while in a certain position like kneeling next to a weapon on the ground) it shouldn't be too hard. Freeze anims cob side, get piece headings and save them, chuck them into a specialized function in cobs of the units that switch amongst each other to set initial positions.

No guarantees any of this would be very fast though...