[MOD] Pathfinding Redux - Pathfinding finally fixed
Avenger
Member Posts: 4
Pathfinding Redux (No Friendly Collision)
Current version: 0.1.5 Preview
Game: Baldur's Gate 1 and 2 EE / EET
Requires: EEex
Current validated environment: BG2EE 2.6.6.0 + EEex 1.2 / BG2EE 2.7 + EEex 1.3 (Windows Tested/Confirmed; Linux Fedora Tested/Confirmed with Wine/Proton)
Status: Solo preview / community testing
Download — Install EEex → download the latest release of Pathfinding Redux → extract the ZIP in your game directory → run "setup-bg-redux-movement.exe"
GitHub
Demo video
────────────────────────────────────────
What is it?
Pathfinding Redux removes friendly collision. This fixes all commonly observed bugs with pathfinding relating to clumping/stuck characters, and the vast majority of "crazy detour" routing of characters because most instances were player ally blocks.
Party members and friendly summons no longer treat other allies as hard movement obstructions. They can simply move through one another, while walls, closed doors, neutral NPCs, enemies and the actual environment continue to block movement normally.
That's basically it.
It sounds like a small change, but in practice it fixes a frankly ridiculous amount of Infinity Engine pathfinding jank.
The mod also adds some light spacing intelligence so removing collision doesn't just result in six people permanently standing on top of each other. Melee characters try to find reasonable positions around enemies, overlapping characters gently separate after arriving, and ordinary travel can prefer cleaner-looking routes when doing so doesn't interfere with movement. Potential downsides are discussed in the "Nerd Talk" section.
The guiding rule is: Traversal is permissive; spacing is intentional.
The practical result
One accidental QoL example I particularly like: Imoen unlocks a container. Jaheira can immediately walk up and open it. You no longer have to wait for Imoen to move because she happens to be standing on the six pixels Jaheira wants.
After playing with the working version for a while, I stopped thinking about pathfinding.
────────────────────────────────────────
Compatibility / Requirements
Currently validated:
This preview uses native x64 hooks, so executable/version compatibility matters substantially more than it does for an ordinary WeiDU tweak.
Other EE games and executable versions should not be assumed compatible until explicitly validated.
Multiplayer is also a separate future milestone.
────────────────────────────────────────
Installation
Individual gameplay features are independently configurable and persistent.
Recommend installing before EET End if possible, though post-installation works on my build.
────────────────────────────────────────
Feedback I'm Especially Looking For
Please report:
If something feels wrong, a save immediately before reproducing it is extremely useful.
Please break it.
────────────────────────────────────────
More Redux Philosophy / Nerd Talk
The steelman against Pathfinding Redux OR: How I learned to stop worrying and love the combat buff
I want to make the strongest reasonable argument against this mod rather than present party pass-through as an obvious improvement with no tradeoffs. Friendly collision is not only pathfinding jank; it also creates real positional constraints, movement friction, and a kind of accidental commitment to where your characters are standing. Removing it makes the game control much better, but it also makes the party genuinely stronger in some situations.
A later polish may include an optional native combat collision component for people who really want the vanilla experience, though I personally prefer combat being non-colliding too.
1. Retreating through your own frontline
Imagine a one-character-wide corridor with five party members lined up behind one another while a fighter enemy attacks the front character. With pass-through, the injured frontliner can simply retreat through the entire formation to safety while the next character takes their place. The enemy cannot follow because the party still physically blocks them. This creates a kind of one-way defensive wall and makes tank rotation much easier.
With attack formations included in this mod, characters try to find "slots" around an enemy rather than naturally standing on top of one another. So even in many narrow geometries, everyone will try to find a reasonable attack position. But if you deliberately micro all your characters onto one spot, you can absolutely abuse this.
My answer: This is probably the strongest legitimate downside. It reduces positional commitment in very narrow spaces. However, it requires restrictive geometry, mostly melee opposition, and often deliberate exploitation. Off the top of my head I'm not sure of an enemy strong enough, combined with a corridor small enough, where this becomes a major practical abuse case. If disengaging becomes too easy, I would rather address disengagement directly than preserve unreliable party pathfinding everywhere just to retain this constraint.
2. Chokepoint stacking / increased melee frontage
If an enemy is standing in a doorway or narrow passage, pass-through can make it easier to compress several melee characters into a very small area and attack the same target. This can potentially increase effective frontage and make some chokepoints less restrictive for the player.
My answer: This already happens to some degree because vanilla formation/path compression can push characters into extremely tight positions. Exact permanent stacking is still undesirable and is one reason smarter attack-position selection and soft destination separation exist. I don't think general movement itself should become obstructive just to solve this edge case.
3. Better pathfinding is itself a combat buff
This is broader than retreating. Vanilla collision imposes a kind of accidental movement tax on the party: characters hesitate, bump, repath, queue behind each other and lose time whenever several party members try to move through the same space.
Removing that means the party can pursue fleeing enemies much more aggressively, maintain better melee uptime, switch targets faster, reposition more reliably in cramped fights, kite and retreat through its own formation more easily, and move through narrow environments as though they are effectively wider. I noticed this immediately while chasing fleeing enemies: several melee characters can now pursue smoothly instead of wasting seconds fighting each other for pathing space.
My answer: I think this should simply be admitted as a real buff. The important question is whether bad friendly pathfinding is a good source of difficulty. I don't think it is.
There is a difference between an enemy successfully escaping because of distance, terrain, speed or tactical positioning and an enemy escaping because three fighters became tangled around each other's circles. If improved movement makes pursuit, kiting or disengagement too strong, those are better treated as separate balance problems. I would rather make movement reliable first and then introduce explicit mechanics that create desirable combat friction.
4. Loss of positional friction
More generally, vanilla friendly collision creates commitment. A fighter who pushes deep into a formation may have difficulty extracting themselves because allies physically occupy the route behind them. Removing collision weakens that commitment and makes party repositioning more forgiving.
My answer: This is the strongest philosophical objection. Some positional friction is legitimate tactics, but vanilla BG does not cleanly distinguish intentional positional commitment from characters shuffling, pushing, rerouting, taking absurd detours or simply getting stuck.
Additionally, through painstaking micro you can often achieve the same result anyway: move Jaheira slightly left → pause → move your character back → sidestep Jaheira right again → resume.
Pathfinding Redux often removes the execution tax rather than enabling something fundamentally impossible.
My preference is therefore: Remove unreliable friendly obstruction first, then deliberately recreate any tactical constraints that prove worth preserving.
I don't want broken movement to serve as the game's disengagement system. Some polish here may be possible that preserves more positional tactics without compromising the main aim, and I'm still considering solutions.
5. Less polished looking sprite walk
One of the things I'm actively still working on is attempting to make traversing the map look less like 6 characters overlapping each other. This is probably a small quibble and I quickly forgot about it when I actually started playing the game, but walking around the map looks noticeably less polished than with native pathfinding (when it works). You'll sometimes see sprites overlap and continue walking over each other in perfect sync until they arrive at their destination.
This produces no known issue, but I find it to be a minor immersion break. The biggest fault here is combat. In a tight space, while the mod will try to find non-occupied positions around an enemy, with a 6 person party it will sometimes be the case that two characters will occupy the same circle while attacking. This may have some effect on some players' current gameplay patterns (eg: I'm used to clicking my character's circle instead of their portrait, and overlapping circles can make that annoying if you're not used to that). Additionally, it just looks less polished.
My answer: Fully agree. While it is not even close to being as annoying as native pathfinding, it is a nitpick I have and am attempting to address with better pathing logic.
Current position
So these are the limitations I'm currently aware of. My position is no longer that party pass-through is merely a QoL improvement. It is also a real combat buff. Better movement means better pursuit, retreat, target switching and positional flexibility.
Speaking personally and putting my non-objective hat on: this feels like a godsend of an improvement overall. Pathfinding has plagued this game since its inception, and I've never felt a more fluid gameplay experience where I am simply not thinking about pathfinding at all. It is glorious.
Current difficulty is partly produced by an unreliable control/pathfinding system. I'll let the community decide whether that effect is meaningful enough to warrant further action. If it creates meaningful balance problems, I would rather solve those problems directly than intentionally make party movement worse again.
Again, please break it.
I'm especially interested in cases where friendly collision currently creates meaningful tactical gameplay that cannot be reproduced more cleanly through another mechanic.
────────────────────────────────────────
The story / inception
The perpetual struggle against Infinity Engine pathfinding has plagued this community basically since its inception.
Over the years, Beamdog, GemRB, modders and engine hackers have attacked the obvious parts of the problem: better path searches, more search nodes, improved bumping, better collision detection, smarter rerouting, etc.
But there is another deceptively simple solution: What if allies just didn't collide with each other?
People have suggested some variation of "just turn off party collision" for years. And philosophically, I think they were right.
Instead of continuously trying to teach six independently moving actors how to negotiate one another in tiny Infinity Engine hallways, why not just remove the conflict?
The problem is that "just turn off collision" sounds a lot simpler than it actually is. For normal Infinity Engine modding, this behavior doesn't live in a convenient .2da, creature flag or script setting. It lives in the engine.
That means reverse-engineering territory. That means tracing compiled x64 assembly code.
Yuck.
Historically, the time and specialist knowledge required to make drastic changes at this level made something like this fairly impractical. A few things have changed.
First, an enormous amount of foundational work has already been done by Bubb through EEex, InfinityLoader, GemRB, IESDP and the wider Infinity Engine modding community. We understand vastly more about the machinery underneath these games than we did twenty years ago.
Second: You know what doesn't care about parsing assembly code for hours? AI.
Modern AI-assisted reverse engineering makes it practical for one person to instrument the executable, compare controlled tests, follow different engine paths, inspect disassembly, build experimental hooks, crash the game horribly, inspect the dump, fix the hook and repeat until the behavior is understood. So with a lot of prior community work doing the heavy lifting underneath it, I present a potential fix for one of the Infinity Engine's oldest annoyances: Disable friendly collision.
"Just disable collision" wasn't actually simple
The engine checks creature occupancy in several separate places: initial route planning, background path searches, early movement waits, physical walking checks, and bump/recovery behavior.
Consequently, fixing one check could remove pushing while another check still made the character walk around an ally—or wait before moving.
One early prototype let me physically walk straight through Imoen while another part of the pathfinder still decided: "Imoen occupies the sensible route. I shall instead explore the Sword Coast."
Normal movement worked before Haste did. Moving actors behaved differently from stationary actors. Attack movement had its own considerations.
This became less: turn collision off, and more: remove collision as a movement constraint while rebuilding the useful spacing behavior separately.
A lot of development has effectively been: reproduce one movement case → record what the engine does → compare it with another case → identify the missing decision → hook it → test again.
Traversal is permissive; spacing is intentional
Collision used to perform two jobs at once: stop characters from walking through one another, and incidentally keep characters visually separated. We want to remove the first without completely losing the second. So the guiding rule became: Traversal is permissive; spacing is intentional.
Allied pass-through
Party members and friendly summons can traverse other allies. Actual environmental and hostile obstructions remain intact.
Attack positioning
Completely free movement initially exposed another problem: multiple melee characters could choose nearly identical attack destinations. The mod therefore prefers reasonable separate positions around an enemy when valid positions exist. Crucially, allies remain freely traversable while approaching those positions. We do not restore collision simply because an attack order was issued.
Gentle settling
If normal movement finishes with multiple party members standing directly on top of one another, they can make a very small local adjustment into nearby valid space. This is deliberately gentle. A new player command always takes priority.
Travel spacing
While traveling through open space, characters can prefer routes that avoid sustained unnecessary overlap. But spacing is only a preference. If the doorway is one-person wide: stop caring about personal space and go through the damn doorway. The spacing systems are never allowed to become another reason movement fails. This is also still in testing so it's far from as good as it likely can be.
What has been tested?
The current preview has been tested with stationary party members, multiple moving party members, full six-person parties, combat, attack routing, Haste, Improved Haste, Boots of Speed, friendly summons, overlapping starts, narrow doors/corridors, scripted MoveToPoint movement, Leader / Follow scripted movement, save/load while using the system, and area transitions. Those tests have been successful so far. That does not mean every possible IE/mod interaction has been discovered.
Hence: Please break it.
────────────────────────────────────────
Thanks especially to Bubb for EEex and the years of engine reverse-engineering behind it, as well as the people behind InfinityLoader, GemRB, IESDP and the wider Infinity Engine modding community.
This project is only practical because an enormous amount of ugly foundational work was already done before I arrived.
Current version: 0.1.5 Preview
Game: Baldur's Gate 1 and 2 EE / EET
Requires: EEex
Current validated environment: BG2EE 2.6.6.0 + EEex 1.2 / BG2EE 2.7 + EEex 1.3 (Windows Tested/Confirmed; Linux Fedora Tested/Confirmed with Wine/Proton)
Status: Solo preview / community testing
Download — Install EEex → download the latest release of Pathfinding Redux → extract the ZIP in your game directory → run "setup-bg-redux-movement.exe"
GitHub
Demo video
────────────────────────────────────────
What is it?
Pathfinding Redux removes friendly collision. This fixes all commonly observed bugs with pathfinding relating to clumping/stuck characters, and the vast majority of "crazy detour" routing of characters because most instances were player ally blocks.
Party members and friendly summons no longer treat other allies as hard movement obstructions. They can simply move through one another, while walls, closed doors, neutral NPCs, enemies and the actual environment continue to block movement normally.
That's basically it.
It sounds like a small change, but in practice it fixes a frankly ridiculous amount of Infinity Engine pathfinding jank.
The mod also adds some light spacing intelligence so removing collision doesn't just result in six people permanently standing on top of each other. Melee characters try to find reasonable positions around enemies, overlapping characters gently separate after arriving, and ordinary travel can prefer cleaner-looking routes when doing so doesn't interfere with movement. Potential downsides are discussed in the "Nerd Talk" section.
The guiding rule is: Traversal is permissive; spacing is intentional.
The practical result
- No doorway jams or party traffic bottlenecks.
- No corner/hallway shuffling, bumping and absurd rerouting.
- No bizarre detours caused purely by allied positioning.
- No party members fidgeting against each other during travel.
- No characters becoming trapped inside overlapping companion circles.
- No more watching Jaheira dry-hump Anomen instead of fleeing an approaching demilich.
One accidental QoL example I particularly like: Imoen unlocks a container. Jaheira can immediately walk up and open it. You no longer have to wait for Imoen to move because she happens to be standing on the six pixels Jaheira wants.
After playing with the working version for a while, I stopped thinking about pathfinding.
────────────────────────────────────────
Compatibility / Requirements
Currently validated:
- Windows
- Fedora w/ Proton
- BG2EE 2.6.6.0 + EEex 1.2
- BG2EE 2.7 + EEex 1.3
- EET
This preview uses native x64 hooks, so executable/version compatibility matters substantially more than it does for an ordinary WeiDU tweak.
Other EE games and executable versions should not be assumed compatible until explicitly validated.
Multiplayer is also a separate future milestone.
────────────────────────────────────────
Installation
- Install the required version of EEex.
- Extract Pathfinding Redux into your game directory.
- Run the WeiDU installer.
- Install the desired components.
Individual gameplay features are independently configurable and persistent.
Recommend installing before EET End if possible, though post-installation works on my build.
────────────────────────────────────────
Feedback I'm Especially Looking For
Please report:
- strange movement regressions;
- creatures that unexpectedly become traversable;
- cases where allies unexpectedly block again;
- weird attack positioning;
- pathological stacking;
- scripted/cutscene movement failures;
- interactions with mod-added creatures;
- balance situations where pass-through produces a genuinely problematic tactic;
- crashes, obviously.
If something feels wrong, a save immediately before reproducing it is extremely useful.
Please break it.
────────────────────────────────────────
More Redux Philosophy / Nerd Talk
The steelman against Pathfinding Redux OR: How I learned to stop worrying and love the combat buff
I want to make the strongest reasonable argument against this mod rather than present party pass-through as an obvious improvement with no tradeoffs. Friendly collision is not only pathfinding jank; it also creates real positional constraints, movement friction, and a kind of accidental commitment to where your characters are standing. Removing it makes the game control much better, but it also makes the party genuinely stronger in some situations.
A later polish may include an optional native combat collision component for people who really want the vanilla experience, though I personally prefer combat being non-colliding too.
1. Retreating through your own frontline
Imagine a one-character-wide corridor with five party members lined up behind one another while a fighter enemy attacks the front character. With pass-through, the injured frontliner can simply retreat through the entire formation to safety while the next character takes their place. The enemy cannot follow because the party still physically blocks them. This creates a kind of one-way defensive wall and makes tank rotation much easier.
With attack formations included in this mod, characters try to find "slots" around an enemy rather than naturally standing on top of one another. So even in many narrow geometries, everyone will try to find a reasonable attack position. But if you deliberately micro all your characters onto one spot, you can absolutely abuse this.
My answer: This is probably the strongest legitimate downside. It reduces positional commitment in very narrow spaces. However, it requires restrictive geometry, mostly melee opposition, and often deliberate exploitation. Off the top of my head I'm not sure of an enemy strong enough, combined with a corridor small enough, where this becomes a major practical abuse case. If disengaging becomes too easy, I would rather address disengagement directly than preserve unreliable party pathfinding everywhere just to retain this constraint.
2. Chokepoint stacking / increased melee frontage
If an enemy is standing in a doorway or narrow passage, pass-through can make it easier to compress several melee characters into a very small area and attack the same target. This can potentially increase effective frontage and make some chokepoints less restrictive for the player.
My answer: This already happens to some degree because vanilla formation/path compression can push characters into extremely tight positions. Exact permanent stacking is still undesirable and is one reason smarter attack-position selection and soft destination separation exist. I don't think general movement itself should become obstructive just to solve this edge case.
3. Better pathfinding is itself a combat buff
This is broader than retreating. Vanilla collision imposes a kind of accidental movement tax on the party: characters hesitate, bump, repath, queue behind each other and lose time whenever several party members try to move through the same space.
Removing that means the party can pursue fleeing enemies much more aggressively, maintain better melee uptime, switch targets faster, reposition more reliably in cramped fights, kite and retreat through its own formation more easily, and move through narrow environments as though they are effectively wider. I noticed this immediately while chasing fleeing enemies: several melee characters can now pursue smoothly instead of wasting seconds fighting each other for pathing space.
My answer: I think this should simply be admitted as a real buff. The important question is whether bad friendly pathfinding is a good source of difficulty. I don't think it is.
There is a difference between an enemy successfully escaping because of distance, terrain, speed or tactical positioning and an enemy escaping because three fighters became tangled around each other's circles. If improved movement makes pursuit, kiting or disengagement too strong, those are better treated as separate balance problems. I would rather make movement reliable first and then introduce explicit mechanics that create desirable combat friction.
4. Loss of positional friction
More generally, vanilla friendly collision creates commitment. A fighter who pushes deep into a formation may have difficulty extracting themselves because allies physically occupy the route behind them. Removing collision weakens that commitment and makes party repositioning more forgiving.
My answer: This is the strongest philosophical objection. Some positional friction is legitimate tactics, but vanilla BG does not cleanly distinguish intentional positional commitment from characters shuffling, pushing, rerouting, taking absurd detours or simply getting stuck.
Additionally, through painstaking micro you can often achieve the same result anyway: move Jaheira slightly left → pause → move your character back → sidestep Jaheira right again → resume.
Pathfinding Redux often removes the execution tax rather than enabling something fundamentally impossible.
My preference is therefore: Remove unreliable friendly obstruction first, then deliberately recreate any tactical constraints that prove worth preserving.
I don't want broken movement to serve as the game's disengagement system. Some polish here may be possible that preserves more positional tactics without compromising the main aim, and I'm still considering solutions.
5. Less polished looking sprite walk
One of the things I'm actively still working on is attempting to make traversing the map look less like 6 characters overlapping each other. This is probably a small quibble and I quickly forgot about it when I actually started playing the game, but walking around the map looks noticeably less polished than with native pathfinding (when it works). You'll sometimes see sprites overlap and continue walking over each other in perfect sync until they arrive at their destination.
This produces no known issue, but I find it to be a minor immersion break. The biggest fault here is combat. In a tight space, while the mod will try to find non-occupied positions around an enemy, with a 6 person party it will sometimes be the case that two characters will occupy the same circle while attacking. This may have some effect on some players' current gameplay patterns (eg: I'm used to clicking my character's circle instead of their portrait, and overlapping circles can make that annoying if you're not used to that). Additionally, it just looks less polished.
My answer: Fully agree. While it is not even close to being as annoying as native pathfinding, it is a nitpick I have and am attempting to address with better pathing logic.
Current position
So these are the limitations I'm currently aware of. My position is no longer that party pass-through is merely a QoL improvement. It is also a real combat buff. Better movement means better pursuit, retreat, target switching and positional flexibility.
Speaking personally and putting my non-objective hat on: this feels like a godsend of an improvement overall. Pathfinding has plagued this game since its inception, and I've never felt a more fluid gameplay experience where I am simply not thinking about pathfinding at all. It is glorious.
Current difficulty is partly produced by an unreliable control/pathfinding system. I'll let the community decide whether that effect is meaningful enough to warrant further action. If it creates meaningful balance problems, I would rather solve those problems directly than intentionally make party movement worse again.
Again, please break it.
I'm especially interested in cases where friendly collision currently creates meaningful tactical gameplay that cannot be reproduced more cleanly through another mechanic.
────────────────────────────────────────
The story / inception
The perpetual struggle against Infinity Engine pathfinding has plagued this community basically since its inception.
Over the years, Beamdog, GemRB, modders and engine hackers have attacked the obvious parts of the problem: better path searches, more search nodes, improved bumping, better collision detection, smarter rerouting, etc.
But there is another deceptively simple solution: What if allies just didn't collide with each other?
People have suggested some variation of "just turn off party collision" for years. And philosophically, I think they were right.
Instead of continuously trying to teach six independently moving actors how to negotiate one another in tiny Infinity Engine hallways, why not just remove the conflict?
The problem is that "just turn off collision" sounds a lot simpler than it actually is. For normal Infinity Engine modding, this behavior doesn't live in a convenient .2da, creature flag or script setting. It lives in the engine.
That means reverse-engineering territory. That means tracing compiled x64 assembly code.
Yuck.
Historically, the time and specialist knowledge required to make drastic changes at this level made something like this fairly impractical. A few things have changed.
First, an enormous amount of foundational work has already been done by Bubb through EEex, InfinityLoader, GemRB, IESDP and the wider Infinity Engine modding community. We understand vastly more about the machinery underneath these games than we did twenty years ago.
Second: You know what doesn't care about parsing assembly code for hours? AI.
Modern AI-assisted reverse engineering makes it practical for one person to instrument the executable, compare controlled tests, follow different engine paths, inspect disassembly, build experimental hooks, crash the game horribly, inspect the dump, fix the hook and repeat until the behavior is understood. So with a lot of prior community work doing the heavy lifting underneath it, I present a potential fix for one of the Infinity Engine's oldest annoyances: Disable friendly collision.
"Just disable collision" wasn't actually simple
The engine checks creature occupancy in several separate places: initial route planning, background path searches, early movement waits, physical walking checks, and bump/recovery behavior.
Consequently, fixing one check could remove pushing while another check still made the character walk around an ally—or wait before moving.
One early prototype let me physically walk straight through Imoen while another part of the pathfinder still decided: "Imoen occupies the sensible route. I shall instead explore the Sword Coast."
Normal movement worked before Haste did. Moving actors behaved differently from stationary actors. Attack movement had its own considerations.
This became less: turn collision off, and more: remove collision as a movement constraint while rebuilding the useful spacing behavior separately.
A lot of development has effectively been: reproduce one movement case → record what the engine does → compare it with another case → identify the missing decision → hook it → test again.
Traversal is permissive; spacing is intentional
Collision used to perform two jobs at once: stop characters from walking through one another, and incidentally keep characters visually separated. We want to remove the first without completely losing the second. So the guiding rule became: Traversal is permissive; spacing is intentional.
Allied pass-through
Party members and friendly summons can traverse other allies. Actual environmental and hostile obstructions remain intact.
Attack positioning
Completely free movement initially exposed another problem: multiple melee characters could choose nearly identical attack destinations. The mod therefore prefers reasonable separate positions around an enemy when valid positions exist. Crucially, allies remain freely traversable while approaching those positions. We do not restore collision simply because an attack order was issued.
Gentle settling
If normal movement finishes with multiple party members standing directly on top of one another, they can make a very small local adjustment into nearby valid space. This is deliberately gentle. A new player command always takes priority.
Travel spacing
While traveling through open space, characters can prefer routes that avoid sustained unnecessary overlap. But spacing is only a preference. If the doorway is one-person wide: stop caring about personal space and go through the damn doorway. The spacing systems are never allowed to become another reason movement fails. This is also still in testing so it's far from as good as it likely can be.
What has been tested?
The current preview has been tested with stationary party members, multiple moving party members, full six-person parties, combat, attack routing, Haste, Improved Haste, Boots of Speed, friendly summons, overlapping starts, narrow doors/corridors, scripted MoveToPoint movement, Leader / Follow scripted movement, save/load while using the system, and area transitions. Those tests have been successful so far. That does not mean every possible IE/mod interaction has been discovered.
Hence: Please break it.
────────────────────────────────────────
Thanks especially to Bubb for EEex and the years of engine reverse-engineering behind it, as well as the people behind InfinityLoader, GemRB, IESDP and the wider Infinity Engine modding community.
This project is only practical because an enormous amount of ugly foundational work was already done before I arrived.
Post edited by Avenger on
0
Comments
https://forums.beamdog.com/discussion/72639/comments-on-new-v2-5-pathfinding-it-is-bad-news/p2
They solve the problem at different levels. Bubb’s fix gives the existing pathfinding system much saner behavior/defaults. Pathfinding Redux changes the underlying movement/engine rules themselves. This is a much 'larger' change essentially.
I think Anomen may like it. If he likes females; I don't quite remember.
There are a few questions about the mod though. For instance, I have the issue sometimes
of chars stacking on the same position and being stuck. I don't know how this arises but
I think a mod may be the culprit. (I have a suspicion but I was often wrong in the past so
I am not speculating what is responsible for that bug.)
Does Pathfinding Redux fix this issue too?
I remember in the old game Warcraft 3, the pathfinding was also an issue. Players made
work arounds early on, e. g. rather than hand over an item from one hero to another,
they would simply drop the item and the second hero then picks it up, which is both
faster, and had less bumping-issues (e. g. units stopping when hitting one another).
Is EEex required? Getting it is probably easy
https://www.gibberlings3.net/forums/topic/41254-mod-eeex-v131/
but I ran into issues with other things, including EET, so I am a bit wary of depending
on certain things. I am not so much opposed about add-ons per se, but often different
people develop things and the quality then varies. I'd actually much prefer if several
people could all agree with things and then work on stuff in a combined manner (I
guess this qualifies for EET; no clue why I had issues with it, but this already begins
with the installer, and asking for improvements here on their issue tracker
didn't really change anything, unlike other issue trackers on github
https://github.com/Gibberlings3/EET)
Yes the Redux fixes issue of characters being stuck in the same position. They can get into same position but they just dont get stuck
Yes EEex is required for this to work.
As for EET issues it is best to report issues on G3 forum - you need to download master branch for those fixes though as there was no release version for quite some time. From what I see @argent77 is providing most of the fixes lately
Thank you
EE compatibility as of most recent version cheers
Awesome. Just in time for my next run.
Thankee!
I`ll copy Bubbs answer to similar question from G3
"All my patch does is fix party members not being able to bump each other free when they get stuck in the same location. As Avenger said, that's redundant when combined with this mod."
No idea about OlvynSpells