Jump to content

Flora Respawn VMAD


DayDreamer
 Share

Recommended Posts

DayDreamer did you see my post in the USKP thread? It would be possible to get it to work with cell resets I think, if SetPosition would just do what it's supposed to do. No idea why that isn't working. If you can think of some other way to get the child object though, should be able to do it with zero stack overhead. It would still require VMAD on TREEs though, so still a bit risky to put in the patch.

 

edit: FWIW, I tried moving the child objects up and leaving the parent object be, and that way I was able to find the child objects after each cell reset, then remove them and place a fresh one. Using an offset of 0.2, and a search radius of 0.1, this works with the side effect of a barely-perceptible movement of the child flora up by 0.2 units. Subsequent cell resets do not move them any more than that. I don't know if that's acceptable for putting in the patch or not, but if SetPosition(...) can be made to work on the parent object, or if someone can think of another way of getting the child objects, it's a moot point.

 

Here's the code:

Scriptname FloraRespawnScript extends ObjectReference

Float offset = 0.2

Event OnReset()
  ObjectReference newObj
  ObjectReference nextNewObj
  
  Debug.Trace("[FloraRespawnScript.OnReset()] " + GetBaseObject().GetName() + " got cell reset event.")

  If(IsDisabled())
    Debug.Trace("[FloraRespawnScript.OnReset()] " + GetBaseObject().GetName() + " is disabled.")
    
    newObj = Game.FindClosestReferenceOfType(GetBaseObject(), GetPositionX(), GetPositionY(), GetPositionZ() + offset, 0.1)
    
    If(newObj != None && newObj != Self)
      Debug.Trace("[FloraRespawnScript.OnReset()] " + GetBaseObject().GetName() + " found child object.")
      nextNewObj = newObj.PlaceAtMe(newObj.GetBaseObject(), 1, false, true)
      
      nextNewObj.SetScale(newObj.GetScale())
      nextNewObj.SetAngle(newObj.GetAngleX(), newObj.GetAngleY(), newObj.GetAngleZ())
      nextNewObj.Enable(false)
      
      newObj.Disable()
      Utility.Wait(0.1)
      newObj.Delete()
    EndIf
  Else
    Debug.Trace("[FloraRespawnScript.OnReset()] " + GetBaseObject().GetName() + " is enabled.")
    
    newObj = PlaceAtMe(GetBaseObject(), 1, false, true)
    newObj.SetPosition(GetPositionX(), GetPositionY(), GetPositionZ() + offset)
    
    newObj.SetScale(GetScale())
    newObj.SetAngle(GetAngleX(), GetAngleY(), GetAngleZ())
    newObj.Enable(false)
    Disable()
  EndIf
EndEvent
Link to comment
Share on other sites

been planning to give this flore fix beta a go.

which nexus file has the latest changes to the flore 2.0 fix beta? which should we download and test now? original beta, or the redux upload by daydreamer?

how and what should we test? which solution is the currently implemented one, and are there shortcomings to be expected, or should we expect everything to behave correctly?

Link to comment
Share on other sites

If you're using my 1.0 already you need to upgrade to my 2.0. If not, anything goes, although naturally I can't support the other one. Again, I still support Flora Respawn Fix so there really was no need for a "redux" as such. C'est la vie.

 

Oh, and if I do switch my mod to using cell reset system as above, it will break existing objects you've already harvested - they'll be affected by the original bug again.

 

Got a good bug report on current FRF 2.0 by the way. If you harvest ingredients in caravan huts, after the caravan is gone they persist. I don't think there is a way to set linked references on objects, and since the current incarnation of FRF deletes the base objects, it's not fixable. I can fix it for stuff going forward though. Strangely it will be easier to handle if I go with the cell reset respawn method, although it should be doable on both. Still contemplating whether to make the switch...

Link to comment
Share on other sites

No.

In fact, I realize now the cell reset method is broken for anything that has an enable parent. The only thing that can be done is to disable the fix completely if the object has an enable parent. This of course rules out fixing most of Hearthfire at all, not to mention caravans.

In light of this I'm not going to release a cell reset version unless a way around that limitation is found.

Link to comment
Share on other sites

In fact, I realize now the cell reset method is broken for anything that has an enable parent. The only thing that can be done is to disable the fix completely if the object has an enable parent. This of course rules out fixing most of Hearthfire at all, not to mention caravans.

In light of this I'm not going to release a cell reset version unless a way around that limitation is found.

Is the 1.0 and 2.0 working on things with an enable parent?

 

And I'm thinking we also should not update in Encounter Zones with Never Reset. I haven't figured out the test for that yet.

Link to comment
Share on other sites

That doesn't do much good. It suffers from the same bug as in the unplugged game, and it doesn't update the texture to an unharvested state, either. Tried with both the timer method and cell reset.

Oh double fudge! We probably should report that....

 

I had an idea about the OnReset version with enable parents, prompted by the SKSE and elsewhere discussion about form values with the top bit set.

 

Could we check for 0xff000000, ((ref & 0xff000000) == 0xff000000) and only delete those, leaving others merely disabled?

 

Is there a good test for has enable parent? (I couldn't find one.)

Link to comment
Share on other sites

Is there a good test for has enable parent? (I couldn't find one.)

 

There isn't. There is not even a link from the object, only the other way around. An that link isn't a link that papyrus even recognizes as a link. It is set up in a different tab in the CK, and checking for a linked reference from the marker returns none (unless the marker has another "regular link" ).

Link to comment
Share on other sites

You can try toggling the enable/disable state on the object, and check if you succeeded. I think the only reason that would fail is if the object had an enable parent. You said "good test" though, which that definitely isn't.

 

Even then, all that would allow you to do is just disable the fix completely, for the cell reset version. For cell reset, the script I posted depends on disabling objects to do its work. If it can't for some reason, bad things are going to happen. For the caravans, over time it would spawn many child references, which would be visible even when the caravan gear isn't there. Even if the player never harvested the object.

 

That rules out fixing most of Hearthfire, I think. I'd rather stick with the timer, and keep the minor bug with the caravans there (for the timer version, the issue is not as serious - it only manifests if the player harvests something placed by the caravans and it doesn't spawn numerous objects either). For Hearthfire it isn't really a bug since the object just gets turned on and then left there. It's only if they're enabled and then disabled later that it's a problem for the timer method.

 

I had an idea about the OnReset version with enable parents, prompted by the SKSE and elsewhere discussion about form values with the top bit set.

 

Could we check for 0xff000000, ((ref & 0xff000000) == 0xff000000) and only delete those, leaving others merely disabled?

 

We could, but that script already leaves the parent object (i.e. the original TREE/FLOR) alone. It doesn't do it by checking the form ID, but it does do it.

 

By the way (x-post from official forums thread):

 

You should not enable 1 object in the same place as another until you've disabled the other object.

 

Can you elaborate on this? AFAIK, there is no reason not to do this. You pointed this out in the other thread too, but I haven't had any problems with it at all. The script I used for Flora Respawn Fix, aside from the (ahem) 'controversial' respawn method, is solid - being a very simple thing after all.

 

I guess it would be one thing if physics were enabled on both, but they're not.

 

Your way, you get the flicker (not that it really matters here). The other way, you don't.

 

What gives?

Link to comment
Share on other sites

By the way (x-post from official forums thread):

Need to catch up on forums. ;)

 

In my tests, if I hadn't disabled the old object before enabling the new one, they have a tendency to visually overlap or move around.

 

For carriages, I've seen a carriage jump up on top of another, or on top of the horse, or a horse on top of the carriage. Even with DisableNoWait followed by Enable, I had to turn Debug.ToggleCollisions() off and then on later, or the driver would be hurt.

 

In my test of TestTreeFlora, I seem to remember the new plant not sitting exactly on the old plant. Do that a few times, and the plant will be too obviously in the wrong place.

 

But you can walk through them, so collisions shouldn't be a problem.

 

Whereas with DisableNoWait followed by Enable, I never saw any flicker. Do you? That would take really good eyesight at 1/60 second! I must be getting old....

Link to comment
Share on other sites

For objects with collision/physics enabled, yes you're totally right as mentioned.

 

I don't know if the underlying coordinates of the new object are off by a bit or not though. I've never noticed new plants "drifting" as you describe, but I wasn't looking for it either. Now I will so thanks.

 

But all DisableNoWait appears to do differently from Disable, going by the description, is do the work of actually disabling the object asynchronously, in a different thread of execution. So if you've got an Enable call for something else immediately after, it's possible you're still enabling that object first anyway. That would explain why you don't see any flicker.

 

Anyway, thanks for replying (finally :) ). I'll keep it in mind.

Link to comment
Share on other sites

Anyway, thanks for replying (finally :) ). I'll keep it in mind.

I'm sorry, I was really excited about Zilav's discovery and leaped on it. Then got distracted by the fact that the new rack code in 2.0.0 wasn't working properly for me in really obvious places. So I've concentrated my "spare" time on that, because we were in beta, and I was hoping (in vain) that the beta would be fixed before release. I'm far behind on reading forae.

 

But this is really important for making the game play well, and not ending up with depopulated desert Skyrim. Thanks for all the work you've done!

Link to comment
Share on other sites

This has probably been mentioned before, but I've noticed that the plantable ingredients/foods (in the garden/greenhouse) from the Hearthfire add-on don't suffer from this glitch for some reason. I doubt that the code used with those would be of any help in fixing the flora respawn issue, but I thought I'd mention it anyway.

Link to comment
Share on other sites

This has probably been mentioned before, but I've noticed that the plantable ingredients/foods (in the garden/greenhouse) from the Hearthfire add-on don't suffer from this glitch for some reason. I doubt that the code used with those would be of any help in fixing the flora respawn issue, but I thought I'd mention it anyway.

 

Yes, and they are fixed for the same reason as in Flora Respawn Fix. There are a lot more bells and whistles, because there is more functionality there to support the planting and replanting, but the basic idea is the same as Flora Respawn Fix: delete the old reference and place a brand new one. That's why they aren't affected.

 

That's another way of saying, yes it can be used, and it already has been. Where do you think I got the idea :)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...