Synergize or Store Dynamis Su5 weapons?

Printable View

07-10-2025, 08:01 AM
Gwydion

Synergize or Store Dynamis Su5 weapons?

Let us Synergize Dynamis Su5 weapons Path A/B/C into a Combined Path D.

Or perhaps, alternatively, let us store Dynamis Sy5 weapons that are capped (max augments).

You've done this before with level 90 Augmented Relic+2 armor.

Thank you!
07-10-2025, 11:18 AM
Zenion

I think storing the augmented weapons is a technical issue. Even capped, since they have multiple paths they'd need that extra data, which would complicate storing them on a slip. With Relic+2, it was probably technically a unique item, which would mean that its augmented status is just baked in and not an extra thing that would need to be tracked.

This implies a solution wherein augmented Su5 weapons get an afterglow upgrade or something that would allow fully completed weapons of each path to be distinct items, but that sounds like a lot.
07-23-2025, 07:15 PM
Gwydion

Quote:

Originally Posted by Zenion

I think storing the augmented weapons is a technical issue. Even capped, since they have multiple paths they'd need that extra data, which would complicate storing them on a slip. With Relic+2, it was probably technically a unique item, which would mean that its augmented status is just baked in and not an extra thing that would need to be tracked.

This implies a solution wherein augmented Su5 weapons get an afterglow upgrade or something that would allow fully completed weapons of each path to be distinct items, but that sounds like a lot.

Yeah, it would be unusual for SE to treat Rostam A, B and C as different items on a Storage Slip. Even if SE gives each weapon 1-bit on the Storage Slip, they'd have to use the weapon name AND the augment to uniquely identify the item being stored and retrieved.

I can also imagine that if SE were to add this functionality, it would probably affect how other Storage Slips would be processed. (Of course, we want everything to go smoothly, but it could have unintended side-effects or consequences).
07-24-2025, 01:52 AM
Voidstorm

it would be a massive inventory saver if they put in the work to implement it.
Unity r15 +Odyssey r30 storage slip
Ultimate weapon r15 storage slip
divergence weapon nq/+1/+2 15/20/25 & jse neck nq/+1/+2 r15/20/25 storage slip
07-24-2025, 04:32 AM
Zenion

Quote:

Originally Posted by Gwydion

Yeah, it would be unusual for SE to treat Rostam A, B and C as different items on a Storage Slip. Even if SE gives each weapon 1-bit on the Storage Slip, they'd have to use the weapon name AND the augment to uniquely identify the item being stored and retrieved.

I can also imagine that if SE were to add this functionality, it would probably affect how other Storage Slips would be processed. (Of course, we want everything to go smoothly, but it could have unintended side-effects or consequences).

I'm not an expert on how FFXI stores item data, but I think it goes a bit like this: A storage slip can store item ID 2000, 2001, 2002, 2003, and 2004. If you trade item 2003, it checks to see if there's one of those stored to the slip already; if there isn't, it removes the item and marks it as stored on the slip.

The problem is, Rostam is item ID 21581. Rostam path A is ID 21581. Rostam path B is 21581. Rostam path C is 21581. Since the slips only work as semi-efficient storage because they're only recording one bit per supported item ID, they literally can not differentiate paths. Adding the augment metadata is an extra two bits just to hold the path, and then the logic needs to be able to check ID AND path, and that's only if you're only allowing rank 15 items. It's not impossible, I'm sure, but it would require the storage slip system to be built out in a way that it's not currently designed for.

Making an afterglow upgrade for each path would let you give Rostam path A afterglow an ID of, say, 30000, then the path B version could be 30001, and the path C could be 30002, and now a storage slip can process them just fine because each is a unique item ID just like relic armor or event items.

Items with just the one augment path might be easier, if you allow storage of just the max rank version; there are already examples of storage slip items coming out with fixed metadata (anything with a recast timer attached), that probably wouldn't be a stretch to implement. I'm sure if you asked around, though, you'd find someone who could explain how that would be exploitable to instantly max out an item for free.
07-24-2025, 06:44 AM
Voidstorm

Quote:

Originally Posted by Zenion

I'm not an expert on how FFXI stores item data, but I think it goes a bit like this: A storage slip can store item ID 2000, 2001, 2002, 2003, and 2004. If you trade item 2003, it checks to see if there's one of those stored to the slip already; if there isn't, it removes the item and marks it as stored on the slip.

The problem is, Rostam is item ID 21581. Rostam path A is ID 21581. Rostam path B is 21581. Rostam path C is 21581. Since the slips only work as semi-efficient storage because they're only recording one bit per supported item ID, they literally can not differentiate paths. Adding the augment metadata is an extra two bits just to hold the path, and then the logic needs to be able to check ID AND path, and that's only if you're only allowing rank 15 items. It's not impossible, I'm sure, but it would require the storage slip system to be built out in a way that it's not currently designed for.

Making an afterglow upgrade for each path would let you give Rostam path A afterglow an ID of, say, 30000, then the path B version could be 30001, and the path C could be 30002, and now a storage slip can process them just fine because each is a unique item ID just like relic armor or event items.

Items with just the one augment path might be easier, if you allow storage of just the max rank version; there are already examples of storage slip items coming out with fixed metadata (anything with a recast timer attached), that probably wouldn't be a stretch to implement. I'm sure if you asked around, though, you'd find someone who could explain how that would be exploitable to instantly max out an item for free.

https://www.bg-wiki.com/ffxi/Storage_Slip_13

There are 2 items with each of the same item IDs, one can't be stored (unaugmented & augment trial in progress) & the other can be stored: augmented.
Only the augmented version can be stored.
As such, it could be possible to make a slip that differentiated between one augment criteria and another.
While abjurations, delve gear, escha gear, Nyame & divergence weapons may be a stretch with the multiple paths and looking for a specific augment signature to validate storage. All the other ranked augments should be able to be stored since they only have 1 path each.
07-24-2025, 08:16 AM
Gwydion

Quote:

Originally Posted by Voidstorm

https://www.bg-wiki.com/ffxi/Storage_Slip_13

There are 2 items with each of the same item IDs, one can't be stored (unaugmented & augment trial in progress) & the other can be stored: augmented.
Only the augmented version can be stored.
As such, it could be possible to make a slip that differentiated between one augment criteria and another.
While abjurations, delve gear, escha gear, Nyame & divergence weapons may be a stretch with the multiple paths and looking for a specific augment signature to validate storage. All the other ranked augments should be able to be stored since they only have 1 path each.

Yup. I basically said this. It would be the first storage slip where SE uses the Item ID and the Augment to differentiate between different bit-positions on the storage slip. My guess is that, this change would need to be tested thoroughly so that it doesn't effect the processing of other Slips. (The consequences could be distastrous if people lose access to their storable items).

Quote:

Originally Posted by Gwydion

Yeah, it would be unusual for SE to treat Rostam A, B and C as different items on a Storage Slip. Even if SE gives each weapon 1-bit on the Storage Slip, they'd have to use the weapon name AND the augment to uniquely identify the item being stored and retrieved.

I can also imagine that if SE were to add this functionality, it would probably affect how other Storage Slips would be processed. (Of course, we want everything to go smoothly, but it could have unintended side-effects or consequences).