Conversation
Create initial wip / proof of concept for battle plando with json export/import for changes manually
Building out further UI functionality but still having many binding errors
Build out further UI editing functionality
FF13/DataStoreWDB.cs
Outdated
| public List<string> Keys => Entries.Keys.ToList(); | ||
| public List<T> Values => Entries.Values.ToList(); | ||
|
|
||
| public List<KeyValuePair<string, T>> Entries => Data.Keys.Select(k => KeyValuePair.Create(k, Data[k])).ToList(); |
There was a problem hiding this comment.
I might need to change this now that you adjusted how some of the entries stuff works behind the scenes...
There was a problem hiding this comment.
yeah this would need to go through a refactor...hopefully for the better?
| return t.GetData(orig ? treasureRando.treasuresOrig[key] : treasureRando.treasures[key]); | ||
| case TreasureRando.BattleData b: | ||
| BattleRando battleRando = treasureRando.Randomizers.Get<BattleRando>(); | ||
| if(battleRando == null) |
There was a problem hiding this comment.
stuff like this is a good argument for having the plando functionality for a sub-randomiser in the same class really since a lot of it ends up being duplicated/shared.
There was a problem hiding this comment.
See comment on the Plandomizer class where we can make an IPlandomizer interface to reuse code and make BattlePlandomizer inherit BattleRandomizer.
That should make it so that Randomizers.Get<BattleRando>() pulls whichever type is loaded (normal rando or plando).
There was a problem hiding this comment.
For the most part this is basically a clone of BattleRando with some unused stuff taken out. made rebasing easier by accident lol, but argument to be made for putting it back in the main class.
There was a problem hiding this comment.
I would be ok with it being its own class as per other comments.
Bartz24
left a comment
Bartz24
left a comment
There was a problem hiding this comment.
It looks like a good starting point. Primarily need to determine how we should reuse code. Either a separate plando class or just add to the rando class. I'm leaning towards a separate class similar to how it is here.
| return new Dictionary<string, HTMLPage>(); | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
We can probably make the Plandomizer an interface and then have each plandomizer inherit from the randomizer and IPlandomizer.
That way we can reuse code in both that does not use the plando.
Ex: class BattlePlandomizer : BattleRandomizer, IPlandomizer
| return t.GetData(orig ? treasureRando.treasuresOrig[key] : treasureRando.treasures[key]); | ||
| case TreasureRando.BattleData b: | ||
| BattleRando battleRando = treasureRando.Randomizers.Get<BattleRando>(); | ||
| if(battleRando == null) |
There was a problem hiding this comment.
See comment on the Plandomizer class where we can make an IPlandomizer interface to reuse code and make BattlePlandomizer inherit BattleRandomizer.
That should make it so that Randomizers.Get<BattleRando>() pulls whichever type is loaded (normal rando or plando).
There was a problem hiding this comment.
I would be ok with it being its own class as per other comments.
FF13/DataStoreWDB.cs
Outdated
| public List<string> Keys => Entries.Keys.ToList(); | ||
| public List<T> Values => Entries.Values.ToList(); | ||
|
|
||
| public List<KeyValuePair<string, T>> Entries => Data.Keys.Select(k => KeyValuePair.Create(k, Data[k])).ToList(); |
There was a problem hiding this comment.
yeah this would need to go through a refactor...hopefully for the better?
2 participants
No description provided.