FREEPROTO and Skunkworks retooling

[scient]

So, I was looking into the undocumented ability of Skunkworks and it's relation to FREEPROTO flag with Spartans.

The undocumented ability is definitely not a bug and clearly intended feature of Skunkworks.  It was most likely added late in development or just forgotten about.  If the facility is present in a base, it overrides the default "Retool strictness" value and sets it to 1 or "Free in Category".  The default in alpha/x.txt is 2 or "Free if Project".

2,       ; Retool strictness (0 = Always Free, 1 = Free in Category, 2 = Free if Project, 3 = Never Free)

Now, if the FREEPROTO flag is set that faction isn't given an option to build a Skunkworks because they already have the documented feature of the facility.  This is similar to how you don't get an option to build a Skunkworks if you're playing on Citizen or Specialist difficulty.  Likewise when using either of these difficulty levels, you don't get a retooling penalty at all and it's treated as "Always Free".

More discussion here: http://www.civgaming.net/forums/showthread.php?t=7453

...

I think best solution for this would be to give FREEPROTO factions this feature of Skunkworks upon discovery of the necessary tech "Advanced Subatomic Theory".  This is in line with how code already works with treating retooling and proto features in relation to Skunkworks for other things like the difficulty.  It seems like this was just oversight since only one faction is affected by this and it would be easy to miss.

On another note, "Never Free" setting for "Retool strictness" alpha/x.txt is broken in some regards.  If isn't parsed correctly when alpha/x.txt is read, it only accepts values 0 to 2.  Also, a corresponding script.txt entry is missing.  However, it is properly handled in function that determines whether there will be retooling penalty or not.  It's simple fix so will enable it in case someone wants to use this setting.

[Guv’ner]

Could you describe the context for the script entry so we could try to work out a wording for reimplementing it?

[scient]

Nothing special, the entries for RETOOLPENALTY2 and RETOOLPENALTY2A can be used.  I could do it in the code where it changes the value from 3 to 2 when it gets to looking up script but easier just to duplicate #2 and rename id to RETOOLPENALTY3 and RETOOLPENALTY3A.  The only difference between #2 and #3 is that #3 gives you retool penalty for Secret Projects as well as everything else.

[Buster's Uncle]

Simply put, the problem was that Spartans didn't get the free prototype ability, or that building skunkworks shouldn't be an option for them?  Am I following, or is some clarification needed for us non-tech types?

[Guv’ner]

The Spartans do get the free prototype ability but that prevents them from building Skunkworks and benefiting from the ability to switch production within category without penalty:
http://www.civgaming.net/forums/showthread.php?t=7453

[scient]

As far as I know, the Spartans do get free prototype ability and that's all working.  They also are correctly barred from building Skunkworks in their bases since they already have ability it is suppose to provide.  The problem was that there is undocumented ability of Skunkworks to give the base it's in the ability to retool production without a penalty within the same category (unit change to unit, base facility to base facility) where the default is you will get penalty unless you're switching to secret project.  It was giving Spartans and FREEPROTO a disadvantage (albeit a pretty minor one) for what should of been positive faction bonus.  The change I made was to give them this undocumented feature once they discover the tech to build Skunkworks where as their free prototype ability is given to them from the get go.

[Buster's Uncle]

Ah.  I use a build queue exploit to evade that...

[Yitzi]

I've actually investigated the matter in the process of making patch 2.0, so basically the undocumented features, as far as I can tell, are as follows:

-If the base has a skunkworks, it's treated as if the retooling strictness were 1 (unless it's already 0), i.e. free retooling between things of the same type.
-If changing from one non-unit to another, and either the old or the new one is a facility already present in the base, retooling is free.  (There seems to be a bug that afterward changing to a unit is also free, but I'm not sure how you get that situation without the scenario editor anyway.)

So either of those would be easy to change.

The queue rushing bit looks like whoever added the "load from queue" feature forgot to pass it through the "retooling penalty" procedure first.  Not really such a major priority for fixing, as banning it makes it not a problem (assuming everyone follows the ban).

So, I was looking into the undocumented ability of Skunkworks and it's relation to FREEPROTO flag with Spartans.

The undocumented ability is definitely not a bug and clearly intended feature of Skunkworks.  It was most likely added late in development or just forgotten about.  If the facility is present in a base, it overrides the default "Retool strictness" value and sets it to 1 or "Free in Category".  The default in alpha/x.txt is 2 or "Free if Project".

2,       ; Retool strictness (0 = Always Free, 1 = Free in Category, 2 = Free if Project, 3 = Never Free)

Now, if the FREEPROTO flag is set that faction isn't given an option to build a Skunkworks because they already have the documented feature of the facility.  This is similar to how you don't get an option to build a Skunkworks if you're playing on Citizen or Specialist difficulty.  Likewise when using either of these difficulty levels, you don't get a retooling penalty at all and it's treated as "Always Free".

More discussion here: http://www.civgaming.net/forums/showthread.php?t=7453

...

I think best solution for this would be to give FREEPROTO factions this feature of Skunkworks upon discovery of the necessary tech "Advanced Subatomic Theory".  This is in line with how code already works with treating retooling and proto features in relation to Skunkworks for other things like the difficulty.  It seems like this was just oversight since only one faction is affected by this and it would be easy to miss.

I'd say give it to them even beforehand, as though they just got bonus skunkworks in the base.  However:
1. Scient, have you figured out which bit is the FREEPROTO flag?
2. What does everyone think about what should be done?  It doesn't seem worth making into an option, but there probably shouldn't be a change that people don't want.

On another note, "Never Free" setting for "Retool strictness" alpha/x.txt is broken in some regards.  If isn't parsed correctly when alpha/x.txt is read, it only accepts values 0 to 2.  Also, a corresponding script.txt entry is missing.  However, it is properly handled in function that determines whether there will be retooling penalty or not.  It's simple fix so will enable it in case someone wants to use this setting.

This fix will be present in version 2.0 of my patch.

[scient]

-If the base has a skunkworks, it's treated as if the retooling strictness were 1 (unless it's already 0), i.e. free retooling between things of the same type.
-If changing from one non-unit to another, and either the old or the new one is a facility already present in the base, retooling is free.  (There seems to be a bug that afterward changing to a unit is also free, but I'm not sure how you get that situation without the scenario editor anyway.)

Yep, that was my conclusion as well.  It's not just non-unit, it's buildable facilities only so stuff like "Sky Hydroponics Lab" are considered different from say "Children’s Creche".  The second bit is so that you only pay retooling cost once per turn.  Whether this is a bug or mechanic, not sure.

I'd say give it to them even beforehand, as though they just got bonus skunkworks in the base.  However:
1. Scient, have you figured out which bit is the FREEPROTO flag?
2. What does everyone think about what should be done?  It doesn't seem worth making into an option, but there probably shouldn't be a change that people don't want.

I could do that, either way.  Making them have tech gives them less of advantage early game so I was hoping it would be more palatable and less of a balance change.  As for FREEPROTO, yes.

00000010 ; enum SPECIAL_RULES_1 (bitfield)
00000010 TECHSTEAL        = 10h
00000020 TECHSHARE        = 20h
00000040 WORMPOLICE       = 40h
00000080 ALIEN            = 80h
00000100 AQUATIC          = 100h
00000200 FREEPROTO        = 200h
00000400 FANATIC          = 400h
00000800 MINDCONTROL      = 800h
00001000 COMMFREQ         = 1000h
00002000 TERRAFORM        = 2000h
00004000 INTEREST         = 4000h
00008000 MORALE           = 8000h

And for SMACX, it will be ptr into faction struct tho so this address is only good for first faction:

00946F58 ; int faction_special_rules_bitfield

This fix will be present in version 2.0 of my patch.

Likewise, but make note that you'll have to modify the id value used here or the script.txt display will be messed up since there is nothing for id 3.  I solve this by just adding in a clone copy of id 2 script.txt strings with id's changed to 3.  But it could be done via code edit.

[Yitzi]

Yep, that was my conclusion as well.  It's not just non-unit, it's buildable facilities only so stuff like "Sky Hydroponics Lab" are considered different from say "Children’s Creche".

However, the "changing one non-unit to another" thing includes satellites as non-units as well; you are correct, though, that with strictness 1 (or equivalently, with skunkworks) satellites/stockpile energy are considered a fourth category.

As for FREEPROTO, yes.

00000010 ; enum SPECIAL_RULES_1 (bitfield)
00000010 TECHSTEAL        = 10h
00000020 TECHSHARE        = 20h
00000040 WORMPOLICE       = 40h
00000080 ALIEN            = 80h
00000100 AQUATIC          = 100h
00000200 FREEPROTO        = 200h
00000400 FANATIC          = 400h
00000800 MINDCONTROL      = 800h
00001000 COMMFREQ         = 1000h
00002000 TERRAFORM        = 2000h
00004000 INTEREST         = 4000h
00008000 MORALE           = 8000h

And for SMACX, it will be ptr into faction struct tho so this address is only good for first faction:

00946F58 ; int faction_special_rules_bitfield

So if I understand you correctly, the special rules are at the dword at 00946F58 (for the first faction; the corresponding place in other factions)...What are those numbers, though?  Seems they should be the positions of the rules, but those only have room for one bit per rule and stuff like INTEREST has more than that.  (Also, what are bits 1,2,4, and 8 for?)

Likewise, but make note that you'll have to modify the id value used here or the script.txt display will be messed up since there is nothing for id 3.

That's ok; I'm moving the alphax.txt value from a dword to a pair of bits to save space (the main goal of 2.0 is to make space so extra alphax rules can be added in that section rather than stealing from the landmarks section), so I had to change it anyway; a simple test for the second bit did the job.

[scient]

So if I understand you correctly, the special rules are at the dword at 00946F58 (for the first faction; the corresponding place in other factions)...What are those numbers, though?  Seems they should be the positions of the rules, but those only have room for one bit per rule and stuff like INTEREST has more than that.  (Also, what are bits 1,2,4, and 8 for?)

What numbers? It's a bitfield.  Those are bits that each of these flags are checked in the dword.  These are only the rules that act like boolean flags that can be turned on or off.  Other special rules like INTEREST are stored in different areas of faction structure.  And I'm not sure what lower bits are for, that's just my enum I've done so far.  Haven't really focused on special rules as a whole.

[Yitzi]

What numbers? It's a bitfield.  Those are bits that each of these flags are checked in the dword.  These are only the rules that act like boolean flags that can be turned on or off.  Other special rules like INTEREST are stored in different areas of faction structure.

Wait, now I'm confused...I suppose that by TECHSHARE you mean the "share tech with infiltrator" flag, but what do you mean by:
00004000 INTEREST         = 4000h
00008000 MORALE           = 8000h
As those things aren't boolean flags.

[scient]

Oh, I see. It's boolean whether it was set in faction file and then if set it stores it in faction struct.  If you're really interested and I can look into it more but I haven't really focused on faction structure.

[Yitzi]

Oh, I see. It's boolean whether it was set in faction file and then if set it stores it in faction struct.  If you're really interested and I can look into it more

Nah, if necessary I can look into it more.

Speaking of which, I don't suppose you already have information on where the difficulty for each faction is stored?

(Also, if there's anything you want to know if I've found, feel free to ask; no point in us doing the same work twice.  I've got pretty much everything on ALPHAX #RULES, and a lot on base structure, plus various other things.)

[scient]

Do you use IDA?  As for difficulty, it's only stored in one place afaik and then the AI is handled differently.

009A64C4 : difficulty_level_value

I have everything in alpha/x globals already marked up, there is one root function where all globals are parsed:

parsing_alphax_general : 005873C0

I've got a lot of base struct worked out as well but if you know what any of portions besides ones I've marked up let me know.  I've skipped areas I haven't identified yet.