Oversight HQ from Dark Horizons missing
Lechloan
Member Posts: 4
Hello, I worked my way through the Section Part in Beregost, had the talk with Nikita afterwards where she gives me the Password scroll, but I can't find or access the Oversight HQ in Zentral BG.
AS far as I Know, it should be in the House behind House 1 in http://www.forgottenwars.com/bg1/ar0700.htm.
but it isn't there.
Am i in the wrong location or can anybody tell me which Variables need to be set for the access?
AS far as I Know, it should be in the House behind House 1 in http://www.forgottenwars.com/bg1/ar0700.htm.
but it isn't there.
Am i in the wrong location or can anybody tell me which Variables need to be set for the access?
Post edited by Lechloan on
1
Comments
We are supposed to meet a woman who will show you the good house. But i never found that woman...
I have the password scroll but nothing happend...
C:MoveToArea("CM0750")
This will put you in the main room, go South and the butler will ask for the scroll and take it - letting you know to go to the 3rd floor to meet someone.
Thoughts on the issue:
I wonder if it's a BGEET thing - ar0700 on Dudley map corresponds to that segment of baldurs gate - but on EET that zone is actually BG0700 - and I do see an AR0700 in the mod files for DH, which indicates to me that it intended to overwrite the zone file (to add this door).
However, MoveToArea("AR0700") in EET drops in me Amn, not in central baldurs gate.
Would this Oversight HQ bug be easily fixed via fan patch?
Since leaving oversight HQ puts the player in the proper BG zone (BG0700 in EET), the only thing missing is the entrance area - so it probably would be a little PATCH IF check that the mod is installed, or a creature from mod is present or something (it has no EET awareness at all, so must be installed on the BGEE side, before EET is started) and then adding a zone point in the same way the mod added it to AR0700 (if it was via a patch and not just a flat overwrite of the file).
I'm not sure what the maintenance status of the project-proper is - if it's still being maintained by someone, it may not be a big fix?
I don't know how complicated modding areas is, so MoveToArea seems a bit simpler for now (but it would be nice to be EET compatible out of the box, no doubt).
Thankee for sharing this fix! Alleluia!
This shouldn't be an EET bug. In fact I went through all my EET archives which had DH installed and all of them already has this specific door installed. EET's own importer shouldn't even make a difference here between mod-added and OG doors to update them during the game content import step.
This issue could only exist if DH failed to install the door to the map for some reason on BG1. Which I couldn't reproduce.
The tweak reproduces the door location exactly as defined in the pre-eet area file (again, when viewed in Near Infinity) with the same exact vertices and everything, so I don't *think* it'd be a problem to have a double door defined (if it did work for someone, but not for another) - is your request aimed at fixing an edge case in the EET portion?
Next time I reinstall I'll hold off on my tweak and run the procedure again plus confirm the door does not exist, and upload that weidu.log - if it's relevant, I'm on GNU/Linux using the BG:EE/SOD/BG2:EE from Steam.
There's weidu --change-log for these reasons to backtrack which mod does it.
My point is that throwing a random change at the end of an install as a perceived fix without any explanations or reasons to explain why the bug happens in the first place is useless. This should be fixed in or atleast reported for the mod which causes this change to be lost.
If you don't have the time to bisect, atleast call your solution as a workaround, instead of a fix.
We don't have any evidence that the word-of-mouths also had issues with losing the door or the area scripts messing with the door's activation. Because the door is activated explicitly in the same area script, instead of using the variable within the door's code itself.
I note the scope of mods, because while I was willing to spend ~30 minutes figuring out the workaround and writing the patch for it, and 30 seconds pushing it into my github repo, I'm not willing to spend more time on it, as an altruism (which is why I was interested in hearing your reasoning for suggesting that I do anything further than I have done).
Maybe I was wrong in assuming more mods = more to diagnose/debug for a "test case" as you state it - I don't need to have an excuse, because it isn't my obligation to do anything with it. If I was providing the original mod, and had a business arrangement with someone for support, then maybe I would need an excuse, but I don't see why you think it'd be an excuse?
Edit: Hopefully the reply doesn't come off confrontational, just trying to "clear the air" around how I perceive my role here, vs what some may expect of others - like I mentioned originally, when I have an opportunity to look into (I lack the disk space to have 2 parallel installs) I'll try to scrutinize the root cause as you suggest. I'll paste a change log, maybe some mod between the two is the culprit for overwriting the file.
From post-eet:
more from post-eet (for the other file)
As noted - if I rollback my ahungry_tweaks (5000) - the bg0700.are file is missing this door entirely - can a script event define a door that isn't in the area file?
I'll break one of my folders with Item Randomizer, I never trusted that mod myself and can't think of the others causing the issue.
EDIT: I've installed the TnT components and Item Randomzer and I couldn't reproduce the issue. I don't know what goes wrong there.
I understand why people like randomizer mods and the chaos that could add the game to, it's just that from my POV, this one is way too risky and somewhat too arbitrary to ensure everything goes well after a randomization.