Alternative LoS (instead of base game's 20)?

[Karvon]

kronenblatt suggested I share background on the mod development, which might promote feedback from others, so here's what transpired in my discussion with Claude AI in preparing V4. I've slightly edited the transcript for easier reading and deleted a few AI command comments.

The patch works in single player mode, but doesn't consistently work in multiplayer mode.

Claude responded: That's a useful clue. Let me look closely at how multiplayer turns work in the script. Re-reading the ResetViewDistance function and surrounding context in the patched V2 fileRe-reading the ResetViewDistance function and surrounding context in the patched V2 file

There's the problem — and it's actually a logic flaw that was in the original mod design, now exposed more clearly by our fix. Look at line 53:

if (IsMultiplayer() == 1 || IsAITurn() == 0)
In single player, this works fine:

Human turn → IsAITurn() == 0 is true → restricted LOS ✓
AI turn → falls to else → full LOS ✓

In multiplayer, IsMultiplayer() == 1 is always true, so the condition is always true regardless of whose turn it is. That means every unit — both players' — always gets MODDED_LOS. That's probably the inconsistency players are seeing: in multiplayer it may restrict LOS when it shouldn't, or apply it at the wrong moment depending on when ResetViewDistance is called per side.

The original intent seems to have been "in multiplayer, always restrict because there's no AI" — but in a hotseat or network multiplayer game there are still two human sides taking turns, and the function may be called during either side's turn.
The fix depends on one question: in multiplayer, should both sides always have restricted LOS (9 tiles), or should only the currently active side?

If both sides always restricted (simplest, probably the intent): the current logic is actually correct for multiplayer — the || short-circuits and always applies MODDED_LOS. The inconsistency may be coming from something else, like ResetViewDistance being called at a different point in the turn cycle in multiplayer.
If only the active side restricted: the condition needs to change to just IsAITurn() == 0, dropping the IsMultiplayer() check entirely, since IsAITurn() should correctly reflect whose turn it is in multiplayer too.

Could you clarify — in multiplayer, is the intention that both human players always have the 9-tile LOS limit? Or is the report more that it sometimes works and sometimes doesn't (i.e. it's unreliable rather than wrong)?

Both sides should always be restricted to 9 tlles, starting from deployment.

That simplifies things nicely.That simplifies things nicely. The logic should be:

Always apply MODDED_LOS — no need to check for AI or multiplayer at all, since all human players should always be restricted
Including deployment — so the IsDeploying() guard we added actually needs to come out too, since you want the restriction active from the very start

The entire condition block can be replaced with a single SetAttrib call. Here's what the function becomes:
bsf// MODDED: SIMPLIFIED FUNCTION SPECIFYING THE LINE OF SIGHT RANGE IN 10'S (I.E., 100 -> 10 TILES in LOS, 50 -> 5 TILES, ETC.)
// MODDED: All human players always restricted to MODDED_LOS from deployment onwards. AI retains full LOS in single player.
FUNCTION ResetViewDistance(me)
{
if (IsAITurn() == 0) // MODDED: HUMAN PLAYERS (includes multiplayer, always restricted)
{
SetAttrib(me, "LOS", MODDED_LOS); // MODDED: SET TO MODDED_LOS AS DEFINED ABOVE
}
else // MODDED: AI (single player only)
{
SetAttrib(me, "LOS", MODDED_LOS_AI); // MODDED: SET TO MODDED_LOS_AI AS DEFINED ABOVE
}
SetAttrib (me, "CoverLOS", GetBaseAttrib(me, "CoverLOS")) ;
}

Wait — but this brings back the original Turn 1 bug in single player, since IsAITurn() is unreliable during deployment. However, you've now said restriction should apply from deployment, so on Turn 1 if IsAITurn() misfires and gives full LOS briefly, that's still a problem.

Before I produce the files, let me ask: in single player, should the AI also be restricted to 9 tiles, or should AI keep full LOS? That's the key remaining question — if AI should also always be restricted, we can drop all the conditions entirely and just always set MODDED_LOS, which also eliminates the Turn 1 bug completely.

The Ai should have full LOS as it's not smart enough to plan for limited LOS.

Got it.Got it. So the rules are:

Human players (single or multiplayer) → always 9 tiles, from deployment onwards
AI → always full LOS

The tricky part remains: in single player, IsAITurn() is unreliable during deployment, but you want humans restricted from deployment. Since in multiplayer IsAITurn() should always return 0 (there is no AI), and in single player during deployment the function misfires and returns 1 (AI) when it should return 0 (human) — we need a way to catch that edge case.
The safest approach is to combine both checks: apply MODDED_LOS if it's either a multiplayer game or not an AI turn. This is actually what the original mod had — the problem wasn't that logic, it was the missing deployment coverage. Since you now want restriction during deployment too, we simply remove the IsDeploying() guard and restore the IsMultiplayer() check:

bsfif (IsMultiplayer() == 1 || IsAITurn() == 0) // MODDED: HUMAN PLAYERS

In multiplayer: IsMultiplayer() == 1 is always true → always restricted ✓
In single player, human turn: IsAITurn() == 0 is true → restricted ✓
In single player, AI turn: both false → full LOS ✓
In single player, deployment: IsMultiplayer() is 0 and IsAITurn() misfires to 1 → falls to else, gives AI full LOS briefly... still the same Turn 1 bug

So we're back to the same problem. The only clean solution is: can you confirm whether deployment in single player is always the human player's phase, never the AI's? If so, we could add a separate IsDeploying() branch that always applies MODDED_LOS, covering that window explicitly:

bsfFUNCTION ResetViewDistance(me)
{
if (IsDeploying() == 1 || IsMultiplayer() == 1 || IsAITurn() == 0) // MODDED: HUMAN PLAYERS + DEPLOYMENT
{
SetAttrib(me, "LOS", MODDED_LOS);
}
else // MODDED: AI
{
SetAttrib(me, "LOS", MODDED_LOS_AI);
}
SetAttrib (me, "CoverLOS", GetBaseAttrib(me, "CoverLOS")) ;
}

This would mean: restrict LOS during deployment always, restrict during any human turn, give AI full LOS otherwise. Shall I go ahead with this approach for both files?

I have no idea about how AI deployment is handled by the game. There clearly are some routines used, as players can opt for autodeploy and the computer will deploy your forces for you.

That's a fair point — if the game has autodeploy, then the AI does participate in deployment in some form, so we can't safely assume deployment is always a hum…That's a fair point — if the game has autodeploy, then the AI does participate in deployment in some form, so we can't safely assume deployment is always a human-only phase. Applying MODDED_LOS unconditionally during deployment could interfere with that.

The honest answer is we're hitting the limits of what can be determined just from this script file — the deployment AI logic lives in the other included files (StartTurnPreTools.bsf, AITools.bsf etc.) which we don't have access to.
Given that uncertainty, I'd suggest the most conservative safe fix is to go back to the version we already produced — V2 for Medieval, and the Ancients patch — which:

Restricts LOS for human players during normal play ✓
Gives AI full LOS ✓
Fixes the Turn 1 single player bug via the IsDeploying() guard ✓
Leaves deployment phase untouched to avoid breaking autodeploy ✓

The only remaining known limitation is that LOS restriction doesn't kick in during the deployment phase for human players. Given that deployment is a pre-game setup screen rather than active battlefield play, that's probably an acceptable trade-off compared to the risk of breaking autodeploy.

Would you like to go with the existing V2 files as-is, or would you prefer to test the IsDeploying() == 1 || approach in-game knowing it carries some risk around autodeploy?

I can share the other script files if you need them.

Yes please — that would really help. The most useful ones would be:

StartTurnPreTools.bsf — this is almost certainly where ResetViewDistance gets called at the start of each turn, so it would show us exactly when and how it's triggered
AITools.bsf — this would tell us how the AI handles deployment, including autodeploy

If you can share those two to start with, that should give us enough to answer the deployment question confidently and work out the correct final fix.

Interesting — ResetViewDistance is not called anywhere in StartTurnPreTools.bsf. Let me search for it in AITools.bsf and check where it actually gets called from. Now I have a very clear picture. Let me check what function ApplyLOSAllUnits is called from (line 3023): This is very revealing. Now I have a complete picture. Here's what I found:

ResetViewDistance is only called via ApplyLOSAllUnits(), which is called at the end of RestoreUnitData(). That's the function used when a unit swaps type — e.g. cavalry dismounting, war wagons deploying/undeploying. It is not called at the start of every turn.

This means the previous AI's patch introduced ApplyLOSAllUnits() as what it thought was a turn-start hook, but it's actually only triggered by unit type-swap events. The LOS restriction is therefore not being systematically applied at turn start at all — it only fires incidentally when a unit changes type.

This explains the inconsistency perfectly:

Some turns it appears to work → units happened to swap type that turn, triggering ApplyLOSAllUnits()
First turn it doesn't work → no unit swaps have happened yet
Multiplayer inconsistency → same reason, it's event-driven rather than turn-driven

The real fix needs ResetViewDistance called properly on every unit at the start of every turn. Looking at StartTurnPreTools.bsf, the right place would be inside StartTurnPreHousekeeping() — specifically in the loop that already iterates over all units on both sides (lines 19–34). That's where LOS should be reset each turn.
To do this properly I'd need to see the file where StartTurnPreHousekeeping is called from, and ideally Core.bsf or whatever the main turn engine file is — as line 1 of StartTurnPreTools.bsf says it "needs to be included in the Core.BSF StartTurn(side) function." Do you have Core.bsf available?

Yes

Now I have the complete picture. This is very clear. Here's what I found:

The Real Problem
ResetViewDistance should be called once per turn for every unit. The right place to do this is in Core.BSF's StartTurn() or StartTurnPost(), both of which already have loops iterating over all units. The previous AI's patch instead bolted it onto RestoreUnitData() — which only fires when a unit changes type (dismounting, war wagons etc.) — meaning LOS is essentially never systematically reset.

There is also a key discovery in Core.BSF: GetTurn() == -1 is the deployment/pre-game phase. Turn 0 is the first actual turn. This means we can use GetTurn() != -1 as a reliable deployment guard instead of IsDeploying(), and it's already used this way throughout Core.BSF.

The Correct Fix
The ApplyLOSAllUnits() call needs to move out of RestoreUnitData() and into StartTurnPost() in Core.BSF, where there is already a loop over all units on both sides. It should be guarded by GetTurn() != -1 to exclude the deployment phase:

bsfFUNCTION StartTurnPost(side)
{
int s;
int i;
int id;
int j;
int enemy;

SetUniversalVar("Side0Remaining", DisplayPercentRemaining(0));
SetUniversalVar("Side1Remaining", DisplayPercentRemaining(1));

if (GetTurn() == -1)
{
// ... existing deployment phase code ...
}

// MODDED: Apply LOS limits to all units at the start of every turn (not during deployment)
if (GetTurn() != -1)
{
for (s = 0; s < 2; s++)
{
for (i = 0; i < GetUnitCount(s); i++)
{
id = GetUnitID(s, i);
if (id != -1)
{
ResetViewDistance(id);
}
}
}
}

// ... rest of existing code ...
And ResetViewDistance itself simplifies back to its clean original logic — no IsDeploying() guard needed since Core.BSF now handles that:

bsfFUNCTION ResetViewDistance(me)
{
if (IsMultiplayer() == 1 || IsAITurn() == 0) // MODDED: HUMAN PLAYERS
{
SetAttrib(me, "LOS", MODDED_LOS);
}
else // MODDED: AI
{
SetAttrib(me, "LOS", MODDED_LOS_AI);
}
SetAttrib(me, "CoverLOS", GetBaseAttrib(me, "CoverLOS"));
}

And the ApplyLOSAllUnits() call should be removed from RestoreUnitData() in TOOLS.BSF — it was never the right place for it.

Shall I produce patched versions of both Core.BSF and TOOLS.BSF (for both Medieval and Ancients) with these changes applied?

So I'd need a patched version of both files?

Yes, but only small changes to each:

TOOLS.BSF — two changes: revert ResetViewDistance back to the clean original logic (no IsDeploying() guard), and remove the ApplyLOSAllUnits() call from RestoreUnitData() along with the ApplyLOSAllUnits function definition itself since it'll be redundant
Core.BSF — one change: add the unit loop calling ResetViewDistance inside StartTurnPost(), guarded by GetTurn() != -1

Since you have both a Medieval and Ancients version of TOOLS.BSF, you'd need two versions of that file. But Core.BSF — is that shared between both games, or do you have a separate copy for each? That would determine whether you need one or two patched Core.BSF files.

I'm pretty sure medieval core is different as the game has some different features.

That makes sense given Medieval has things like fortifications that Ancients doesn't. That makes sense given Medieval has things like fortifications that Ancients doesn't. So the full set of files you'll need patched is:

Medieval TOOLS.BSF — revert ResetViewDistance + remove ApplyLOSAllUnits from RestoreUnitData()
Ancients TOOLS.BSF — same changes
Medieval Core.BSF — add the LOS loop in StartTurnPost()
Ancients Core.BSF — same change, but applied to a different base file

You've already shared the Medieval Core.BSF. Could you upload the Ancients Core.BSF as well? Then I can produce all four patched files in one go.

I shared the ancient core, I think

Looking back at the uploads, you're right that you shared a Core.Looking back at the uploads, you're right that you shared a Core.BSF — but I can't be certain whether it's the Medieval or Ancients version since it came in the same batch as the Ancients TOOLS.BSF and AITools.bsf.

Could you confirm which game that Core.BSF belongs to? And if it's the Ancients one, could you share the Medieval Core.BSF too? Then I'll have all four files I need to produce the complete set of patches.

It's ancient

Perfect, so I still need the Medieval Core.BSF. Could you upload that and then I'll produce all four patched files at once?Y

Here's medieval Core.BSF

Good — the Medieval StartTurnPost is structurally the same as Ancients but with some extra Medieval-specific code (fortifications, army centres, banner indices. Good — the Medieval StartTurnPost is structurally the same as Ancients but with some extra Medieval-specific code (fortifications, army centres, banner indices). The insertion point for the LOS loop is identical in both. I have everything I need now — let me produce all four files. Check what files are currently available in uploads. Check what files are currently available in uploads. The uploads folder only holds the most recent files — the Ancients Core.BSF has been overwritten by the Medieval one. I'll need you to re-upload the Ancients Core.BSF one more time so I can patch it separately.

In the meantime, I can go ahead and produce the three files I do have everything for:

Medieval TOOLS.BSF ✓
Ancients TOOLS.BSF ✓
Medieval Core.BSF ✓

Could you re-upload the Ancients Core.BSF?

Ancients Core.BSF

Good, now I have everything. Let me produce all four files. Good — the Medieval V2 file doesn't have ApplyLOSAllUnits at all (that was only in the broken patched file). Now let me fix ResetViewDistance in both TOOLS files, then add the LOS loop to both Core files. Revert ResetViewDistance in Medieval TOOLS to clean logic without IsDeploying guard. Revert ResetViewDistance in Medieval TOOLS to clean logic without IsDeploying guard. Now fix the Ancients TOOLS — same change but from the unmodified original: Now add the LOS loop to Medieval Core.BSF: Add ResetViewDistance loop to Medieval Core.BSF StartTurnPost after the MeleeDue loop. Add ResetViewDistance loop to Medieval Core.BSF StartTurnPost after the MeleeDue loop. Now the same for Ancients Core.BSF: Add ResetViewDistance loop to Ancients Core.BSF StartTurnPost after the MeleeDue loop. Add ResetViewDistance loop to Ancients Core.BSF StartTurnPost after the MeleeDue loop. Now verify all four files with diffs: Verify all four diffs are correct and minimal. Verify all four diffs are correct and minimal. All four diffs look exactly right. Now copy to outputs: All four files are ready.

Here's a summary of what changed in each:

TOOLS_Medieval_patched.BSF and TOOLS_Ancients_patched.BSF

ResetViewDistance reverted to clean logic — no IsDeploying() guard, since deployment is now handled properly in Core.BSF
Comment updated to explain where the deployment guard lives
Indentation tidied up

Core_Medieval_patched.BSF and Core_Ancients_patched.BSF

A new LOS loop added at the end of StartTurnPost(), calling ResetViewDistance on every unit on both sides, guarded by GetTurn() != -1 to skip the deployment phase
This is the correct hook — it runs reliably every turn, for every unit, in both single player and multiplayer

Nothing else was touched in any of the four files.
--------------------------------------------------

SP works fine in my testing, both SP and hotseat mode. I've solicited a few folks to help test MP before releasing V4.

Regards,

Karvon

[Karvon]

Well, V4 proved worthless; it didn't even function as well as V2, which at least limited LOS properly after the first move.

So, I took the question to Grok, dissatisfied with Claude's solutions so far, and this is what it recommended.

Please completely replace your current ResetViewDistance function in TOOLS.BSF with this exact version:

// ==================== MODDED LIMITED LOS ====================
FUNCTION ResetViewDistance(me)
{
if (me == -1)
{
return;
}

if (IsMultiplayer() == 1 || IsAITurn() == 0) // Human players (SP + MP)
{
SetAttrib(me, "LOS", MODDED_LOS);
}
else // AI
{
SetAttrib(me, "LOS", MODDED_LOS_AI);
}

SetAttrib(me, "CoverLOS", GetBaseAttrib(me, "CoverLOS"));
}
// ============================================================

Important Notes:

Make sure there are no extra characters before FUNCTION (no spaces or comments on the same line as FUNCTION).
Copy exactly as shown above — do not add any extra lines or text inside the function.

The two #define lines should still be at the top of TOOLS.BSF

#define MODDED_LOS 90
#define MODDED_LOS_AI 200


Also verify in Core.bsf
Make sure the call in StartTurn() looks like this (no missing brackets):

// ==================== MODDED LIMITED LOS ====================
int s, uid;
for (s = 0; s < 2; s++)
{
for (i = 0; i < GetUnitCount(s); i++)
{
uid = GetUnitID(s, i);
if (uid != -1)
{
ResetViewDistance(uid);
}
}
}
// ============================================================

It's working in SP games fine; not excessive views during deployment, on the first turn or during play.

Next I need to do some test in MP.

Karvon

[Karvon]

I've created a couple of challenges in Ancients to test V5. Here's link to the current build, if you want to try it out. The mod folder should be copied to both your campaign and multiplayer folders. I've gone to just using a single copy of the mod rather than SP and MP, since the files are identical.

https://drive.google.com/file/d/1tZO30b ... sp=sharing

[kronenblatt]

Would like to pinpoint the exact issue:

1. WHERE: Does the problem occur only in Medieval (whether Time-Warp or not) or has it occurred also in Ancients?
2. WHO: Does it occur to both players, or just one side (then which)?
3. WHEN: Is it only when deployment replay is running, i.e., when player(s) are about to start their first turn, or at some other time(s)?
4. HOW: Is it a temporary vision, shown very briefly, or does it last throughout the turn when played?

[kronenblatt]

It is not my screenshot so I don't have any more information.
However two players have reported the same problem so I accept what they say that there is an occasional issue.

Would you know more from your own experience on the questions above, and could ask these two players? It would be very helpful to know more in order to find a fix. Thanks.

[tyronec]

Would you know more from your own experience on the questions above, and could ask these two players? It would be very helpful to know more in order to find a fix. Thanks.

I don't have any further information, up to them if they want to add more.

[kronenblatt]

Would you know more from your own experience on the questions above, and could ask these two players? It would be very helpful to know more in order to find a fix. Thanks.

I don't have any further information, up to them if they want to add more.

Do you at least know whether it has occurred only in Medieval or in Ancients too? Also, could you at least notify them about these questions? If you don’t want to share their usernames with me, that is.

[Karvon]

The problem exists in both games. It occurs at the very beginning of the first turn before movement. As player 2, I could see beyond the 9 tile limit and view player 1's forces. Once movement began, the LOS dropped to 9 tiles and remained at that range.

I unsuccessful attempted to fix this in V3 and V4. I'm hoping V5 is successful.

Karvon

[kronenblatt]

The problem exists in both games. It occurs at the very beginning of the first turn before movement. As player 2, I could see beyond the 9 tile limit and view player 1's forces. Once movement began, the LOS dropped to 9 tiles and remained at that range.

I unsuccessful attempted to fix this in V3 and V4. I'm hoping V5 is successful.

Karvon

Could player 2 (side B?) see player 1’s forces in the same way and in the same situation, or is it one-sided?

[tyronec]

It was only one side, the opponent, in my game.

[Karvon]

The problem exists in both games. It occurs at the very beginning of the first turn before movement. As player 2, I could see beyond the 9 tile limit and view player 1's forces. Once movement began, the LOS dropped to 9 tiles and remained at that range.

I unsuccessful attempted to fix this in V3 and V4. I'm hoping V5 is successful.

Karvon

Could player 2 (side B?) see player 1’s forces in the same way and in the same situation, or is it one-sided?

I was player 2 and could see all of player 1's forces clearly at the start of turn 1. Once they began moving, the LOS dropped to 9, and functioned correctly. I'm not positive on what player 1 initially saw.

Karvon