DragonKnightOfBreeze / Paradox-Language-Support

IDEA Plugin: Paradox Language Support.
https://windea.icu/Paradox-Language-Support
MIT License
36 stars 4 forks source link

Allow somehow through cwt configs to generate pseudo definitions for scripted effect, game concepts etc. #77

Open adriangaro opened 3 months ago

adriangaro commented 3 months ago

It is often the case to avoid boilerplate code i have to call to using inline_scripts to avoid repetitive definitions, especially for stuff life game_concepts, economic categories and so on.

For example i have the below inline

# concepts/tec_district_concept

concept_tec_$district$$suffix$ = {
    alias = { 
        concept_tec_$district$$suffix$_plural 
        concept_tec_$district$$suffix$_icon 
        concept_tec_$district$$suffix$_plural_icon 
    }
    icon = "gfx/interface/icons/districts/$icon$.dds"
}

and it is invoked as

inline_script = {
    script = concepts/tec_district_concept
    district = district_tec_eco_farming
    suffix = "_machine"
    icon = district_tec_eco_farming 
}

But due to its nature of using interpolation and inlines, the concepts will no be available for autocomplete in localisation, and will show errors.

Would be nice to somehow be able to say that if this inline is called, expect this definitions to exist, maybe by providing a string template for the name, although probably hard. Alternatively maybe just infer new definitions from inlines.... but that might need them to actually be evaluated more thoroughly which seems more complicated (should be doable since technically the parameters are static)

DragonKnightOfBreeze commented 3 months ago

Definitions in inline script files are not yet to be indexed

DragonKnightOfBreeze commented 3 months ago

So what you want is (are) ?

  1. Indexing definitions in inline script files.
  2. Indexing definitions (and other things) in inline script files after parameters inlined (if possible)
  3. Provide a way to specify definitions that will be declared in inline scripts / parameters by extended configs (and definition names can be matched by wildcards)
  4. Provide a way to ignore 'unresolved xxx' if related extended config exists (code completion should be already available)
adriangaro commented 3 months ago

1 and 2 would be the most ideal, making 3 not needed at all. 4 on its own could be useful for compatibility, to not have to make dummy declarations.