Changes: Monitor property changes.

Since I just found out Veracity added a bunch of interesting property functions, I whipped up a script to track property changes. This is probably mostly useful to script authors who like to see exactly what properties get changed and when so they know how to react to them.

Suggested use is to call "Changes.ash update" in your afterAdventureScript, or "Changes_Since(true);".

ASH Usage:
Checkpoint( [string name] ):
Save all properties to a Checkpoint. If "name" is unspecified, uses the checkpoint "last".
Property values are stored in "Changes_<Character_Name>_<last>.txt".
Changes_Since( [string name], [boolean update] ):
Prints out all changes since checkpoint <name>, optionally updating that checkpoint (default true).
IgnoreProperty( string prop ):
Adds/Removes a given property to a list of properties to ignore (Changes_ignores.txt).
Will verify the property exists first, correcting case if necessary.

CLI Usage:
Changes (set|update|since|ignore) [name]:
If "name" is unspecified, uses the checkpoint "last".
Changes set [name]: Creates a checkpoint, same as ash Checkpoint().
Changes update [name]: Lists all changes, and updates the checkpoint. Same as ash Changes_Since( [name], true ).
Changes since [name]: Lists all changes, does not update. Same as ash Changes_Since( [name], false ).
Changes ignore <name>: Ignores the specified property, or stops ignoring it. Corrects improper casing.

Code:
svn checkout https://svn.code.sf.net/p/kolm-changes/svn/
 

ckb

Minion
Staff member
This sounds interesting. One useful option might be to timestamp the checkpoint instead of using "last". You can do this easily with now_to_string()
 
Timestamping the checkpoint is a good idea, but the default identifier is going to be a constant value because the main idea was to use it to track changes turn-by-turn, constantly comparing and updating. You can create more permanent checkpoints by just calling "Checkpoint( now_to_string() )". I'd be careful if you do this regularly or in a script, though, because you'll end up with a large mess of individual property files pretty quick, and you'd need to specify the whole previous now_to_string() value in a "changes since <x>" if you wanted to compare it.

FYI, the messages it prints out are logged to the session log, so you can go back and see (roughly) when individual properties changed over the course of a run by putting it in your afterAdventureScript.
 

fronobulax

Developer
Staff member
Timestamping the checkpoint is a good idea, but the default identifier is going to be a constant value because the main idea was to use it to track changes turn-by-turn, constantly comparing and updating. You can create more permanent checkpoints by just calling "Checkpoint( now_to_string() )". I'd be careful if you do this regularly or in a script, though, because you'll end up with a large mess of individual property files pretty quick, and you'd need to specify the whole previous now_to_string() value in a "changes since <x>" if you wanted to compare it.

FYI, the messages it prints out are logged to the session log, so you can go back and see (roughly) when individual properties changed over the course of a run by putting it in your afterAdventureScript.

What's the use case for tracking to a particular turn? If I run one turn and then look at changes, what do I do with the information? How do I use it to plan my next turn? Or is the turn level of accounting just OCD?

I'm asking because my OCD has me exploring some kind of code level logging within KoLmafia that reports the what and when for preference reads and writes and the answer might encourage me to explore more or just give up. :)
 
What's the use case for tracking to a particular turn? If I run one turn and then look at changes, what do I do with the information? How do I use it to plan my next turn? Or is the turn level of accounting just OCD?

The use case is in script authorship where you need to know when a particular property changes so you can react to it in your own script. Like if you're building an ascension script and need to know exactly when the questL07Cyrptic changes and what causes it and - oh look, cyrptAlcoveEvilness just went up by 1 after that adventure, I didn't realize that was there and maybe that's what I should be looking at! - etc. It adds transparency in how Mafia updates its properties to your session log so you can more easily make good use of them.

I can't think of how it'd be useful outside of script authoring. I certainly don't see how it would help you plan your next turn. If Mafia already has a way to, or could be updated to, write property changes into the session log as they happen, this would be pretty much entirely deprecated in my view.
 
Last edited:
I'm asking because my OCD has me exploring some kind of code level logging within KoLmafia that reports the what and when for preference reads and writes and the answer might encourage me to explore more or just give up. :)

I modified my local copy of mafia to report on all writes (not reads) because this information is very useful for scripting.
 

VladYvhuce

Member
This seems like a nifty addition. Especially since I'm still in the "trying to learn coding" phase. With a tool like this, I might not come off sounding like such a dolt...
 
Top