We could also use it to set the monster appearance rates in AreaCombatData.
New Content - Implemented 2019 April IOTM - PirateRealm membership packet
- Thread starter taltamir
- Start date
Are we going to add new modifiers for things like FunPoint drops and sailing speed? Rubee Drop was added for FantasyRealm, after all.
On a related note, is there a reason that a lot of modifiers aren’t actually implemented, just commented out in modifiers.txt? If it is just that no one cares, I’d be happy to implement a lot of them myself.
On a related note, is there a reason that a lot of modifiers aren’t actually implemented, just commented out in modifiers.txt? If it is just that no one cares, I’d be happy to implement a lot of them myself.
Generally because no one cares and wouldn’t maximise for them. If you aren’t going to maximise for them, we don’t really need to support. Occasionally when one becomes important it gets added.
Can certainly see an argument for adding various ways of adding passive or retribution damage, as they are used in both ascension and a number of other fights. Probably would want both average damage and source count for each type.
Can certainly see an argument for adding various ways of adding passive or retribution damage, as they are used in both ascension and a number of other fights. Probably would want both average damage and source count for each type.
I do want to maximize for a lot of them, actually. “Allows Pickpocketing”, for instance, especially if being the right classes were recognized as giving that modifier as well, is very useful. My general design ideal consists of hardcoding as little as possible in favor of specifying what I actually want, and that only works if things like that are accessible programmatically.
I mean, a lot of the unimplemented modifiers are booleans with no impact on other modifiers. Couldn’t we just throw them in without making any real code changes? If they don’t get used by anyone, they don’t get used by anyone.
If the patches will be accepted, I’m more than willing to steadily go through modifiers.txt with the Find tool, and implement each commented-out attribute I find (besides the ones that are genuinely more complicated). Almost none of them will require any real code changes, and people will be able to use them with the Modifier Maximizer by using their exact names.
Last edited:
For PirateRealm items, I recommend adding a new modifier: FunPoint Drop. Due to PirateRealm’s design, the specific criteria for the bonuses can easily be implemented by restricting them by location.
Code:
Item PirateRealm party hat Muscle: +10, Mysticality: +10, Moxie: +10, FunPoint Drop: +1
Item Red Roger's red right foot FunPoint Drop: [1*loc(Sailing the PirateRealm Seas)], Single Equipthe dictator
Member
Just saying, I continously forget to set_location() so scaling them by that would probably piss me off more than if it would just suggest both, always. Especially because you have to swap back and fourth 5 times during a run through the realm, and ideally you do that when you just finished the location, which means that would still be your location by default, and thus, wrong all 5 times. Possibly 6 times, but I don't know if the 'choose your mate/curio/ship encounter sets your location to the sea or not.
Last edited:
the dictator
Member
Just unlocked it, filling out my shop:
Code:
--------------------
10230 piratical blunderbuss 141455552 pr_gun.gif weapon 0
piratical blunderbuss 80 Mox: 0 2-handed rifle
Item piratical blunderbuss Familiar Weight: +5, Booze Drop: +30
--------------------
--------------------
153 PirateRealm Assortment prealmtat.gif PirateRealm party hat, piratical blunderbuss, conquistador's breastplate, plush sea serpent, pirate radio ring
Outfit PirateRealm Assortment Moxie Percent: +20
--------------------
--------------------
PirateRealm Fun-a-Log buy 1000 piratical blunderbuss ROW1063
--------------------
Nice! Thanks. Revision 19176 will now show all items in the Fun-a-Log, but ones you have not yet unlocked are greyed out.
I have over 1,000 FunPoints, but have not unlocked the blunderbus, It is greyed out.
I have less than 5,000 FunPoints and have not unlocked the tattoo kit. It is greyed out.
Have not checked yet if ASH function to buy from a coinmaster actually checks if the item is available. Will check - and correct, if needed - by and by.
I have over 1,000 FunPoints, but have not unlocked the blunderbus, It is greyed out.
I have less than 5,000 FunPoints and have not unlocked the tattoo kit. It is greyed out.
Have not checked yet if ASH function to buy from a coinmaster actually checks if the item is available. Will check - and correct, if needed - by and by.
Last edited:
the dictator
Member
prAlways hasn't been given it's own checkbox in preferences -> IotM tracking (yet).
Edit: barrelShrineUnlocked is also missing
Edit: barrelShrineUnlocked is also missing
Last edited:
Revision 19186 adds all of the PirateRealm islands as individual adventuring location. This is primarily for logging and to allow each location to have exactly the correct monsters in it, but you can automate using the individual island names.
I left the following as adventuring locations:
Sailing the PirateRealm Seas
PirateRealm Island
... which are what you see in the charpane, but I also made "PirateRealm Island" a "zone" which contains:
Crab Island
Prison Island
Jack's Hideout
and all the rest. They all have the same URL as the "PirateRealm Island" location, but when translating from URL to Adventure Location, if it is that (shared) URL, we look in the "_lastPirateRealmIsland" setting, which is set when you choose the island in "Island #1, Who Are You?", "What's Behind Island #2?", or "Third Island's the Charm" choice adventures.
I left the "PirateRealm Island" location for backwards compatibility; if you have a script which uses only the two advenure.php URLS in PirateRealm, you can use the original names for them. I believe that any script which runs PirateRealm, if there are any, has to know which islands it is visiting - and in any case it caln look at _lastPirateRealmIsland to get the real location name, but, whatever.
I do not validate whether you can actually go to "Crab Island", for example. I could check the setting, but I don't (yet) clear that setting when you have done the boss fight or otherwise collected the reward. For that matter, we don't validate either the generic "Sailing the PirateRealm Seas" or "PirateRealm Island" adventures. Probably should do that - and also at least recognize the "you can't go there any more" messages, if you try to automate when they are unavailable.
I left the following as adventuring locations:
Sailing the PirateRealm Seas
PirateRealm Island
... which are what you see in the charpane, but I also made "PirateRealm Island" a "zone" which contains:
Crab Island
Prison Island
Jack's Hideout
and all the rest. They all have the same URL as the "PirateRealm Island" location, but when translating from URL to Adventure Location, if it is that (shared) URL, we look in the "_lastPirateRealmIsland" setting, which is set when you choose the island in "Island #1, Who Are You?", "What's Behind Island #2?", or "Third Island's the Charm" choice adventures.
I left the "PirateRealm Island" location for backwards compatibility; if you have a script which uses only the two advenure.php URLS in PirateRealm, you can use the original names for them. I believe that any script which runs PirateRealm, if there are any, has to know which islands it is visiting - and in any case it caln look at _lastPirateRealmIsland to get the real location name, but, whatever.
I do not validate whether you can actually go to "Crab Island", for example. I could check the setting, but I don't (yet) clear that setting when you have done the boss fight or otherwise collected the reward. For that matter, we don't validate either the generic "Sailing the PirateRealm Seas" or "PirateRealm Island" adventures. Probably should do that - and also at least recognize the "you can't go there any more" messages, if you try to automate when they are unavailable.
AlbinoRhino
Active member
Sweet. Sounds awesome!
Nice job. If you are only leaving it in for backwards-compatibility, you may want to consider warning people that it is deprecated (sort of like the warning you’d get for using $location[PirateRealm Isla]). Considering how new the content is, I doubt there are many unmaintained scripts using that location by this point. After a few months of notice, it should be safe to remove the old location entirely.
Leaving it in can make things tricky for scripts that iterate through $locations[], so it is best avoided in the long-term in my opinion.
Oh, and I have an equipment script that is equipping Red Roger's red left foot when my_location() is PirateRealm Island. It doesn’t need to know which island for that. Anything else probably would, though.
Is “PirateRealm” still a zone? As far as organization goes, this is a bit like Hobopolis: everything in the zone works similarly with regards to applicable modifiers and such, with one exception. In Hobopolis’s case, “A Maze of Sewer Tunnels”. In PirateRealm, “Sailing the PirateRealm Sea”. Based on that precedent, I don’t think sequestering the islands in a distinct zone is necessary.
If you can nest zones, which I wasn’t aware of as a possibility, maybe we could do the same with Hobopolis?
If you can nest zones, which I wasn’t aware of as a possibility, maybe we could do the same with Hobopolis?
Zones can nest. There is no visibility within ASH for zones, but they are displayed in the GUI and you can filter on them, just as for individual locations.
PirateRealm -> Sailing the PirateRealm Seas = a location
PirateRealm -> PirateRealm Island = a location, but which maps to a specific island, which changes as you progress
Those two locations appear in the charpane (and api.php) as links to adventure.php?snarfblat=xxx
And that is a reason to leave them. I'll give a specific example later.
PirateRealm -> PirateRealm Island -> Crab Island = a location
Happens to have the same adventure number as "PirateRealm Island", but if we know you are adventuring there, my_location() returns $location[ Crab Island ] which has "giant crab" and "giant giant crab" as monsters.
Now, why would we want generic "PirateRealm Island" as a location?
Looking at my own session log:
I got the choice adventure to choose (this or that) island.
(At tis time, KoLmafia knew what my various choice options ere; it had a map from option number -> (text displayed for that option. 1 -> Crab Island, etc.)
This was a choice that, somehow, did not prevent me from doing SOME other things. I didn't know which isand to go to, so I ran "missingManuel".
That looked up every Manuel page and reported on which monsters had incomplete factoids.
Based on that idata, I selected the choice option - in the relay browser - for the Island which would get me factoids.
KoL accepted it!
And KoLmafia reported I had taken choice XXX option 3 which was "unknown" - since it had thrown away the choice options.
That is probably worth a closer look; I was still in a choice, although I had opened 27 Manuel pages, at least.
But, because I had navigated away from the choice - as KoLmafia thought - it forgot the options.
As I said - it should not have forgotten them. Peraps Manuel (questlog) requests should not count as "walking away" from the choice.
But the result was that _lastPirateRealmChoice was "unknown".
Which we now translate to the generic "PirateRealm Island" adventure, given a PirateRealm Island URL.
If you take that choice outside of KoLmafia, the same thing will happen: we will recognize you are in PirateRealm Island but will not know which one.
That's a degenerate case, but we CANNOT assume that every single click you make in the game has been watched by KoLmafia.
PirateRealm -> Sailing the PirateRealm Seas = a location
PirateRealm -> PirateRealm Island = a location, but which maps to a specific island, which changes as you progress
Those two locations appear in the charpane (and api.php) as links to adventure.php?snarfblat=xxx
And that is a reason to leave them. I'll give a specific example later.
PirateRealm -> PirateRealm Island -> Crab Island = a location
Happens to have the same adventure number as "PirateRealm Island", but if we know you are adventuring there, my_location() returns $location[ Crab Island ] which has "giant crab" and "giant giant crab" as monsters.
Now, why would we want generic "PirateRealm Island" as a location?
Looking at my own session log:
I got the choice adventure to choose (this or that) island.
(At tis time, KoLmafia knew what my various choice options ere; it had a map from option number -> (text displayed for that option. 1 -> Crab Island, etc.)
This was a choice that, somehow, did not prevent me from doing SOME other things. I didn't know which isand to go to, so I ran "missingManuel".
That looked up every Manuel page and reported on which monsters had incomplete factoids.
Based on that idata, I selected the choice option - in the relay browser - for the Island which would get me factoids.
KoL accepted it!
And KoLmafia reported I had taken choice XXX option 3 which was "unknown" - since it had thrown away the choice options.
That is probably worth a closer look; I was still in a choice, although I had opened 27 Manuel pages, at least.
But, because I had navigated away from the choice - as KoLmafia thought - it forgot the options.
As I said - it should not have forgotten them. Peraps Manuel (questlog) requests should not count as "walking away" from the choice.
But the result was that _lastPirateRealmChoice was "unknown".
Which we now translate to the generic "PirateRealm Island" adventure, given a PirateRealm Island URL.
If you take that choice outside of KoLmafia, the same thing will happen: we will recognize you are in PirateRealm Island but will not know which one.
That's a degenerate case, but we CANNOT assume that every single click you make in the game has been watched by KoLmafia.
the dictator
Member
Do you have a shop.php relay override that can't handle the piraterealm fun-a-log?
Huh. Now that I’m looking for them in zoneslist.txt, there’s a lot of things that can be improved by using nested zones. For example, the following line in modifiers.txt:
Code:
Item doll-eye amulet Single Equip, Item Drop: [40*(zone(Manor0)+zone(Manor1)+zone(Manor2)+zone(Manor3))]
Code:
Item doll-eye amulet Single Equip, Item Drop: [40*zone(Manor)]