Random Invisibility Mod

Well in its current form, it works great. :goodjob: The only annoyance is the way that units display their spotting ability in the civilopedia. If a unit has 4 chances to spot an invisibility type, it will state this four times in the civilopedia.

That's interesting. I hadn't noticed that since I rarely use the civilopedia.

My other Random Invisibility mod uses a different approach. It doesn't require you to list an invisible type many times to increase the odds of seeing it (though you can still do this). It does require you to insert placeholder invisible types. The odds of seeing an invisible type depend on where it is placed relative to the placeholders.

Neither approach is universally better or worse than the other. You may prefer one or the other depending on what you want to do. I think I will be posting it soon, since you expressed interest.
 
Hi all,

I have posted a new version of this mod in the downloads database:

http://forums.civfanatics.com/downloads.php?do=file&id=11721

I tried to put the file in the original thread post, but have had some trouble with this.

Version B 0.30 includes Better BTS AI 0.60, and allows up to 34 civilizations. Only the CvUnit.cpp, CvPlot.cpp, and CvDefines.h have been modified from Better BTS AI 0.60.

Version B works differently from the other versions I have posted so far. It is not necessarily better. It is just different.

The Submarine has the following SeeInvisible tag:

01,02,03,04,05,06,07,08,09,INVISIBLE_NUCLEAR_SUB,11,INVISIBLE_SUBMARINE

In this mod the 01, 02, 03, and so forth tags are just placeholders. The probability of seeing an invisible unit is higher the farther out you put the SeeInvisible tag. I use a Fibonnaci sequence style calculation. Each iteration of the loop increases the probability of seeing the invisible unit by the fibonacci sequence. The first round (position 01) has a 1/987 chance of seeing the invisible unit. Then it is 2/987, then 3/987, then 5/987, and so on.

To make a unit easier to see, put it farther to the right in the sequence, say position 16. To make it harder to see, put in farther to the left like in position 01.

Battleships have a low probability of seeing Submarines, only 2 out of 987, as may be seen below:

01,INVISIBLE_SUBMARINE

Meanwhile, Attack Subs have higher odds as may be seen below:

01,02,03,04,05,06,07,08,09,10,INVISIBLE_NUCLEAR_SUB,12,INVISIBLE_SUBMARINE

If you set the SeeInvisible for the relevant unit far out enough, it will have 100% odds of seeing the invisible unit. This is the main difference between this version and previous versions.

I hope my explanations are clear. If they are not, please ask and I will clarify.
 
The values should be greater than zero and not greater than 32,000.
If so, your code should convert negative values to 0 and values greater than 32,000 to 32,000 internally. Never allow an invalid value input to your system to stay invalid.
 
How about adding some code to Sentry. When you click Sentry, all remaining movement points are expended one at a time as multiple checks against See_Invisible. If a unit is detected, the Sentry function would stop (and wake your unit up of course).

Maybe Patrol should do the same thing? Or auto-attack detected units?
 
How about adding some code to Sentry. When you click Sentry, all remaining movement points are expended one at a time as multiple checks against See_Invisible. If a unit is detected, the Sentry function would stop (and wake your unit up of course).
That would go against the way Sentry, Skip Turn, and Fortify/Sleep (and wake) work in Civ4. These orders are entirely revocable. One of the really frustrating things about earlier incarnations of Civ is that once you ordered a unit to forfeit the remainder of its movement for the turn (via Skip Turn or Fortify), if you changed your mind and tried to reactivate it, the movement was still gone.

Now we have a saner approach. The movement isn't actually forfeited until you end the turn.

I would advocate a separate order, most likely using the Binoculars mission button air units use for Recon, which explicitly converts movement points into increased visibility. That mission consumes the air units' sole MP for the turn, so re-using that button for other units doesn't introduce any confusion. Everyone knows it produces a temporary visibility improvement.

In fact, this could go beyond attempting to see invisible units; it might also temporarily grant the unit +1 visibility range if it had not used any movement on the turn (just like spy missions, the unit would have to begin its turn in the tile where this mission is performed).
 
If so, your code should convert negative values to 0 and values greater than 32,000 to 32,000 internally. Never allow an invalid value input to your system to stay invalid.

What you are referring to applied to the older versions, and really wasn't an issue. Putting in values less than zero or greater than 32,000 wouldn't have caused a crash, nor any other serious problem. They just wouldn't have resulted in the expected probability, just as your suggestion would not result in the expected probability either. Doing what you suggested would have complicated the code for no gain in reliability whatsoever. I would have to check my old code carefully, but in fact the behavior in case of invalid inputs might have even been exactly the same as what you suggested.

Anyway, this doesn't apply in the same way to the newer B versions that I now have up. I am now using the game's built-in random number generator, and I am not sure what are the limits for the integers it will accept, nor how it would behave if the inputs were out bounds. The game's internal functions just aren't documented.

In the older versions I used the C random number generator, which I knew was limited to 32,000.
 
01 1
02 2
03 3
04 5
05 8
06 13
07 21
08 34
09 55
10 89
11 144
12 233
13 377
14 610
15 987 = 100% ?

PHP:
01	1	0,101
02	2	0,203
03	3	0,304
04	5	0,507
05	8	0,811
06	13	1,317
07	21	2,128
08	34	3,445
09	55	5,572
10	89	9,017
11	144	14,59
12	233	23,607
13	377	38,197
14	610	61,803
15	987	100
 
I really want this modcomp in my mod but it bothers me the way the random invisiblity chances are displayed in civilopedia. Any chance you could fix that?
 
I really want this modcomp in my mod but it bothers me the way the random invisiblity chances are displayed in civilopedia. Any chance you could fix that?

It really doesn't bother me that much, but I am a bit of a perfectionist and so would like to fix it. However, I don't know what exactly is causing the issue and so don't know how hard this would be to fix. So I can't really guarantee anything. All I can say is that I may get around to it.
 
In CvGameTextMgr.cpp:

Code:
	for (iI = 0; iI < GC.getUnitInfo(eUnit).get[B]Num[/B]SeeInvisibleTypes(); ++iI)
	{
		if (bCivilopediaText || (GC.getUnitInfo(eUnit).getSeeInvisibleType(iI) != GC.getUnitInfo(eUnit).getInvisibleType()))
		{
			szBuffer.append(NEWLINE);
			szBuffer.append(gDLL->getText("TXT_KEY_UNIT_SEE_INVISIBLE", GC.getInvisibleInfo((InvisibleTypes) GC.getUnitInfo(eUnit).getSeeInvisibleType(iI)).getTextKeyWide()));
		}
	}
Would removing the bolded part fix this issue, I wonder...
 
I think you should consider expanding this mod a little by including promotions, that make it more likely for units to spot subs. Would you be interested in that? :) Or would I need to do the hard work myself? :D
 
I did, but the pedia didn't work after that. I also tried three other changes, and they didn't work either. I wasn't too focusd, though, and I'm convinced it can be fixed.
 
This works:

Code:
if (GC.getUnitInfo(eUnit).getNumSeeInvisibleTypes() > 0)
	{
	szBuffer.append(NEWLINE);
	szBuffer.append(gDLL->getText("TXT_KEY_UNIT_SEE_INVISIBLE", GC.getInvisibleInfo((InvisibleTypes) GC.getUnitInfo(eUnit).getSeeInvisibleType(iI)).getTextKeyWide()));
	}


Comment out the section four posts above this one, and put this section instead.
 
Oh, sorry, I forgot about this one. I don't have the mod as stand-alone, it's a part of my Merged Mod. But the code for this mod is actually very small, and the Civilopedia fix is also pretty tiny. You should be able to grab the code you need from the first post, and then fix the pedia the way I described above.
 
Back
Top Bottom