Multiple Parts Units

Multiple Parts Units

Discuss game development here, from a distinct game project to an accessible third-party mutator, down to the interaction and design of individual units if you like.

Moderator: Moderators

Moe479
Posts: 4
Joined: 24 Feb 2010, 16:26

Multiple Parts Units

Post by Moe479 »

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?
User avatar
Guessmyname
Posts: 3301
Joined: 28 Apr 2005, 21:07

Re: Multiple Parts Units

Post by Guessmyname »

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.
Moe479
Posts: 4
Joined: 24 Feb 2010, 16:26

Re: Multiple Parts Units

Post by Moe479 »

do it need to be hitspheres or can it be composed of boxes or better a set of boxes for each part?
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Multiple Parts Units

Post by smoth »

It was done with lua and the specifics only flozi knows.
User avatar
aegis
Posts: 2456
Joined: 11 Jul 2007, 17:47

Re: Multiple Parts Units

Post by aegis »

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.
User avatar
Wombat
Posts: 3379
Joined: 15 Dec 2008, 15:53

Re: Multiple Parts Units

Post by Wombat »

this huge ship in THIS works the same ?
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Multiple Parts Units

Post by FLOZi »

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:
Often it is better off faking it - unless you really want each section to be individually target-able.
Still, if anyone really wants to see what I did, it is all here:
http://spring1944.svn.sourceforge.net/v ... tTest.sdd/

Please note it doesn't work at all with current Spring. :wink:
User avatar
CarRepairer
Cursed Zero-K Developer
Posts: 3359
Joined: 07 Nov 2007, 21:48

Re: Multiple Parts Units

Post by CarRepairer »

User avatar
Guessmyname
Posts: 3301
Joined: 28 Apr 2005, 21:07

Re: Multiple Parts Units

Post by Guessmyname »

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.
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.
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...
User avatar
SpliFF
Posts: 1224
Joined: 28 Jul 2008, 06:51

Re: Multiple Parts Units

Post by SpliFF »

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).
User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7049
Joined: 16 Nov 2004, 13:08

Re: Multiple Parts Units

Post by zwzsg »

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.
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Multiple Parts Units

Post by knorke »

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)
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Multiple Parts Units

Post by FLOZi »

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...
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.

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. :wink:

I did actually do some work on a composite unit using transports, which exists here:

http://rebelsummer.svn.sourceforge.net/ ... nk/ST.sdd/
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: Multiple Parts Units

Post by Pxtl »

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?
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Multiple Parts Units

Post by FLOZi »

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.
User avatar
SinbadEV
Posts: 6475
Joined: 02 May 2005, 03:56

Re: Multiple Parts Units

Post by SinbadEV »

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 )?
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: Multiple Parts Units

Post by Pxtl »

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.
User avatar
Guessmyname
Posts: 3301
Joined: 28 Apr 2005, 21:07

Re: Multiple Parts Units

Post by Guessmyname »

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.
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...
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Multiple Parts Units

Post by FLOZi »

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 )?
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...
This is a possibility. :-) I was personally trying to replicate Men of War type behaviour.
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Multiple Parts Units

Post by knorke »

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...
With that you would not even have to check where the projectiles impacted.
You could just do
If AttackingUnit was aiming for Head then ExplodeHead
If AttackingUnit was aiming for Arm then ExplodeArm
Post Reply

Return to “Game Development”