About headMarkers

[tssailzz8]

i konw in the raid，the headMarkers have offset,but i do not konw the ture ID is.how do you know it ,likes https://github.com/quisquous/cactbot/blob/6a8053285b5aaa5abad966b7d775e839f374783c/ui/raidboss/data/06-ew/raid/p4s.ts#L1110,the blueTether is 012C.can you tell me? @Legends0

[tssailzz8]

And in the NetworkTether,the second to last act line is line's width,likes Tether 23:40003202:Articulated Bit:10FF0001:Tini Poutini:0000:0000:0001:10029769:000F:0000 the line's width is 0xf,it was byte and not big than 0x99.in fact it have a line to clear the line ,likes Tether 23:40003202:Articulated Bit:10FF0001:Tini Poutini:0000:0000:0001:10029769:0000:0000,the wight change to the 0

[Legends0]

In the case of p4s, there are two characteristics used to determine that headmarker's true id.

1. The first headmarker in part one is known from normal mode, happens to have the same id and normal mode does not use random offset
2. Fights with a door boss happen to exist in the same instance (or something like that) and since we know what the true value of the headmarker in part one is, we can calculate its offset and from a log that includes part one and part two we can use the calculated value in part one to calculate the true value of the headmarkers in part two.

Now as for cases where we don't know any headmarker in a fight and there is an offset, some other function would have to be used and I don't know if we could get the true values there.

[quisquous]

And in the NetworkTether, the second to last act line is line's width...

Sorry, I'm not sure what you asking. Could you rephrase and ask again?

[tssailzz8]

而在 NetworkTether 中，倒数第二个行为线是线的宽度......

对不起，我不确定你在问什么。你能改写一下再问吗？

sorry，recenty I've been studying actorcontrol,so it is my find something

[tssailzz8]

i can figure out the real value，but it read the memory.

[tssailzz8]

can it help?

[quisquous]

Where does this code come from?

In general, cactbot uses the real values. I think the only way it would be easier would be to convince Ravahn to handle this in the ffxiv plugin so the values are correct in the log lines. Otherwise, the triggers are going to look about the same as they do now whether or not we know what the offset is or have to calculate it from the first one.

[tssailzz8]

it from this，my English is not good ,can you tell Ravahn ?

[quisquous]

Oh, did you find this yourself? How did you find the address?

[tssailzz8]

yes ,by the switch's the receive packets call

[quisquous]

Sorry, I haven't looked at the receive packets call. How do you find that? I am trying to answer the question "if I wanted to find this signature in the future if it changed, what steps would I go about to find this signature?" (I know how to find signatures in general, but I don't know what I need to look for to find these in particular.)

[quisquous]

Additionally, I think it'd be better if you could find the network data that these offsets came in on instead of a memory address.

[tssailzz8]

I use the Dalamud's ProcessZonePacketDown call. Each opcode corresponds to a case cycle of switch case. I use the corresponding opcode to find the corresponding network packet.and i find it was write from InitZone,but i don't find it related to the network packet data

[quisquous]

I think really I need the network data that corresponds to these offsets. If you can find it, please let me know. I'm going to close this for now (as I'm not sure there's anything else actionable as a cactbot issue), but feel free to comment if you find it.

[tssailzz8]

In my recent research I found that this value is a random number. In the game, the client and the server use some synchronization mechanism to ensure that the random number generated is the same, and the random number seed is initialized when switching maps, so it is troublesome for third party programs to join the synchronization as well.

[tssailzz8]

[tssailzz8]

World_2022_03_26_21_23_20.log

[ShadyWhite]

Due to the poor network status of tssailzz8, upload this file instead of him. Network_26404_20220326.log