Magus_Prime
Well-known member
When using a modeling claymore it, according to the wiki, reduces the count of both Frat boys and Hippies by 36 - 40 each. The IsleWar image in the relay browser properly reflects this but the CLI counter does not.
New Content - Implemented KOLHS modeling claymore use not tracked in IsleWar counts
- Thread starter Magus_Prime
- Start date
I'm pretty sure it updates when you happen to visit the island. There is no support for having it go look for itself.
Most of our Big Island support is in webui/IslandDecorator. We also have IslandArenaRequest to attend concerts, PyroRequest to visit the lighthouse, and the "nunnery" command submits a raw GenericRequest to visit the nuns. Breakfast (during the war) will visit the farmer to collect his reward, using a GenericRequest.
I wonder if all this can be rationalized so that IslandRequest, say will visit either bigisland or postwarisland, as appropriate, and will handle logging requests and parsing responses that go to those places. IslandManager might keep track of the internal state, and IslandDecorator would do just the Relay Browser decoration.
We could have IslandRequest() - no arguments - be a "visit the current island" request, the result of which would update state based on what it sees on the map.
Regardless of code cleanup, the issue remains that the variable result from the claymore will make accurate trapping of war kills impossible. If you are looking for a Wossname, say, you are out of luck. And do we really want to automatically submit a request to look at the map after you use a claymore? We'd be better off filing a bug report with KoL, asking that the result of the item use actually tell us how many combatants were blown up - even if only in an HTML comment, in case listing the actual number visibly is deemed to be "not funny".
As if war is "funny".
Most of our Big Island support is in webui/IslandDecorator. We also have IslandArenaRequest to attend concerts, PyroRequest to visit the lighthouse, and the "nunnery" command submits a raw GenericRequest to visit the nuns. Breakfast (during the war) will visit the farmer to collect his reward, using a GenericRequest.
I wonder if all this can be rationalized so that IslandRequest, say will visit either bigisland or postwarisland, as appropriate, and will handle logging requests and parsing responses that go to those places. IslandManager might keep track of the internal state, and IslandDecorator would do just the Relay Browser decoration.
We could have IslandRequest() - no arguments - be a "visit the current island" request, the result of which would update state based on what it sees on the map.
Regardless of code cleanup, the issue remains that the variable result from the claymore will make accurate trapping of war kills impossible. If you are looking for a Wossname, say, you are out of luck. And do we really want to automatically submit a request to look at the map after you use a claymore? We'd be better off filing a bug report with KoL, asking that the result of the item use actually tell us how many combatants were blown up - even if only in an HTML comment, in case listing the actual number visibly is deemed to be "not funny".
As if war is "funny".
And every war kill thereafter, as the image only changes when certain thresholds are reached, and the turn you use the claymore will only set a viable range.
xKiv
Active member
Well, actually, you would only want to look at the image # if you know that the current viable range spans at least two different image# ranges, and then the visit will likely reduce the current viable range (maybe to half, on average?), making it so that it will take more turns until the next time useful img# check ...
I refactored support for the Big Island into IslandManager, IslandRequest, and IslandDecorator a while ago. As a result of that, we could do this:
in UseItemRequest.parseConsumption for a modeling claymore to go look at the island map and update our internal variables for the progress of the war. Probably only if the responseText indicates that it did something; it has different messages depending on whether the war is going on or not.
Note that that will only increase the kill counts to the minimum required to be in the windows corresponding to the images on the map; it cannot know exactly what the new counts are, since the item does a variable number of kills.
Code:
RequestThread.postRequest( new IslandRequest() );Note that that will only increase the kill counts to the minimum required to be in the windows corresponding to the images on the map; it cannot know exactly what the new counts are, since the item does a variable number of kills.