What's new
By:
  • Visit Rebornbuddy
  • Visit Panda Profiles
  • Visit LLamamMagic
  • Visit Resources
  • Visit Downloads
  • Visit Portal
RebornBuddy Forums

Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

[Release] RebornBuddy64 Version 1.0.681 - DirectX11 / x64 bit compatible

Making progress on the 6.4 update. There have been some large internal changes to things such as character status flags and raycasting.
 
All the current offsets have been updated.

With the changes to StatusFlag, one major subsection of RB now needs to be redesigned, as InCombat status of the player, party members and npcs relyed on this flag.
The new flag seems to not clear once combat has ended and as such can no longer be used as we were using it.

For the localplayer object this can be worked around using some other data in the client, and since hostile npcs don't "draw" their weapon unless their incombat that will work there, but this will give a false positive for other players if they have their weapons drawn.

Still sniffing thru the client to see if there is another replacement we can use.
 
mastahg said:
All the current offsets have been updated.

With the changes to StatusFlag, one major subsection of RB now needs to be redesigned, as InCombat status of the player, party members and npcs relyed on this flag.
The new flag seems to not clear once combat has ended and as such can no longer be used as we were using it.

For the localplayer object this can be worked around using some other data in the client, and since hostile npcs don't "draw" their weapon unless their incombat that will work there, but this will give a false positive for other players if they have their weapons drawn.

Still sniffing thru the client to see if there is another replacement we can use.
Click to expand...
Thanks for keeping us up to date. I know you're working hard on it.
 
Version 563
Code: 
Initial release for version 6.4

When loading a profile attributes passed into tags that do not take the passed attribute now output that information into the log to help profile authors.


Breaking Changes:

StatusFlag enum has changed, now only contains None,WeaponOut,HadEngagedInCombat,IsDying

If anyone is curious, they merged the previous isdying into the statusflag, and now what was isdying has a flag for incombat
 
New build coming now that fixes DD

Code: 
Revert changes to StatusFlags enum = Hostile,Incombat
Update CharacterStatus enum = WeaponOut,HadEngagedInCombat,Dying
 
New hotfix broke some stuff btw; right now rb can't identify ff14 game client. just a headsup
 
Is it possible to detect waymarks that have been placed in an instance? E.g: A, B, C, D, 1, 2, 3, 4 markers that groups place on the ground.
 
Dalamud has a custom waymark editor that can load, save, and replace waymark presets + actually placed waymarks. I'm told their memory patterns are done a little differently from RB's style, but they could be a good starting point to finding RB's version: https://github.com/abashby/WaymarkP.../WaymarkPresetPlugin/MemoryHandler.cs#L79-L85

Waymarks don't show up as GameObjects, so it's probably a more general AVFX that RB isn't aware of yet. Adding support would be cool because some attacks are only telegraphed by pure AVFX without a cast or hidden GameObject until it's too late, like the water fountain spam in Dohn Mheg's first boss. Here are the internal file paths to each waymark, but I'm not sure how to look further for a general AVFX list like we have with GameObjects:
  • A: vfx/common/eff/fld_mark_a0f.avfx
  • B: vfx/common/eff/fld_mark_b0f.avfx
  • C: vfx/common/eff/fld_mark_c0f.avfx
  • D: vfx/common/eff/fld_mark_d0f.avfx
  • 1: vfx/common/eff/fld_mark_10f.avfx
  • 2: vfx/common/eff/fld_mark_20f.avfx
  • 3: vfx/common/eff/fld_mark_30f.avfx
  • 4: vfx/common/eff/fld_mark_40f.avfx
 
I wouldn't be opposed to adding the ability to read their positions, but I am against adding the ability to place them. After the kerfuffle that occurred with addons placing them.
 
mastahg said:
I wouldn't be opposed to adding the ability to read their positions, but I am against adding the ability to place them. After the kerfuffle that occurred with addons placing them.
Click to expand...

That sounds fine to me. I'd guess the main use-case would be ACRs trying to do strategies relative to markers. Or in my case, using it to quickly extract XYZ of a location I need to go towards but can't stand on and can't detect as GameObjects since it's more AVFX-only(?), like dungeon jump pads or zone lines.
 
So ActionResourceManager.Ninja.NinkiGauge is accessing ActionResourceManager.CostTypesStruct.offset_C when it actually should read ActionResourceManager.CostTypesStruct.offset_A
 
mastahg said:
I wouldn't be opposed to adding the ability to read their positions, but I am against adding the ability to place them. After the kerfuffle that occurred with addons placing them.
Click to expand...
Manta said:
That sounds fine to me. I'd guess the main use-case would be ACRs trying to do strategies relative to markers. Or in my case, using it to quickly extract XYZ of a location I need to go towards but can't stand on and can't detect as GameObjects since it's more AVFX-only(?), like dungeon jump pads or zone lines.
Click to expand...

Yeah. I'm not interested in placing them, just detecting where each one is. Some groups use different marker positions than others. This is mainly about being able to do a Toast like "4 safe" instead of "NW safe". Some groups put 1 NW though. For now I have just been adjusting a variable that covers different variations that groups like to use. Would be nice to be able to detect marker coordinates though!
 
You must log in or register to reply here.
Back
Top