Multiple Parts Units
Moderator: Moderators
Multiple Parts Units
ok i like to design tanks kbots and stuff where parts can be destroyed.
lets take a traked tank for example:
i like to split it in front, aft, right and left side and the 5th part should be the turret, when a part gets destroyed the tanks loses capabilties, eg. the right side is destroyed, this was housing the right track the tank isnt anymore capable of moving but it can still turn using it left trak
if the turret is destroyed it should get replaced by a damaged modelpart and it losing any stuff mounted on that turret eg. its maincannon.
if its losing its aft section it cant move anymore cause its engine was located there, if front is lost it losing its mgun and cant anymore fight effectivly against small targets
developers: do i need c++ programming-skills to archive that with spring or is it alread in springs engine but not used/i have never seen it?
lets take a traked tank for example:
i like to split it in front, aft, right and left side and the 5th part should be the turret, when a part gets destroyed the tanks loses capabilties, eg. the right side is destroyed, this was housing the right track the tank isnt anymore capable of moving but it can still turn using it left trak
if the turret is destroyed it should get replaced by a damaged modelpart and it losing any stuff mounted on that turret eg. its maincannon.
if its losing its aft section it cant move anymore cause its engine was located there, if front is lost it losing its mgun and cant anymore fight effectivly against small targets
developers: do i need c++ programming-skills to archive that with spring or is it alread in springs engine but not used/i have never seen it?
- Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
Re: Multiple Parts Units
I... believe Flozi managed something, though how is beyond me and there were a few hitsphere issues (ie hits to the turret registering as hits to the body due to it's larger hitsphere etc). You'd have to ask him about it.
You can also 'fake' this with unit scripting (ie using the HitByWeapon script, doing some calculations and then disabling weapons / reducing unit speed, show/hiding pieces etc as necessary), which might get you better / cheaper results.
You can also 'fake' this with unit scripting (ie using the HitByWeapon script, doing some calculations and then disabling weapons / reducing unit speed, show/hiding pieces etc as necessary), which might get you better / cheaper results.
Re: Multiple Parts Units
do it need to be hitspheres or can it be composed of boxes or better a set of boxes for each part?
Re: Multiple Parts Units
It was done with lua and the specifics only flozi knows.
Re: Multiple Parts Units
unit with different states can be done by swapping units in place... lua can handle animating state changes and pieces falling off/breaking.
like in e&e we did a submersible battleship with different weapons above/below water... it worked very well/seamlessly.
it could submerge/fire/surface/fire in a queue without stuttering/pausing.
like in e&e we did a submersible battleship with different weapons above/below water... it worked very well/seamlessly.
it could submerge/fire/surface/fire in a queue without stuttering/pausing.
Re: Multiple Parts Units
this huge ship in THIS works the same ?
Re: Multiple Parts Units
There are several ways of doing true composite units, all with their own issues.
Often it is better off faking it - unless you really want each section to be individually target-able.
FWIW, my example was never complete; movement and weapon firing seemed to be impaired by the composite parts. It was a true composite of 3 units, 1 base unit which contained the model, and 2 empty units which were effectively just hit volumes, which were held in place using MoveCtrl every frame (I was working on getting the 'turret' hit volume to rotate with the model turret when I gave up. This is now substantially easier thanks to Spring.UnitScript.GetPieceRotation). This was all actually done in a gadget - though later on I'd no doubt have had to use some unusual LUS and 3 way communication between the composite units to control disabling the movement or turret etc..
There was a widget which would detect which of the 3 was being moused over and highlight the corresponding piece of the model (a fairly trivial modification of the highlightUnit widget) in order to give a visual aid to targetting - this is basically all that my first video showed.
The main alternatives are to either use a transport (most likely with isFirePlatform) which is how the Imperator works in THIS, but to even call AttachUnit in the script means that the unit has to have transport tags, and that rather precludes a unit with the composite system actually being a transport (making it useless for S44's halftracks); Or to go down the route of kdr_11k's MicroMachines mod (at least I think it was that one) where multiple single units can be combined into one in specific combinations only which are actually represented by another unit with the desired characteristics, which is only of use if you want to combine units as a gameplay element and not as a technical means-to-an-end.
As an aside; You can give a single unit multiple (per-piece) hit volumes with usePieceCollisionVolumes unitdef tag and modify them with the Spring.SetUnitPieceCollisionVolumeData lua function. You can also use the Spring.GetUnitLastAttackedPiece lua function to get which piece was last hit by a projectile (at least I think that is what it does). This would make many things easier but; You cannot, however, so far as I know, target individual pieces/hitvolumes, so you would still need multiple units for multiple targetable pieces. This is pretty much what I meant when I said:
http://spring1944.svn.sourceforge.net/v ... tTest.sdd/
Please note it doesn't work at all with current Spring.
Often it is better off faking it - unless you really want each section to be individually target-able.
FWIW, my example was never complete; movement and weapon firing seemed to be impaired by the composite parts. It was a true composite of 3 units, 1 base unit which contained the model, and 2 empty units which were effectively just hit volumes, which were held in place using MoveCtrl every frame (I was working on getting the 'turret' hit volume to rotate with the model turret when I gave up. This is now substantially easier thanks to Spring.UnitScript.GetPieceRotation). This was all actually done in a gadget - though later on I'd no doubt have had to use some unusual LUS and 3 way communication between the composite units to control disabling the movement or turret etc..
There was a widget which would detect which of the 3 was being moused over and highlight the corresponding piece of the model (a fairly trivial modification of the highlightUnit widget) in order to give a visual aid to targetting - this is basically all that my first video showed.
The main alternatives are to either use a transport (most likely with isFirePlatform) which is how the Imperator works in THIS, but to even call AttachUnit in the script means that the unit has to have transport tags, and that rather precludes a unit with the composite system actually being a transport (making it useless for S44's halftracks); Or to go down the route of kdr_11k's MicroMachines mod (at least I think it was that one) where multiple single units can be combined into one in specific combinations only which are actually represented by another unit with the desired characteristics, which is only of use if you want to combine units as a gameplay element and not as a technical means-to-an-end.
As an aside; You can give a single unit multiple (per-piece) hit volumes with usePieceCollisionVolumes unitdef tag and modify them with the Spring.SetUnitPieceCollisionVolumeData lua function. You can also use the Spring.GetUnitLastAttackedPiece lua function to get which piece was last hit by a projectile (at least I think that is what it does). This would make many things easier but; You cannot, however, so far as I know, target individual pieces/hitvolumes, so you would still need multiple units for multiple targetable pieces. This is pretty much what I meant when I said:
Still, if anyone really wants to see what I did, it is all here:Often it is better off faking it - unless you really want each section to be individually target-able.
http://spring1944.svn.sourceforge.net/v ... tTest.sdd/
Please note it doesn't work at all with current Spring.
- CarRepairer
- Cursed Zero-K Developer
- Posts: 3359
- Joined: 07 Nov 2007, 21:48
- Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
Re: Multiple Parts Units
FLOZi wrote:There was a widget which would detect which of the 3 was being moused over and highlight the corresponding piece of the model (a fairly trivial modification of the highlightUnit widget) in order to give a visual aid to targetting - this is basically all that my first video showed.
Couldn't you combine these two? ie use the two 'hitvolume' units as targets for units to aim for and general targetting stuff, whilst using the GetLastAttackedPiece etc in the carrying unit to handle damage (ie the hitvolume units are never take hits or really do anything, they just follow the host unit and serve as points for units to aim at, whilst all hits are registered and dealt with by the host)FLOZi wrote:As an aside; You can give a single unit multiple (per-piece) hit volumes with usePieceCollisionVolumes unitdef tag and modify them with the Spring.SetUnitPieceCollisionVolumeData lua function. You can also use the Spring.GetUnitLastAttackedPiece lua function to get which piece was last hit by a projectile (at least I think that is what it does). This would make many things easier but; You cannot, however, so far as I know, target individual pieces/hitvolumes, so you would still need multiple units for multiple targetable pieces.
This is assuming you can stop the hitvolume units actually taking damage or interacting with projectiles in any way. Is there a tag for that or not? I can't remember...
Re: Multiple Parts Units
I don't think using transport tags to attach weapon units really precludes using the "unit" as a transport. The way I see it you have two options:
1.) Give the chassis lots of attach points and make your COB/Lua transport function a little smarter so units go in the right points and have their weapons enabled/disabled as appropriate. There's a sample custom transport script here: http://answers.springlobby.info/questio ... ort-attach
2.) Attach a transport to another transport (untested).
1.) Give the chassis lots of attach points and make your COB/Lua transport function a little smarter so units go in the right points and have their weapons enabled/disabled as appropriate. There's a sample custom transport script here: http://answers.springlobby.info/questio ... ort-attach
2.) Attach a transport to another transport (untested).
Re: Multiple Parts Units
I've done it in TA, just with bos/cob. It was on a battleship with lots of turret, where turrets would explode as the health went low. I used HitByWeapon callin to know where the unit is fired at, the explode/hide/show bos command, and some delaying code in the aiming function to wait without firing on the exploded turrets. However, HitByWeapon only gives the direction to the last point the unit was hit (not even the direction the shot came from), which makes it too imprecise to really know which piece was hit. And you couldn't specifically target a part. I have that unit in Springified form somewhere... And also my camembert unit which was a simpler demonstrator of how to use HitByWeapon.
Re: Multiple Parts Units
You could just "blow up" (hide) random parts and ignore where the unit was actually hit because I doubt ingame you would notice. Unless the unit is very big.
Like for a tank:
if health < 80 hide antenna
if health < 50 hide turret
if health < 10 hide drivetrain
Then in the blaqueryweapon thing function:
return false if the turret is hidden so the unit can not shot without turret.
I guess with similiar stuff you could disable the radar (antenna) and set the units speed (damaged drivetrain)
Like for a tank:
if health < 80 hide antenna
if health < 50 hide turret
if health < 10 hide drivetrain
Then in the blaqueryweapon thing function:
return false if the turret is hidden so the unit can not shot without turret.
I guess with similiar stuff you could disable the radar (antenna) and set the units speed (damaged drivetrain)
Re: Multiple Parts Units
There's some setting I forget the name of that makes them non blocking, but iirc when I tested that also prevents mouse rays detecting them -> you can't target them anyway.Guessmyname wrote:Couldn't you combine these two? ie use the two 'hitvolume' units as targets for units to aim for and general targetting stuff, whilst using the GetLastAttackedPiece etc in the carrying unit to handle damage (ie the hitvolume units are never take hits or really do anything, they just follow the host unit and serve as points for units to aim at, whilst all hits are registered and dealt with by the host)
This is assuming you can stop the hitvolume units actually taking damage or interacting with projectiles in any way. Is there a tag for that or not? I can't remember...
Spliff; I'm not saying that approach is entirely impossible but I hate transports in Spring anyway. Plus you are ignoring the whole issue of how the collection of transport tags actually work, so please don't patronise me by linking to my own example LUS transport script.
I did actually do some work on a composite unit using transports, which exists here:
http://rebelsummer.svn.sourceforge.net/ ... nk/ST.sdd/
Re: Multiple Parts Units
I'm curious, why does the child unit need to be non-blocking? I assume it causes weird bugs, but what's the actual problem behavior? As buggy as transports are, they seem functional once the child is attached. Or are the children always non-blocking on the transports?
Re: Multiple Parts Units
Guessmyname was suggesting to use non-blocking children so that the per-piece hit volumes on the 'parent' unit would intercept weapons, not the children.
There was an issue with air transports that made targeting transported children very unreliable, though I think that problem was either much alleviated or non-existent with ground transports.
There was an issue with air transports that made targeting transported children very unreliable, though I think that problem was either much alleviated or non-existent with ground transports.
Re: Multiple Parts Units
Obviously I'm not as knowledgeable about the system as you guys but...
Would there be a way, Synced Lua side, to allow the user to choose the target (like an GUI overlay that is put over a unit when an attack command is being issued) and then pass an attack command with the corresponding dummy unit as target (even though this dummy unit would otherwise be missed in a TraceScreenRay )?
Would there be a way, Synced Lua side, to allow the user to choose the target (like an GUI overlay that is put over a unit when an attack command is being issued) and then pass an attack command with the corresponding dummy unit as target (even though this dummy unit would otherwise be missed in a TraceScreenRay )?
Re: Multiple Parts Units
I don't see why you wouldn't just use the child hit volume and pass the damage on through Lua. You just got non-primitive collision volumes for free.
I thought the problems would be weirder, like obstacle avoidance and pushing algorithms throwing a hissy-fit at the compound object.
edit: nm, re-read your first post. Aiming problems and you have to pretend they're transports/transportees, or you have the child-objects being entirely moved through movectrl. Ouch, terrible.
I thought the problems would be weirder, like obstacle avoidance and pushing algorithms throwing a hissy-fit at the compound object.
edit: nm, re-read your first post. Aiming problems and you have to pretend they're transports/transportees, or you have the child-objects being entirely moved through movectrl. Ouch, terrible.
- Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
Re: Multiple Parts Units
To be fair, having to zoom in on an individual target to aim for the treads / turret / whatever would be a bit of a bitch in large-scale engagements anyway; better implemented as a 'aim for turret / body' option in the attacking unit (kinda like hold fire and movestates etc) I'd've thought. Or at least, that's how Mech Commander did it...FLOZi wrote:Guessmyname was suggesting to use non-blocking children so that the per-piece hit volumes on the 'parent' unit would intercept weapons, not the children.
There was an issue with air transports that made targeting transported children very unreliable, though I think that problem was either much alleviated or non-existent with ground transports.
Re: Multiple Parts Units
SinbadEV wrote:Obviously I'm not as knowledgeable about the system as you guys but...
Would there be a way, Synced Lua side, to allow the user to choose the target (like an GUI overlay that is put over a unit when an attack command is being issued) and then pass an attack command with the corresponding dummy unit as target (even though this dummy unit would otherwise be missed in a TraceScreenRay )?
This is a possibility. I was personally trying to replicate Men of War type behaviour.To be fair, having to zoom in on an individual target to aim for the treads / turret / whatever would be a bit of a bitch in large-scale engagements anyway; better implemented as a 'aim for turret / body' option in the attacking unit (kinda like hold fire and movestates etc) I'd've thought. Or at least, that's how Mech Commander did it...
Re: Multiple Parts Units
With that you would not even have to check where the projectiles impacted.To be fair, having to zoom in on an individual target to aim for the treads / turret / whatever would be a bit of a bitch in large-scale engagements anyway; better implemented as a 'aim for turret / body' option in the attacking unit (kinda like hold fire and movestates etc) I'd've thought. Or at least, that's how Mech Commander did it...
You could just do
If AttackingUnit was aiming for Head then ExplodeHead
If AttackingUnit was aiming for Arm then ExplodeArm