All of that affects skills that you start with. None of it affects your daily absorb limit. Given that, one of those settings shouldn't exist, and both of those settings are irrelevant for this script.
Character Info Toolbox
- Thread starter Chez
- Start date
Bale
Minion
I'm obviously missing something. Could you explain what the benefit is for completing a Gelatinous Noob ascension? I was assuming that absorption limit would get larger. What do you mean by "skills you start with"? Do I get to choose skills from a previous ascension to already possess at the beginning of an ascension?
Please somebody explain this to me like I am clueless, because obviously I am clueless, and everyone posting is thinking I know more than I actually do. Pretend I don't know more than already exists on this page. (I know a little more than that, but not much.)
Last edited:
That is exactly how it works. That is the entire benefit of building up points from repeated gelatin runs.
Bale
Minion
Before anyone complains that ChIT isn't working because SourceForge is screwing up. It isn't my fault this time! I've fixed all that, but now the problem is that zlib won't run without sourceForge. When zLIb fails to update itself ChiIT isn't able to run.
To fix this, open zlib and wack line 206. It looks like this:
Just put a hashtag # in front of it to comment it out.
To fix this, open zlib and wack line 206. It looks like this:
Code:
cli_execute("svn update " + proj);Just put a hashtag # in front of it to comment it out.
Bale
Minion
AlbinoRhino, you attempted to fix the problem where the walls errerroneously overlap the bottom of the ceiling...
Your fix has been utterly effective for me! There have even been a few times that I've seen the walls overlap my ceiling for a fraction of a second and then snap down a step to the right place. Just wow! I haven't once had the problem since you committed this change. I cannot thank you enough for this as it has been an annoying thorn in my side since I first took over the script from Chez.
Your fix has been utterly effective for me! There have even been a few times that I've seen the walls overlap my ceiling for a fraction of a second and then snap down a step to the right place. Just wow! I haven't once had the problem since you committed this change. I cannot thank you enough for this as it has been an annoying thorn in my side since I first took over the script from Chez.
AlbinoRhino
Active member
I'm glad I could help out !
Absorbs per day are capped at 15 once you get to higher levels.
Bale
Minion
I am currently considering migrating Chit's user configuration from zlib vars to vProp style user properties. If that sentence means nothing to you then this post will be tough to wade through, but I'll write a paragraph to explain. If you understood that perfectly, please skip the following paragraph.
If you have configured any of ChIT's many configuration options from the default, then you are familiar with using zlib to change them. Probably using a CLI command like zlib chit.stats.layout = muscle,myst,moxie|hp,mp,axel|mcd|terminal| trail,florist. Recently Veracity has revamped scripting mafia properties in an amazing way. All the reasons that I was inclined to use zlib vars instead of mafia properties are now moot. There are several advantages to vProps. One of these is not needing to save configuration data unless you want to change it from the default value. Another is that if you change the default value in the file it will change the configuration for ALL characters unless they have individual configuration. (Obvious both of those two changes are related.) Then there's the whole awkward infrastructure of vars which requires reading and writing to a separate file and maintaining a map of the values. (My least favorite thing is that it was easy for stray script options to get lost in a huge file without any good way of finding or removing them -- totally fixed by Veracity.) There are a bunch of other things as well, but honestly zlib vars were created because of previously existing shortcomings in the property system so it just isn't needed as a work-around anymore.
Now that I've caught everyone up to speed, here's my problem. A lot of users already have configuration data. I can envision several different solutions for them.
I favor solution THREE, but honestly the easiest one for me to implement would be number TWO. If enough people favor the second I'd do it in a heartbeat. Note that after implementing the first solution if enough people are unhappy, the third solution could be implemented at any time later since the zlib vars will still be present even after I switch over. Finally... solution ONE is the most troublesome one from my perspective since it will require the most work and I worry that I'd remove the code before everyone has run ChIT, but it is the only solution that will require ZERO attention on the part of the user so I am definitely willing to hear people who tell me it is a good idea.
If you have configured any of ChIT's many configuration options from the default, then you are familiar with using zlib to change them. Probably using a CLI command like zlib chit.stats.layout = muscle,myst,moxie|hp,mp,axel|mcd|terminal| trail,florist. Recently Veracity has revamped scripting mafia properties in an amazing way. All the reasons that I was inclined to use zlib vars instead of mafia properties are now moot. There are several advantages to vProps. One of these is not needing to save configuration data unless you want to change it from the default value. Another is that if you change the default value in the file it will change the configuration for ALL characters unless they have individual configuration. (Obvious both of those two changes are related.) Then there's the whole awkward infrastructure of vars which requires reading and writing to a separate file and maintaining a map of the values. (My least favorite thing is that it was easy for stray script options to get lost in a huge file without any good way of finding or removing them -- totally fixed by Veracity.) There are a bunch of other things as well, but honestly zlib vars were created because of previously existing shortcomings in the property system so it just isn't needed as a work-around anymore.
Now that I've caught everyone up to speed, here's my problem. A lot of users already have configuration data. I can envision several different solutions for them.
ONE: Automatically copy all vars to vProps when ChIT starts up. Keep a property that tells me this migration has taken place. If I do this, how long should I keep the migration code in place? I will remove it eventually because I want to remove zlib as a dependency after this. After all, at least once there was a problem that I wasn't able to fix because zlib was required for vars. Also, ChIT will be slightly faster without zlib. Is a week enough time to ensure that people who regularly log on to KoL will keep their configuration? Do I need to leave it in place for a month?
TWO: Heck with the old, in with the new. This means I'd simply stop referencing the old zlib vars for chit. Everyone with a custom setup will have to migrate their own data or change it from scratch. Either is good. Some people will want to edit the default values so that it will apply to all their characters and having ChIT automatically copy over their old vars will actually get in the way of their ability to do this. Plus, this way I won't have to write all that troublesome migration code in the program, just to delete it a week later.
THREE: A good compromise. I would write a separate script that the player can run on each character to migrate that character's zlib vars to vProps. One advantage is that the player can decide for each character if he wants to keep that character's custom settings or let it default to base settings dependent on running the migration script. The related disadvantage is that the character will have to run this script for each character. A second advantage is that the player is not held to my one week or one month time limit. Even a year later the script can be run to migrate their settings. There is no associated disadvantage. A third advantage (mostly for my benefit) is that the migration code will be easier for me to write than the first proposal.
TWO: Heck with the old, in with the new. This means I'd simply stop referencing the old zlib vars for chit. Everyone with a custom setup will have to migrate their own data or change it from scratch. Either is good. Some people will want to edit the default values so that it will apply to all their characters and having ChIT automatically copy over their old vars will actually get in the way of their ability to do this. Plus, this way I won't have to write all that troublesome migration code in the program, just to delete it a week later.
THREE: A good compromise. I would write a separate script that the player can run on each character to migrate that character's zlib vars to vProps. One advantage is that the player can decide for each character if he wants to keep that character's custom settings or let it default to base settings dependent on running the migration script. The related disadvantage is that the character will have to run this script for each character. A second advantage is that the player is not held to my one week or one month time limit. Even a year later the script can be run to migrate their settings. There is no associated disadvantage. A third advantage (mostly for my benefit) is that the migration code will be easier for me to write than the first proposal.
I favor solution THREE, but honestly the easiest one for me to implement would be number TWO. If enough people favor the second I'd do it in a heartbeat. Note that after implementing the first solution if enough people are unhappy, the third solution could be implemented at any time later since the zlib vars will still be present even after I switch over. Finally... solution ONE is the most troublesome one from my perspective since it will require the most work and I worry that I'd remove the code before everyone has run ChIT, but it is the only solution that will require ZERO attention on the part of the user so I am definitely willing to hear people who tell me it is a good idea.
Last edited:
Bale
Minion
I'd like mention that I'm going to be using a rather stripped down and customized version of the vProp code. Thanx to Veracity for the inspiration, but since I have control over how it is used I don't need to account for every variation. Also, I need to use multiple delimiters in a single property whereas vProp is only able to handle one at a time.
In case anyone is curious -- mostly for Veracity's curiosity -- I present my intended code. Note that normalize_prop() has a functional improvement over vProp's equivalent to allow me to mix comma and bar in a single property. define_property() is merely a stripped down version since it doesn't have to survive in someone else's environment. (I feel safe in believing that I won't attempt to override a default mafia property.) Despite my changes I owe much gratitude to Veracity for envisioning the concept and designing the original, astonishingly robust, code for me to work with.
In case anyone is curious -- mostly for Veracity's curiosity -- I present my intended code. Note that normalize_prop() has a functional improvement over vProp's equivalent to allow me to mix comma and bar in a single property. define_property() is merely a stripped down version since it doesn't have to survive in someone else's environment. (I feel safe in believing that I won't attempt to override a default mafia property.) Despite my changes I owe much gratitude to Veracity for envisioning the concept and designing the original, astonishingly robust, code for me to work with.
Code:
string normalize(string value, string type) {
if(value == "string")
return value;
string func = "to_" + type;
return call string func(value);
}
string normalize_prop(string value, string type) {
matcher list = create_matcher("(^|[,|])([^,|]*)", value);
buffer newlist;
while(list.find())
list.append_replacement(newlist, list.group(1) + normalize(list.group(2), type));
return newlist;
}
string define_property(string name, string type, string def) {
// All "built-in" properties exist. A "custom" property that doesn't exist uses the (normalized) default.
string normalized_def = normalize_prop(def, type);
if(!property_exists(name))
return normalized_def;
// The property exists and (potentially) overrides the default
string raw_value = get_property(name);
string value = normalize_prop(raw_value, type);
if(value == normalized_def)
remove_property(name);
else if(raw_value != value)
set_property(name, value);
return value;
}
Last edited:
It's completely fine with me if you want to take my code and adopt it and modify it and customize it to your taste.
Open source, and all that.
And I will consider your code as potential inspiration for my own.
As I mentioned elsewhere, my attention has been elsewhere all day, so I'll look closer tomorrow.
Thank you for telling me that I fixed all the deficiencies in the original set of "property" functions. I made the changes because I wanted something closer to how _I_ wanted them to behave - and I am sure that zarqon could/would have used them had they existed - but, having commit access to the KoLmafia source, it was easier to simply Make It So for my desired changes.
I believe that my public comment thread which existed at least a week before I started coding allowed sufficient user input into my thinking.
I"ll look at and opine, by and by, on your three proposed options - although actual Chit users' opinions count for more.
Open source, and all that.
And I will consider your code as potential inspiration for my own.
As I mentioned elsewhere, my attention has been elsewhere all day, so I'll look closer tomorrow.
Thank you for telling me that I fixed all the deficiencies in the original set of "property" functions. I made the changes because I wanted something closer to how _I_ wanted them to behave - and I am sure that zarqon could/would have used them had they existed - but, having commit access to the KoLmafia source, it was easier to simply Make It So for my desired changes.
I believe that my public comment thread which existed at least a week before I started coding allowed sufficient user input into my thinking.
I"ll look at and opine, by and by, on your three proposed options - although actual Chit users' opinions count for more.
AlbinoRhino
Active member
I like option 'TWO' myself. I wanted my chit settings to be "global" to begin with and didn't like that, when I decided to change something, I had to do it separately for each character.
Last edited:
Bale
Minion
I am very glad you feel that way. (Knowing your feelings towards open code I'm not surprised, just glad.) You did some amazing work which I hadn't even thought I wanted until I saw it.
I adore your changes. One of the reasons I hated the idea of using properties for configuration settings is that it is too easy for them to get lost in the preferences file and then I'd end up with a bajillion settings for programs that I tried out once and don't use anymore. Your changes made it possible to winnow out the preferences that aren't part of mafia. Lack of structure for scripts to organize or remove preferences is one of the reasons that zarqon created the variable system that he built into zlib. Though your idea that scripts would contain global preferences so that modification by the user is helpful was entirely new.
I really, really hope that everyone who uses preferences to configure programs thinks to make sure that the name of their program is in the name of the preference. I'd hate to have to guess at their purpose the next time I winnow through the prefs.
I'm a little surprised that the first vote was for option TWO. It is certainly the option that makes the least work for me.
Last edited:
Magus_Prime
Well-known member
I vote for option three.
txrangersxx
Member
I vote for Option two
xKiv
Active member
Immediate reaction: one year. Err on the side of caution, then multiply by 3, then round up to something with a short name. A month sounds like it should be enough, which means it wouldn't.
That being said, this is the worst option, because it just hands-off obsoletes the zlib variables, which will then keep stinking up my files.
Two is good, though at "Some people will want to edit the default values" I can't keep myself from thinking about how to make sure svn can merge any changes without conflict when you also change the ... *default* default ...
like
Code:
var propDefault = 'original setting from bale';
// propDefault = 'change this and uncomment the line if you want a different default for all your characters';
define_property('prop','string',propDefault);Three is best for me. Especially if the script also handles removing lines from vars_xKiv.txt.
(I don't need to keep them for backups, I already make *several* off-PC backups every year! which is good, because when my power source died yesterday, I had a month "young" data to work with on another computer)
Bale
Minion
Then maybe I'll keep you to that. I can handle TWO, which honestly is quite a bit of work. Meanwhile you can write a script that would port the zlib settings to identically named preferences. Slightly less work for me!
I'm reassured by how many people are comfortable with the last two options. Everyone seems to think it is fine to have a separate script for migrating your old ChIT settings to the new system. And many don't even need that much.
Last edited: