Replies: 6 comments 9 replies
-
|
Anything in your xi_map logs to indicate the server isn't happy with what you're doing? |
Beta Was this translation helpful? Give feedback.
-
|
Hi, nope, none of the logs say anything when I run the command. nothing is displayed where it moves the item or not. Just the "Wardrobe 3 currently not enabled" message in the chatlog / console (when trying to move something to wardrobe 3). Any space that isn't wardrobes 3 to 8 and it just moves the item with no issues. Just to clarify, the applicaiton I have made doesn't link in or affect the LSB client in any way. It simply spits out a script file for me to run in the client to add and move the relebant items. It all works fine except for this issue of the wardrobes not being enabled. Thanks for your response! |
Beta Was this translation helpful? Give feedback.
-
|
Hi, Just an FYI I didn't resolve the issue but I bypassed it by simply commenting out the bool check that Itemizer runs. Of course, not an ideal solution, however this script will only even be run under controlled conditions and only once per character so I am happy with the solution for now! See image for the lines I commented out (in Itemizer.lua) just incase anyone else ran into the same issue.
Thanks again for the help! |
Beta Was this translation helpful? Give feedback.
-
|
Do your login settings have these enabled? They are on by default but perhaps you've grandfathered an old config in that doesn't have these. server/settings/default/login.lua Lines 59 to 64 in 374016c |
Beta Was this translation helpful? Give feedback.
-
|
Hi Winter, thanks for the response. I have checked and I do have those variables set to true in my config file. For a moment there I was hoping I hadn't! That would have made me feel better. So unfortunately that didn't make a difference, thanks though! Its appreciated |
Beta Was this translation helpful? Give feedback.
-
This line was changed quite some time ago, though it looks correct in your screenshot ( |
Beta Was this translation helpful? Give feedback.
-
|
Hi Cocosolos, |
Beta Was this translation helpful? Give feedback.
-
|
tl;dr with the help of atom0s and Arcon we've found the missing packet data that windower expects, I can't test this because Windower refuses to work on Linux, but try this patch: My character on retail has 0xB (wardrobes 3-5, correlating with the bit skip Windower uses) |
Beta Was this translation helpful? Give feedback.
-
|
This is actually reproducible on stock and seems to be an issue with one of our packet implementations. Here's a Windower issue saying as much. I found this looking around in the Windower Discord for issues surrounding enabled bags: Which seems that 0x37 (char update packet) has something at 0x5C that controls this (this snippet is from 2021 likely before the other wardrobes were added). I can't do the math to figure out where this is supposed to be but I'm thinking it might be one of the Flag4-6 unknown structs. |
Beta Was this translation helpful? Give feedback.
-
|
yeah I got snippet of that exact block of code (except there are more wardrobes in it now) |
Beta Was this translation helpful? Give feedback.
-
|
This is 'technically' a bug with Windower. The manner in which they detect what bags a client has access to is not the same manner in which the actual client does. The client obtains which Wardrobes are available at an account wide level from the lobby server. This is stored inside of the clients Windower is instead relying on older data sent in packet For example in how the retail client works with what Wardrobes are available, on the title screen it will draw the icons via: v32 = 0;
v47 = v46 * 1.7;
v51 = v50 * 1.8;
do
{
v33 = 0;
switch ( v32 )
{
case 0:
v34 = PTR_g_pNtSys->SrvExCode2 >> 2;
goto LABEL_60;
case 1:
v34 = PTR_g_pNtSys->SrvExCode2 >> 3;
goto LABEL_60;
case 2:
v34 = PTR_g_pNtSys->SrvExCode2 >> 4;
goto LABEL_60;
case 3:
v34 = PTR_g_pNtSys->SrvExCode2 >> 5;
goto LABEL_60;
case 4:
v34 = PTR_g_pNtSys->SrvExCode2 >> 6;
goto LABEL_60;
case 5:
v34 = PTR_g_pNtSys->SrvExCode2 >> 7;
LABEL_60:
v33 = v34 & 1;
break;
default:
break;
}
if ( v33 )
{
v41 = 0;
v39 = -8355712;
}
else
{
v41 = 68;
v39 = 1346388032;
}
result = FUNC_YmMenuShape_ExtraDraw(*(_DWORD *)(*(_DWORD *)v58 + 4 * v32 + 908), (__int64)((double)(21 * v32 + 74) * v54), (__int64)(v55 * 360.0), v47, v51, v39, 0, v41, 0);
++v32;
}
while ( v32 < 6 );When the client is opening any of the Wardrobe containers, it will validate if the client can interact with the container using the same value stored in the else if ( v7 == 11 )
{
LABEL_30:
if ( (PTR_g_pNtSys->SrvExCode2 & 4) == 0 )
return 0x80404040;
goto LABEL_31;
}
if ( v5 == 11 )
goto LABEL_30;
if ( v7 == 12 || v5 == 12 )
{
v14 = PTR_g_pNtSys->SrvExCode2 >> 3;
goto LABEL_39;
}
if ( v7 == 13 || v5 == 13 )
{
v12 = (PTR_g_pNtSys->SrvExCode2 & 0x10) == 0;
LABEL_40:
if ( v12 )
return 0x80404040;
goto LABEL_31;
}
if ( v7 == 14 || v5 == 14 )
{
v12 = (PTR_g_pNtSys->SrvExCode2 & 0x20) == 0;
goto LABEL_40;
}
if ( v7 == 15 || v5 == 15 )
{
v14 = PTR_g_pNtSys->SrvExCode2 >> 6;
LABEL_39:
v12 = (v14 & 1) == 0;
goto LABEL_40;
}
if ( v7 == 16 || v5 == 16 )
{
v12 = (PTR_g_pNtSys->SrvExCode2 & 0x80) == 0;
goto LABEL_40;
}While the manner they are currently using works fine, it's not 'technically' retail-correct. (Mind you, it is pretty unlikely SE will change the packet to remove that data at random. The amount of packet work/touchups that are performed anymore is like once every few years.) |
Beta Was this translation helpful? Give feedback.
-
|
Wow, this is so much more in depth than I first thought it would be, but is so interesting. I have only just started to look into LSB and working out how ffxi and LSB work..
Realising how ridiculously awesome coders you guys are!
Sent from Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: atom0s ***@***.***>
Sent: Sunday, May 5, 2024 7:57:40 AM
To: LandSandBoat/server ***@***.***>
Cc: jubae ***@***.***>; Author ***@***.***>
Subject: Re: [LandSandBoat/server] Wardrobes 3 to 8 accessible in LSB, but "not enabled" in WIndower->Itemizer (Discussion #5611)
This is 'technically' a bug with Windower. The manner in which they detect what bags a client has access to is not the same manner in which the actual client does.
The client obtains which Wardrobes are available at an account wide level from the lobby server. This is stored inside of the clients g_pNtSys->SrvExCode2 which the client will make use of for all future checks when attempting to validate if the client can make use of the various Wardrobe containers.
Windower is instead relying on older data sent in packet 0x0037 that the client does not make use of any longer. (It will read the data and store it into other bits that are held in the client entities' render information, but the bits are not read/used after being set.)
For example in how the retail client works with what Wardrobes are available, on the title screen it will draw the icons via:
v32 = 0;
v47 = v46 * 1.7;
v51 = v50 * 1.8;
do
{
v33 = 0;
switch ( v32 )
{
case 0:
v34 = PTR_g_pNtSys->SrvExCode2 >> 2;
goto LABEL_60;
case 1:
v34 = PTR_g_pNtSys->SrvExCode2 >> 3;
goto LABEL_60;
case 2:
v34 = PTR_g_pNtSys->SrvExCode2 >> 4;
goto LABEL_60;
case 3:
v34 = PTR_g_pNtSys->SrvExCode2 >> 5;
goto LABEL_60;
case 4:
v34 = PTR_g_pNtSys->SrvExCode2 >> 6;
goto LABEL_60;
case 5:
v34 = PTR_g_pNtSys->SrvExCode2 >> 7;
LABEL_60:
v33 = v34 & 1;
break;
default:
break;
}
if ( v33 )
{
v41 = 0;
v39 = -8355712;
}
else
{
v41 = 68;
v39 = 1346388032;
}
result = FUNC_YmMenuShape_ExtraDraw(*(_DWORD *)(*(_DWORD *)v58 + 4 * v32 + 908), (__int64)((double)(21 * v32 + 74) * v54), (__int64)(v55 * 360.0), v47, v51, v39, 0, v41, 0);
++v32;
}
while ( v32 < 6 );
When the client is opening any of the Wardrobe containers, it will validate if the client can interact with the container using the same value stored in the g_pNtSys object:
else if ( v7 == 11 )
{
LABEL_30:
if ( (PTR_g_pNtSys->SrvExCode2 & 4) == 0 )
return 0x80404040;
goto LABEL_31;
}
if ( v5 == 11 )
goto LABEL_30;
if ( v7 == 12 || v5 == 12 )
{
v14 = PTR_g_pNtSys->SrvExCode2 >> 3;
goto LABEL_39;
}
if ( v7 == 13 || v5 == 13 )
{
v12 = (PTR_g_pNtSys->SrvExCode2 & 0x10) == 0;
LABEL_40:
if ( v12 )
return 0x80404040;
goto LABEL_31;
}
if ( v7 == 14 || v5 == 14 )
{
v12 = (PTR_g_pNtSys->SrvExCode2 & 0x20) == 0;
goto LABEL_40;
}
if ( v7 == 15 || v5 == 15 )
{
v14 = PTR_g_pNtSys->SrvExCode2 >> 6;
LABEL_39:
v12 = (v14 & 1) == 0;
goto LABEL_40;
}
if ( v7 == 16 || v5 == 16 )
{
v12 = (PTR_g_pNtSys->SrvExCode2 & 0x80) == 0;
goto LABEL_40;
}
While the manner they are currently using works fine, it's not 'technically' retail-correct. (Mind you, it is pretty unlikely SE will change the packet to remove that data at random. The amount of packet work/touchups that are performed anymore is like once every few years.)
—
Reply to this email directly, view it on GitHub<#5611 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AELF3HMSWYI5DPMOBWGL7F3ZAXJ6JAVCNFSM6AAAAABHGUTVMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TGMJYGE4DA>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Did the patch above work? or did you not have time to test yet |
Beta Was this translation helpful? Give feedback.
-
|
Just tested and looks like it works. Was able to get and put from wardrobe 3-8. |
Beta Was this translation helpful? Give feedback.
-
|
Apologies @WinterSolstice8, wasn't able to test it yet as I went away for the weekend and not back yet. Thanks for the confirmation and testing @cocosolos, you guys are the best! |
Beta Was this translation helpful? Give feedback.
-
Hi, I am currently creating an application/process to match my LandSandBoat character equiptment/inventory to my retail alternative.
I have come across a strange issue with the mog wardrobes. When using windower and using Itemizer to move items from my Inventory to a mog Wardrobe. It doesnt work for any of the wardrobes above wardrobe 2.
The command : "put 'item' Wardrobe2" works and moves the item correctly.
The command : "put 'item' Wardrobe3" doesnt. It says "Wardrobe 3 currently not enabled". This is the same for all the wardrobes above 2.
After looking into it I can see that Itemizer runs the following windower command to check if the bag is enabled :
So the "Windower.ffxi.get_bag_info(specified_bag).enabled" returns false in the LSB client, where as returns true in the retail client when the same command is run.
I can confirm that I can access all the mog wardrobes in the LSB client and can move items in and out of them manually with no problems.
It is just when I am trying to do it with Itemizer it tells me the wardrobes are not enabled above 2 in the LSB client. I just wondered if there is a flag anywhere that would determine this that I could edit to make it match the Retail version? Or is this just something that hasn't been implemented yet?
Thanks for any help!
Beta Was this translation helpful? Give feedback.
All reactions