C2C Combat Mod Option: Hide and Seek

[Toffer90]

Ok... same tile must still suffer from some kind of off math. Will review again looking for how that takes place.

It's not just a problem for the same tile; it's still, as it was, stronger intensity the further away from the observer situation; as I said in SVN thread: nothing really changed as far as I could see.

EDIT: is this situation specifically setup after the latest revision or is this a replay of a previous test? The visible data on plots would be completely flawed from the previous math if its the latter. So make sure its a clean setup of the test. I'll try something on this end but running the math through the variables for that scenario suggests that the same plot should have 12 pts towards the size visibility.

I made a clean new game with rev.8867.

Time to test 8870 then.

 

[Toffer90]

Case from 8870:
My units who are sharing a tile:

• Unit 1: 11 visibility & -1 Range
• Unit 2: 10 Visibility & 0 Range

Target have 7 invisibility.

-My units can see the Target two tiles ahead (1 empty tile between them).
-When they get closer the target turns invisible.

┼ There are no other forms of invisibility involved in this scenario.
Something is seriously fracked up.

Edit:
A Target of 5 invisibility can get closer without turning invisible; not sure what would happen if he were to share the tile with the observers though.

 

[Thunderbrd]

I'll be setting up a simple test to confirm the math and see what's taking place. I KNOW I've fixed the math where it was broken in a few spots but where to fix it further will take deeper analysis.

 

[Thunderbrd]

Looks like negative range was not allowed on a unit in the code. That's a part of the issue of course. Not all of it. How a unit can get closer and still be less visible is still mysterious. Looking into that still. This discovery, however, requires a recompile to check it further. And it also means that negative visibility range has been having absolutely no effect on units in-game (except perhaps to counter other positive range factors.)

EDIT: after fixing that and thorough testing, it definitely appears to all be working as intended. Obviously not everything can get tested in full but if you continue to find issues with clean setups (existing games probably have severe flaws in the plot visibility values from previous bugs) then by all means let me know.

The problem with existing games is that once a visibility value is painted onto a plot, once the unit data is corrected and the math is corrected, it's still not going to resolve the previous incorrect value on the plot so further unit interaction is only going to be interacting with flawed base visibility values on the plot. Very unfortunate and it appeared to me that recalc didn't fix the situation. I may need to figure out how to reset all visibility values on plots as part of the recalc but wow would that take some time for the system to reset all that.

 

[Thunderbrd]

Ok, so another point that's been brought up is that perhaps some invisibility types should have an automatic modifier to all unit visibilities when the unit to be seen is on the same tile.

Do you think it would be appropriate for that to be handled by a tag on the invisibility type itself or should it be handled by a tag on unitcombat? Seems fairly generically applicable so I'm initially thinking of adding it to invisibility type infos.

Note: just to clarify, currently the same plot is handled the same as an adjacent plot in terms of establishing visibility rating.

 

[Toffer90]

Will be testing it thoroughly now.

I don't see the need for that value to be unique for specific units, and agree that it seems appropriate to have it together with the invisibility type declaration.

 

[Thunderbrd]

Actually, unfortunately, not only do I believe it would be less memory consuming to place such a modifier on unitcombats but would also be more appropriate. A flyover scouting is not any more likely to see smaller creatures within the same tile than it is in the adjacent. This points to the effectiveness of such same-tile visibility modifiers as being Motility/mobility unitcombat appropriate.

 

[Toffer90]

Actually, unfortunately, not only do I believe it would be less memory consuming to place such a modifier on unitcombats but would also be more appropriate. A flyover scouting is not any more likely to see smaller creatures within the same tile than it is in the adjacent. This points to the effectiveness of such same-tile visibility modifiers as being Motility/mobility unitcombat appropriate.

Good point, and I thought it would be less memory intensive to have the value defined once and apply the same to all units. You'll do what's best. ^^

 

[Thunderbrd]

The problem amounts to having to open up a whole new tag entry class. Invisibility Infos isn't setup to take new tags - operates only on the basic game tags. Opening up the whole thing for new tags for just one tag seems a little excessive.

 

[Toffer90]

↑↑ Makes sense, I understand the technical perspective of what you're saying.

Note: just to clarify, currently the same plot is handled the same as an adjacent plot in terms of establishing visibility rating.

Just to further clarify: A unit with 12 visibility and -2 Range would have:
A - 10 vis.Intensity (Same Tile), 10 vis.intensity (First adjacent tile) and then 8,6... etc.
OR
B - 12,12,10... etc?

 

[Thunderbrd]

↑↑ Makes sense, I understand the technical perspective of what you're saying.

Just to further clarify: A unit with 12 visibility and -2 Range would have:
A - 10 vis.Intensity (Same Tile), 10 vis.intensity (First adjacent tile) and then 8,6... etc.
OR
B - 12,12,10... etc?

Option B.

Actually... Option C:
12,12,9,6,3,0

Reason being is that there is an automatic reduction of 1 per tile and negative range just increases this reduction increment by the amount of negative range. Therefore -2 would mean an additional -2 to the already existing -1.

And funny thing is after all that rationalizing done previously, I realize only now that Size visibility can only be modified through Size Matters Unitcombats. Lol. So size modifiers for the same tile will be applied equally to all Qualities. For the core, 2 will be the default adjustment there but I'll leave you to rethink it. It's still more than likely that we'll go with your settings if they prove through testing to be appropriate and not overwhelming in any sense.

Also... you'll notice that the Microscopic unitcombat has been added. I hope it works ok to have a 0 pt on the size scale - the first version of size matters wouldn't have been able to handle it and I'm a little worried it still can't for forgotten reasons. So it'll take some observation there.

 

[Toffer90]

Option B.

Actually... Option C:
12,12,9,6,3,0

Reason being is that there is an automatic reduction of 1 per tile and negative range just increases this reduction increment by the amount of negative range. Therefore -2 would mean an additional -2 to the already existing -1.

I know I'm being a pain but is it possible to get it like A?
Intensity 12 for all below.
0 Range: 12,12,11,10...
-1 Range: 11,11,10,9...
-2 Range: 10,10,8,6

And then have it so that the new tag that will affect Same Tile won't affect the 1. adjacent tile? If so, there would be no rush on it, you've done a tremendous job already.

Also... you'll notice that the Microscopic unitcombat has been added. I hope it works ok to have a 0 pt on the size scale - the first version of size matters wouldn't have been able to handle it and I'm a little worried it still can't for forgotten reasons. So it'll take some observation there.

Noticed, hope it will work out of the box.

Here's the latest excel btw.

Spoiler :

 

[Thunderbrd]

I know I'm being a pain but is it possible to get it like A?
0 Range: 12,12,11,10...
-1 Range: 11,11,10,9...
-2 Range: 10,10,8,6

It's possible to get these results from the xml already so no need to force range into odd behavior.

0 Range: 12,12,11,10... is a total of 12 intensity and no range adjustment.
-1 Range: 11,11,10,9... is a total of 11 intensity and no range adjustment.
-2 Range: 10,10,8,6 is a total of 10 intensity with a -1 range adjustment.

Hopefully this will be workable for you. Getting more complicated with the math strikes me as being unnecessary really. The mathematical complexity is already bad enough

And then have it so that the new tag that will affect Same Tile won't affect the 1. adjacent tile? If so, there would be no rush on it, you've done a tremendous job already.

The same tile tag ONLY affects the SAME tile. It specifically does NOT affect the adjacent tile.

Thus an Intensity 12 visibility with a +1 Same Tile would be:
13, 12, 11, 10, 9 etc...

 

[Toffer90]

It's possible to get these results from the xml already so no need to force range into odd behavior.

0 Range: 12,12,11,10... is a total of 12 intensity and no range adjustment.
-1 Range: 11,11,10,9... is a total of 11 intensity and no range adjustment.
-2 Range: 10,10,8,6 is a total of 10 intensity with a -1 range adjustment.

Well, I would like these results without changing intensity. (To be continued &#8595

Hopefully this will be workable for you. Getting more complicated with the math strikes me as being unnecessary really. The mathematical complexity is already bad enough

I can appreciate that aspect. ^^

The same tile tag ONLY affects the SAME tile. It specifically does NOT affect the adjacent tile.

Thus an Intensity 12 visibility with a +1 Same Tile would be:
13, 12, 11, 10, 9 etc...

That is good. (Continuation of &#8593 This will probably let me get close to the results I want.

 

[Thunderbrd]

Hopefully it suits all needs.

 

[Toffer90]

I've adapted the excel to the changed reality.
The change is massive so it's probably less balanced than the last overview. Any help would be appreciated.

Spoiler :

-Group volume now only gives Same tile (ST) visibility and range.

Medium Size:

• Incapable see Forces
• Poor see Squad
• Superior see Solo
• Standard see Party
• Hunters (Exceptional) need hunting sight I & II to see Fine-Solo.
• Divine can see Fine-Solo with only 1 Spot promo
• Battalion-Superior See Fine-Solo when they are in the same tile.

-Countless-Standard-Microscopic can see Solo-Microscopic when sharing a tile. But cannot see much in adjacent tiles. Eradicator could be awarded by a promo, even to microscopic units.
-Divine-Colossal can see Solo-Medium


I will see if I can make an alternative based on the old excel using what I learned from this one; it might not have to be so different to still achieve the same balance.
Edit: Closer to how it was:

Spoiler :

What seems like the more reasonable solution?

 

[Toffer90]

Hide and seek seems to work well now.
One thing I've observed is that units who do not have a combat class with this tag in it: "<bForMilitary>1</bForMilitary>"; cannot see units who has any forms of invisibility type, even when the observer has higher visibility of all types.
At least I think that tag causes it, can't be sure without more testing though. One thing is for certain and that is that something is making my solo wanderer (with +1 range) unable to see any other units. Other units who have less visibility stats can see what the wanderer can't.

Edit: Scratch that, something is still wrong... What I said above had probably nothing to do with it.
Now my stone spearman with 0 range & 10 size visibility (+3 Same Tile Size vis.) cannot see a unit with 6 size invisibility when they are standing side by side (not even when they are sharing the tile); but get this, he can see it from two tiles away. This was a new game on rev.8877

Edit2: After restarting the game and reloading an autosave the stone spearman could not see the same unit two tiles away and could when moved closer. (WAD due to features and terrain modifiers to camouflage invisibility)
There seems to be a caching error here.

 

[Thunderbrd]

I'll have to look into it. You sure that terrain or features aren't playing a role? Could be the way I'm manipulating the vector on the plot data that's causing some skewing later. There's also a lot of calls in the code to the changeVisibility function on a plot and I need to audit those to make sure they're all in the right spots. A single overlapping call can cause some undesireable stuff to take place (and we had something going on with visibility on units before all this so it may be the same bug as before and I just never found it. At one point I thought I had but I discovered I was wrong.) Can unit deaths be causing some of it?

Looks like I'm going to need to build a visibility recalculator as well.

I would have some feedback for your chart but I'm going to be away from the ability to build a chart myself until much later today. I still strongly feel that starting with Battalion/Medium at 0 INvisibility is the way to go, (and while some small amount of negatives above that point would be ok just to counter any other possible modifications may apply, with size, if you don't give them access to a promo that would allow it it should be unnecessary to track anything less than 0. You've got Battalion/Medium starting at 3 invisibility. I'm thinking it would take a blind person to not notice such a force. Or at least it could introduce bad invisibility situations in the game anyhow.

 

[Toffer90]

I'll have to look into it. You sure that terrain or features aren't playing a role?

I'm certain something is fishy as the stone spearman I mentioned moved between the same two tiles in both the case of EDIT1 and EDIT2.

The target was a tribal guardian in a city. Everything seemed good when I moved the HN stone spearman to the adjacent tile of the city and fortified him there (The target became visible when I moved to its adjacent tile). After 10-20 turns I noticed that the tribal guardian had become invisible for no good reason. Thats when I moved the stone spearman 1 tile away, from a hill to a flatland forest (the same way the spearman came from to begin with), and then the tribal guardian became visible again. This is when I saved and quit the game to write the first edit of my last post.
When I loaded the game the tribal guardian had become invisible as he should have been; I then moved my unit 1 tile closer back to the hill that I had originally fortified it in and the guardian became visible again (as expected).

Obviously something has to be wrong, perhaps a bad interaction between the feature/terrain modifiers on mobility foot unitcombat and the tags used for Sise Matters unitcombats?

 

[Thunderbrd]

Initially, it sounded like the guardian might have a buildup promo that was enhancing his invisibility and then he changed what he was using. I checked the promo they get for visibility to ensure that wasn't the case and looked at the code all the way through to make sure it wasn't confusing visibility with invisibility and it looks straight there.

I'll have to look deeper to see what could possibly cause a unit that hasn't moved to adjust its visibility field. Might have something to do with that.

This seems to be the key root issue:

After 10-20 turns I noticed that the tribal guardian had become invisible for no good reason.

Answering 'How would that happen?' becomes the key to solving this I think. Were there any other units of either player around the area? Was your unit or his using a buildup? The AI shouldn't know anything about statuses.

Barring any kind of xml derived possible solution to understanding that behavior, it suggests there's a call to changeVisibility for that unit that exists somewhere that is fouling things up.

The fact that things changed between a save and load is odd as well. That suggests that the visibility values were painted correctly but somewhere along the way it began reading them incorrectly for the isVisible check and then read them correctly again after being reloaded. This means I could be going on a goose chase to look at how the data is stored so maybe I should look at how the isVisible check is handled deeper first.

EDIT: I wonder if this solves it (sorta) or at least explains some of the previous buggy stuff you've dealt with:
I currently have a maximum of 10 visibility hardcoded into the dll. Anything higher than that is ignored. This maximum may also be fouling up other checks and indexes, particularly when a value over 10 exists or is possible to. I think I can reprogram it to not have this problem but it was initially designed this way to keep from bogging the game down. I'll have to figure out a way to cache this properly. Won't be able to address this until much later today.