Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Entity Data Allow/Warn/Disallow Lists #70

Open
jason-e opened this issue Jan 7, 2025 · 3 comments
Open

Entity Data Allow/Warn/Disallow Lists #70

jason-e opened this issue Jan 7, 2025 · 3 comments

Comments

@jason-e
Copy link
Member

jason-e commented Jan 7, 2025

There are some entity types (and maybe inputs/outputs or other data) that we offer in the game for fun/experimentation purposes but do not want to allow in official maps. Lumper should be able to automatically detect these using handmade lists (Allow, Warn, and Disallow).

There are three depth levels we could target with this:

  1. Classnames
  2. Classnames and Entity I/O
  3. Classnames and all keys/values

For now, we can start with just filtering entity classnames into the Allow/Warn/Disallow lists. This may very well be sufficient so we should wait and see before delving into other keys/values which would be considerably more involved to both support in Lumper and maintain the lists.

There should be some table view in Lumper that lists all classnames found in the map and which list each is found under (or none if not on a list yet). Items under "Allow" can be hidden. Buttons (inline next to each item?) can be used to add the classname to a list or change the list it is on (items should only be on one list).

It might be nice to support including a comment with each item added to the Warn or Disallow lists to explain why it is there, especially for "Warn" where any classnames on that list should undergo some sort of manual review.

It should be possible to select an entry in the table and further dive into the full list of matching entities including their keys and values for reviewing (editing not necessary here).

These lists will be saved to a local configuration file which we will periodically upload to some official server (taking care to first merge changes with others if the lists are worked on collaboratively). Lumper could maybe be able to download the latest version of this file (either automatically or manually) -- though before long, the lists should be pretty stable so a built-in way to download it as a convenience might not be necessary.

Once the lists are relatively stable, it would be nice to also have the game use the same lists when an unofficial map is loaded to check the entities and alert the user which entities are not allowed in official maps.

@tsa96
Copy link
Member

tsa96 commented Jan 10, 2025

Was wondering if we could integrate this into the Entity Editor view, but I think doing a separate page is reasonable, will be helpful for quick review.

Buttons (inline next to each item?) can be used to add the classname to a list or change the list it is on (items should only be on one list).

So are you saying users should be able to modify the list locally within Lumper? Not sure what the advantage of this is over just manually modifying the configuration file, if possible to just edit a JSON config file I think that'd be better

  • Relatively few people will be responsible for changing this
  • There's not a huge number of entities
  • Will have to mess with the configuration as text anyway when merging configurations in Git
  • UI for setting comments sounds a bit tricky
  • Good to make clear to porters that the entity list is fixed -- they shouldn't get to alter the configuration just because they want to use the entity or whatever. I worry that making it editable confuses two different usages
  • Is the "Allow" list even really needed?

This is quite a large feature so not sure if we have any contributors besides myself who'd be likely to work on it. Will probably be at least a month until I get the opportunity, I'm expecting to be spread very thing leading up to 0.10.0 release. If someone is interest definitely let me know, we should talk through the technical implementation first. Some notes on that:

Configuration can be JSON using standard Newtonsoft.JSON serialization approach (grep for usages of JsonSerializer).
If we're just doing classnames, we probably want something like:

public class EntityRule
{
  public enum AllowLevel
  {
    Allow = 0,
    Warn = 1,
    Disallow = 2
  }

  public AllowLevel Level { get; } = AllowLevel.Allow; // need setters if we do in-editor editing
  public string? Comment { get; } // as above
}

then at runtime store in a Dictionary<string, EntityRule> where string is the classname.

Not 100% sure the best way to load entity rules list, would be good to potentially allow CLI usage in the future so I'd keep the list loading stuff in Lumper.Lib, similar to my incoming asset manifest stuff.

UI can be an Avalonia DataGrid

@jason-e
Copy link
Member Author

jason-e commented Jan 10, 2025

Manual editing is probably fine, yeah.

I want to have an explicit "Allow" list so everything has to be categorized, and anything not categorized will stand out. I guess if it's only classnames to start (or possibly forever) then its not that hard to account for every classname up front, but it doesn't seem that complicated to explicitly allow things and then it's totally bulletproof.

And I don't know much about Lumper or what the code looks like but I would have figured this would be pretty easy (read JSON, iterate each classname in the map, and put it in a table). Even just listing the classnames without any breakdown from there would be useful.

@tsa96
Copy link
Member

tsa96 commented Jan 10, 2025

Yeah table isn't hard at all, and I think more practical than integrating with the entity editor page. Also I really like keeping the different tools separate, and if someone's not doing entity review stuff (e.g. using for something other than map porting) they can just ignore that page entirely.

Fair point with the "Allow" thing, that's fine to do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants