The whole business of persistent references in MW always looked fishy to me. Do we actually need to implement it?Now that you have mentioned a global list of "special" references, we may actually need this to track persistent references or other kinds of "special" references. I have recently produced a few save files (.ess) just to get an idea on which cells are preloaded by Morrowind (in OpenMW, loading Bloodmoon.esm preloads several cells on Solstheim, so the basic ability seems to be there). But this can be definitely split from the main topic.
Multiple ESMs and ESP support
Re: Multiple ESMs and ESP support
I would still prefer a global list to a per-cell implementation, but go ahead.
Re: Multiple ESMs and ESP support
Guess what, folks? My mother entered hospital last week, intensive care unit, artificial coma, the full program, with a really nasty lung infection the doctors don't quite know how to cure yet. This means that I am currently struggling keeping the more important parts of my life stable, as no one can predict what will come next. Therefore, I am afraid I will have to take an indefinite hiatus - but only after the current things have finally found their way into the main branch.
But first things first. I have managed to implement the reference moving between cells I anounced two weeks ago. Moved references now spawn as expected, even when moving them across half the map and their "master" cell is not loaded. I did not find the time to do as much testing as expected, but it generally seems to work (except maybe for a few rare cases I have not managed to track down yet). Last weekend, I succeeded at a successful merge, but the mentioned real-life complications prevented me from pulling off a pull request. I am reasonably sure I'll manage to do it next weekend (following another merge).
Other than this, I have seen that the first bits of the custom editor have found their way into the main branch. This editor will also need to have multi-esX support sooner or later, but I will not find the time to do it in the forseeable future. But on the other hand, it should be comparably easy to port what will soon enter openmw, and most of the code is shared via the "components" target anyway.
So, folks, it was an interesting experience. I'll still do the pull request this weekend, and then, another unplaned hiatus. Well, at least I am able to anounce it in advance this time, so I am not leaving you in the dark .
@zini: If you prefer a global tracker (or it turns out that the local version does not work as expected due to some nasty details turning up later), it should be easy to change it, as the basic functionality is now there; moving pieces of code around generally isn't quite as bad as coming up with something completely new. I am not sure what to do about persistent references myself, as I have yet to see anything that definitely requires it. I suggest we leave it out until we actually find something that needs it.
I think that a few references need to be tracked, such as the intervention/prison markers, which are required to teleport the player to the "nearest instance". But I do not remember if these references actually have to be persistent of if this behaviour is hard-coded. There might also be some cases where a script is trying to reference a persistent object in a distant cell. Well, basically any really big, script-heavy mod might do something tricks, but I also think the best approach would be to wait some some time, collect the problems that will emerge and then think about what must be done.
But first things first. I have managed to implement the reference moving between cells I anounced two weeks ago. Moved references now spawn as expected, even when moving them across half the map and their "master" cell is not loaded. I did not find the time to do as much testing as expected, but it generally seems to work (except maybe for a few rare cases I have not managed to track down yet). Last weekend, I succeeded at a successful merge, but the mentioned real-life complications prevented me from pulling off a pull request. I am reasonably sure I'll manage to do it next weekend (following another merge).
Other than this, I have seen that the first bits of the custom editor have found their way into the main branch. This editor will also need to have multi-esX support sooner or later, but I will not find the time to do it in the forseeable future. But on the other hand, it should be comparably easy to port what will soon enter openmw, and most of the code is shared via the "components" target anyway.
So, folks, it was an interesting experience. I'll still do the pull request this weekend, and then, another unplaned hiatus. Well, at least I am able to anounce it in advance this time, so I am not leaving you in the dark .
@zini: If you prefer a global tracker (or it turns out that the local version does not work as expected due to some nasty details turning up later), it should be easy to change it, as the basic functionality is now there; moving pieces of code around generally isn't quite as bad as coming up with something completely new. I am not sure what to do about persistent references myself, as I have yet to see anything that definitely requires it. I suggest we leave it out until we actually find something that needs it.
I think that a few references need to be tracked, such as the intervention/prison markers, which are required to teleport the player to the "nearest instance". But I do not remember if these references actually have to be persistent of if this behaviour is hard-coded. There might also be some cases where a script is trying to reference a persistent object in a distant cell. Well, basically any really big, script-heavy mod might do something tricks, but I also think the best approach would be to wait some some time, collect the problems that will emerge and then think about what must be done.
- sirherrbatka
- Posts: 2159
- Joined: 07 Aug 2011, 17:21
Re: Multiple ESMs and ESP support
Good luck. I see that lung infections are your nemesis.
Re: Multiple ESMs and ESP support
Okay.@zini: If you prefer a global tracker (or it turns out that the local version does not work as expected due to some nasty details turning up later), it should be easy to change it, as the basic functionality is now there; moving pieces of code around generally isn't quite as bad as coming up with something completely new. I am not sure what to do about persistent references myself, as I have yet to see anything that definitely requires it. I suggest we leave it out until we actually find something that needs it.
That should not be a problem. We generally ignore the persistency flag. Accessing an object in a distant cell is already implemented.I think that a few references need to be tracked, such as the intervention/prison markers, which are required to teleport the player to the "nearest instance". But I do not remember if these references actually have to be persistent of if this behaviour is hard-coded. There might also be some cases where a script is trying to reference a persistent object in a distant cell. Well, basically any really big, script-heavy mod might do something tricks, but I also think the best approach would be to wait some some time, collect the problems that will emerge and then think about what must be done.
Re: Multiple ESMs and ESP support
Thanks for your contributions (so far?) and giving us a heads up. Best wishes and I hope you will be able to return to us soon.
Re: Multiple ESMs and ESP support
mark76, hope your mom is well soon!! Take care man.
- sirherrbatka
- Posts: 2159
- Joined: 07 Aug 2011, 17:21
Re: Multiple ESMs and ESP support
I just want to say: thank you, for this work.