util: add basic support for CEs to encounter_tools #729
Conversation
|
@jacob-keller Thanks for your contribution! 🌵🚀 |
|
@valarnin do you think something like this could be merged? I tried to figure out a way to make the encounter listing work without breaking existing support. |
|
I guess my question is whether this approach is good, or if we need to do some other refactoring on the encounter logic as a whole to properly support CEs. |
|
I have some more thoughts on this, and I will try to clean it up before making it a non-draft |
|
I'll hold off on reviewing actual code changes in detail until you switch to non-draft. As far as I've been able to determine, the mapping of
Unfortunately, XIVAPI has a bug with this data sheet where the // normal typedef for XIVAPI exported data
const data: DynamicEventSetType = {
'3.5': {
// ... other fields
'Name': {
'en': 'Calamity Bound',
// other langs
},
},
} as const;
export default data;
export type CEMap<CEList> = {
[directorCEID: string]: keyof CEList;
};
// `<foo>CEs` auto-generated based on XIVAPI sheet
// `<foo>CEs` keys auto mapped by stripping non-alphanumeric characters
// and lowercasing first character maybe?
// `<foo>CEMap` is a manual mapping in the util script, like in `zone_overrides.ts`
export const bozjaCEs = {
// entries from `data` starting with `1.`
} as const;
export const bozjaCEMap: CEMap<typeof bozjaCEs> = {};
export const zadnorCEs = {
// entries from `data` starting with `2.`
} as const;
export const zadnorCEMap: CEMap<typeof zadnorCEs> = {};
export const southHornCEs = {
// entries from `data` starting with `3.`
'calamityBound': data['3.5'],
} as const;
export const southHornCEMap: CEMap<typeof southHornCEs> = {
'32F': 'calamityBound',
};Other solutions are fine too, the ultimate goal is to source the name of the CE and its base "zone" from XIVAPI somehow. |
Any idea if XIVAPI stuff is open source and I could look at what it takes to fix this? |
It's fixed as of a minute ago or so. https://v2.xivapi.com/api/sheet/DynamicEventSet/3:1 For future reference, the XIVAPI discord is at https://discord.gg/MFFVHWC |
|
I'll take a stab at implementing something hopefully in the next couple of days |
jacob-keller
force-pushed
the
jk-encounter-tools-ce-support
branch
from
6d9744d to
e38d07b
Compare
jacob-keller
changed the title
valarnin
left a comment
valarnin
left a comment
There was a problem hiding this comment.
I'll do a more proper review later or tomorrow, just wanted to address this first.
valarnin
changed the title
jacob-keller
force-pushed
the
jk-encounter-tools-ce-support
branch
from
e38d07b to
e573741
Compare
|
I have some additional followup work to extend the make_timeline.sh with support for inserting appropriate headers for the CE start, as well as a new --timeline_offset commandline argument to allow adjusting the initial timelinePosition value to make it easier to create CE timelines in the way that we have them laid out in the exploration zone timeline files. I'm planning to submit those after this merges. |
|
I think it worked for what I provided in #736 ? |
|
Updated to include the director ID for forked tower reported by Legends0. |
|
Does this need any changes to be acceptable? |
|
Some additional notes... there are more action control lines within forked tower: blood:
|
I can add them, but we'd need to either add a separate synthetic entry or add something to the CeInfoType that doesn't exist for the other CEs if I understand it right? |
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
In particular, outside of the tower, CEs end with a 80000014 entry with the director ID set to 00, but inside the tower, they instead end with the special unique IDs? I'm not sure how best to handle adding these. I don't think they warrant their own entries in the synthetic CE list. |
|
@xiashtra is there anyone who can review this to merge? Its been waiting quite some time, and I believe I have fixed most of the remaining issues, with only the issue of the "success" IDs being missing, but I'm not sure how useful those would be. |
|
I think there might be some duplication when viewing a forked tower log: The -1s lines cannot be queried and result in fight not found. The CEs outside work: EDIT: Duplication probably isn't the right word to describe it. It just looks wrong and I am unsure if that is the intended output for a forked tower log since the encounters don't produce a timeline and if they did, the binding lock one would be useful for manually creating a timeline. |
|
I think you're right. For CEs we use the "000000" id to reset the encounter. Does that happen in Forked Tower? Maybe we do actually need to use the ending ID to check when the CE ends. |
I don't see a 000000 id in the Forked Tower. The ending ID seems like an alternative to use, but I am unsure how missing the ending ID (such as through a disconnect/reconnect) or exiting the instance would impact the parse. |
|
Ok. I wonder if those extra ones are because of the cases where we get two unseals for the passage ways? |
|
I also noticed it says "The pronged passage" instead of "Pronged Passages". |
|
Ok, it looks like what happens is that the encounters within forked tower use traditional unseal lines rather than CE data. This means that we're essentially starting the CE and immediately ending it when the unseal line happens. |
|
@Legends0 I'm not sure what the best solution is. I can try adding the end IDs, but I don't think that will help, because the seal lines are also triggering encounters. That might mean we should just leave out the forked tower CE lines, or mark them as not generating encounters somehow? |
|
We also seem to completely lose the central passages encounter, possibly because it doesn't keep you incombat the entire time? We could instead mark the seal lines within forked tower as invalid somehow and rely solely on the CE director IDs instead? |
|
I make a script to find all of the director ID updates and seal/unseal lines for my two runs on Sunday: From the look of it, se wee the 33B seal at 17:14:42 and 2 minutes later we see the net seal message at 17:16:53, followed in 15 seconds by the game log seal message at 17:17:08 then we see the director Update for the CE being done, the net unseal and the unseal log message: Then we see the 33F central passages director update. This is immediately followed by the unseal message from the palaeography room no longer being sealed: This is why the central passages gets skipped. There's no seal or unseal for that "encounter". After this, we get the director id update for dead stars along with its room seal unseal: I'm really not certain how this should be handled. As it stands, I marked 33C as the "dead stars" ID, and 33F as the "central gallery" ID, but those are really the IDs for when the previous boss dies, (when demon tablet dies or when central gallery walls come down). Those do not make sense as "starting" encounters. Same for Marble Dragon which is 33D for clearing bridges, and 33E is likely the room unlock not the actual start of Magitaur. Since these do not line up with the actual encounters. The only one that might work properly for making a timeline is the binding lock with the end of Marble Dragon up to when Magitaur unlocks. Even trying to use the CE IDs to handle the central passages and lockwards is rough because the unseal gamelog message comes after the director update for the last boss being defeated... |
Keeping the 4 seal based encounters and ignoring the CE director IDs is simpler. It might be better to do a separate PR/feature request for handling the Central passages and binding locks since those seem to need to check for a future CE ID to know when to stop. I never checked if BA had something similar. It's good the CE IDs are documented, but for those that already have a seal it is creating an issue if we treat all CE IDs the same. Outside of a Lockwards type encounter, the trash pulls leash and follow a short loop of abilities. There also looks to be some sort of counter for the lockwards that gets logged as actor controls, probably the countdown to activation/lock. In the raidemulator it also parses the trash encounters as part of the first pull of the boss, so triggers can be emulated against a timeline. |
The main issue is figuring out a clean way to avoid ending the encounter due to an unseal from the previous encounter consistently happening after the "start"... |
|
I'm going to remove them for now with a comment in overrides documenting the IDs. |
I think "Pronged Passages" was a typo. Misunderstood with colloquial use to describe the encounter as Bridges. It is one passage, and the pronged description means it splits like a fork, although it looks more like two prongs until the geomancer buttons are pressed to connect their ends. |
Trying to include the CE IDs for the DirectorUpdate lines within the forked tower is problematic. Each area gets its own DirectorUpdate upon completion, but the main encounters already have seal/unseal lines to track the encounter. Trying to treat these as CEs results in a bunch of 0-length encounters, and this results in confusion when checking timelines with the log tools. Theoretically we could try to use the IDs for tracking the central passages and the lockwards. Unfortunately, this is problematic because the DirectorUpdate happens *before* the unseal messages from the game. For now, just remove these synthetic IDs and leave a comment detailing the IDs for the future. If someone wants to try and fix the logtools to better track this somehow they will have the information to help with this. Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
|
I removed the CEs, though I didn't strip out the synthetic CE support in case we need it in the future. I updated the synthetic CEs to comment the forked tower DirectorUpdate IDs. |
|
@Legends0 @jacob-keller this was approved quite a while ago but never merged, is there an outstanding issue waiting to be resolved? |
Im good with a merge, just didn't know if @valarnin had resolved his concern. |
|
Not that I'm aware of. There's probably some follow up work like making the raid emulator work better, but I'd much rather do that as follow up. I don't have merge privileges, so I can't merge myself |
|
My original concern was resolved but the conversation wasn't marked as resolved. |
|
Sounds like everyone is good for this, I'm going to merge it then. |
) Add some basic support for detecting and splitting encounters by CE, based on the 0x21 network log line. The IDs for this are manually determined, but we now pull the encounter names from xivapi, and generate appropriate mappings. This works ok in my tests, and so far doesn't appear to break any other encounter logic. However, it likely needs more testing and fine tuning. I also now added logic to pull the CE info from xivapi, with a new generator script. I did pull a bit more data than we currently use (since the current code doesn't use anything but the english names). I don't yet pull the Chinese or Korean data like how zone_ids.ts does yet. There's probably some further cleanup we can do around encounter support, but I wanted to try and get the very basic splitting functionality done. - util: add support for sheets with subrow_id to xivapi - util: log eslint errors when failing in writeFile - util: generate CE info from xivapi - encounter_tools: detect and report CEs as separate encounters Signed-off-by: Jacob Keller <jacob.keller@gmail.com> --------- Signed-off-by: Jacob Keller <jacob.keller@gmail.com> df45b52
…verlayPlugin#729) Add some basic support for detecting and splitting encounters by CE, based on the 0x21 network log line. The IDs for this are manually determined, but we now pull the encounter names from xivapi, and generate appropriate mappings. This works ok in my tests, and so far doesn't appear to break any other encounter logic. However, it likely needs more testing and fine tuning. I also now added logic to pull the CE info from xivapi, with a new generator script. I did pull a bit more data than we currently use (since the current code doesn't use anything but the english names). I don't yet pull the Chinese or Korean data like how zone_ids.ts does yet. There's probably some further cleanup we can do around encounter support, but I wanted to try and get the very basic splitting functionality done. - util: add support for sheets with subrow_id to xivapi - util: log eslint errors when failing in writeFile - util: generate CE info from xivapi - encounter_tools: detect and report CEs as separate encounters Signed-off-by: Jacob Keller <jacob.keller@gmail.com> --------- Signed-off-by: Jacob Keller <jacob.keller@gmail.com> df45b52
5 participants
Add some basic support for detecting and splitting encounters by CE, based on the 0x21 network log line. The IDs for this are manually determined, but we now pull the encounter names from xivapi, and generate appropriate mappings.
This works ok in my tests, and so far doesn't appear to break any other encounter logic. However, it likely needs more testing and fine tuning.
I also now added logic to pull the CE info from xivapi, with a new generator script. I did pull a bit more data than we currently use (since the current code doesn't use anything but the english names). I don't yet pull the Chinese or Korean data like how zone_ids.ts does yet.
There's probably some further cleanup we can do around encounter support, but I wanted to try and get the very basic splitting functionality done.
Signed-off-by: Jacob Keller jacob.keller@gmail.com