Shop Inventory Filling - Possible Coding Mistake

Discuss coding questions, pull requests, and implementation details.
User avatar
Rand
Posts: 72
Joined: Sat Nov 23, 2019 5:10 am
Location: Canada

Re: Shop Inventory Filling - Possible Coding Mistake

Post by Rand »

Ralzar wrote: Thu Nov 28, 2019 10:21 am And maybe have shop quality affect selection? If we're talking about modding this.
It actually already does, to a very limited extent, but for broad categories of items, not materials. But yes, eventually.

I just want to start with the most basic general adjustment to get the rates reasonable for everyone as a basic mod. Then, as my skillset grows, look into coding a different system, which is what the system you'd like requires.
At present, doing either would require compiling essentially a forked build, which is sub-optimal mod-wise, so it's dependent on the devs allowing access to these systems for modding, which is a ways off, according to them.

User avatar
Rand
Posts: 72
Joined: Sat Nov 23, 2019 5:10 am
Location: Canada

Re: Shop Inventory Filling - Possible Coding Mistake

Post by Rand »

The more I think about it, the more I don't understand the meaning of this outlier:

public static byte[] itemGroupsTemple = new byte[] { 0x0C, 0xFF, 0x02, 0xFF };

Women's clothing, and armor, both FFs for chance.

Now obviously, the 0xFFs are signed 8-bit signifying -1s, but why? :?

Is it actually used? Some sort of placeholder, or foundation for data that is edited in-game (changing item sets and/or chances)?

Weird.

User avatar
Hazelnut
Posts: 3015
Joined: Sat Aug 26, 2017 2:46 pm
Contact:

Re: Shop Inventory Filling - Possible Coding Mistake

Post by Hazelnut »

Rand wrote: Wed Nov 27, 2019 10:10 pm
Hazelnut wrote: Wed Nov 27, 2019 2:18 pm It certainly is odd that daedric is more common than the two materials that precede it, but I am not convinced it's a bug or error. It might be, but I think like some other peculiarities it may have been intentional. I doubt we will ever know for sure. Personally I don't feel this is clear cut enough to be considered a bug that should be fixed in DFU, but I might be in a minority there.

This was actually one of the motivating factors for the new quest and armour service for FG members (and later to be extended to KOs) that I've developed for the Roleplay & Realism mod since it's really hard to complete an Orcish or Ebony set of armour.
gimble's analysis convinced me that it's basically a bug:
viewtopic.php?f=5&t=2656&start=10#p31680

But the question is: is it policy to stay as true to the original as possible?
My vote would be an unqualified yes, and so to leave it as-is in the default code, but also to expose the numbers to allow mods to rebalance them.

To this end, I already set up a spreadsheet to work the numbers myself. It's not too hard to find ones that give more reasonable results, differentiating materials by level more evenly, and moving Daedric and such to the higher levels they belong at in a levelled world.
Thanks for your replies Rand, I think I'm clear now about what you're saying. As for policy for DFU, it's been to recreate classic DF with QoL updates. Having said that there are some light touch gameplay changes in the options. I think that DFU should continue to replicate classic behaviour, and either we expose this stuff to have a mod change it to what we think was probably the original intent, or DFU gets another option or two for it. Pretty sure Interkarma is not keen on adding more options into base DFU so probably the former, but we should wait for his opinion - I don't want to speak for him. There's also the added benefit of allowing multiple interpretations if it's opened up for modding too. I can do the dev work, but not sure when I will get to it. (hopefully over xmas hols)
See my mod code for examples of how to change various aspects of DFU: https://github.com/ajrb/dfunity-mods

User avatar
Rand
Posts: 72
Joined: Sat Nov 23, 2019 5:10 am
Location: Canada

Re: Shop Inventory Filling - Possible Coding Mistake

Post by Rand »

Hazelnut wrote: Thu Nov 28, 2019 8:48 pm Pretty sure Interkarma is not keen on adding more options into base DFU so probably the former, but we should wait for his opinion - I don't want to speak for him. There's also the added benefit of allowing multiple interpretations if it's opened up for modding too.
Leaving aside the shop code for a moment...

Yes, I agree. For those reasons, I don't think options in the settings is the way to go, and it also adds little value alongside a lot of possible confusion (to the uninitiated) as to what the effect is in-game. Mods "fix" it better.

Because it isn't either broken or a bug, really. There's nothing mathematically wrong with the material generation numbers, it just wasn't optimized for the final play experience, causing some materials in the mid-late list having sharply reduced rates of generation.

My research and number-crunching has revealed to me that while adjusting the numbers themselves can basically "fix" the problem, it doesn't completely negate it, and the numbers in that list can't be adjusted individually (without making the problem worse). All the numbers short of the final one need to sum to at most 254 (at least with the current code limiting the maximum bound of the player level modified "roll" number to 255). And I was wrong in my initial assumption: It doesn't matter what the final number (for Daedric) is. The 5 is arbitrary. Any number other than 0 produces the same result as it does now (and 0 causes Daedric to be unable to appear).

Unfortunately, a really satisfying fix would require the adjustment of at least the maximum bounding number (if not some other code as well around line 116 of ItemBuilder.cs), in conjunction with a complete adjustment of the chance numbers. This is too much for an option setting.

Unlevelled worlds will require a complete overhaul to this generation code, unfortunately. Although as Ralzar says, it would be very simple to make all types above a certain level disappear completely; all you'd have to do is make sure the numbers up to the point you want them to stop add to 255 or more, and those after them can never be generated. 0s should work, too.

Post Reply