Factories producing different units.

[lt albrecht]

Since D so kindly "fixed" the kennel hack, would he care to offer a quick replacement such as a "BuiltAt=" tag on units to specify one or more production structures the unit needs to appear on the sidebar and may exit from? Obviously defaulting to the generic factorytype system in use now.

[MT1337 (mt1337)]

Yeah, us modders definitely need the control of which structures can build what. In favour.

[Teleros (teleros)]

Would be a great idea too IMHO.

[Droke (droke)]

I also could use this. Would be very helpful.

[WoRmINaToR (worminator)]

yes we definitely need a replacement to the kennel hack; this screws one of the coolest easter egg features in my mod...

[Bug Importer (bug-importer)]

I'd like to have it back too.

[EagleEye (eagleeye)]

Kennels! Yay!

[angrymod (angrymod)]

I'd like this so that helicopters dont come out of the WF and instead a custom WF that may look like a helipad that opens up, and also to have factories that only build hero units.

[Professor_Tesla (professor-tesla)]

I would also like to see this done so that we could have things like kennels as well as distinct light vehicle factories and heavy vehicle factories (as seen in Dune 2000).

[EagleEye (eagleeye)]

Any chance of being able to build a vehicle from a War Factory that's modded to only build ground vehicles while building a helicopter coming from another War Factory that's modded to only build helicopters?

[WoRmINaToR (worminator)]

probably not, since they are both VehicleTypes and build queues are global (at least for that player) and are not factory-specific.

However, I never did figure out how exactly westwood was able to get naval factories and war factories to produce at the same time, considering they both produce units from the [VehicleTypes] section.

Maybe the separate build queues are determined by the factory's coding (WarFactory=yes versus Naval=yes), and not by what they produce, so we might be able to add extra tags to war factories to allow parallel queues between different types of vehicle-producing factories.

This is all pure conjecture, however. I have no idea how feasible the idea really is.

[YR M0ddEr (yr-m0dder)]

^^^ That sounds nice, the Ares coded kennel hacked warfactory should be able to queue its own units if it possible

[reaperrr (reaperrr)]

This is a must-have, IMO. I don't want my vehicle-type helicopters/VTOLs, vehicles and mechs all produced in the same factory. I want more control over which factory can produce what unit(s).

[Blade (nadia-xy)]

I disagree, its a "nice to have", but it doesn't stop you making those kinds of units, you just need to design the factory so it looks like it makes sense making all these types of unit.

[reaperrr (reaperrr)]

>>you just need to design the factory so it looks like it makes sense making all these types of unit.

That's the problem, there are more than enough modders out there - including me - who don't have the graphical skills for that. People who are not able to make their own factory graphics but don't want to re-use RA2/YR factories either and would prefer to use, for example, TS' factories are left out in the cold.

[Droke (droke)]

I wouldn't go so far as to say its a 'must have', placing it on the same scale as superweapons and the like. However, it is well above a simple 'nice to have'. Other then obviously wanting to separate VTOLs from ground vehicles, single factories can screw with a mod's fiction. Perhaps a faction has normal vehicles and hulking mutated creatures. That radioactive giraffe certainly shouldn't be coming from a machine shop. Single factories also prevent modders from giving the illusions of separation.

I honestly don't see what graphical skill has to do with it though, as more buildings require more art.

Anyway, how will this handle production queues work? If it uses the same logic as the naval yard, each factory would have its own queue, but what happens with overlapping factories?

[Zhuriken (zhuriken)]

I strongly support this. I've always wanted a separate factory for all aircraft including Kirovs and helicopters. Kennel sounds nice too

[MasterHaosis (masterhaosis)]

I also strongly support this. Because there are also special case units such are epic units which are huge for war factories. So you can customise special war factory for it, for special helipad for helicopters, or order Mechanical infantry which are actually vehicles in codes (because organic units cannot use mechanical warheads), and order it to exit from Barracks, so you actually do have a mechanical infantry.

[Professor_Tesla (professor-tesla)]

"or order Mechanical infantry which are actually vehicles in codes (because organic units cannot use mechanical warheads), and order it to exit from Barracks, so you actually do have a mechanical infantry."

I don't think that's the way it's planned to work.

[WoRmINaToR (worminator)]

Yes, actually. As long as he is willing to make it an actual full-blown vehicle (that looks like an infantry), then it's exactly the same as the kennel logic. it's a special vehicle that has to exit from a special factory.

On second thought, he would be best off creating it from its own special barracks, to avoid unnecessary code complications, but in theory it's still possible...

[MasterHaosis (masterhaosis)]

WoRmINaToR, o hai! Yeah, you do understand what did I mean.

[DCoder DCoder (dcoder1337)]

You two, read bug:475.

[RandomNutjob (randomnutjob)]

Well I did read all that.....so, this would simply be set as BuiltAt= - sounds "easy" enough, reality though?

[RandomNutjob (randomnutjob)]

This'll be only thing I'll say with regards to that post - I, for one, am not an ass kisser/licker/whatever, my post - if took notice - was to get this back on topic as has drifted so far it's like it has been subject to a black hole

I have no ill feelings/thoughts but there is a time and place to act way/s have

That aside, what is the status of this and how tricky is it/will it be to implement?

[DCoder DCoder (dcoder1337)]

The part where the unit can come out from a specific factory is pretty simple to implement.

The part where each factory can have its own production queue is scattered all over the UI management and whatnot and is too expensive to implement.

[RandomNutjob (randomnutjob)]

Oki doki, thanks for info - had feeling the latter part would be tricky

Personally I'd be happy with what this originally requested but can see the desire others have/may have for the other

[Steel Mirage (steel-mirage)]

Not to be a total necromancer... Has any work been done on this yet?
I'm thinking about making this my pet project for a while. It seems like splitting the production queue is the primary problem. Would that be a rulesmd.ini fix or would that be something addressed by the parser? Either way, I think this is one of the more interesting items in the house and I'd like to start here.
The whole "too expensive to implement" thing: what does that even mean?

[Graion Dilach (graiondilach)]

Too expensive in work. I can't look at it right now but IIRC, there isn't a place where the list of buildable objects could be associated to a building... which means one must be written and things like that.

You can't just write new FactoryTypes that easily.

[YR M0ddEr (yr-m0dder)]

"Has any work been done on this yet?"
Pretty sure no one have done anything related to this feature yet.

[Steel Mirage (steel-mirage)]

So would it just be a matter of writing a new section of code for rulesmd, or would it involve how the game actually "thinks"?

After some further review, in the original rulesmd file (at least, in the one I have):
(1) I looked at a few different examples of units, land, sea, air and infantry. Their tags seemed useless to our purpose.
(2) I looked at the factories involved: WEAP, YARD & PILE/HAND/BRCK. They all had the Factory= tag in common, so I looked that up.
(3) Turns out, there are five choices involved in that tag:
[\code]Factory = type of object to build [InfantryType, AircraftType, UnitType, BuildingType, VesselType] (def=none)[code]
the first four have their own dedicated lists within rulesmd.ini, obviously. Interestingly, "VesselType" seems to be an orphan. There are no other references to "VesselType" in the entire file.
(4) Looked at everything ModEnc could give me on the "factory" tab. [\url]http://modenc.renegadeprojects.com/Factory[url] was helpful, but inadequate.

I followed a lot of things down a lot of rabbitholes, and couldn't seem to find whether or not the lists that originally come with RA2/YR are hardcoded or not.

IF they aren't hardcoded, reworking the lists into different Factory=XTypes could theoretically allow the original feature request to be accomplished.

The shitty part: Doing this would be terrifically complex and open to a lot of criticism, argument, etc. I don't even know how it would be tested... You'd need to have all your art animations and sounds set up for the new factory buildings, on and on.

The solution, should this be viable, would be a "subcommittee" formed to coordinate efforts to achieve this end. I submit that this would be worthwhile to do seeing as there seems to be a great deal of interest in this subject, and that its fairly high on the priority list for the next version.

Issues to decide:
1. How many lists there need to be.
2. What the lists should be called.
3. How it could be made easy to understand for those coming after us.
4. What would be the best way to make it run smoothly with the rest of the game.
5. What other questions need to be addressed.

This is just my interpretation(s). I'd love to see this kind of feature be added and I'd love to contribute.

[DCoder DCoder (dcoder1337)]

VesselType doesn't exist. It might have existed when someone originally wrote that comment, but it's not in the released game.

[YR M0ddEr (yr-m0dder)]

If I understand you correct, you are planning to add a few new entries to Factory= tag. To me, that seems hardcoded. It should be more customizable, example:

[FactoryTypes]
0=HelicopterFac
1=AlienFac

[MAWEAP]
Factory=AlienFac

[Steel Mirage (steel-mirage)]

That was my original thought, yes, but I haven't been able to confirm/deny whether or not its hard coded, and frankly have no clue how to test it myself. Yet.

In a nutshell, this is my idea:
What we have now-> [InfantryType], [AircraftType], [UnitType], [BuildingType]
What I think we might like to have->
For infantry: [BaseInfantryType], [AdvancedInfantryType], [HeroUnitType]
For aircraft: [BaseAircraftType], [AdvancedAircraftType]
For ground vehicles: [LightMechUnitType], [MediumMechUnitType], [HeavyMechUnitType]
For naval vessels: [SmallVesselType], [MediumVesselType], [CapitalVesselType]
or something like that. This way it seems that you could have multiple build queues, much like infantry, aircraft, units and naval vessels already have their own build queues.

As for the hardcoding, is it hardcoded? Or would it just include such a major reorganization of the artmd.ini files, etc, that it seems hard coded? It occurs to me that the folks at Westwood were just trying to keep it simple. Maybe with just a little elbow grease this could be accomplished.

If it is hardcoded, then the whole point of having multiple building queues associated with the multiple factories might be a moot point entirely. It would be a decent feature, but could be accomplished with prerequisite= logic rather than a major shake-up, right?

Either way, the multiple build queues is the key feature that I'm interested in. Without the possibility of getting that, is it even worthwhile to attempt this feature?

[Professor_Tesla (professor-tesla)]

You don't understand him correctly. It's going to be implemented like this:

[GAHVYWEAP]
(code similar to GAWEAP's goes here)

[ASUPTNK]
BuiltAt=GAHVYWEAP

This code causes the game to only let the unit exit from the specified factory, but the specified factory must be type of factory corresponding to the unit's type (in this case, GAHVYWEAP would be the same as GAWEAP in most ways. Since ASUPTNK is a vehicle type, GAHVYWEAP has to be a vehicle factory).

[Steel Mirage (steel-mirage)]

I think I get that. What I'd like to accomplish is being able to build things at the same time.

For example: Say I have a light factory, medium factory and heavy factory, and I queue up (1) a Grizzly, (2) a Mirage and (3) a Battle Fortress. Instead of having to wait for each successive unit to be built, the light factory builds the grizzly, the medium builds the Mirage and the heavy builds the battle fortress. Simultaneously. Kinda like the GAYARD can build a ship at the same time GAWEAP cranks out a tank, except broken down smaller...

If its even possible, ya know?

[Professor_Tesla (professor-tesla)]

Quoted from DCoder's post above: "The part where the unit can come out from a specific factory is pretty simple to implement.

The part where each factory can have its own production queue is scattered all over the UI management and whatnot and is too expensive to implement."

In other words: It might be possible, but it's too complex and difficult to be worth doing.

[DCoder DCoder (dcoder1337)]

Aside from the fact that you need 3x the base space to have those three separate factories...

A lot of things are possible in this engine, even more so if you know how to program. More often than not, the question is not "is it possible", it's "is it worth the time investment". I don't see any way this can be implemented without one of us asm readers doing all the analysis and guiding your progress, during which time we are unable to work on our own features.

[Steel Mirage (steel-mirage)]

I could see where that would be a pain... And I have to keep remembering that ya'll do your programming in C++, which is so far out of my wheelhouse its not funny.
If I work on this within the standard rulesmd.ini, would that be helpful at all? Or would I just be wasting everyones time in general?

[OmegaBolt (omegabolt)]

"If I work on this within the standard rulesmd.ini, would that be helpful at all?"

As far as I can see you would NEED to program this feature into the game. The logic doesn't exist already for this to be possible with simple ini editing. The kennel hack was the closest thing we had which has been removed by Ares, hence Lt. Albrecht's original request.

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: DCoder
Location: trunk, r1095
Commit contains DLL: No
Revision comment:
Branch for issue #634
SVN: http://svn.renegadeprojects.com/Ares/1095

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: DCoder
Location: issue-634-factories, r1096
Commit contains DLL: Yes
Revision comment:
Related to issue #634 -
[InfantryOrVehicle]
BuiltAt=FACT1,FACT2,FACT3 ; will be kicked out of the first
; not-busy building the house owns that's mentioned in this list
ClonedAt=CLON1,CLON2 ; each building owned by the same house
;will kick out an extra clone of this object for free
;(no refunds if it can't exit)
Cloneable=; [y]/n - if no, won't be cloned

[Building]
CloningFacility=; [y]/n - will clone all VehicleTypes
;with the same Naval= setting as itself.
If ClonedAt is specified, neither Cloning=yes nor CloningFacility=yes will clone the object.
BuiltAt and ClonedAt can be reset in gamemode/map using the value of none.

Also cleaned up a few parser issues in PoweredBy= parsing - zero out the list before adding new items (gamemode/map), log invalid values appropriately.
SVN: http://svn.renegadeprojects.com/Ares/1096

[DCoder DCoder (dcoder1337)]

That was less than 2 hours of work, btw.

[Krozalid (krozalid)]

How should we test this? Just put BuiltAt=[any factory type right]?

[Graion Dilach (graiondilach)]

CloningFacility goes to the factory, rest goes to units.

I'll check it in a moment. CloningFacility sounds interesting.

[AlexB (alexander-b)]

D, in Ext/Building/Body.cpp line 815, kicking out the unit could fail (for instance, because the weap is still kicking out another tank), leaking the unit.

[DCoder DCoder (dcoder1337)]

Dammit Westwood! Their code has the same problem...

Thanks, will fix.

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: DCoder
Location: issue-634-factories, r1097
Commit contains DLL: Yes
Revision comment:
Related to issue #634 - you wouldn't notice this, but if a clone production building failed to kick out the clone, that clone would linger on in memory. Fixed so it is deleted properly instead.
SVN: http://svn.renegadeprojects.com/Ares/1097

[cranium (cranium)]

Using only

[DEMON]
BuiltAt=RFWEAP2
ClonedAt=RFWEAP
Cloneable=yes

Causes game to either Freeze or go into super, super, slow mo during the "kick out process" in the pic above shows game froze just after war fac doors opened.

[Graion Dilach (graiondilach)]

[14:22] BTW, a question.
[14:22] What happens if I have a CloningFacility=yes without Factory settings?
[14:24] a better question would probably be what happens if the building that's kicking out the clones does have those settings
[14:25] because then it'd most likely get stuck in an infinite loop
[14:25] Well, then I guess that happened with Cranium.
[14:25] lol
[14:25] already?
[14:25] http://bugs.renegadeprojects.com/view.php?id=634#c10224
[14:26] great

[cranium (cranium)]

Using,

[DEMON]
BuiltAt=RFWEAP2
;ClonedAt=RFWEAP
;Cloneable=yes

Works great. The Demon Tank was only built at RFWEAP2 while all others exited normal RFWEAP.

[cranium (cranium)]

Seems no matter what settings I use for cloning, game freezes or crawls to a halt during kick out. I tried

BuiltAt=RFWEAP2
ClonedAt=RFWEAP
Cloneable=yes
with and without CloningFacility=yes on RFWEAP

BuiltAt=RFWEAP2
;ClonedAt=RFWEAP
Cloneable=yes
with and without CloningFacility=yes on RFWEAP

BuiltAt=RFWEAP2
ClonedAt=RFWEAP
;Cloneable=yes
with and without CloningFacility=yes on RFWEAP

Normal BuiltAt= works fine.

[Graion Dilach (graiondilach)]

[14:29] But it still uses Outline10 and ExitCoord for kicking out the unit, am I right?
[14:34] you're not supposed to use Factory=foo on a cloner
[14:34] since that part is not responsible for kickout placement
[14:35] WeaponsFactory=yes forces the Outline10 behaviour
[14:35] GDI/Nod/ThirdBarracks forces one of the three barracks kickout behaviours
[14:35] lacking that, the unit just drives out from the left corner of the structure

[Graion Dilach (graiondilach)]

Using CloningFacility=yes with WeaponsFactory=yes but not using Factory= makes the cloning work.

Cloneable=no works for both Infantry and VehicleTypes.

This rocks.

[cranium (cranium)]

yup, commenting out Factory= on the clonefacility makes it work superbly.

Cant believe we actually have this ability now, This just unlocked a whole new world to modding. Man you rock DCoder.:)

[Bug Importer (bug-importer)]

Code related to this issue has just been checked in!
Author: DCoder
Location: issue-634-factories, r1098
Commit contains DLL: Yes
Revision comment:
Related to issue #634 -
Factory=smth is not needed for cloning facilities and causes infinite loops. Fixing those would be expensive, so for now Ares will simply exclude Factory=smth buildings from possible clone production facilities.
Note that Factory= is not what causes the units to drive out nicely, WeaponsFactory=yes is.
SVN: http://svn.renegadeprojects.com/Ares/1098

[cranium (cranium)]

Not sure if I understand the last commit comment,"so for now Ares will simply exclude Factory=smth buildings from possible clone production facilities." but using 1098 and keeping Factory=yes on the CloneFacility=yes building stops any cloning from happening. Commenting out Factory=yes will allow it. Is this how 1098 is intended to work?

[Graion Dilach (graiondilach)]

I guess yes, since factories can't be cloners.

[DCoder DCoder (dcoder1337)]

You're welcome. :)

Now all you guys need to do is run this through enough vicious testing in a week or so that we can confidently put it into trunk.

Edit: yes, disabling cloning on Factory= buildings with an appropriate log message is the right thing to do in my opinion. Better than getting the game stuck in an infinite loop, easier than fixing westwood's spaghetti derpballs.

[Graion Dilach (graiondilach)]

Using WeaponsFactory=yes, Cloning=yes and CloningFacility=yes on a building produces a weird result.

The first trained infantry gets stuck into the building, every unit produced after it gets exited at the first PowerPlant built. Will check if using Barracks gives the same.

[cranium (cranium)]

WeaponsFactory=yes for Infantry?

[Graion Dilach (graiondilach)]

Just for a try. I had to use something. Take note that the building is meant to clone both infantry and units. :P

[DCoder DCoder (dcoder1337)]

Yeah, no. A building cannot produce multiple *Types without falling face first into nonsense.

[Professor_Tesla (professor-tesla)]

Testing results log:

1st Testing session: The tag BuiltAt= was tested. The original intended use of this feature works perfectly.
Note: All of the original units of the same Unit Type as the special unit(s) need to have BuiltAt=(default factory types) added to their rulesmd entry or they will be able to come out of the special factory (e.g. all of the original infantry types should have BuiltAt=GAPILE,NAHAND,YABRCK added to them in the otherwise unmodded game if there is a special infantry type that comes out of a special barracks).

2nd Testing session: The tag ClonedAt= was tested. It is possible for cloned infantry to come out of any building, but this only works properly for a non-barracks building if the building has a 2x2 square foundation. It is also possible for cloned vehicles to come out of any building (even the same one that clones infantry), but, again, a non-weapons-factory cloning building must have a 2x2 foundation for this to work properly.

3rd Testing session: The BuiltAt= tag on my special infantry was given a value that referred to a non-barracks building. The unit failed to appear in the sidebar, even when I built the building in question, and triggered the NCO bug.

[DCoder DCoder (dcoder1337)]

2: What does "works properly" mean? Did you use WeaponsFactory= or GDI/Nod/YuriBarracks= on the cloning structure?

3: What is a "non-barracks building"? One that doesn't have Factory=InfantryType?

[Professor_Tesla (professor-tesla)]

Oops. I probably shouldn't have used that word. What I meant was that it doesn't cause any other problems. No, I didn't have any of those tags on the cloning structure. I also don't know why I bothered mentioning the third item.

[DCoder DCoder (dcoder1337)]

1. This logic simply allows a unit to be delivered from an arbitrary building. The ejecting building does not override normal NCO checks - you still need to own a structure with the proper Factory= and Naval= settings to get the unit on the sidebar without the NCO glitch.
2. The code responsible for unit delivery and exit is a big ball of mess that will not be fixed in any foreseeable future. Use the WeaponsFactory=yes or one of the XXXBarracks=yes flags on your exit buildings to make it work better.

As I see it, you need to either
a) have both Factory= and WeaponsFactory= on all vehicle factories and then apply BuiltAt= to every single unit (#include to the rescue?),
b) have one Factory= and WeaponsFactory= building that most units will use, WeaponsFactory= on all alternative factories, BuiltAt= on the units using the alts, and include the Factory= building in their prereqs.

[falaka21 (falaka21)]

I think, it is impossible to "set rally point" function for new "Cloning Facilities " since they must not have " Factory= " tag... Anyway ,DCoder... You are the ruler supreme ,man !!! :)

[Graion Dilach (graiondilach)]

I guess you're wrong because the Cloning Vats an RA2 doesn't have Factory, only NodBarracks and it can have a rally point.

Also if I see it well, my cloning factory could have a rally point but I used a Mobile War Factory for testing... and it undeployed itself. (and it only has XXXBarracks or WeaponsFactory for testing)

[YR M0ddEr (yr-m0dder)]

Testing BuiltAt= tag, it work as intended. I also ran into what Professor_Tesla explained in "1st Testing session". I suggest a new tag to fix this:

IsAlternativeFactory=yes; NO units can be built here unless a unit have its name on BuildAt= tag.

------

Clone logic work as intended.
Clone war factories can not have waypoints.
"If ClonedAt is specified, neither Cloning=yes nor CloningFacility=yes will clone the object."
Can you reexplain that? I dont think it work, but I am not sure if I understood correctly.
Edit: no need for reexplain, I confused Cloning= with Cloneable=.

Resetting ClonedAt= tag in a map also works.