Jump to content

What happens if the Quest (script) is edited incorrectly? And what can be considered incorrect editing?


Recommended Posts

I want to remove turrets from BoS302 quest. If I do like in the screenshot? I will simply select in the field Cell - NONE? What could be the consequences? Because to get into the script itself and edit it, then, as I understand it, it will need to be compiled, and this is more difficult, and if I can do it as above, then why not? But in order for me to check the work, I will need to reach this point in the game? And if there are problems, then I will have to restart the quest through the console...

 

 

 

 

Link to comment
Share on other sites

This is from a Papyrus viewpoint and not FO4 itself. If you change a property variable to NONE and there is not a default value for that property on the script itself, there could be problems. To be more specific, if a variable has a none value it can create errors in the papyrus log. Depending on how the script was written and how the variable is used, the script will cease to run, be left waiting for something that will never happen or just fail that bit and proceed. Only way to know would be extensive testing.

 

As far as what you want to do, there may be alternative ways. However, it will take someone who is familiar with FO4 and that particular quest to chime in.

Link to comment
Share on other sites

The quest script fragment seems to only Enable() and Kill() the turrets so it probably won't cause CTDs or anything like that. The turrets are enabled through an EnableParent (EP) so if you remove their EP and call BoS302Turret0X.Disable(), you can avoid setting the script property variable's value to 'None'.

Link to comment
Share on other sites

Depending on how the script was written and how the variable is used, the script will cease to run, be left waiting for something that will never happen or just fail that bit and proceed. Only way to know would be extensive testing.

So there may be problems with the fact that the event in the game (quest) simply will not be started or continued? Or even CTD? I don't like both of these things...

 

 

The turrets are enabled through an EnableParent (EP) so if you remove their EP and call BoS302Turret0X.Disable(), you can avoid setting the script property variable's value to 'None'.

 

But what if EnableParent is empty? For example, in GlowingSeaPOIJS01, there are two LvlTurretBubble turrets. There is no binding in their settings, but both of them are used by DefaultDummyON, which has a GlowingSeaPOIJS01Script script, which specifies two Protectrons and two turrets. If NONE cannot be set in the script, can I make Clear Value? Then opposite Turret02 will be <<Default: None>>

 

The simplest solution is to simply remove the turret without changing anything else, despite the warning that this object is used by the DefaultDummyON specified above. I did this and checked - it works. When I flip the switch in the bunker, Protectrons are activated, they turn on and attack me, but there are no turrets, because I removed them.

If I set to None, then turrets are present but not activated in any situation.

 

If CK writes about "they will be checked out and their use of it will be removed", then would this be acceptable, given that I don't need to use them?

Link to comment
Share on other sites

I doubt a CTD would happen due to a property variable being set to NONE.

 

Just wanted you to be aware that if a variable that is not expected to have a NONE value has one, then the script may not behave in an intended way. Testing is the only way to know what will happen in that scenario.

Link to comment
Share on other sites

 

The turrets are enabled through an EnableParent (EP) so if you remove their EP and call BoS302Turret0X.Disable(), you can avoid setting the script property variable's value to 'None'.

 

But what if EnableParent is empty?

 

If an object reference is already enabled through its Enable Parent (EP) by the time a plugin overrides its record to clear its EP, the object would still remain enabled until a script calls Disable() on it.

 

You can either clear the turret's EP then Disable() it or delete the turret in the Creation Kit. Generally, deleting an editor placed object reference should be avoided if possible. CTDs may happen for example if another mod that holds it in a script property as well would try to access it for processing. Though probably that Bubble Turret is not edited by many mods so deleting it shouldn't cause problems.

Link to comment
Share on other sites

Just wanted you to be aware that if a variable that is not expected to have a NONE value has one, then the script may not behave in an intended way. Testing is the only way to know what will happen in that scenario.

So both options can lead to unpredictable results? In 01.png screenshot, the specified turret. Below is the result if NONE is selected and even lower if Clear Value is selected. Even in the second case there can be problems?

 

 

You can either clear the turret's EP then Disable() it or delete the turret in the Creation Kit. Generally, deleting an editor placed object reference should be avoided if possible.

Now I know for sure that it is better to avoid deleting what is in use. If it works somewhere, then in other cases it can lead to blocking the quest. For example, when entering Vault 81 (Vault81Entry) to remove two LvlTurretBubbles that are used in the quest V81_00_Intro (screenshot 02.png), then I press the button to open the vault door, nothing happens. If these turrets are removed in the quest, then everything works.

 

The easiest option is to simply move all the turrets off the map or even replace them with radroaches, as I did at first. But then I thought, it's too unhygienic... It turns out that it would be better if I stayed with radroaches.

 

 

 

Edited by orangedeal
Link to comment
Share on other sites

The game will politely keep running, with a few missing turrets and some angry text in the papyrus log if you have one activated -- the problem could arise in the case where the presence of this turret is in some way part of a control condition which could lead to cascading errors.

I highly doubt it though.

Link to comment
Share on other sites

  • Recently Browsing   0 members

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