Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Starsector 0.97a is out! (02/02/24); New blog post: Simulator Enhancements (03/13/24)

Pages: 1 [2] 3

Author Topic: [0.9.1a] Expanded Fleet Dialogue  (Read 7608 times)

Morrokain

  • Admiral
  • *****
  • Posts: 2143
  • Megalith Dreadnought - Archean Order
    • View Profile
Re: [0.9.1a] Expanded Fleet Dialogue
« Reply #15 on: May 17, 2020, 06:16:06 PM »

Check if it works properly when talking to a trade fleet with Underworld running.
Do both mods' options work? Only one? Or does the dialog code get stuck in an infinite loop?

Thanks will do. I'll get back to you here with what happens.

*EDIT1* Any trade fleet? Just to be clear? Or a Cabal trade fleet specifically?
« Last Edit: May 17, 2020, 06:52:33 PM by Morrokain »
Logged

MesoTroniK

  • Admiral
  • *****
  • Posts: 1731
  • I am going to destroy your ships
    • View Profile
Re: [0.9.1a] Expanded Fleet Dialogue
« Reply #16 on: May 17, 2020, 08:44:17 PM »

I could not test Tiandong Heavy Industries because the mod plugin is set up to crash the game if Fleet Dialogue is active
My apologies, I will fix that in the next THI update.

Now, in general I see no easy way around this on my side since the majority of vanilla factions rely upon the defaults, but as an olive branch if there are particular modder/modders who really don't want to add custom dialogue for their faction or an exclusion in the mod plugin and also don't want these options available: Post here with a link to the mod page and I will try and add a "not this faction" check to the defaults and I *think* that should allow the original defaults in vanilla to still populate for that faction without the dialogue options. That is very much an educated guess though, and will be done in an "upon request" kind of way.
Morrokain, I would *strongly* suggest you allow the opt-out (or really ideally, converted to opt-in...) system done within other mod's themselves. Having folks need to ask you every time (if they do not specify custom dialog blah blah) is not good. That is taking up the Mantle of Infinity on your end. And then what happens if you are no longer available for some reason? Then modders are just screwed, and either are *forced* to do custom dialog, or just live with this mod hitting their own against their wishes for all eternity or at least until you are available again.

Histidine

  • Admiral
  • *****
  • Posts: 4661
    • View Profile
    • GitHub profile
Re: [0.9.1a] Expanded Fleet Dialogue
« Reply #17 on: May 18, 2020, 02:42:57 AM »

Check if it works properly when talking to a trade fleet with Underworld running.
Do both mods' options work? Only one? Or does the dialog code get stuck in an infinite loop?

Thanks will do. I'll get back to you here with what happens.

*EDIT1* Any trade fleet? Just to be clear? Or a Cabal trade fleet specifically?
Any trade fleet. Cabal doesn't actually ever have its own trade fleets, to my knowledge.
It should look like this (interaction is with a smuggler fleet)
Logged

Morrokain

  • Admiral
  • *****
  • Posts: 2143
  • Megalith Dreadnought - Archean Order
    • View Profile
Re: [0.9.1a] Expanded Fleet Dialogue
« Reply #18 on: May 18, 2020, 03:32:35 AM »

My apologies, I will fix that in the next THI update.

No worries! I get why you would do that as a safeguard just in case. If you choose to keep it considering the below response, I will not hold it against you as I completely understand the complexities involved. Trying to do the best for everyone.

Quote
Morrokain, I would *strongly* suggest you allow the opt-out (or really ideally, converted to opt-in...) system done within other mod's themselves. Having folks need to ask you every time (if they do not specify custom dialog blah blah) is not good. That is taking up the Mantle of Infinity on your end. And then what happens if you are no longer available for some reason? Then modders are just screwed, and either are *forced* to do custom dialog, or just live with this mod hitting their own against their wishes for all eternity or at least until you are available again.

The take away to what I'm about to say should be: I want to work with you, I understand your concerns, and what is the best way to go about this? Nevertheless, I again feel the need to get very detailed. (Really sorry if this comes across as pretentious prattling. I really feel it has a well-meaning concern for the community behind it though. I'll just say that.)

I get what you are saying and I want to be delicate here and say upfront that I will try my best to work on a solution, but... well, this is more difficult to "fix" because that is just how vanilla is set up with rules and vanilla factions iirc. I'm pretty sure PickGreeting is the only entry point in the rules dialogue for this and it's hardcoded, and I'm pretty sure many vanilla factions still use the default version of that implementation. I could be wrong and I will investigate that more. The only way I see that I could get around that is to create my own rules dialogue for each vanilla faction using the default greetings as a guideline. What that would boil down to, in that case, would be me fleshing out the greeting system for potentially lots of factions instead of a mod author copy pasting the defaults (one time) and adding their mod id to the check *if* they wanted to opt-out of the dialogue features. (They don't have to actually write custom dialogue, just implement an id check to it. It would even be a good idea to do this, so that custom dialogue can be added later on if desired.) So, the onus would be on me to handle a purely vanilla feature so mod factions don't have a few options added to their fleets who also use said vanilla feature when it is unnecessary to do so in the first place. I actually want to do that eventually, anyway, but is it really worth it to wait until that work is completed? What if I didn't already want to do that? Let's consider:

1) No custom mod content is truly being modified.
2) Different methods of opting out within the faction mod itself have been given with various levels of difficulty/effort.
3) If zero effort whatsoever is desired, the interim solution is provided (Assuming the mod id doesn't change, even though this option is done within this mod it would be a "one and done" change that wouldn't require future maintenance unless Rules changed significantly... which would generally break everything anyway. Still, it's not the option I would pick as a modder and yes the complication of my availability is an issue that isn't ideal)

I think this is pretty reasonable considering it purely stems from vanilla implementation. I want to reassure that I'm not saying I won't personally be conscientious or do more about this and seek a solution before release, I am trying to be crystal clear that it's not custom mod content at that point, if that makes sense. It is custom mod content using vanilla components that are themselves fair game. If you are using defaults from vanilla that vanilla factions use en masse (as opposed to faction specific) and another modder wants to make a mod overriding those defaults to affect vanilla, that inherently is going to affect anyone still using the defaults. The expectation is that if you aren't providing custom content and are using vanilla components, anyone modding those components will affect you assuming they are moddable in the first place. It is not "hitting another mod against their wishes" though- at least not intentionally in this case- because those mods are relying upon vanilla components, themselves, which are also justifiably able to be overridden for other reasons. If that was not the case and this was not the access point vanilla itself uses and it was specifically set aside for faction mods, that would be a very different story. This just happens to be one of the parts of vanilla where I don't believe this is the case. I will be happy to be wrong, maybe it is easier than I think and I'll let you know if so!

Can you suggest anything as an alternative? Technically-speaking, is there a way that doesn't involve me essentially finishing the game's greeting dialogues and removing defaults from the vanilla factions altogether? I may even be willing to do that before a release if it's important enough (heck, I did a lot more for the TC to be able to use faction mods that edit vanilla ships and that isn't even balanced for faction mods in the first place) but I reserve the right to, well, not, if it comes down to it. That isn't what I want, though. I'd like to satisfy everyone if possible. Can anyone give me a use case where this would cause technical complications, for instance? "I don't want the feature for my faction" is probably not a valid use case if you are using vanilla defaults. Why?:

The point of all this detail/musing: We quite simply cannot police people for overriding vanilla. It is completely unreasonable in every way to expect modders to never touch vanilla features or accommodate every other mod that has come before them in a community with a mod index like the one we have. Not only will that kill mod variety and features that could be useful or just desirable to some end users, if we're really honest with ourselves it's just not fair to the modding community. Fledgling modders are going to want to try out their own cool things with vanilla components and we have to let them- even when it affects another mod in weird ways or ways outside of the faction mod's original vision. I'm definitely not saying that you shouldn't let them know "Hey this is doing X to my mod, anything we can do about that? I'd rather it did Y or nothing at all." Nevertheless, overriding vanilla is a perfectly valid way of modding and it brings more features to the end user community. It should be preserved as such. It's how we all got here initially.

Conceptually: If you want to preserve every aspect of a faction mod 100% when dealing with a mod merging community, you are either going to have to not use vanilla defaults and keep everything faction specific where possible, make it a TC, or manually exclude mods that don't fit your vision. It's just that simple. Read as: Not at all simple and filled with obstacles and headaches but an overall necessity. Without more complex mod merging management options (which would be great, I'll add, but most likely are outside the scope of Starsector's development), power creep from feature mods will happen. Feature mods making the game easier/harder/more accessible will happen. This is a natural part of every healthy modding community with a diverse set of preferences.
---------------------------

Any trade fleet. Cabal doesn't actually ever have its own trade fleets, to my knowledge.
It should look like this (interaction is with a smuggler fleet)

Thanks, I was looking for cabal trade fleets. I found a normal trade fleet and:

It should accommodate both. I haven't had a chance yet to check hostile trader fleets assuming that's different. I will check later.
« Last Edit: May 18, 2020, 03:42:47 AM by Morrokain »
Logged

SafariJohn

  • Admiral
  • *****
  • Posts: 3010
    • View Profile
Re: [0.9.1a] Expanded Fleet Dialogue
« Reply #19 on: May 18, 2020, 07:24:50 AM »

Just use a merging .csv? Set up your code/rules so they only take effect if the fleet's faction's id is in the csv.
Logged

Morrokain

  • Admiral
  • *****
  • Posts: 2143
  • Megalith Dreadnought - Archean Order
    • View Profile
Re: [0.9.1a] Expanded Fleet Dialogue
« Reply #20 on: May 18, 2020, 01:21:10 PM »

Just use a merging .csv? Set up your code/rules so they only take effect if the fleet's faction's id is in the csv.

I'd like to, but how? I'm pretty sure I can figure out how to set up a mod .csv (going to assume those merge if they share the same directory between mods) to get all the values and it would operate on having to be present in the faction mod to be eligible for the trigger (That's the idea anyway). How would I plug that into rules, though? OpenCommLink (not PickGreeting I was thinking of something else) is the trigger that they have to fire off of. I'd need some kind of default implementation that checks for a mod id variable that could be any mod id in the merged list? Oh! Actually, iirc I could use a rule script in the condition section, right? If so, that would probably be the best way to go about it in my mind. That script can just search through the list and return true if a faction id found matches the entity faction id- and maybe set the values relating to that faction id into memory temporarily which can then be read from the script that handles the results of the calculation.

I took a look and there are currently 5 default implementations of that trigger that require the override to fire the script for the options. For reference, they fire alongside FireAll PopulateOptions when the player is friendly or neutral and fire stand-alone when the faction is any of the 3 hostile settings.

When I look at the rules, I don't see any other way to do it except that one. So, Hegemony, Tri-Tachyon, Diktat, Luddic Church, Luddic Path and Pirates all have their own faction specific implementation of those by mod id. They aren't the problem because they don't use the defaults. Independent, Scavengers, and Persean League seem to use the defaults though. Probably the player fleet as well, though that's less important for now since the design uses rep as a balancing factor and that's not possible with the player faction.

To get around any vanilla faction using the defaults, I can implement rule sets for each faction currently using them and add their id as a condition check. I honestly thought I'd have to implement more of them, but it doesn't seem too bad to only have to do ~20 max. I think I created a few more implementations of OpenCommLink for my mod factions and that was probably skewing the number I'd have to do in my mind.

That should handle removing the defaults and let all mods automatically "opt-out" though, I believe. That shouldn't be too bad to handle, actually.

Thoughts? Critiques? Better ways of doing it?
Logged

Tartiflette

  • Admiral
  • *****
  • Posts: 3529
  • MagicLab discord: https://discord.gg/EVQZaD3naU
    • View Profile
Re: [0.9.1a] Expanded Fleet Dialogue
« Reply #21 on: May 18, 2020, 01:27:29 PM »

There are plenty of examples of CSV merging in various mods, there is a simple one in Scy's String manager if you want a reference.
Logged
 

Morrokain

  • Admiral
  • *****
  • Posts: 2143
  • Megalith Dreadnought - Archean Order
    • View Profile
Re: [0.9.1a] Expanded Fleet Dialogue
« Reply #22 on: May 18, 2020, 01:30:53 PM »

There are plenty of examples of CSV merging in various mods, there is a simple one in Scy's String manager if you want a reference.

Yes please, and thanks.  :)
Logged

Alex

  • Administrator
  • Admiral
  • *****
  • Posts: 23986
    • View Profile
Re: [0.9.1a] Expanded Fleet Dialogue
« Reply #23 on: May 18, 2020, 03:19:00 PM »

With the caveat that I didn't read everything (sorry!) and might thus be missing some critical bit of context:

The entry point for the extended dialog is a PickGreeting rule, right? Why not add a condition to it, like this:

!$faction.c:optOutOfMorrokainExtendedDialog

And then in the .faction file, in the custom section, one could add "optOutOfMorrokainExtendedDialog":true, for any faction that didn't want this dialog to fire.

If the custom values aren't populated into $faction memory the current release (i.e. if this is an in-dev feature), you could do this yourself in the CampaignPlugin.updateFactionFacts() method, like so:

Code: java
if (JSONObject.getNames(faction.getCustom()) != null) {
for (String key : JSONObject.getNames(faction.getCustom())) {
String val = faction.getCustom().optString(key);
memory.set("$c:" + key, val, 0);
}
}
Logged

Morrokain

  • Admiral
  • *****
  • Posts: 2143
  • Megalith Dreadnought - Archean Order
    • View Profile
Re: [0.9.1a] Expanded Fleet Dialogue
« Reply #24 on: May 18, 2020, 03:53:25 PM »

With the caveat that I didn't read everything (sorry!) and might thus be missing some critical bit of context:

The entry point for the extended dialog is a PickGreeting rule, right? Why not add a condition to it, like this:

!$faction.c:optOutOfMorrokainExtendedDialog

And then in the .faction file, in the custom section, one could add "optOutOfMorrokainExtendedDialog":true, for any faction that didn't want this dialog to fire.

If the custom values aren't populated into $faction memory the current release (i.e. if this is an in-dev feature), you could do this yourself in the CampaignPlugin.updateFactionFacts() method, like so:

Code: java
if (JSONObject.getNames(faction.getCustom()) != null) {
for (String key : JSONObject.getNames(faction.getCustom())) {
String val = faction.getCustom().optString(key);
memory.set("$c:" + key, val, 0);
}
}

Thanks I appreciate it! (It is OpenCommLink that needs the condition, but I'm pretty sure PickGreeting works in a similar way for station npcs so I initially confused the two)

I had no idea (or at least didn't remember) about that portion of the faction file. I will probably do the opposite and make the check for true instead of false in the condition so the default is being opted out. That way faction modders won't actually have to do anything unless they want to plug into the system. I can then specify additional values in that section for ways to manipulate the levers of the system in a similarly opt-in way. Essentially that would allow modders to include whatever complexity they wanted with the system and allow for a more diverse set of responses overall. I'm liking this idea- especially since checking a hash map as a condition of a script in rules for theoretically a lot of faction ids could possibly impact performance every time OpenCommLink is triggered since there are already a lot of potential matches for that trigger to begin with. Idk, though, I'm not really sure how efficient a contains check is. It may be negligible to performance and this wouldn't matter anyway.

Either way, I have lots of ideas now, so thanks for the help everyone! Now to bog myself down in the nitty gritty details and get this thing working... I may have more questions later lol. :D
Logged

Alex

  • Administrator
  • Admiral
  • *****
  • Posts: 23986
    • View Profile
Re: [0.9.1a] Expanded Fleet Dialogue
« Reply #25 on: May 18, 2020, 04:52:27 PM »

(For a map, a contains() check is super fast, and, more importantly, *does not get slower as the map gets bigger*.)
Logged

Morrokain

  • Admiral
  • *****
  • Posts: 2143
  • Megalith Dreadnought - Archean Order
    • View Profile
Re: [0.9.1a] Expanded Fleet Dialogue
« Reply #26 on: May 18, 2020, 07:14:06 PM »

(For a map, a contains() check is super fast, and, more importantly, *does not get slower as the map gets bigger*.)

Thanks again that's good to know.
Logged

Morrokain

  • Admiral
  • *****
  • Posts: 2143
  • Megalith Dreadnought - Archean Order
    • View Profile
Re: [0.9.1a] Expanded Fleet Dialogue
« Reply #27 on: May 19, 2020, 05:55:30 PM »

So as it turns out, both implementations that were given as examples will be very useful.

I plan on using the .csv system to allow an immense amount of custom dialogue for faction mods (with hopefully a possibility of random selection of dialogue responses per each response category- similar to how rules already operates).

It will be a lot of work, but I will provide an example implementation when it's done. The base system has a lot of response categories, so I need to both provide a spreadsheet cell for each one and provide parsing and methods to obtain a random string selection of each category based upon a comma separated list in each cell matching cell. I should soon have a small prototype of this already working, I believe. It is looking promising, at least.

For the options to opt in for each faction, and provide custom settings for that faction for how likely each response category will spawn, I will use the custom portion of the faction file and read those values separately. No prototype for that in the works yet, though.
Logged

Morrokain

  • Admiral
  • *****
  • Posts: 2143
  • Megalith Dreadnought - Archean Order
    • View Profile
Re: [0.9.1a] Expanded Fleet Dialogue
« Reply #28 on: May 20, 2020, 03:41:20 PM »

Update: Success!

I have a working example of the first element of description dialogue loading from the csv and being used as intended in the campaign. I have also successfully parsed the first variable $personRank into the correct data when pulled from the spreadsheet.

Phew! It's a proof of concept at least. There is still a lot of work to do, though. I also need to test the implementation of multiple options in each category (like rules separated by "OR").

Is there any place that documents all of the possible variables in the text portion of rules? Or maybe a class? I can't remember. I also plan on adding a couple of my own most likely.  :)

Examples:

Spoiler



[close]
Logged

Morrokain

  • Admiral
  • *****
  • Posts: 2143
  • Megalith Dreadnought - Archean Order
    • View Profile
Re: [0.9.1a] Expanded Fleet Dialogue
« Reply #29 on: May 28, 2020, 10:36:51 PM »

I'm still working on getting the dialogue spreadsheet capability fully up and running and there is a lot of rules left to convert to that format. I'm particularly running into some trouble getting highlights to work for credit costs when converting from the spreadsheet cell to in-game dialogue. All replacement tokens have been handled, however, and I've added a few extra of those. I've also added functionality to allow the strict use of Notepad or Notepad++ if a modder prefers that over a spreadsheet editor. New paragraphs can be handled by adding $NEWLINE between the paragraphs. Spreadsheet editor new lines such as Excel and Open Office are fine as well. Adding OR between dialogue responses allows for multiple options that will be chosen at random in each unique case.

Finally, I now also have a working model for opt in behavior and all the various ways to interact with calculations or odds within the system for each faction. I'm still testing, but I don't think I will even need any rules overrides. It will be very easy to opt in to the default dialogue and the modder will have versatile customization options from there.

There's still much work that needs to be done, but there has been some substantial progress made as well.
Logged
Pages: 1 [2] 3