From the OU Discord #dev channel, 7/8/2020:
------------------------------------------------------
AcornToday at 2:38 AM
I just experimented: a very brief visit to Minkata to pick up some more markers from one of the Kiva marker quests and then quitting gave me the same runtime error. Whereas, a visit to Er'cana doing the usual Er'cana things and then quitting had given no error. Will carry on exploring. Avvie Acorn2020#174 if this helps.
DeledriusToday at 5:04 AM
rarified: I think we saw something like this last fall and I traced it down to an improperly created keyed object. I'll look through the H'uru commits for "must do" kind of commits in the general topic you suggest.
@rarified On this note, now that you have a combined, working code tree, what's the status on doing a larger-scale merge to using the modern codebase we've built up (minus the removal of the Game Manager)? Getting to that point would save you a lot of work rather than doing this piecemeal catch-up chasing bugs that have already been documented and fixed.
There are some relatively major, and necessary, library updates coming around the corner soon; they'll be a lot easier to incorporate if you aren't still working through six years of code debt.
(I checked the forum thread on this topic, but after the potential blockers were addressed there has been no new activity)
rarifiedToday at 7:47 AM
So that thought has been rattling around in your head too, @Deledrius? I've been thinking about that for much of the year while focused on the Fan Age needs. I think a thread in the OU forums will be needed as things start to happen (I'll start it off, soon(tm)), but for now things distill down to two considerations:
[7:49 AM]
1) When: Throughout this year the answer has been "after fan age support has made it to MOULa". We're not quite there yet because of stability considerations, but once it happens I think that is what I will focus on.
[7:54 AM]
2) How: I feel a responsibility to understand the scope and impact of the changes carried with the current codebase. A large part of it (restructuring for clarity, the updated string handling, more thorough static analysis and resolution of issues) is absolutely the right thing to happen. Some of it -- changes in behavior or environmental interaction (configuration, tolerance for previously disallowed inputs, etc) needs deeper understanding for me to know what we're getting. That will take some time, and will be when I will most benefit from having skilled and experienced guides through the code.
[7:56 AM]
So -- just like fan age support -- the migration to the current codebase is coming. Need I add the usual "SOON(tm)" again? And as our distinguished Doobes says "It's not a matter of 'if', but of 'when'".
[7:58 AM]
That said, back to the current situation. Having given the current rebuild a couple of days to establish a pattern, the virtual function call errors only appeared after the alteration of the build configuration to create the debugging PDB files, even with a "Release" build. This rang a bell with me that the earlier encounter with those function call errors also correlated with a change to add debugging to a build last fall.
[8:04 AM]
I'm now fairly convinced that the option in the VS2010 GUI for enabling "Generate Debug Info" for linking the client does far more than just creating the PDB files when linking. I ran into a MS knowledge base article that described a lot of changes in compiler behavior as well, among which was changing exception handling in the generated code to be "debuggable". We saw this way back with early Unix C compilers (GCC and vendor) who were unable to generate debugging symbol information from optimized code. So when you asked for debugging information, it turned off all optimization, which of course changed the behavior of what you were trying to debug.
[8:05 AM]
In looking at the VS documentation, there are some variations of the option for generating debug information that may bring us back to diagnosing the exit crashes, not the artificially induced virtual function errors. I think I'm going to see how to work those into the next build.
DeledriusToday at 8:55 AM
I assumed it would definitely be "after fan age support has made it to MOULa", given that this is seemingly nearing a major milestone. It wouldn't make sense to jump sideways and redo that work (even though it will be necessary).
These threads already go over the topic, for reference:
viewtopic.php?f=92&t=958
viewtopic.php?f=92&t=957
DoobesToday at 9:07 AM
rarified: 2) How: I feel a responsibility to understand the scope and impact of the changes carried with the current codebase. A large part of it (restructuring for clarity, the updated string handling, more thorough static analysis and resolution of issues) is absolutely the right thing to happen. Some of it -- changes in behavior or environmental interaction (configuration, tolerance for previously disallowed inputs, etc) needs deeper understanding for me to know what we're getting. That will take some time, and will be when I will most benefit from having skilled and experienced guides through the code.
@rarified
See, the thing about that is that'll take a very long time and put a lot of very unnecessary work on you despite the fact many other people in the community have discussed, debated and ultimately implemented these changes and fixes years ago...and it's all well documented if you ever want references after the fact. In fact, there's a prime example of its end result that you can visit at any time: Gehn Shard.
You really need to start trusting your community of programmers here as they've been doing the grunt work of fixing and improving the client for a very long time now.
I know a full integration won't be perfect at first, but you have excellent programmers here that can help you smooth out the wrinkles after things have finally been caught up.
DeledriusToday at 9:09 AM
"Some of it -- changes in behavior or environmental interaction (configuration, tolerance for previously disallowed inputs, etc) needs deeper understanding for me to know what we're getting. That will take some time, and will be when I will most benefit from having skilled and experienced guides through the code."
As for this, we tend to have pretty thorough discussions back and forth on all of these changes, and make sure they don't adversely impact other things (at least not without very good reason, and minimally so). It's unfortunate that you haven't participated in them, because it would save a lot of this rediscussion happening solely for your benefit, sometimes years later, when the topics are no longer fresh in our minds. I don't see your name in the list here (
https://github.com/H-uru/Plasma/watchers), but I'd recommend setting a watch on the repository in order to keep up with things as they happen and actively participate. You'll be sent notifications on PRs and such (should you set it to).
We're certainly willing to dig back (as you've seen) and explain or find changes from all the work done so far, but I think it would really be great if you were able to at least participate in the active changes going in as the decisions are being hammered out. At the very least, I hope the PRs and commit messages generally do a preliminary job of explaining themselves.
[9:09 AM]
I absolutely understand your desire to make sure everything that's entering the OU-CWE repo with your stamp on it has your approval and understanding. I think the current way of doing things has made this slower than it needs to be; if you are able to find some time to participate in the discussions as they happen, you'll have an active familiarity with the solutions and why they were chosen much more organically.
I'm sorry if this comes across a bit bluntly but I hope you can see why this feels redundant at times, and I don't mean to be rude about it. I do really think it would be wonderful to have you engaged more directly with the code changes and discussions as they occur rather than long after the fact.
rarifiedToday at 9:11 AM
@Deledrius and @Doobes thanks for taking the time for those extended replies. As is my custom, now is the time to say "Something this long is a discussion and should be continued in the forum". I may even cut and paste your comments into the threads.
DeledriusToday at 9:11 AM
Yeah, I was thinking that too.
rarifiedToday at 9:11 AM
But let me be clear -- I don't doubt the programming skill of the H'uru team at all.
DeledriusToday at 9:12 AM
Feel free, we can continue there if you wish.
rarifiedToday at 9:12 AM
The code changes I've seen have been very well thought through, and executed.
[9:13 AM]
My main consideration is coming to understand the goals of the project as a whole -- what non-fix changes are intended to accomplish, who the change benefits, and who the change impacts.
DeledriusToday at 9:13 AM
Indeed.
[9:13 AM]
It might be best to classify the PRs in that regard, and treat them atomically that way.
[9:13 AM]
We (almost always) do atomic PRs, which should help a lot.
rarifiedToday at 9:13 AM
With CavCon as low as it is, I have to try to look at any client update from what I perceive as Chogon's and Cyan's perspective and needs/wishes.
[9:14 AM]
To reduce the amount of time Chogon has to go "Hmmmm..."
DeledriusToday at 9:15 AM
Do we know what the biggest cost is? Is it the data hosting/bandwidth? Perhaps that could be addressed to make Cyan's server more viable for them cost-wise.
DoobesToday at 9:16 AM
Plus, Chogon could always come onto Minkata(-alpha) to do any "Hmm"ing before it hits their staging server.
DeledriusToday at 9:16 AM
With the exception of a couple of very specific changes, we've been exceedingly careful to maintain backwards compatibility, and those things should be manageable (as discussed on the forum) so that the client is perfectly fine from "Chogon's and Cyan's perspective". If we had specific metrics, we could be more specific.
dpogueToday at 9:19 AM
My understanding is that, with OU building the client, Cyan's/Chogon's involvement would mostly just be uploading those builds to staging, doing some community-assisted testing, and then uploading it to the live server?
DeledriusToday at 9:19 AM
That was my understanding as well. Is that accurate?
DoobesToday at 9:19 AM
That's what I figured too, @dpogue . That's why we have two Minkata shards, I believe.
DeledriusToday at 9:19 AM
Three layers of testing before MOULa Live.
[9:20 AM]
That's not counting the many years most of the code has lived in production on Gehn.(edited)
rarifiedToday at 9:20 AM
I can't answer that from an official Cyan position. But as a pathological example I don't think it would go over very well to upload a client that plants a virus. (Not in any way implying the Huru client does).
DoobesToday at 9:21 AM
Yep, as I said, Gehn Shard is a prime example of all the H'uru fixes in action.
rarifiedToday at 9:21 AM
But, please "To the Forum!"
DeledriusToday at 9:21 AM
(In which case, it's gone through testing on local systems, Gehn Beta, and then proven in production on Gehn, before going through Minkata-alpha and Minkata and MOULa-Staging)
I would hope we'd find major incompatibilities before then.
DoobesToday at 9:21 AM
Why would a client upload a virus? I don't believe that has ever happened.
DeledriusToday at 9:21 AM
Ah, yes, the forum.
dpogueToday at 9:21 AM
The problem with the forum is that stuff sits there with no response for years
[9:22 AM]
We've had this conversation 3 or 4 times on the forum
rarifiedToday at 9:22 AM
@dpogue I do try, I really do. But it's only me.
[9:22 AM]
Right now there are three of you.
DeledriusToday at 9:22 AM
That is certainly a pathological example, and the amount of testing and eyes on the code are here to prevent precisely that. The only way for the client to be distributing a virus would be if Cyan added it to their manifest, outside of RCE exploits.
DoobesToday at 9:23 AM
This we understand, @rarified . We are trying to save you a lot of work and headaches others have already gone through, if possible.
DeledriusToday at 9:23 AM
I mean, code obfuscation puzzles aside, of course, but that's an NP problem...
[9:24 AM]
@Doobes Not much to be done about the work needing to currently being redone, but my suggestions were more about heading off more of the same in the future and maybe reversing the flow of code debt.
DoobesToday at 9:25 AM
Oh yes. We could definitely use you in some current discussions, rarified. Everyone's thoughts are welcome...including mine, which is quite generous of them.
DeledriusToday at 9:26 AM
Thankfully we have players and artists participating in the IRC channel, so we get at least a rough sampling of different perspectives when we devs have questions. :p
dpogueToday at 9:27 AM
@rarified Why is it just you? Lots of people have offered on multiple occasions to get involved so it's not solely your responsibility, and those offers have also received no response
DoobesToday at 9:27 AM
Please remember though, @rarified , it's not "just you"...quite the contrary. You have the community here behind you, but you need to let us help.
dpogueToday at 9:29 AM
It's frustrating for you, because there's an ever-growing mountain of insurmountable changes that need reviewing as well as Minkata shard admin and real life
It's frustrating for us, because we have expertise with this codebase that's being ignored when we offer to help, and bugfixes that have been waiting for almost 10 years to see the light of day
rarifiedToday at 9:29 AM
Discussing the topic of trust is a tricky thing to conduct in a public forum. I usually agree with the "sunshine is the best remedy" but sometimes human frailties get in the way.
dpogueToday at 9:30 AM
Every time we ask how to improve things, we get stonewalled with vague answers about undefined Cyan requirements, or lack of people/time, or just never responded to
DoobesToday at 9:34 AM
We understand it's a lot of stuff...but that's all the more reason to just update to what's current, ask questions where needed, smooth out the wrinkles with all of our talents, then come on in to participate in any future discussions. You would be very welcome and we most definitely want you to be a part of all this as you have expertise and are an important part of this process.
And again, if Chogon or Cyan want to peek in on what we're cooking before we serve it on their table, they can come over to Minkata...either flavor.
DeledriusToday at 9:34 AM
I want to help get things caught up. That's the goal.
DoobesToday at 9:35 AM
Absolutely.
DeledriusToday at 9:35 AM
I am 100% in understanding of wanting to make sure everything's kosher. I would do the same in your shoes.
DoobesToday at 9:36 AM
Well, you've seen that people are willing to test the heck out of things if we give them the signal. I'm sure they'd do the same with a major client update. Again, it won't be smooth at first, but we can smooth it out as we go. Be a more complete team!
dpogueToday at 9:39 AM
(Aside: I do actually think the discussion about these concerns and solutions should happen on the forum, which is better suited to longer-form asynchronous discussion that can be referred back to more easily. It just can't be taken to the forum and then ignored to death again.)
DeledriusToday at 9:41 AM
::Exeunt, Pursued by a Bear::
rarifiedToday at 9:42 AM
Ok, ok... It would help me to throttle the inflow of ideas for a bit. I'm trying to empirically determine the best way to get past the stability issue on the current client and am deep in VS documentation, Gooies, and platform command prompts. I can't keep shifting two displays to the left to watch Discordant blurs
DeledriusToday at 9:42 AM
Understood. Didn't mean to derail the current work!
rarifiedToday at 9:43 AM
(Oh and putting the OU forum on auto-refresh to catch @dpogue's testing that I watch the topics )
DeledriusToday at 9:45 AM
Please do consider Watching the Plasma repo on Github to keep up with the PRs and Issues as they arise. Good luck with the Schrödinger's Debug Build (I hate that problem).
DoobesToday at 9:46 AM
Indeed. Hopefully the problem isn't too difficult. Really, this is discussion of moving forward once the new client if properly fixed and fan Ages are finally on MOULa. Hopefully, that will rekindle interest and draw in more help and interested parties.
rarifiedToday at 9:46 AM
Actually I do have Fisheye watching the Plasma repo, and occasionally have time to look at activity there.
[9:47 AM]
https://foundry.openuru.org/fisheye/browse
