Feature Request: Support of xml patch files about rwxml-language-server

[Wolfsblvt]

the real problem is, what should we need to do if we want to support features for <value> node?

yeah, I think the other questions are more or less answered, and pretty straightforward. (Not meaning easy, but pretty defined what should happen)

Being able to analyze the contents of an xpath patch, so what is inside the <value> tag likely is... crazy.
There are so many different possibilities what can be written there.

I mean if we talk about knowing where that patch is applied, you could know what the referenced fields and their classes are to, so it would work similarly to a normal def. But how much work would that be? Sounds a bit crazy.

Dunno, based on an xpath if you understand if it's a Def or what kind of def and how many layers you are into, you could work on that, doesn't need to have the actual Def in memory even.
Example. You are doing a patch replace on /Defs/ThingDef[defName="MealSurvivalPack"]/ingestEffect You should know this targets a ThingDef, and that the ingestEffect attribute is part of the EffecterDef class.
So the patch value that is applied should be able to highlight EatMeat and EatVegetarian, whatever is written there, because it knows that those defs are placed there.

This would be the most complete way to achieve this I guess.

---

Another possibility would be to just "name-match" defNames and Names inside that value tag and fields inside, whatever you can find there. This would be the "good enough" solution. Because most of the time you only want to get those actual references linkable. You would miss the type checking and all, that's true, but it's better than nothing.

I don't know if it's worth to invest this much work to pick apart actual xpath elements.
I can't really guesstimate the work needed for that.

[Wolfsblvt]

Having the parsing only work if defName is provided in the xpath would be a decent option I guess. That should cover most cases anyway. If you could include the @Name for abstract classes as well and be able to parse the or concatenations, I think this covers nearly all of the cases.
So those things from the Wiki

@ select by attribute. Useful for patching (Abstract) bases.
/Defs/ThingDef[@Name="BuildingBase"]
or is inclusive.
/Defs/ThingDef[defName="Cassowary" or defName = "Emu" or defName = "Ostrich" or defName = "Turkey"]

let's start with adding reference to xpath. it's the most concrete thing of things that we discussed.

Yeah, reference to xpath is also much more important and helpful, I'd say. Agreed!

[Wolfsblvt]

Now that I worked a bit more with patches in the last days, I think there is another thing that might be really useful as well.
Writing it here, as it is about patches as well, but can open a separate issue.

It's xpath validation.

There are tools out there who validate if an xpath is correct, but having all the meta info about rimworld defs already at hand, you could validate whether an xpath will match samething, and if so, what exactly and how many places.

Something like "this patch will be applied to X defs" and then a list of those defs if you click on it.

The Muffy bot on the Discord server does something like that already, dunno how that works:

[zzzz465]

I haven't seen muffy's source code, but there are some possible ways to achieve that I guess.

• merge all XML data to single file and execute xpath search (no file path will be displayed though)
• execute xpath file by file while iterating all files
• use actual rimworld code to find things (highly doubt)
• or some other way I don't know?

[zzzz465]

btw, in order to implement this feature, we have something to think about.

• how to find a defName, Name text span from xpath?
• • select with regex after defName="(text)" ?
• how to inject rimworld typeInfo to partial data?
• • it needs to parse xpath to find which def the selector is looking
• • what if xpath selects multiple def types? (like ThingDef and HediffDef at the same time, eg: Defs/*)
• what if xpath is targeting non-dependency mods?
• • currently only dependency mods are loaded in consideration of performance and memory usage.

[Wolfsblvt]

Those are some really good questions. That's why I thought it might be a bigger feature, not something simple.

1. How to achieve: I guess merging XML data in a single file would be okay if iterating all files is too difficult or too heavy on performance. I think most important would be to show defName/Name and maybe the def code block or whatever.
   But of course iterating over the files and then being able to actually open the file at the specific place in VSCode would be much, much better. You could jump to the matching defs then.

2. Isn't attributes and inside-tags standard XML? I mean xpath is not something Rimworld invented, there is a logic behind that works for all XMLs. There are validators out there as well. There might be something that can be used for our case?

3. So if xpath selects multiple def types they should all be displayed in the list of results. I mean for xpath, the "type" itself isn't really relevant. It's more about... how many XML tags do I match?
   And if more than zero, show me all matches in a list so I can jump to them.

4. So of course including non-dependency mods would be nice, as those are patched often as well, but I think it would be fine to leave that out. And just consider rimworld base/ideology/royalty and dependency mods. For the sake of performance.

---

That's just what I came up with without thinking too much about it. Happy to hear your opinion on that.

[zzzz465]

How to achieve: I guess merging XML data in a single file would be okay if iterating all files is too difficult or too heavy on performance. I think most important would be to show defName/Name and maybe the def code block or whatever.
But of course iterating over the files and then being able to actually open the file at the specific place in VSCode would be much, much better. You could jump to the matching defs then.

actually merging is more worst way than traversing files in point of performance.
since all files are already loaded in-memory, there's no cost for reading files.
also, opening file is possible because it's already done in "Go to References", "Go to Definitions"

Isn't attributes and inside-tags standard XML? I mean xpath is not something Rimworld invented, there is a logic behind that works for all XMLs. There are validators out there as well. There might be something that can be used for our case?

what I'm saying is, that an attribute is just an attribute. to think about defName and Name attribute, it can exist not only in Def Nodes but in any nodes. but I believe that we can assume that those two xml attributes only exist in Def node. let's skip the edge cases.

So if xpath selects multiple def types they should all be displayed in the list of results. I mean for xpath, the "type" itself isn't really relevant. It's more about... how many XML tags do I match?
And if more than zero, show me all matches in a list so I can jump to them.

yes, it's possible to implement that.
the real problem is, what should we need to do if we want to support features for <value> node?

So of course including non-dependency mods would be nice, as those are patched often as well, but I think it would be fine to leave that out. And just consider rimworld base/ideology/royalty and dependency mods. For the sake of performance.

I agreed on this point. maybe global caching might be helpful if we "really" want to support this. but definitely not a high-priority job.

[zzzz465]

Example. You are doing a patch replace on /Defs/ThingDef[defName="MealSurvivalPack"]/ingestEffect You should know this targets a ThingDef, and that the ingestEffect attribute is part of the EffecterDef class.

what if xpath is /Defs/*[defName="MealSurvivalPack"]/ingestEffect ?, I strongly believe that there's planty of mods that use xpath like this.
one good way to achieve def is, try to resolve defType from xpath, or just left it unknown if cannot. support only if def type is revealed. (like typescript's unknown type?)

let's start with adding reference to xpath. it's the most concrete thing of things that we discussed.