Joined: 19 Aug 2009 Location: Moscow State University
Posted: Fri Nov 28, 2014 4:46 pm Post subject:
unit to unit attaching feature
Point of this feature is really easy to get : if one unit type cannot do, use another type for it. If one unit is not enough to carry the weapon/spawn/super weapon/etc, use a combination of them.
e.g.
Ammo for different weapons= primary unit + secondary unit (invisible)
Gattling infantry that cost power and can cast super weapon= infantry + gattling tower (invisible)
Mobile gap generator = tank + gap generator (invisible)
Battleship= ship + turret + turret + turret+...........
Carrier with many types of spawns= carrier A + carrier B (invisible) + carrier C (invisible)+.......
Mobile War factory= tank + factory(invisible), though you need to make the tank bigger
Mobile buildings = invisible tank+ visible building
In a word with this feature you can combine as many features as you like on one single unit, ignoring which type it is.
Other uses like:
Capsule: give the sub-unit 1 hp and a death weapon , place it on the center of parent unit,let the parent recreate one if sub unit is dead, so it can always release a death weapon when parent is hit.
Then we get:
Units that gets buff when hit (capsule releases buff)
Units that is immune to weapons whose damage is below certain amount(capsule releases healing)
Units that get extra damage from certain warhead types(capsule releases toxin)
Etc. It could be combined with every feature that is done already and that will come in the future.
sounds similar to my shield logic idea, attaching one unit onto another.
Though your approach is even more flexible and seeing it was already done, this sounds like a nice new feature.
I would especially like the multiple turret support. Having a cruiser with 3 triple barrel turrets and several smaller ones would be surely rocking.
Though then an additional key should be implemented, which links several attached units together, so they always aim/shoot at the same target. _________________ SHP Artist of Twisted Insurrection: Nod buildings
I am a big fan of OverlordContain, which works similarly to this in Generals and Zero Hour. While there could be tons of bookwork and potential bugs in this (temporal, emp, shields, attacheffect) I think it would open a new realm of modding possibilities. QUICK_EDIT
Joined: 19 Aug 2009 Location: Moscow State University
Posted: Tue Dec 02, 2014 6:17 am Post subject:
The keys should be defining:
on parent:
sub unit types: A,B,C,D
sub units' position:A,B,C,D
sub unit regen rate if destroyed:A,B,C,D
on sub unit
share experience?
share command? (for something like walking-shooting infantry)
(hard coded?) rules concerning special conditions(I suggest they use all the rules like normal units in most cases,like normal damage, iron curtain, etc, because the attaching system is only a bridge between different types)
And if possible, use attacheffect to attach to any target the unit you want.
Attach to all enemy buildings an invisible building that costs power=graphite bomb
Attach to overlord a speaker tower using super weapon.
Attach to parent vehicle drones
Fixed. It is not your shield logic since you didn't proposed it.Stop editing things around and claiming logics as your whereas you take no role in prompting the shield logic to be imply in RA2.
Anyway, I always wanted to have independent turrets like the cruiser seen in RA. It will have many uses. I have been playing around with trying to get independent turret, only that can be done using simply deploy to switch turret back and forth. _________________ Mod Leader and founder of World Domination
Fixed. It is not your shield logic since you didn't proposed it.Stop editing things around and claiming logics as your whereas you take no role in prompting the shield logic to be imply in RA2.
Anyway, I always wanted to have independent turrets like the cruiser seen in RA. It will have many uses. I have been playing around with trying to get independent turret, only that can be done using simply deploy to switch turret back and forth.
You're also not the first to suggest it, so you can't claim it as yours either. QUICK_EDIT
Fixed. It is not your shield logic since you didn't proposed it.Stop editing things around and claiming logics as your whereas you take no role in prompting the shield logic to be imply in RA2.
Click on the link and look who wrote the post. It was not you.
You suggested a shield logic, but with a completely different idea behind it.
You
many small keys
My idea
only 1 single key. A unit being attached/followed by another unit
And my link was pointing directly to my post. Not your initial post in the topic with the umpteen keys. (Start=11 is in the link, thus you don't see the discussion about your idea. So if someone is reading my post here, he doesn't has to scroll in your topic to find my post with my idea) _________________ SHP Artist of Twisted Insurrection: Nod buildings
Joined: 19 Aug 2009 Location: Moscow State University
Posted: Wed Dec 03, 2014 8:21 am Post subject:
please, gentlemen, get your shield discussion out of here as I assume you dont even get the point of this flexible feature. would you first get shield idea out of your mind before reading this? this has nothing to do with shields and not a workaround for it.
the first being actual multiple turrets ala battleships and the other one that comes into my mind is the mechapede logic from KW... _________________ ~ Excelsior ~ QUICK_EDIT
While this isn't a workaround for shields, you could simply put a larger unit that looks like a shield onto this unit that would get hit first (probably)
But multiple turrets and a train without IsTrain= would be pretty nice, Deathweapon and custom armor types solving any remnants too. Only thing I see wrong with this is your building-type examples like GapGenerator. As far as I know, buildings aren't able to be moved as it would instantly cause an IE or simply never work. _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
please, gentlemen, get your shield discussion out of here as I assume you dont even get the point of this flexible feature. would you first get shield idea out of your mind before reading this? this has nothing to do with shields and not a workaround for it.
lko, see lh_mouse's video. your idea of "attach" is just switch upon death. totally different concept.
Lin Kuei Ominae wrote:
sounds similar to my shield logic idea, attaching one unit onto another.
Though your approach is even more flexible and seeing it was already done, this sounds like a nice new feature.
as you can see, i read your post and acknowledged the difference/advantage.
However there are still several questions unanswered
a) can attached units/buildings be targeted/destroyed independently?
b) how can such a multi object be build? I assume the game would only build the base unit, but not the attached units, since they did not got their build order (the game would have to build multiple different objects at the same time and then attach them together right after they are spawned)
Or the base unit would have to generate/spawn all the attached objects when build. Though how do all the attached object know their X,Y,Z place on the base unit?
c) how are veteran factors and scoring points calculated for the attached objects costs? Would a destruction of one of these multi-units count as 1 kill or as n kills?
d) how do attached buildings work when they need power? Do they also shut down the base unit so it can't move anymore when low on power?
What about bigger buildings which need big foundations?
e) how are the render ZAdjust layers defined on such a multi-object? How can you make sure that the lower turret A of the cruiser is correctly covered by the higher turret B in the right directions?
f) what if 2 attached units somehow contradict each other? (e.g. one enables something while the other attached object is disabling the same thing, or one makes the base unit immune to a certain warhead while the other is making the base unit very vulnerable to the same warhead)
...
i think there even more fundamental issues that need to be solved _________________ SHP Artist of Twisted Insurrection: Nod buildings
Joined: 19 Aug 2009 Location: Moscow State University
Posted: Wed Dec 03, 2014 4:51 pm Post subject:
@4StarGeneral
They don't "move". They read their parents' position information and give it to themselves (this is what I remember about that). In LH_Mouse's screenshots you can see the gattling cannon moving.
@LKO
In general. Sub units act just like any normal units (except they are fixed to the parent). Should not make much big difference however a unit is in sub condition or not. If a normal unit can do something, a sub should also do everything a normal one can do. Tags that affect a certain type should affect any unit of that type, be it sub or not.
Quote:
a) can attached units/buildings be targeted/destroyed independently?
Should be. Or this will limit its potentials. Depends how Ares team makes the framework.
Quote:
b) how can such a multi object be build? I assume the game would only build the base unit, but not the attached units, since they did not got their build order (the game would have to build multiple different objects at the same time and then attach them together right after they are spawned)
Or the base unit would have to generate/spawn all the attached objects when build. Though how do all the attached object know their X,Y,Z place on the base unit?
Sorry I ain't programmer, not qualified to answer such algorism questions.
Quote:
c) how are veteran factors and scoring points calculated for the attached objects costs? Would a destruction of one of these multi-units count as 1 kill or as n kills?
This should be defined in general settings. Since the aim of the feature is to "make one type use another type's tags", I suggest to give sub units 0 cost,0 point, insignificant and so on. Or make it simple: sub unit is just a unit that follows the parent. So the kills are calculated as killing a group of normal units. If you give it cost, then you get experience of both parent and sub unit. Country veteran settings should affect sub units as they do to normal ones.
Quote:
d) how do attached buildings work when they need power? Do they also shut down the base unit so it can't move anymore when low on power?
What about bigger buildings which need big foundations?
That's why LH_Mouse made the "virtual" concept so game won't need to calculate foundations.
If you want the parent unit to shutdown.....use robot tank logic.
Quote:
e) how are the render ZAdjust layers defined on such a multi-object? How can you make sure that the lower turret A of the cruiser is correctly covered by the higher turret B in the right directions?
Would need something to define layer.
Quote:
f) what if 2 attached units somehow contradict each other? (e.g. one enables something while the other attached object is disabling the same thing, or one makes the base unit immune to a certain warhead while the other is making the base unit very vulnerable to the same warhead)
Units never contradict. What you mean are warheads (attacheffect) I think? Then it's the warhead's definition, which is out of THIS feature. No unit can directly have any effect on other unit,except the Prerequisite thing. But again, it is just like building 2 contradictory buildings,it won't be "Unit Attaching System" to decide the result, but Prerequisite system itself. In most ways,to affect another unit, one must be using some warheads, weapons. Then it's the warhead system's part. _________________ Tired of grabbing my random SHP conversions? Why not learn to create SHPs for yourself? QUICK_EDIT
Targeting the subbed units should be up to the modder so you can either have it exist on its own or if parent unit dies they all die. _________________ ~ Excelsior ~ QUICK_EDIT
The default setting should be that attached units die if parent unit dies.
But there should be a tag to allow attached unit to survive.
Just an example: recreating "terror drone surprise" effect from RA3, where a dying vehicle spawns (releases) a terror drone.
Or a Battle Fortress that behives like CC Generals Battle Bus, - becoming an immobile "bunker", speed=0, after destruction, even though the passangers form the Battle Fortress will not "jump" by themselfs, and will have to be sent manually into the "Battle Fortress Hull".
So, if possible, the attached units sould be able to survive. QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sun Dec 07, 2014 10:01 am Post subject:
Which would overly complicate the controls. Do not merge features.
UnitDelivery warheads would be IMO a more consistent feature for that than decoupling attached units - which I always considered dummy ones in GZ anyway. _________________ "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 am confuse. In this and Mouse's thread I see talk, even pictures in Mouse's. And yet, nothing seems to have come of it?
Well, you not realise it was done experimentally in LH Mouse's project which is now long dead & abandoned (codes scattered for most part so can't just add to ares so don't suggest it) thus doesn't exist as far ARES is considered and merely proposed here again. QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Wed Feb 11, 2015 6:39 pm Post subject:
This is very interesting. StarCraft had something like this for turrets (although it wasn't noticeable except if you dug into the code). It's too bad this thread has gone kind of abandoned, I think it would be a very promising feature to be implemented. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
This is very interesting. StarCraft had something like this for turrets (although it wasn't noticeable except if you dug into the code). It's too bad this thread has gone kind of abandoned, I think it would be a very promising feature to be implemented.
You are working on ways of doing this with turrets now, aren't you? _________________ ????????MyAnimeList my Last.fm QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Wed May 13, 2015 8:56 am Post subject:
That was a very hack-y demonstration approach by hijacking the Spawns code. I'd prefer if Ares people did a cleaner implementation of it. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Well my pennies say coordinate should be specified like the IFV turret FLH for each weapon, call it something more appropriate, AttachedObjectXFLH= etc. As long as it's not relative to the underlying unit's PrimaryFLH, nor relative to it's turret -- although it probably makes sense to disallow a turret on the underlying unit, this could be a problem for targeting logic.
Zadjust can be handled easily enough with a fixed setting, and this would open up interesting options like .shp turrets on a voxel vessel, though I think the primary use would be voxels on voxels.
So perhaps it makes sense to force the use of matching attached types, .shp on .shp, .vxl on .vxl, then the height offset can be included either in the graphic OR voxel offset. If that's the case, the attachments could be held to the units Z centerline, and the locations could be set like TurretOffset instead of FLH type coordinates.
Realistically you could have a limit of 4 attachments to limit the number of .ini commands, that should allow a unit to have distinct "turrets" for each naval/land/air/submarine targets. I can't see a need to have 2 AA guns and 3 sets of cannons when we can just add Burst= ... _________________ http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Wed May 13, 2015 1:08 pm Post subject:
Honestly, while I'd welcome this - if my hands wouldn't be full all the time I'd even try implementing - I'd certainly cut this a bit beforehand. Like hardcoding attached units to VehicleTypes. And prolly to keep them virtual, because getting them nonvirtual attached would cause instant recons and whatnot due to how the game maintains positions.
I simply just can't see attaching buildings to other types working. Logics like WeaponFactory hardcode would prove this terribly problematic.
If I go with LH's experiences, then I think the most toughest part of virtual unit implementation is to keep them in sync with parents and some building logics would really mess themselves up if kept virtual - tho no idea how would they work tbh.
Most of the vehicle logics would give no fuss tho, which is why I'd prefer that way.
If anything, the proposed idea would prolly be a lot more easier for OpenRA due to their actor-trait system. _________________ "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
1) virtual units are considered airborne units (the same applies to buildings), which enables virtual units to receive damage and be auto acquired as targets.
At the time when I gave up YR modding, only AA units could automatically acquire virtual units as targets. (All units could have been airborne units. That is why YR engine sucks. That was why I gave up.)
2) Virtual units don't receive experience when killing a unit. They give the experience (by $$) to their virtual parents.
3) Virtual units can't be selected, just as terrain objects.
4) Virtual units are deleted as soon as their parents are gone. The only effective way to keep an isolated virtual unit, is to assign itself as its parent. _________________ Fusion Reactor upgrade is complete.
Joined: 19 Aug 2009 Location: Moscow State University
Posted: Thu Aug 18, 2022 5:06 pm Post subject:
POPUP!
Suprise! Gentlemen, after all these years, the feature said here is fully functional. With Dynamic Patcher Kratos, this is called Stand system (a JOJO reference). On Hares it is accessory unit function. Whatever it is called, it is a design finally done by programmers. Cheers!
The SWs I mentioned are all confirmed doable with it. On Kratos version it is even possible to use Stand system on projectiles.
If you add prism tower stands, you would get a mobile prism support network——just as designed. I should have saved a GIF for it somewhere but I cannot find the old file. Whatever, here's a video of it, hope you can play it.
https://www.bilibili.com/video/BV1F4411j7Eb
You cannot post new topics in this forum You cannot 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