Posted: Sun Jul 24, 2016 8:22 pm Post subject:
Max number of turrets on a single unit?
I saw OpenRA allows multiple turrets on the same unit (RA cruiser has 2) using names for those turrets like @PRIMARY and @SECONDARY.
Is it possible to add more turrets and how many turrets are max possible on a single unit?
Is there a reference guide with all the possible keys available?
Also can rotation restrictions be applied to certain turrets?
e.g. some turrets are only allowed to rotate from -135° to 135°, some from 135° to -135°, others from 180 to 315° etc
Currently i'm creating a unit with 39 turrets and wonder if all these can be added as independent turrets ingame.
It would be my first test to add something to OpenRA and check the possibilities of the engine. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sun Jul 24, 2016 8:43 pm Post subject:
There are no actual limit of the amount of turrets. The @ID is just an id, as long as it's unique, you're fine. The reference guide is https://github.com/OpenRA/OpenRA/wiki/Traits - if it makes sense for a trait to have multiple instances (palette definitions, queues, whatnot), then the @ID suffix lets you define more. For inheriting purposes though, keep in mind that null is also a valid @ID, so you can't override WithSpriteBody@PRIMARY with WithSpriteBody or vice versa.
Limiting turret angle rotation however atm isn't possible (mostly because the attack-turret interactions code atm cannot handle such). Also right now you can only have one AttackTurreted trait - shoulda try to fix up my PR to get more working. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... Last edited by Graion Dilach on Sun Jul 24, 2016 8:53 pm; edited 1 time in total QUICK_EDIT
That sounds very promising. Thanks for the info.
If i understand it correct, i can define only one turret and let duplicate turrets inherit from the first if they all share the same graphic and weapon. That should come in very handy and time saving.
"One AttackTurreted trait", means all turrets will target the same target and don't fire independently on their own different targets right?
Hmm that could be visually a bit strange if the slow big AG turrets also aim at air units along with the fast AA turrets.
I guess i'll find that out anyway, but how does the engine handle render layer on multiple turrets? e.g. is it possible to have a higher and lower turret with the higher turret covering the lower turret? Or turrets on the side of the unit being covered by the unit body itself at certain facings. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sun Jul 24, 2016 9:04 pm Post subject:
You can only inherit between (pseudo)actors and not between traits, so I don't think you can inherit in your case, but you'll need to c'n'p 39 turret definitions.
Attack* traits controls which Armaments are active at the moment, and upgrading an AttackTurreted is impossible atm - a good example case I'd think of is to have a turreted Tick Tank. (AttackFrontal is upgradable on the fly though already.)
Independent targeting AFAIK is impossible because even with multiple active Attack* traits, the actor can only have a single active attack activity, although I haven't tested if an actor with an active AttackTurreted and AttackFrontal at the same time can have separate targets (AttackTurreted buffers it's own target so that's the sole likely possibility atm).
Knowing you, there is a ZOffset tag on sequences, to order SHPs. Voxels are rendered as 3D objects, so they can blend into each other without hardcoded turret-on-top-of-body restrictions. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
Ok, a first simple test, giving the cruiser 3 turrets with different weapons was successful.
At first it wasn't shooting with the new 3rd turret and a bit tricky to find out that i had to add a complete new line
Armaments: primary,secondary,tertiary
under
AttackTurreted:
which previously had no Armaments key.
Now i'm trying to give it 2 different turrets, turr.shp and ssam.shp.
However the game crashes with a missing sequence error.
under sequences\ships.yaml i changed the cruiser to
I assume 2 turret: keys (are they still called "keys" like in inis?) are not allowed in one sequence. Something like the second key overwriting the first.
then in rules\ships.yaml i added to my tertiary turret the sequence key
WithSpriteTurret@TERTIARY:
Turret: tertiary
Sequence: ssam
that however seems wrong as the game crashes with
Exception of type `System.InvalidOperationException`: Unit `ca` does not have a sequence named `ssam`
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Mon Jul 25, 2016 1:33 pm Post subject:
Lin Kuei Ominae wrote:
At first it wasn't shooting with the new 3rd turret and a bit tricky to find out that i had to add a complete new line
Armaments: primary,secondary,tertiary
under
AttackTurreted:
which previously had no Armaments key.
Yes, because you specified Armament-Name along, which defaults to primary IIRC. Multiple armaments can share names though, but yours is also a solution. Probably in your case, yours is nicer, but turrets with multiple armaments (like the Mammoth Tank turret) might benefit from both armaments sharing the name.
Lin Kuei Ominae wrote:
I assume 2 turret: keys (are they still called "keys" like in inis?) are not allowed in one sequence. Something like the second key overwriting the first.
Yeah, let's call them keys and yes, you're right. It should actually crash on that with a "duplicate entry found" even.
Lin Kuei Ominae wrote:
then in rules\ships.yaml i added to my tertiary turret the sequence key
WithSpriteTurret@TERTIARY:
Turret: tertiary
Sequence: ssam
that however seems wrong as the game crashes with
Exception of type `System.InvalidOperationException`: Unit `ca` does not have a sequence named `ssam`
No, both you and the game are absolutely right here. Indeed, that Sequence key is the solution to your problem, and indeed that sequence key is what you forgot to add.
Code:
ca: # Image level, every time a trait mentions Image, think these. Some have it hardcoded like IIRC all explosions look for the explosions image.
idle: # Sequence level, every time a trait refers a sequence, it means this.
Facings: 16
turret: turr
Facings: 32
ssam: ssam #Specifying a sequence means specifying the key's name. The right will be the filename and yes, these can differ.
Facings: 32
muzzle: gunfire2
Length: 5
icon: caicon
_________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... Last edited by Graion Dilach on Mon Jul 25, 2016 1:40 pm; edited 1 time in total QUICK_EDIT
ah, Sequence defaults to "turret" and in this case it's like defining a new key. left the name, right the file.
Ok that makes sense.
Since i share the turret sequence with the destroyers, would it be possible to create a global set of turrets and then use these on different units?
Or for my test use the destroyers turret directly by specifying the origin something like this
Sequence: dd\turret
? _________________ SHP Artist of Twisted Insurrection: Nod buildings
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Mon Jul 25, 2016 2:16 pm Post subject:
You cannot crossreference sequences from another image, unless your trait has an Image override to allow that (WithSpriteTurret lacks this, it takes it's image from RenderSprites).
You can inherit sequences by now (it's a relatively new feature, previously inheritance only worked in rules, but now in all yamls) but you cannot have relative filenames in sequences afaik.
So I guess it would look like the following, but notsure how helpful that is.
A good use-case where this is useful is in an open PR of mine: https://github.com/GraionDilach/OpenRA/blob/896e840558c55595bc77dcb277265da8be3c0433/mods/ts/sequences/vehicles.yaml _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
a) can i add SHP (TS) files among the SHP (TD) files in conquer.mix of RA1?
Debug.log says
File not found: iowa16iA.shp
File not found: iowa16iB.shp
File not found: iowa5inH.shp
File not found: iowa5inL.shp
File not found: iowaMG.shp
Do i have to change the SHP file format? I tried already to save it under SHP (TD) in SHP Builder, but it only corrupted the file
b) When testing ingame, the game crashes with a sequence not found error
Unit `iowa` does not have a sequence named `tur16inA`
however the sequence is defined from what i can see
Maybe a result of the "file not found" problem, why it also can't create the necessary sequence?
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Fri Aug 05, 2016 9:54 am Post subject:
The OpenRA RA mod should already handle ShpTS files (see mod.yaml's SpriteFormats list). The sole case where it bugs out if said SHP(TS) files start with an empty frame, but in those cases, it crashes with an invalid SHP error.
You don't have to edit conquer.mix tho, just add the files to the bits folder loosely.
Wait a second... which tool are you using for editing conquer.mix? Since last year, OpenRA doesn't hash the filenames to look them up within mixes, but loads the list from the XCC lmd. This means without the lmd, you cannot use additional filenames within mixes and I'm aware of tools in the community which doesn't create lmds. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
i use XCC Mixer. The SHPs have no empty frames.
Oh there is a bits folder with un-mixed files
Can i move the whole support folder stuff somewhere into the mods\ra\ subfolder?
Seems a bit messy if the game takes from such completely different folders the used content.
The bits folder did it. No crash and unit visible ingame. Thanks again for your help. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Fri Aug 05, 2016 11:07 am Post subject:
If you look at the mod.yaml's Packages: list, you'll see a hierarchy list with the order to load the assets from (not yamls!) (bottom overriding top).
By default, the mix contents are loaded earlier than the loose folders, and at that point, only the support and mods/ra folders are known - the $modfolder syntax means find the selected mod's main directory either in the support or the main folder, either as a loose folder or in a zip file with the oramod extension (the smth: smth refers to use that exact entry as the prefix in front of a path using | to prevent overriding, like side EVAs in TS) (also, mods/common isn't a mod, since that lacks mod.yaml which is why it uses an explicit path), so at that point, you can move all mixes to the mods/ra folder and it'll work. Keep in mind though that the support folder will still be used by autodownloaded maps/screenshots/replays/etc.
The messiness of the structure is already discussed in that other topic, everything in the support directory are planned with the mindset to be writable without admin rights and gatherable through the game from third-party sources (asset downloading, install from CD/external install). _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
ah, that makes sense. So when creating a completely new mod, you can at first keep everything nicely together and deliver updates later via the Support folder.
Another question:
What's the camera angle at which the Offset keys 3D Vector is calculated?
As you can see on the screenshot, the turrets look good when facing west/east, but get misaligned when facing north/south.
I guess i would have to render the unit again with the right angle used by the Offset keys, so it matches ingame again.
Is there some kind of sandbox mode, where i can quickly change keys and test the change ingame?
I tried the map editor, but i couldn't find an option to rotate the placed unit. Right click removed it, single or double left click didn't open a context menu or something like that, to set Facing, Hitpoints, Player, attached trigger etc.
Right now i have to start the game, open skirmish, select the side/start location (which OpenRA unfortunately doesn't remembers), start the map, build a shipyard, build the unit, check the facings, close OpenRA, edit the Offsets
and then start it all over again, which are quite many steps just for a quick check ingame.
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Fri Aug 05, 2016 12:26 pm Post subject:
I don't think runtime rule changes are supported. Maybe when you reload the mod (mod browser and back). Local menus are also missing from the map editor as well IIRC.
However I think I know your issue and it's a blameWestwood thingy due to https://github.com/OpenRA/OpenRA/issues/4823. If I'm right the solution should be this in rules.yaml (and without messing with the offsets themselves):
Code:
IOWA:
BodyOrientation:
UseClassicFacingFudge: false #inherited to be true from the defaults
_________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
nah i don't think this is the problem.
I think reaperrr's numbers are also completely wrong there.
let's say frame 0 has the unit at 0°
every frame rotates the unit by exactly 11.25° when using 32 facings.
So the 4th frame is exactly 45°. Thus the 4th frame has to be the one used for NW.
8th frame has 90° rotation, thus west facing
12th frame has 135°, thus SW facing
16th frame 180°, facing south
20th SE
24th E
28th NE
In my case however, the Forward offset value is matching on horizontal facing, but is longer when vertical.
Thus my rendered unit is using a different camera angle than the offset calculation and the question would be which angle the offset calculation uses. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Fri Aug 05, 2016 1:01 pm Post subject:
The body facings are your problem. Westwood didn't use proper facings in TD and RA1. The turret offsets on the image are properly positioned, but since the game uses the wrong SHP frame for the facing, the turret positions go wrong on the angles.
Oh, and I've tested this btw. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
I applied the key, but the turrets are on the same "wrong" places as before. It didn't change anything.
I rendered my unit with a different camera angle and just have to find the one OpenRA uses for its offset calculation.
See attachment, showing the red ellipse of my 50° (iirc) camera angle and the blue ellipse of the unknown OpenRA camera angle (could be 45°)
-blue ellipse is following a small turret placed directly on the bow with Offset: 8000,0,0
-red ellipse is following the bow
both ellipses should match if the camera angle is the same
Thanks.
I just noticed that i accidentally rendered with the 30° TS camera and not the 40° TD camera.
Will render the unit with the right camera again and then it should fit perfect.
Also nice to know that the CameraPitch can be adjusted.
Another question right away:
As you can see, does the unit have a quite high superstructure, which should even cover turrets behind it.
Is there a way to define the superstructure as a separate sequence with a higher ZOffset? Unlike rotating turrets, this sequence should be fixed and always have the same facing as the base unit.
I would then render the superstructure alone as a separate SHP, so it can be assigned to that sequence.
Could you provide a code example how such a sequence would be set in the yamls?
I think such a fixed additional sequence would be also great for effects like headlights or light effects in general. Provided that sequence can be set to use always the full brightness, regardless of a maps Ambient lighting value. Though then it would be also necessary to set this sequence as additive blending and transparent like Rewire has shown on the explosion anims. _________________ SHP Artist of Twisted Insurrection: Nod buildings
cool
can't i use this for the move anim as well? From what i can see it would be just another (but animated) sequence which is rendered under the unit.
This way i could render the waves in a separate anim, which is easier/faster to do in 3dsmax and which could be also used on other units.
Damn, with the little experience from implementing this unit alone, OpenRA's modding possibilities look glorious. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sat Aug 06, 2016 2:10 pm Post subject:
There isn't an UpgradeOnMove trait, so either you write one yourself, send it in then use an upgradable WithFacingSpriteBody, either you create a WithInfantryBody from the waves and use that (Which might be a better option for idle waves).
Lin Kuei Ominae wrote:
Provided that sequence can be set to use always the full brightness, regardless of a maps Ambient lighting value.
Unlighted palette slots logic doesn't exist in OpenRA. You need to create a copy of the palette with AllowModifiers: false defined on it and use that variant of said pal to create unlight colors. See the cameos for an example. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
I got now all graphics ingame and all the turrets done (position is now perfect, thanks to the same camera angle ).
However only 2 turrets shoot, despite having 4 assigned Armaments: 16inchA,16inchB,16inchC,5inchLA
Which name is actually applied to the Armaments key?
Is the name applied to Armaments the one defined after the @
-Armament@Arm5INCHRB:
the one on the Name key
-Armament@Arm5INCHRB:
Name: Starboard Side 5in cannon
or the one of the turret
-Armament@Arm5INCHRB:
Name: Starboard Side 5in cannon
Turret: 5inchRB
Could someone take a look on the code again?
Maybe you also have code improvement suggestions, like a way to write less with the same effect, since a lot is just copy pasted with 1 or 2 keys slightly changed.
Is it correct that i can use 3 offsets for a single turret, like
LocalOffset: 480,-100,40, 480,0,40, 480,100,40
so i have on a Burst=3 weapon 3 different projectile start locations?
I simply added a 3rd Offset, but am not sure if this is actually supported by the engine. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Mon Aug 08, 2016 4:46 pm Post subject:
Armament->Name is what gets checked at AttackTurreted->Armaments. You might end up better if you omit all of them and let them all default to primary.
The long code is a consequence of modularity, doubt there are much which can be done regarding it.
Multiple LocalOffsets are supported but they are only used at weapons with burst. (IOW, in order to use three barrels, have Burst: 3 or more on the weapon.) Since OpenRA lacks the press-stop-on-burst-to-trigger-infinite-burst bug, having a weapon where ROF = BurstDelay will be bugfree. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
ah, i see.
I thought Name is only some non-used, for organization purposes meant key, since the description on github is empty.
Ok then it's clear my code
Armament@ArmMGRI:
Name: Starboard Side MG Turret
is complete nonsense.
Well, then i think i go back to primary, secondary and tertiary. This worked already.
So i can also group the 16inch turrets to
Name: primary
the 5inch turrets to
Name: secondary
and all the MG turrets to
Name: tertiary _________________ SHP Artist of Twisted Insurrection: Nod buildings
I don't think so. At least not until OpenRA offers ways to give units a bigger foundation and cover multiple cells (at least i think it doesn't support it, though not sure, since it supports TD and TD actually had a 3x1 foundation big gunboat unit). _________________ SHP Artist of Twisted Insurrection: Nod buildings
As far as I recall, the Gunboat occupied only one cell at a time like any other unit. Its sprite animation went beyond that one-cell hitbox, though. Also, it could travel through any unit or structure without any collision. _________________
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Thu Aug 18, 2016 2:47 pm Post subject:
Multicell units are unsupported (pathfinding issues, mostly AFAIK, but take this with a grain of salt).
Hitboxes can go outside of the foundation though. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Thu Aug 18, 2016 3:59 pm Post subject:
In order to have limited turret angles, the following needs to be done:
- unlink AttackTurreted from all the turrets and only link it with the turrets it's weapons use (already in progress, just style fixes remain)
- add a method to the turreted attack activity to allow the AttackTurreted trait to tell the unit to turn and only then, limit the turret angles (it would probably make sense to do these two at the same time). _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
last point could be problematic for multi turreted units, where turret A tells the unit to turn this way and then turret B tells the unit to turn the other way
Might need some kind of
TurretIsPrimary: true
key, to avoid such conflicts and where only this turret can tell the unit to turn.
Though then also a key
TurretIsSecondary: true
in case you have a unit with 2 turrets, one on the left and one on the right, where none of the turrets is actually primary.
\Edit
another thing that could be very useful,
if you could assign one turret to another turret. Imagine a big turret on which smaller turrets are attached, where the smaller turrets follow the movement of the big turret, not the main unit. _________________ SHP Artist of Twisted Insurrection: Nod buildings
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum