Jump to content

Disable jumping to the Unity when Armillary is built at outpost


MojFPS

Recommended Posts

I'm not sure how Bethesda missed this one... The Armillary connects to your grav drive in order to jump to the Unity. However, if you do not want to start a new game, you must remove the Armillary from your ship. This all makes sense. What doesn't make sense is that building the Armillary at an outpost somehow still triggers you to grav jump to the Unity, so the only option you have is carrying around the stupid thing in your inventory. Would love to see a mod that can fix this.

Link to comment
Share on other sites

Now there is an interesting concept. :D Even just having a menu option when you power the grave drive to go to the unity, or jump to another system would be nice. :D I leave a LOT of cool gear on the ground at the Buried Temple, since there is no point in picking it up.

Link to comment
Share on other sites

  • 2 weeks later...
  • 3 weeks later...
On 10/28/2023 at 7:44 AM, MojFPS said:

I'm not sure how Bethesda missed this one... The Armillary connects to your grav drive in order to jump to the Unity. However, if you do not want to start a new game, you must remove the Armillary from your ship. This all makes sense. What doesn't make sense is that building the Armillary at an outpost somehow still triggers you to grav jump to the Unity, so the only option you have is carrying around the stupid thing in your inventory. Would love to see a mod that can fix this.

EDIT: See below.

Edited by xtcrefugee
Link to comment
Share on other sites

OK, sorry for the double post but I have a working solution now. It needs to be done in a specific way to work.

Scrap your existing armillary (on your ship or outpost) if you have one, and go to the outpost you want your armillary at. You should be at either the "build the armillary on your ship" stage of the main quest, or the "return to the unity when you are ready" stage if you went to Unity and backed out. Open the build menu and build the armillary, but after placing it don't close the build menu yet. Open the console and enter:

Quote

set 7994F to 0

This sets MQArmillaryCompleteGlobal to 0, which would have been set to 1 by building the armillary either at an outpost or on your ship. Now exit the outpost build menu, and the quest should update if you've yet to go to Unity, it won't change if you backed out before. Now open your map and set a course to another star system and try to jump.

If you get an error saying grav jump isn't available, scrap your armillary and repeat what you did before, make sure you open the console as soon as you've built the armillary and before you exit the outpost build menu.

This seems to be working for me without issues so far. If/when you want to go to the Unity, just scrap and rebuild the armillary. MQArmillaryCompleteGlobal doesn't seem to get reset between game sessions. MQArmillaryLocation is what gets checked to determine Starborn attacks, so those should work as intended.

MQ305_ReadyForUnityJump (000214F4) are the conditions for when you jump to Unity, and the only thing it checks are MQArmillaryCompleteGlobal and whether you have a non-disabled ship. A "real" CK fix for this would probably be to alter this and check MQArmillaryLocation is set to 1 (on a ship) and not 2 (at an outpost).

Link to comment
Share on other sites

6 hours ago, aurreth said:

Can't you just make an override for 000214f4, adding a second condition:  Equal to, Comparison Value 1, GetGlobalValue, MQArmilleryLocation

Yes, that's what I was saying. I'm personally not comfortable doing that with a pre-CK mod when a console command will work, but the OP is free to use either method.

Link to comment
Share on other sites

7 hours ago, xtcrefugee said:

I'm personally not comfortable doing that with a pre-CK mod when a console command will work, but the OP is free to use either method.

The problem is you don't know what else that variable is linked to.  There may be other functions or quests that are affected by its value.  MQArmillaryCompleteGlobal is referenced by a quest, two activators, and a condition form.  Are you sure changing it in the console won't break anything?

Look, I use console commands a lot.  I have no objection to them.  But you want to use a SET when a GET does the job. 

Edited by aurreth
Link to comment
Share on other sites

The quest being the quest that sets its value, and the condition being the one we were talking about, the check before the jump to Unity. I don't think it's too much of a mystery, and regardless it's easy to reset. As I mentioned, I did test this.

No offence, but I think people are being somewhat blasé with xEdit, the author has been explicit about the risks. Broken saves have been a thing with previous BGS games when the tools weren't ready for primetime. The risks of changing a single global are small in comparison.

Edited by xtcrefugee
Link to comment
Share on other sites

I've never really understood people worrying about broken saves.  It's just a game.  Back up your saves, and if you screw something up, well, at least you know not to do that next time.

I've broken my game twice with xEdit, and that's because I was doing something Elminster specifically said not to do, modifying records with reflection data, by finding a way around restrictions he specifically put in to xEdit to prevent that kind of thing.  Eh, it happens, back up, restore save, try again.  But as a result there are now mods completely altering planets.  I blew up a moon so you don't have to 😁  (No, seriously, I destroyed the moon I was standing on and got sucked into a black hole.  No escape.  But I can now duplicate and replace planets.  Definitely not safe, so I won't be releasing anything soon.)

No mod is ever 100% safe, but as long as you don't violate the restrictions in xEdit you're probably not going to break anything to the point it can't be recovered.  Most of the mods out there are just ESM versions of the bat files that change the values of variables anyway.  They are really no different than a console command.

 

 

 

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...