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

mastahg said:
New build updates IsWithinInteractRange logic to better match the server side logic
Click to expand...

The new IsWithinInteractRange is having trouble in some new areas' aetheryte, including Garlemald, and Mare Lamentorum
For example, in Camp Broken Glass, no matter how close I am to the Aetheryte, the IsWithinInteractRange returns false.
Sinus Lacrimarum is a bit different it doesn't return true until you jump to the aetheryte, where old logic return true on the ground.
 
hkme said:
The new IsWithinInteractRange is having trouble in some new areas' aetheryte, including Garlemald, and Mare Lamentorum
For example, in Camp Broken Glass, no matter how close I am to the Aetheryte, the IsWithinInteractRange returns false.
Sinus Lacrimarum is a bit different it doesn't return true until you jump to the aetheryte, where old logic return true on the ground.
Click to expand...

Thanks for the report. New build resolves the issue.

Code: 
Don't use aethertyte object specific location
Update below distance check for IsWithinInteractRange

Kupo:
Machinist rotation updatred
 
mastahg said:
Thanks for the report. New build resolves the issue.

Code: 
Don't use aethertyte object specific location
Update below distance check for IsWithinInteractRange

Kupo:
Machinist rotation updatred
Click to expand...

Thank you. The issue in Garlemald and Mare Lamentorum is fixed.
However there is another issue in Elpis where IsWithinInteractRange just change from false to true and when we interact at that point we get the in-game error Target too far above you.
 
hkme said:
Thank you. The issue in Garlemald and Mare Lamentorum is fixed.
However there is another issue in Elpis where IsWithinInteractRange just change from false to true and when we interact at that point we get the in-game error Target too far above you.
Click to expand...
which one in elpis?
 
hkme said:
All three of them
Click to expand...
Quite frustrating. It looks like some aetherytes use their secondary location serverside for the height check while others use the primary location of the object.

New build will check and use whichever object height is higher, as there is so many aetherytes I can't test all of them but this did work with all the ones I did test. If this breaks any of them i'll just have to revert the changes and hardcode some logic for the troublesome ones.
 
Some Stormblood aethernet shards also sometimes suffer from bad range or height. I'm not sure if this is from the recent changes or not.

These specific cases can be fixed by lowering the interact range for aethernet shards, or getting closer until the height difference with the player is smaller. Shards are much smaller than aetheryte crystals and walking closer will better align the heights.

In Rhalgr's Reach, "Northeastern Rhalgr's Reach" is within interact range from the top of the hill, so the shard is "too far below":

https://pastebin.com/raw/5fx730pW

In Kugane, "The Ruby Bazaar" is within interact range from the top of the stairs, so the shard is "too far below":

https://pastebin.com/raw/wtHb2sNw

Unrelated: Reporting bugs or fixes is difficult because forum's spam filter almost always prevents me from posting logs or code, then randomly lets me post the exact same text days later. Can you relax the spam filter or consider an alternate issue tracker, please? (e.g., non-code GitHub repo with only Issues enabled, à la esi-issues)

aMqitjC.png
 
Manta said:
Some Stormblood aethernet shards also sometimes suffer from bad range or height. I'm not sure if this is from the recent changes or not.

These specific cases can be fixed by lowering the interact range for aethernet shards, or getting closer until the height difference with the player is smaller. Shards are much smaller than aetheryte crystals and walking closer will better align the heights.

In Rhalgr's Reach, "Northeastern Rhalgr's Reach" is within interact range from the top of the hill, so the shard is "too far below":

https://pastebin.com/raw/5fx730pW

In Kugane, "The Ruby Bazaar" is within interact range from the top of the stairs, so the shard is "too far below":

https://pastebin.com/raw/wtHb2sNw

Unrelated: Reporting bugs or fixes is difficult because forum's spam filter almost always prevents me from posting logs or code, then randomly lets me post the exact same text days later. Can you relax the spam filter or consider an alternate issue tracker, please? (e.g., non-code GitHub repo with only Issues enabled, à la esi-issues)

aMqitjC.png
Click to expand...

Thanks for the report.
I've increased your post count so you shouldn't get flagged by spam any more, also manually marked your previous posts as not spam.

New build:
Reverting the aetheryte location changes, and adding a hack for the aetheryte that started this whole mess, falcons nest.
Please let me know if there are any more weird aetheryte/ general interaction issues.
 
mastahg said:
I've increased your post count so you shouldn't get flagged by spam any more, also manually marked your previous posts as not spam.
Click to expand...

Thanks!

Now there's a new issue: Navserver is dead. Everyone in Discord is suddenly reporting it's broken for pre- and post-patched clients.


[15:01:10.205 N] Navserver rejected login information executing treeroot.stop()
[15:01:10.208 N] Stopping the bot. Reason:Navserver rejected login information executing treeroot.stop()
[15:01:10.209 N] Waiting 5 seconds before attempting to reconnect
[15:01:10.255 D] CurrentBot.Stop()

EDIT: Looks like it's back up!
 
Last edited:
Build 479
Code: 
DirectorManager.ActiveDirector.GetTodoArgs will now return the proper values while inside a trust
 
Mastahg I was wondering if you'd given any thoughts to moving over to .net 6 again? Perhaps as an experimental beta version? There's quite a few benefits from doing so, in particular with performance.
 
Neverdyne said:
Mastahg I was wondering if you'd given any thoughts to moving over to .net 6 again? Perhaps as an experimental beta version? There's quite a few benefits from doing so, in particular with performance.
Click to expand...

No. There was too many issues with the compiler system. No one was able to provide any precise benefits of exactly what would be improved either.
 
Getting Span<T> and Memory<T> would be awesome for real world performance gains but are .NET 6 exclusive. Some devs have talked about fancy assembly features but I don't have enough experience to expand on that one.

Many useful FF-related libraries like Lumina are moving to .NET 5/6 without .NET Standard and therefore breaking compatibility with RB. That means more duplicated + hard-coded game data, leading to incomplete information or manual updates after game patches. Or daring to try integrating Saint Coinach :eek:

Even standard lib stuff from Microsoft would improve logging, dependency injection, etc, but those are more limited by RB's refusal to load precompiled binaries and having very odd assembly resolution due to custom compilation. I technically had these working in Faith 1.5 years ago with assembly weaving and a Loader.cs, but it's hard to recommend that path to newbies and so good practices suffer.
 
Last edited:
Yeah, Span<T> is awesome. The new System.Text.Json serializer is faster than json.net too, which can improve performance when saving logging files in a tick. Another cool thing is Assembly Load Context letting you load assemblies with their own dependencies and then unload them afterwards.
 
Hey mastahg,

Running into an issue again getting the Nav to teleport correctly into Firmament, it's selecting the 3rd option (index 2).

[17:12:20.683 N] Latency to Buddy service: 120 ms
[17:12:21.077 D] Interacting with aetheryte 0x23D09B6C930
[17:05:38.630 D] Teleporting to Foundation
[17:05:46.332 N] [NavGraph] Objective set to Move to <-59.2751, 8.113304, 40.28277> on Foundation(418) and interact with 70 to take us to <10.02715, -15.2, 174.1999> on The Firmament(886)
[17:05:46.393 D] Interacting with aetheryte 0x23D09B6C930
[17:06:06.658 D] Interacting with aetheryte 0x23D09B6C930

unknown.png
 
Wkok said:
Hey mastahg,

Running into an issue again getting the Nav to teleport correctly into Firmament, it's selecting the 3rd option (index 2).

[17:12:20.683 N] Latency to Buddy service: 120 ms
[17:12:21.077 D] Interacting with aetheryte 0x23D09B6C930
[17:05:38.630 D] Teleporting to Foundation
[17:05:46.332 N] [NavGraph] Objective set to Move to <-59.2751, 8.113304, 40.28277> on Foundation(418) and interact with 70 to take us to <10.02715, -15.2, 174.1999> on The Firmament(886)
[17:05:46.393 D] Interacting with aetheryte 0x23D09B6C930
[17:06:06.658 D] Interacting with aetheryte 0x23D09B6C930

unknown.png
Click to expand...


Thanks for the report... I changed this in December but I can't find the report that caused me to change it so I am reverting the change.

The new build that is coming now also comes with the updated greymagic. This should result in much less stutters during normal usage. RB cpu usage will slightly higher in low TPS scenarios but I consider that an ok tradeoff as long as the game no longer freezes due to desyncs.

If you get an error message or failure to load please make sure you have the latest VC++ installed
 
You must log in or register to reply here.
Back
Top