I opened the thing once trying to localize Starsector into Korean. Then it got updated... made me quit the project.
I think that's more to do with the inherent issues in localizing something that's a work in progress than rules.csv specifically, though.
Heck I postponed Seeker for two years despite having a dozen of extremely scripted artifacts, fully implemented, completely weird, with interesting stories and quests attached to them sitting on my hard-drive because it is beyond my competences to implement the dialogues properly.
Hmm - what's the biggest hurdle? If we're talking about "talking to NPCs specifically" (and even if we're not) I should probably add an easy way to divert that from rules into an "interaction dialog"-style plugin.
Well, here's my abbreviated list of problems with current rules.csv implementation:
Thank you, I appreciate it and want to get this conversation going. And hopefully get to a point where it's much more usable.
First, let me say a few things about how it works/my experience with it, just so we're maybe more on the same page. The rules system, btw, is not something I came up with from scratch but is rather an adaptation of a
system used by Valve for Left 4 Dead. They're using it for something simpler, but it's a flexible and powerful system - and that's a large part of the issue. There are many ways to do the same thing, and many ways to do things that maybe you don't want to do using it. It took me some time working with it to figure out some basic patterns that work well. Definitely took a shift in thinking compared to writing regular code. (Why add this system in the first place? Well, the game needed *something* to handle the rapidly-multiplying number of interactions.)
The other point is that the system is more or less optional, and standard interaction dialogs (i.e. like the FleetInteractionDialogPluginImpl) can be used instead. More or less, the rules system is best for a larger number of simpler things. If you get into any kind of conversation tree more than a few levels deep, it's not going to work out.
For example, the new salvage system - the core interaction is implemented using rules.csv, but there are also a bunch of "special" things that can happen - you find something, and there's an option or two to select - and those each have a custom fully-Java plugin that handles it before returning back to the core interaction.
- The documentation is really incomplete
What specifically is missing? Aside from documenting all the commands; that's not really viable - there's a ton of them and you can also add new ones.
- It lacks a bunch of basic programming flow stuff, like OR in conditions
Looking at it as a programming language is probably not the right way to go. That said, two possible approaches:
1) A custom command that computes whatever condition you want to check for, or
2) Multiple rules for each set of conditions, that FireBest <trigger for rule with the actual work>
- There are a number of little things that can trip a new modder up, like the text column's contents being displayed before the script column code is run (so you can't get variables in the same row that as the text that uses them)
It runs in that order so you can set text highlights from the script. If one wants to print the text after running some commands, there's an AddText command.
- Programming in a spreadsheet editor is generally clunky to begin with – a couple of people in the modding chat mentioned than an editor would be nice
As an aside: a really hardcore implementation would be to dispense with the custom scripting language entirely and make the conditions and scripts use raw Java code with Janino script evaluation.
Yeah, I thought about that - but as you say, programming in a spreadsheet editor is no fun, and Janino script evaluation isn't particularly fast, either - which can be an issue if it's checking conditions, which has to be fast.
The "right" way to do it is to add custom commands for code with any amount of complexity. In vanilla, to minimize the number of custom commands, I tend to have a single command for a specific interaction, with parameters. For example, there's a "SalvageEntity" command, and then the various rule-scripts run things like:
SalvageEntity showCost
SalvageEntity performSalvage
SalvageEntity demolish
That way all of the heavy code is in the same Java file that you edit using an IDE, and the interaction-related stuff in the spreadsheet is kept as simple as possible. If the flow of the interaction is set up right, it's also easy to add different descriptive text based on the specific entity being interacted with and its properties, without affecting the rest of the flow.
The way to do that is setting up a trigger that prints the description text, and then having every rule using that trigger continue the interaction in the same way
E.G:
description1, EntityDescription, $entityType == <entity type 1>, FireBest RestOfInteraction, <description of entity 1>
description2, EntityDescription, $entityType == <entity type 2>, FireBest RestOfInteraction, <description of entity 2>
restOfInteractionStart, RestOfInteraction, , <whatever code etc>
The nice thing here is a mod could add some custom text for a mod-specific entity into the interaction process without altering the interaction flow, and in a way that's compatible with multiple other mods doing the same thing.
Thoughts?
Personally, I found it a bit difficult to get the rules to do much, and found myself re-writing the code used to generate those UIs rather than mess with them further.
Fair enough, pretty much why that's an option.
I think that you're in danger of creating a meta-language here that just makes things more obscure, rather than less;
Yeah, that's a good point and something I'm aware of/concerned about. I *think* part of the issue is a lot of the earlier rules I put together, I was still trying to figure out how to use this best, and so it's very much not a good example to follow or try to figure out.
I'd honestly recommend that the code governing the operation of the Rules gets pretty explicitly documented at some point. But not right now; it's too much of a waste of time, I'd imagine, with things getting refactored fairly often. If I ever feel like diving back into a major mod for this game again, I'll give more feedback at that time
The nice thing is that the rule-operation code is very stable - I think over the course 0.8a, I've only had to fix a few minor bugs in it. It kind of just does what it needs to do; the core of it is pretty simple - the last thing I'd want to do is add more features to it. Anything complicated gets farmed out to Java code via custom commands.