Talk:OBSIDIAN

RNG method

When this article was created yesterday, one of the Features listed was the different RNG from OBLIGE. I was curious what this was, so I looked into the GitHub repo, and it appears that Mersenne Twister was retired to the "attic" a few months ago and replaced by fastPRNG. (This means it's currently incorrectly stated in the Obsidian README file and thus this article is out-of-date too.)

At this point, I don't think it's worth listing as a feature, since either RNG is probably good enough randomness for this tool. But the new one being faster would make sense for less time to make maps.

(This is in contrast to the replacement of Carmack's very basic RNG for vanilla Doom with Mersenne Twister in ZDoom long ago. That's a big step up in terms of RNG quality worth noting in that article. Plus it's a popular source port, so it's fundamentally more significant.) --PhilthyPhilistine (talk) 19:59, 2 March 2022 (CST)

To clarify, the original RNG method was actually a custom RNG by Andrew Apted called AJRand. It was a merger of multiple low-quality RNG's to produce a number that had a lot of bias. We initially introduced Mersenne Twister to get higher quality numbers replacing AJRand. Out of another user's concern though, we eventually settled with fastPRNG/xoshiro for performance reasons. Truth be told, AJRand on its own was sufficient for the purposes of a map generator but since the new work is already there and we just prefer larger numbers with lesser bias, there's currently no point going back to AJRand. The README file is frequently out-of-date due to the rapid pace of changes unfortunately.

That aside, seeds can now also be input as strings rather than just numbers, something that was not originally available to Oblige and that fastPRNG is also driving the number gen for our SLUMP variant. MsrSgtShooterPerson (talk) 21:05, 2 March 2022 (CST)

Thanks for explaining this. I actually briefly looked at the AJrand code when I poked around your attic last night. Even though it was good enough, it's cool you now have better and faster RNG. I tried Obsidian a bit last summer and had some pretty good results, so I'll probably use it again sometime down the road. (I still have a number of person-made mapsets in my queue first.)

As for this article, I don't think the more flexible seed inputs is a big enough feature to mention in the list. (Definitely a nice improvement to the tool, though. I appreciate the work you and others are doing on it.) --PhilthyPhilistine (talk) 10:27, 3 March 2022 (CST)

You really seem dead-set on not thinking this is a notable feature, despite providing a unified RNG for Oblige and SLUMP and strings as seeds. For the sake of consistency, are you going to remove string seeds as a notable feature from the ObHack page as well? Dashodanger (talk) 13:17, 3 March 2022 (CST)

I agree and do not see a worthwhile motivation here. Since when do we nitpick feature lists? Most of the ones that exist on the wiki are copy-pasted from the port or tool's readme file with only minor adjustments at best. Arguing with the authors of the tools themselves is not healthy community building here. Seed behaviors and RNG are the core of anything which does randomization, how can it not possibly be relevant? Dashodanger: I suggest you restore it to the way you wanted it. If it's changed back afterward I will consider it edit warring. --Quasar (talk) 13:24, 3 March 2022 (CST)

No, not "dead-set" on excluding it, though I do tend to be frank, so it may seem that way. And how did I argue with anyone? I just stated my opinion. --PhilthyPhilistine (talk) 14:16, 3 March 2022 (CST)

SLUMP had its own, even worse RNG implementation, so mentioning that it does use fastPRNG is relevant.Dashodanger (talk) 15:12, 4 March 2022 (CST)

Relevant from a design perspective, but of scant signficiance from an end-user perspective. If the tool works well enough and generates fun maps, what difference does it make. And, as I stated in my edit comment earlier today - it was sensible development to unify the RNG in Obsidian for seed consistency and whatnot. You have full control of the source code, after all. --PhilthyPhilistine (talk) 15:32, 4 March 2022 (CST)

The old RNG was biased towards certain patterns of numbers. The RNG determines almost every facet of the generated map, including things like prefab and shape grammar pattern selection. When there are biases in the numbers generated, they will manifest as biases towards certain maps shapes and prefabs. So, one benefit for the end-user is a better quality end result. Another benefit to the end-user is that with a higher-quality RNG

implementation, we were able to eliminate the need to re-seed, reducing the number of Lua calls during a map gen run by hundreds if not thousands. Also, for the end-user, they have the benefit of an exponentially higher

number of potential seeds, which may be a "scant" thing to you, but is vocally appreciated by our user base. Moving to a unified generator brings many of these same benefits to SLUMP as well. We have given you many

reasonable statements as to why we feel the new RNG implementation is a notable feature, yet you continue to be fixated with downplaying its value. I am going to change it once again, and ask that you refrain from

nitpicking as was mentioned previously.Dashodanger (talk) 18:28, 4 March 2022 (CST)

Apparently I have to be pushed to show that I mean what I say when I say it. --Quasar (talk) 19:14, 4 March 2022 (CST)

Node builder

Question: How does the change of node builder affect the map output? For context, I've never made a map for any video game. (I first encountered the terms "node builder" and "spatial grammars" when I started working on these articles 2 days ago.)

Follow-on: If the change of node builder is not much of a difference, is it worth keeping in the Features list for educational purposes? --PhilthyPhilistine (talk) 10:33, 3 March 2022 (CST)

ZDBSP is significantly more featured/modernized and is required for things such as UDMF support so it is absolutely a relevant detail. --Quasar (talk) 11:06, 3 March 2022 (CST)

Thanks for explaining. In the Features list, I merged the UDMF item with ZDBSP since they're directly related. --PhilthyPhilistine (talk) 11:12, 3 March 2022 (CST)

I don't think that was necessarily appropriate. ZDBSP does not automatically mean a tool supports UDMF; a lot of additional work is required for that. It's a prerequisite; necessary, not sufficient on its own. --Quasar (talk) 11:16, 3 March 2022 (CST)

UDMF, as mentioned, involved a lot of work converting from the binary format used everywhere else throughout the program. In addition, we use ZDBSP to provide more granular node-building options for various ports that can support them (Compressed nodes, extended nodes, etc). They are related, but distinct topics. Dashodanger (talk) 13:18, 3 March 2022 (CST)