search

tsitu / MH-Tools

Assortment of MouseHunt utilities
https://tsitu.github.io/MH-Tools/
Apache License 2.0
29 stars 35 forks source link

More detailed population structure #61

Open groupsky opened 6 years ago

groupsky commented 6 years ago

In Iceberg the population is affected by several bases, while in ZT the population is affected by several weapons. These cases currently are handled in code with some complicated ifs.

I suggest to include columns for weapon and base in population data and similar to charm column these would be used in cases where specific weapon/base affects the population. The CRE and setup ui could also list these special values on top, again similar to charms.

Mistborn94 commented 6 years ago

@groupsky @tsitu I've been working on the POC to rebuild these tools in Angular and figured this needs to be done right from the start.

I have an idea, but need some input : Proposed Json Structure Sample File

image

Proposed CSV structure: Sample File

image (Possibly moving sample sizes to a separate file - all parsing logic happens during the CI build anyway)

Any suggestions/comments?

groupsky commented 6 years ago

If I get it right, the idea is to have one special field that augments population - what happens if there are two different parts, like charm and base?

Mistborn94 commented 6 years ago

Thats why I'm asking for comments :)

The reason why I didn't want to stay with the old (json) structure where everything is nested in everything else is that it could become really complex with some fields having defaults and having to check all possible combinations. And if we add additional population altering effects (eg. Auras/ BW Rift curses), that structure becomes even more complex. I tried to make my structure somewhat more flexible.

I though some sort of combined key might work - but it might suffer from the same kind of problems. As for the CSV structure - It might be possible to keep that more like the old one and cater for the combined cases in the parsing logic...

You can see my current population selection logic here (If you are not familiar with rxjs - it selects the first of Charm/Weapon/Base/Basic that has a value).

If you have a different suggestion - please elaborate.

Also, do we currently have locations where a combination of items affects the population?

groupsky commented 6 years ago

The reason why I didn't want to stay with the old (json) structure where everything is nested in everything else is that it could become really complex with some fields having defaults and having to check all possible combinations. And if we add additional population altering effects (eg. Auras/ BW Rift curses), that structure becomes even more complex. I tried to make my structure somewhat more flexible.

What if during build, a structure for the special charms/bases/weapons is also build? That can be used only for the UI fields, while the actual population data could still be the old hierarchical structure.

I though some sort of combined key might work - but it might suffer from the same kind of problems. As for the CSV structure - It might be possible to keep that more like the old one and cater for the combined cases in the parsing logic...

IMO the current CSV structure is easy to work with many instruments, so I think it's good to keep it that way.

You can see my current population selection logic here (If you are not familiar with rxjs - it selects the first of Charm/Weapon/Base/Basic that has a value).

The logic is sound and I like the simplicity with rxjs - allows for overriding of specific mice that change. One suggestion though - if you normalize the population after selecting it, will be better as we could increase/decrease only some mice population and that would automatically affect the rest. Another problem would be to correctly generate this data from the samples that can be extracted from HT/Jack's DB.

If you have a different suggestion - please elaborate.

I was faced with the problem of having multiple items affecting the loot and my solution was similar - I use overrides per loot item, but I still use the nested structure as I didn't need anything for the UI and just extended it to include trap and base. That allowed me to model all loot affecting scenarios at the cost of making 128 (O(2^n) where n is the depth of nesting) iterations inside the array - I have an idea how to optimize this down to around 14 (O(2n)) but haven't gotten down to write it, and doesn't seem to be slow.

The problem you're describing is that it's hard to create the UI, because the data structure is hard to traverse. I think this could be handled separately as I described above.

I think a great solution should:

  1. be able to handle all possible scenarios
  2. allow the UI to be generated/populated with ease
  3. be reusable

Also, do we currently have locations where a combination of items affects the population?

I just checked the cre code and it seems only Iceberg has the base as population affecting. I guess the devs also find it difficult to build all the different population affecting attributes :smile:

groupsky commented 6 years ago

Just an idea - what if we use the IndexedDB or any of the other db libraries?

Mistborn94 commented 6 years ago

The issue is not only the UI, but checking all "possible" combinations. I guess some sort of 'is special' check before would reduce the number of combinations -I like the idea of generating that list during the CI build.

For now I just store all population data in the redux store - if it becomes infeasible we can always investigate indexedDb - but I don't think that solves the structure challenge?

If we decide to go the indexedDB way and don't want to struggle with it - localforage seems like a simple to use abstraction