How do we want Monolith's to work for players and VCAI?

I’m currently doing some research on pathfinding and AI improvements and one of my goals it’s to let player use shifted (with different X/Y) Subterranean Gates and Monolith’s include one-way (as toggable option). I’m always also want to implement Monolith support for AI, at least for bidirectional. So here is few interesting questions about that:

1 - Do we really want two-way Monolith’s to always be random? By default they don’t use movement points at all so I think like we need of course leave randomness as default behaviour, but also add option for client to choose what Monolith teleport when player already visited it once and just need to go to certain point. So I think it’s pointless to show 5 teleportations to the player just to get to certain point.

2 - Should AI at this point use things like one-way Monolith’s at all? Just add it as possible low-priority task?

3 - Monolith’s also bring question about how Fog of War working for AI. Is it currently break AI ability to move until explored? Should AI “remember” status on Monolith’s forever like it’s happen with Subterranean Gates? Thoughts?

Experimental code will be available there: … athfinding … perimentAI
Those are just my personal branches and code here not going upstream without cleaning up.

The randomness makes them unexpected for players when playing a map for the first time, which is good for gameplay. I agree however than once monoliths are discovered, it’s a waste of time.

They are common feature on some custom maps.

AI considers Subterranean Gates as prioritized exploration point, but doesn’t know what is on the other side.

Most certainly it should. This is actually the issue - how to handle discovering multiple Monoliths over time.

Yeah I agree, but for the AI there is little problem from what I see: when AI discover two-way Monolith it’s will want to make sure that that it’s know all possible entries. And there is dilemma:
[ul]]AI will teleport like crazy many many times to make sure it’s know all of them./:m]
]Or we need to let it cheat just a bit. E.g use special pseudo-random mode where it’s can see all entry points in NN attempts with 100% guarantee./:m][/ul]

So I think I’ll try implement special option to move to certain location when player already see monolith.

Yeah it’s true, but I worry that it’s may cause weird logical problem on some other maps where I may unable to solve them properly…

Sorry, but it’s not what I mean. It’s more like question about Cover of Darkness. As far as I understand currently AI have to explore it from scratch as it’s fully depend on pathfinding and without it he’s heroes can’t even back to base.

I think there should be few different conditions like:
1 - As I stated above bidirectional isn’t problem at all as AI may visit all Monoliths of same subtype fast.
2 - It’s will require more coding for whirlpools as we don’t want to lose army here. Though there actually need to be special code that make hero only use it if it’s explore or have other goal that not require lot of stacks.
3 - If AI open like NN% of map it’s may decide like it’s know about all Monolith’s.
4 - For the one-directional I have no idea to be fair. I’ll have mess with VCAI a lot more before I can suggest solution. Though I think I can at least make AI use them in case it’s know that there is any other way-back available. E.g to avoid many heroes on other side of map.

PS: Though at moment main problem I’m trying to solve on client-side is ability to find paths via monolith/gate for the hero that standing on them.[/list]

If AI teleport to monolith with guards, it will go to battle, as I remember, right?
If it will go lets say twenty times to monolith, it will encounter several guards. Guards are placed by RMG, AI can calculate fight value of possible guards. I propose that: if AI army is more or equal to preached fight value of guards, AI will go to monolith and teleport. Than if there were guards and AI army went down under fight value of possible guards, AI will stop teleporting. If army is still high, AI will teleport several times to see that all monoliths are visited. This value of possible teleports can be calculated estimately. Is there known possibility chance to visit location by teleports? Or for example, for XL map this count of test teleports can be set to 10…20 counts.

PS Cheating is all decided if AI wil receive full map exploration on start :sunglasses:
I propose to give AI full exploration on medium…hardest game difficulty.

Actually it’s shouldn’t go into battle according to H3 game mechanics.
Fact that it’s happen is VCMI bug: #1990

I’m not really say about real cheating, but to give AI equal chanced with human player.
Basically we humans have memory and we may want to have option to give AI some partial information about the map or at least make sure it’s not completely lose it after some “Cover of Darkness” activated.

Here is small example:
[ul]]AI have two-way Monolith teleporter just about right next to it’s town, let’s say in 10 tiles.
Many maps designed on like that actually./
]Also there is “Cover of Darkness” thingly somewhere around./:m]
]This AI player take huge army and go through it to make something it want to do./:m]
]Someone else come from this teleporter, take his town and activate Cover of Darkness./:m]
]Now AI likely won’t even able to find path to his town via teleporter and possible may try to use longer and less effective path./:m][/ul]
Human player in this case will definitely able to go back to that town via teleporter.
So here is question what information AI have to remember and what is not.

PS: Also I’m not 100% sure about that as I didn’t yet learn how exactly VCAI works in every situation, but from what I seen in pathfinding code it’s will be exactly this situation.

Well yes, AI can’t handle Cover of Darkness (or Veil of Darkness, it already caused a lot of bugs). On the other hand, Cover of Darkness is so rare this should not be urgent feature.

AI should ignore Darkness Cover. If AI explored that place before, Darkness should not erase his knowing of objects or paths or etc. He should only not see current state or position of enemy heroes or state of castles.

I suppose it’s tricky part as it’s have to be implemented in the engine.

Unless this is one-way monolith. In this case battle will start. Learned this hard way after blocking exit with 1-pikeman hero :frowning:

True. But usually this only results in 5-10 re-enters till you’re sure that there are no uncovered exits = wasting time on mashing space bar without any benefits to gameplay.

I liked how this was implemented in H4 - in case of multiple exists you can choose your destination via a dialog that displays exits on a map (including exits behind FoW) with some random name for flavor.

Implementing something like this in VCMI may be a good idea - if player steps on a two-way monolith, show Town Portal-like dialog (possibly with map) to select exit. But also allow for pathfinder to lay path through it and teleport player to desired exit without such dialog.

One-way monoliths are more tricky - you can never be sure that you will exit where you want unless you’ve explored entire map. And neither can AI. Easiest way would be to let AI know of monoliths with just one exit. Or just use “enter and pray” approach for poor AI :stuck_out_tongue:

Ohh Ivan, welcome back :slight_smile:

Thanks. I’m not exactly “back” but definitely back enough for some spamming on forums :slight_smile:

I doubt that there will be any coding from me soon so I guess I’ll just try to stay alive on forums/github.

Actually I was talking about different behaviour. Currently in VCMI there is a bug that player can’t go back via Monolith/Gates if exit is guarded. In H3 you can always attempt to visit Monolith/Gates even exit one without going into battle.

Also as far as I know behaviour you explaining is when there another hero going inside. In this case battle may be triggered in any Monolith/Gates according to H3 behaviour.

Let’s say fair I don’t think that additional dialog windows is good idea unless there is really a lot entry points like >4 which is rare.

Otherwise I think it’s better to just switch monolith into non-random mode in case player know all exits. I use keyboard quite a lot while playing and pressing space bar few times looks easier.

Also idea about the option for direct movement. Any thoughts how this should be implemented? Currently there no option to pass extra arguments to onHeroVisit and I don’t think it’s good idea to access hero path data from code that handle object visits is right way to do that.

Any idea what’s would be best way to request hero teleportation to specific tile?

Creating dialog just for monolith - yeah. But it may be also used as an improved Town Portal dialog - minimap is definitely needed here once you have more than 3-4 towns.
Or just reuse current one and generate some flavor names + general direction, e.g. “Monolith in Valley of Flowers, North-East”

Of course this would be really optional - even simple pathfinding through monoliths would be great.

When hero visits monolith - send query with list of possible exits. Such query does not have to be visual unless you’ll implement dialog for it.

When client receives query he will
a) if hero has path that goes through this monolith -> send reply with desired exit
b) if player path ends on monolith -> send random answer to server.

Will try to do that this way. Thank you.

Sounds good, but this way AI might never discover other exits of multiple Monoliths :-/

I think we’ll need to teach AI go into monolith and find every exit.
After all it’s nothing more than subterranean gates with multiple exits. I looked into that and it’s really not hard; at least much easier than cheat-free implementation of movement.

At moment my idea is create unified functionality for all kinds of teleporters so they all work via same interface. @AVS suggested other nice idea so instead of CGTeleport there will be CGMonolith and two of it’s heirs: CGSubterraneanGate and CGWhirlpool.

Though I still try to find good solution how to unify functionality for them all…

PS: Also I’m decide to drop fly/water walk for now and finish clean teleporters implementation: … athfinding
My roadmap for this currently:[ol]]Done reimplementation of teleporters handlers./:m]
]Cleanup pathfinding code that currently depend on this handler./:m]
]Implement movement via teleports using query as Ivan suggested./:m]
]Pull request for teleport functionality.
At this point AI should be able to use them all, but only if already explored exits.
]After it’s merged I’ll start to reimplement movement for cheat-free fly/stopping./:m]
]Implement fly and water walk./:m]
]Work on option of pathfinding via whirlpools./:m]
]Then I’ll try to rewrite AI bits to let it “understand” teleporters better./:m][/ol]
I’m possible end up splitting those into separate pull requests of course as it’s all more tricky than I originally think. :blush:

Why? If server will send all possible exits (including those behind FoW) then AI will know all exits as soon as he visits first one.

After this he can travel to each exit to reveal FoW.

Good idea, although not trivial.

  • separate classes for one-way & two-way monoliths (AI handling may be quite different for them)

  • method to list possible exits for pathfinder (empty for whirpool/one-way)

  • method to list exits + teleport mode flags (one-way/two-way + random/selectable)
    oh - and while for two-way/subterra gates we can list exits behind FoW for other teleport only visible exits should be listed.

Not sure which approach is better though…

Not sure if this is a good idea due to whirpool randomness - unlike monolith whirpools have cost attached to them so selectable exits are not an option. Because of this cost (MP + army) player or AI may want to take a longer route without use of whirpools.

I think problem is AI will only see monoliths, but won’t going to use them as everything around them inside FoW.

I think currently AI not going to go into Monoliths without a reason (goal).
So at least there have to be special code to handle that.

My idea is completely different. I wanted to have “channels” each with one vector of entry points and another for exit points. So it’s make two things possible:
[ul]]Mixed channels is possible. E.g several bidirectional exits/entries and one exit-only./:m]
]It’s easy to find out what type we checking just by checking intersection between vectors./:m]
]Pathfinding code will able to work only with CGMonolith and not it’s heirs./:m][/ul]
Though hardest part is how to map default objects into that system.

We can always make pathfinding via them toggable and automatically enable it if hero have protection bonus or 1 stack with 1 unit only. :wink:

This is actually trivial, use same code which now handles Subterranean Gates.