Slaves

[Demon Red Storm]

The slave logic needs a little work. I cannot create slaves that are used for some purpose other than resources, such as the buzzer hive in cnc3 (defensive structure for scrin). This would be interesting and help on modding Yuri's side quite a bit by opening some major doors.

[Bug Importer (bug-importer)]

Well, wouldn't a new Spawn logic be better (spawning infantry or vehicle types, not just aircraft) - Slaves are kinda annoying with their side switch and stuff...

/Millennium

[Professor_Tesla (professor-tesla)]

Sounds like an interesting idea. Adding the ability to spawn InfantryTypes would be cool.

[Teleros (teleros)]

As far as slaves go, how about something like this:

[SMIN]
Freed.Slave.Behaviour= #

Where the # is one of the following:

0 = Freed, as per default YR. System would default to this.
1 = Remain loyal to original owner.
2 = Die.

[WoRmINaToR (worminator)]

I vote for a spawning-esque logic, rather than a slave logic. The spawning logic already is geared specifically toward attacking and things like that, so it would be much easier to work with. There are only a few things that would need addressing:

1) Obviously as already stated, infantrytypes, vehicletypes, etc. cannot be spawned.
2) Buildings, while they can technically spawn aircrafts, the aircraft cannot dock back into the building and the logic just gets hacky and weird when used with a building.

There may be an advantage to using a slave logic though; if used as slaves, the individual slaves would, instead of having attack missions decided by the spawn hub, select their own targets, meaning many targets could be engaged at once by one spawning hub defense.

In any case I support this issue.

[Teleros (teleros)]

"There may be an advantage to using a slave logic though; if used as slaves, the individual slaves would, instead of having attack missions decided by the spawn hub, select their own targets, meaning many targets could be engaged at once by one spawning hub defense."

Then presumably return to hanging around outside their spawner or entering it & disappearing Slave Miner-style. Which is something I'd like to make use of at least, although I agree that better spawning logic would be nice to see.

[Bug Importer (bug-importer)]

I would definately like to be able to do more stuff with the slave logic.

[Bug Importer (bug-importer)]

Fuck slaves, all we need is be able to spawn infantry. But this have been request before, it have been even requested to PD a and VK when they were hacking.
It seems like it will never happend.

[Droke (droke)]

Spawning infantry in the same way as aircraft could certainly be interesting, however, it would not achieve the same effect as adapting slaves.

The ability for a structure to maintain a specified number of infantry (or maybe vehicles too?) within a set range would certainly be useful. The thought of hives and drone control buildings come to mind instantly, and I'm sure that other modders would find even more uses.

[Firefly (firefly)]

defend your base with slave-drones. sounds pretty cool to me

[Bug Importer (bug-importer)]

or repairing vehicles with two spawned engineers from a reapir truck like in blitzkrieg (if only infatry could repair xP)

[MasterHaosis (masterhaosis)]

I support this idea!

[arielby (ariel-bys)]

Full Support!

Also, we probably need a way to make the slaves remain near their owner, instead of moving with their enemies into the enemies base (or, if they are Repair Drones, moving from the Service Depot into the battlefield).

So let's add these 2 new fields, and problem solved.

Slaves.SoftRangeLimit=float; Slaves, when they are idling and more frames apart then this from the slaver, will start a move mission towards the slaver until they are within range.
Slaves.HardRangeLimit=float; Slaves won't be able to move behind this limit, behaving like there's an invisible wall past that radius.

[EagleEye (eagleeye)]

Strong support. Also requesting slave logic for vehicles (both owner-wise and slave wise).

[YR M0ddEr (yr-m0dder)]

well, this would require many new tags to work, but i support it!

[Dupl3xxx (dupl3xxx)]

This is a great idea, strong support!

[Darkstorm (bynnar-starblade)]

Definitly for this! I'm purposing code kind of like this though:

[SLAVETHING]
...
                      ; Original Slave Code
Enslaves=EnslavedUnit ;Unhardcode for any type of unit please
SlavesNumber=number
SlaveRegenRate=number
SlaveReloadRate=number
                      ;New Slave Code
Slaves.Mission=type of mission ;guard,hunt,harvest,deploy,sleep,etc
Slaves.Freed=behavior ;one of a few things:
Slaves.MutateAnim=animation ;animation to play on mutation effect (see bottom)

Now Behavior can mean a number of things:

0 = Default, liberated
1 = remain loyal
2 = become neutral
3 = die
4 = mutate

[Blade (nadia-xy)]

5=Beserk

[Darkstorm (bynnar-starblade)]

Agreed. Though it is only really neutral except they attack randomly. So it should really be:

5=become hunting neutrals

[Renegade (renegade)]

Alright, here's the deal: This is pretty much the biggest and most complex feature left for 0.2, and implementing it could possibly take quite a while.

That in itself would not be a problem, and I take it from the support marked in ICS that many of you wouldn't have a problem with that.

However, if you go back over the discussion, while there is a certain basic consensus on that Slaves should be more liberal and be able to actually fight rather than just mine, beyond that, it's not really clearly defined what exactly the community wants Slaves to be able to do, and what not.

There are a bunch of ideas from individuals which are all interesting, but there is no common set of "we want Slaves to be expanded to do the following things as part of this issue".

As such, in the interest of defining this issue more clearly before implementation and in the interest of releasing 0.2 sooner to switch to 0.3's quicker release cycles, I am hereby un-targeting this for 0.2, and am requesting more feedback on this issue.

Basically, the question to answer is: What exactly do you want?
From a quick glance over the discussion, the following things popped out at me:

- The ability to give them normal weapons and allowing them to use them normally
- The ability to give them a target (as in, commanding all slaves to attack one target) if wished
- The ability to spawn and be spawned by VehicleTypes; if we enabled slaves on TechnoTypes in general, combined with liberating them to be general combatants, this would basically implement #bug:1009

So...what do you want? What general behavior/freedoms do you expect, what special functionality should work or be created, what additional stock functionalities do you expect to work on slaves?

In addition to that fundamental question over the actual nature of this request, there's also the question of "how important is this to you?".
I know this is in the Top 5 of ICS, so I figure you'd all like to see it a lot, but I'd like to hear whether you want this more than #bug:981 or #bug:634, for example, or whether there are other arguments for doing this sooner or later than other requests.

[Professor_Tesla (professor-tesla)]

Speaking for myself, I would want the three things you mentioned. One thing though - a modder might not want to have the slaves switch to the enemy side when the controlling unit is destroyed (the concept in the hypothetical mod might be that the slaves are soldiers based in the "controlling" unit, or maybe robotic drones). There should be an option as to what happens to the slaves when the "controlling" unit is destroyed (the default for normal slaves being, of course, to switch to the enemy side). As to how much I want this, for me, this is a "would be nice to have" feature; I would rather have 634 for example.

[Dupl3xxx (dupl3xxx)]

AlphaBravo's idea with soft and hard rage is nice. However, Unit support is more important.

To make it into a nice list:
Soft and hard range [would be nice]
Units as slaves [must have]
Normal weapons [must have]
Command slaves as group [should have]
Command single slaves [would be nice]

[Droke (droke)]

This is a feature that is pretty much at the top of my wish list. I believe that 643 is more important, but deciding which I want more is difficult.

As for defining the feature itself, two list.

Core list:
-Capability to use weaponry.
-Capability to set the slave's mission to guarding the hub.
-Capability to determine the behavior when freed. (freed, loyal, self termination)

Refinement list:
-Capability to retaliate individually.
-Capability for slaves to inherit the hub's target.
-A radius at which to trigger a return to the hub.
-Expansion to vehicle types, both slave and hub.

[WoRmINaToR (worminator)]

My needs would encompass everything Renegade said above, and this:

I think it would be a good feature to give the slaves a "leash," where the slaves can attack and pursue targets like normal units, but cannot move beyond X amount of cells away from the host object. Also, when the slaves are idle (they don't have a target to attack), they return to the host and hang around it and follow it around.

Also, some way to restrict slaves from re-entering their host vehicle, and a way to prevent the host vehicle from reproducing slaves. This would produce something of a "bodyguard" or "squad" logic, something I have been dreaming of in RA2.

As for priority, I say they should get priority in this order:

1) 634 - This is very necessary for several features in my mod, namely Epic Unit Factories like in Kane's Wrath

2) 357 - This issue. It's definitely something that would radically alter gameplay for many mods, but it is a very very big issue compared to 634 (which is, in theory, smaller in scale), and I think 634 should be taken care of first.

3) 981 - I place this last for several reasons. Firstly, this is a huge and complex issue which could take an unimaginable amount of time to implement, because this will basically have to re-define the game's idea of weapons. New targeting modes, basic support for several different weapons, controlling in which scenarios each weapon fires, etc.. It's just a nightmare to think about.

Secondly, I honestly don't see this feature being used on an overwhelming amount of units in the game. Most units, just by nature, don't need more than 2 weapons. 1 weapon is usually enough for that unit to fittingly fulfill its role in the game. Secondaries, as it is, are usually only used for "special" things like C4 sappers, VirtualScanners, and the like.

Lastly, I want the other issues above a lot more than I want this. I personally have gotten by just fine with each unit having only 2 weapons, and I have little to no intention to add more weapons to any of my units. on the other hand, I would use the Slave system to simulate squad logic for all of my infantry units

[Cabal8616 (cabal8616)]

What I'd specifically like to see from this is:

-The ability to spawn infantry or vehicles from buildings and other units. This is pretty self explanatory, but I'd like to see every possible combination of spawning (with the exception of spawning buildings, of course). Vehicles that can spawn vehicles and infantry, buildings that can spawn infantry and vehicles, aircraft that can spawn other aircraft (this one is listed in another issue), etc.

-The ability for slave logic to work in more ways than just resource collecting. The main thing to slave logic that can still be used is the fact that it's tied to a building/unit, and if the unit/building dies, the "slaves" become free. But, having something other than IsSlave=yes- something like OffensiveSlave=yes- would work nicely.

-The ability for the units that the building/unit spawns to forcefully come out of it upon being "ready", rather than being ordered to do something (in the case of slave miners, they're ordered to collect resources) in order to come out. This could be handy for creating something of a different form of barracks- basically you build a structure, and out comes 5 infantry. These infantry could be selected and used completely like normal infantry, but if one dies, the building that it's tied to could make another. Not sure if it's needed or not, but it'd also be nice to have a tag to specify that the units spawned won't also die if the "master" building/unit dies.

I think if all 3 of those things were put in, everybody could be satisfied.

[kakrain (kakrain)]

but if one dies, the building that it's tied to could make another i think that would be a nice idea but it would be better that it doesnt neesarilly ties to that barracks and the barracks would have a counter so it wouldnt be so much overpowered
i think also it would be nice that if the "leader" dies, the game just select another slave to make him the leader, i think it would be nice for a squad

[Graion Dilach (graiondilach)]

How about expanding the Aircraft Carrier logic for this?

As I can see, the proposals are more similar to the Aircraft Carrier and his Hornets except that they doesn't have a Ammo-tag and it'd applies to Infantry and VehicleTypes than the Slave Miner.

EDIT: Going to test on stock YR the possibilities of the AC logic.

EDIT2: AC logic can only spawn AircraftType, others results with an IE exception code 004145BD, which says that the other types are tried to be identified as AircraftType, considering ModEnc's explanation.

[AlliedG (alliedg)]

I think Graion Dilach expanding AC logic would be a lot less workload then recoding the whole slave behaviour and thus I would this feature to encompass that behaviour as a priority.

[DCoder DCoder (dcoder1337)]

Looks to me like sufficient feedback was given?

[Graion Dilach (graiondilach)]

Special feedback.

While I'm working on 1362, I noticed Westwood uses TechnoClasses in the whole SpawnManagerClass, deriving them from an AircraftTypeClass, while SlaveManagerClass uses InfantryClasses constantly. On the other hand, YR++ has SpawnManager->SpawnNode->Status as an int, while that's an enum in SlaveManagerClass.

I guess reworking that class to use TechnoTypeClasses is far less work then rewrite an entire class. Maybe expanding that Status int (which I think is also an enum just haven't documented in YR++ yet) can be the addition and this request is basically done.