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

[Feature Request] Add some api for register the external modules properties #263

Open
p4535992 opened this issue Feb 2, 2023 · 1 comment

Comments

@p4535992
Copy link

p4535992 commented Feb 2, 2023

Simple case I want to add in the suggestion list flags.xxx.yyyy from the module with id zzzz, but just for the effect change list is there any way to do it from the api ?

If not is there you can insert something like this ?

let moduleIdOrSystemId = "zzzz"; // useful for help to understand what module or system use this ? e.g. flags.xxx.yyyy (zzzz)
let propertyKey = "flags.xxx.yyyy"; // the property key to suggest
let enabledOn = ["effect"]; // useful for let the other module developer tell you if  is just a property for active effect or a property for the item ecc.
game.modules.get("autocomplete-inline-properties").api.addProperty(propertyKey, moduleIdOrSystemId, enabledOn)

I think something like this could help developers a lot to create suggestions.

If this interests you , but you don't have time to devote to it I can try to prepare a PR

@p4535992 p4535992 changed the title [Feature Request] Add some api for regietr the external modules properties ? [Feature Request] Add some api for regietr the external modules properties Feb 2, 2023
@p4535992 p4535992 changed the title [Feature Request] Add some api for regietr the external modules properties [Feature Request] Add some api for register the external modules properties Feb 2, 2023
@ghost91-
Copy link
Collaborator

ghost91- commented Feb 7, 2023

The way autocompletion entries are gathered for most systems, this doesn't make much sense. The entries are usually collected by recursively checking the actual data of the affected actor, so any flag that is in there is already being listed anyways. Granted, this does of course not work if the flag is not set (yet), or if you are editing effects on an unowned item (that's really a separate issue, though). But that's the current implementation, and just adding individual properties to that doesn't make a whole lot of sense, because it's a fundamentally different approach.

I'll think about whether something like this might still be useful, but to be honest, I don't think so. What's the actual use case you are thinking of, that's not already covered due to the actual data of the actor being used?

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