(Augh, sorry for not responding for a while here! Got sidetracked, and also, after the thread has been stickied, I keep not seeing it - just not used to where to look, still.)
I've been trying to make a dialogue option only appear if a memory key containing my script does not exist (i.e. is null). However, if I use the !$[memKey] condition in rules.csv to check for that, it doesn't appear to work correctly, so the dialogue still appears even when that script exists and is stored in the specified memory key.
rules.csv Condition for a PopulateOptions trigger (Highlighted is the problem condition)
$isPerson
$personFaction.id == adversary
$player.fcm_faction == adversary
Commission personCanGiveCommission
!$player.defeatedAdversaryAttack
!$global.adversary_mt_ref
In Devmode, after going through my dialogue, triggering the script, and then dumping the memory, I can see it clearly as $global.adversary_mt_ref = MutualTenacityScript@[object #], but, for whatever reason (and this is my guess), the !$global.adversary_mt_ref condition still thinks that that memory key doesn't exist, making the condition always true when I expect it to be false at that point. All other conditions seem to work fine, and, from what I can find, the other times I used !$global.[memKey] to check for global memory keys had worked as intended. It's only that !$global.adversary_mt_ref condition check that isn't working as I thought it would.
If this is an unsupported feature (or just user error), what would be the intended solution for checking memory keys containing a non-boolean object in rules.csv?
(Oh, and I used the PiracyRespiteScript.java, which contains "$prf_ref" as its key, as a reference for my own script. I didn't see its memory key get used anywhere in the vanilla rules.csv, though, so there wasn't anything else I could fall back on for help with this problem.)
Yeah, the ! (not) operator is not going to work to check for the existence of a key like this. Generally when vanilla goes this sort of thing, the reference is a mission or some other type of CallableEvent, so using Call $<ref> <action id> would return false if the reference is not set.
You could also create your own custom rule command - ah, I see you already did that. Nice!
For the next release, I've made it so that the == null check works. != null already works, by the way.
But I can't see anything regarding the bounty information in the dialogue. I believe I'm missing some files corresponding to $mcb_ref showBountyDetail and $mcb_ref showBountyAssessment in the rules.csv. But I can't find any class called mcb_ref or any methods in the starfarer.api so far. I may also be missing the triggers. Currently I'm using my own bounty creater names as triggers, but I don't know how to define new triggers, is there any examples about doing that? And in general, my guesses could all be wrong, please let me know what am I missing if that does happen.
$mcb_ref is a reference to the MilitaryCustomBounty mission. That class extends BaseCustomBounty, and that has a callAction() method that handles these calls.
Question 2: I defined a custom bounty following the vanilla CBRemnantPlus.java file, and the starsector.log tells me that the following code is problematic:
picker.add("tesseract_Attack");
picker.add("tesseract_Attack2");
picker.add("tesseract_Strike");
picker.add("tesseract_Disruptor");
fleet.getFleetData().addFleetMember(picker.pick());
It says: No applicable constructor/method found for actual parameters "java.lang.Object"; candidates are: "public abstract void com.fs.starfarer.api.campaign.FleetDataAPI.addFleetMember(com.fs.starfarer.api.fleet.FleetMemberAPI)", "public abstract com.fs.starfarer.api.fleet.FleetMemberAPI com.fs.starfarer.api.campaign.FleetDataAPI.addFleetMember(java.lang.String)"
Have you set up an IDE? There are some instructions for how to do this floating around on the forum and on the wiki. At this point, it sounds like you would save some time by doing this, as - when set up properly - a dev environment would catch these sorts of things for you immediately, and point you to what you need to do.
But that means if the Colony Crisis intel gets added mid-game, the custom Crisis will not get put in too (and, thus, not contribute towards the event) unless the game was saved and then reloaded. Also, if the CC intel gets removed (due to losing all colonies at once) and then gets added back in, the custom Crisis will temporarily disappear until yet another save reload. Not exactly the biggest deal for what I've planned with my faction, but, if possible, I'd appreciate a way to avoid those edge cases and cleanly implement a custom Colony Crisis.
Hmm, you're right, actually. For the moment you'd probably want to set up a script that uses an IntervalUtil to run these checks every few seconds.
Made a note to add a completely clean way of doing this.
Is there any way to get missile's id from WeaponAPI?
There is no getId in MissileSpecAPI....
MissileSpecAPI.getHullSpec().getHullId() *may* work.
But yeah, this sounds like the right way to go:
1-I changed the mission name to mcb in the person_mission csv file instead of my faction's special mcb name, call it tomas_mcb
2-I changes everything in my rules csv accordingly, directly copying from vanilla rules.csv for the mcb rule lines, and added some conditions, changed the rules id, as if I have made a new voice for the vanilla mcb mission.
Then it magically worked, a lot of mcb variables that were not there when I was using my alternative version of the custom bounty file were created. And I don't know why by adding a condition to the person_mission csv file in my mod that says id: mcb, conditions: id == tomas_kol would not block other npc's from offering mcb bounties. I thought it would. I don't know why this would work, I don't know why my version didn't work, and I'm just more confused.
This sounds like changing the mission id to "mcb" is making use of some vanilla rules that you maybe didn't have duplicated for your specific mission? I'd be concerned that this may only seem to be working and something else might've broken. For example, if the mission id is mcb now, you've *replaced* the vanilla mcb mission with yours!
In particular also if variables were missing make sure about calling Call $mcb_ref updateData in your "conditions" column.
But, honestly, it's hard to say exactly what's going on here; I don't really have a full overview and it's hard to take in that much info at a glance. If I might suggest more bite-size increments, making things work one step at a time?