[Release] shStudio 0.7.5

[vincentpaulzee]

Thank you so much sir! Very helpful!

[[-Silomatx]]

Thank you castor, working on a server would be much harder without your ShStudio.

I recently started using your newest update of ShStudio and whenever I edit gear and weapons the Studio makes them not tradeable (sets value between 1 and 3 somewhat randomly?) and I cannot edit it and set it to tradeable. I have to use ShStudio 0.7.5.5 to make them tradeable again.

Also wanted to say that for a couple of versions now if you edit NPCQuest.sdata and want the quest to begin at NPC e.g. 1 123 and want it to end at NPC 5 321, it will change the completing NPC to 1 321, because it copies the type from the starter npc somehow?


Not sure if you already know about this or are planning on any fixes, but I hope it helps you. Of course it is not a problem to switch to ShStudio 7.5.5 to fix the items.
Again, amazing job you're doing there!

[sominus]

Studio version: 0.8.0.1
game client : Oficial Aeria ES (ep 6)

Skill.SData format: EP6
When editing skill ID 181 (DayFLy), the fields Phys - Dist - Magic revert back to 0 after editing them (they should keep the value we put on it '1')

When editing skill ID 307 (Behemot), the field HP (base damage), reverts back to 0 after editing. (it should keep the value we put on it)
And if we put a value in HP (add damage), that value is saved into HP base damage.


Item.SData format EP6.2
When editing any lapis (type 30), the 'restrict' combobox takes de 'Account Restricted' value, and it won't accept any other value. So all edited (or just viewed) lapis become non-tradeable

[DEEPDARKP]

Hi i am So happey for this tool but the problem is i cant change the Language to Ararbic when i change it from the Font its giving me linw that language no can understand it
can you help me please

[{Skrillex}]

Hello,
maybe i found a bug in ShStudio Version 0.8.0. If I edit an random Items with Tradable Status 'Not Restricted' the tradable status goes blank. Also In-Game all edited Items still non tradable.
Maybe someone had the same problem? I tried so use search function but I couldn't find any results.

Thanks in advance.

[BigBadkitty]

Originally Posted by .:Unix:.

Hello,
maybe i found a bug in ShStudio Version 0.8.0. If I edit an random Items with Tradable Status 'Not Restricted' the tradable status goes blank. Also In-Game all edited Items still non tradable.
Maybe someone had the same problem? I tried so use search function but I couldn't find any results.

Thanks in advance.

you could ignore this in the client side and just edit it in the database (at least that's what i did.)

[Cups]

It seems to me like the saving of DBSdata is bugged? Trying to save the DBMonsterData or DBSkillData saves a file that shStudio cannot re-open, and is also ~60% smaller in file size. This was done with the current version of OS EP8's files. Am I doing something wrong? I'm happy to contribute code towards the project if you're need a hand.

[castor4878]

Hello All,

A maintenance release 0.8.0.2 is available for download (see initial post).
It includes several bug fixes, including the corruption of the tradeable field.

Enjoy.

[hronolight]

Originally Posted by JuuF

Is there any upcomming update for Turkish Codepage problem that i mentioned before?

Originally Posted by hronolight

Same problem with a russian language

Originally Posted by parkjunghun

Same problem with a korean language

Still not solved problem with encoding?
Cool

[castor4878]

The irony is supposed to help ??

I exchanged several private messages with JuuF, as you cannot read them, you have apparently chosen to criticize a supposed lack of interest for this problem, free to you.

In this post, you're displaying a description whose origin and content are unknown.
If you want to give usable information, indicate from where the data come from (for example an AE file or something edited by you) and provide a hexadecimal dump of the record read from the items.sdata.

Without this information, I can only see that - from my point of view - the display is correct when the chosen codepage is the right one (here 949) and the file actually encoded with this codepage (here the original korean file).



Of course, you may think it's up to me to buy a Windows license for all possible languages and to find an official distribution of the game in Turkish or Russian, but I'm sorry I cannot share this opinion.

[hronolight]

Originally Posted by castor4878

The irony is supposed to help ??

I exchanged several private messages with JuuF, as you cannot read them, you have apparently chosen to criticize a supposed lack of interest for this problem, free to you.

In this post, you're displaying a description whose origin and content are unknown.
If you want to give usable information, indicate from where the data come from (for example an AE file or something edited by you) and provide a hexadecimal dump of the record read from the items.sdata.

Without this information, I can only see that - from my point of view - the display is correct when the chosen codepage is the right one (here 949) and the file actually encoded with this codepage (here the original korean file).



Of course, you may think it's up to me to buy a Windows license for all possible languages and to find an official distribution of the game in Turkish or Russian, but I'm sorry I cannot share this opinion.

Adding the possibility of using the default encoding (as it was in the old version of ShStudio) would solve all the problems.

You tried to do better by adding support for all popular encodings, but now this solution sucks because of the tiny bug and all your great work is simply in vain for a large number of people.

I am not a professional in C ++ (I think you are writing your utility in this language), but in C # such a bug would be very easy to find and fix. Therefore, I am surprised that for so many years this has not been fixed. This is one of the reasons why I had to make my own tool instead of using yours.

As I recall, you have already sent a hex file with problem languages, but this did not help.

I did not mean to offend you. Your tool is very good.

[castor4878]

The language used to code the application is not the main cause of mistake; C# is natively Unicode, so yes, C# code is easier to write. OOH Win32 WM_SETTEXT msg relies on "a pointer to a null-terminated string that is the window text", but of course the MS doc takes care to never specify the actual content of such string, making it a bit harder.

But the issue actually comes from the Shaiya client!
Recent releases of the client seem to use Unicode encoded text resources; at least some text files are Unicode encoded; but obviously, it wasn't the case for old clients, instead they rely on a specific (hardcoded) codepage (likely CP1250 for all European countries, 949 for Korean client - the fact that Korean .sdata (Korean client is the sole not-European/English game I can have access to) are finely managed using a CP949-to-Unicode conversion shows that such codepage conversion exists in client).

So, the client that you use (of which of course I don't know anything) probably uses a certain codepage translation and thus is virtually the source of the bug. Possibly the client performs a conversion (call MultiByteToWideChar) or uses an old Win32 text API that relies on an OEM Character Set conversion; so the text encoded by shStudio is correct if and only if shStuddion is settled to use the same codepage.

Another issue, in your capture the names in items-list and dialog "name" item are finely displayed (I assume they are but I didn't read Russian) while the description contains garbage; yet all these fields are translated with the exact same method and parameters; either all texts should be garbage or none of them. So the source of error can also be "the way strings are provided", not to say the keyboard itself but possibly a cut-n-paste from another application.
You also didn't indicate if all texts are invalid within the game (whatever the shStudio display), or if the name is fine & description invalid (same as dialog display) or if all are fine. Your post dated November 17th, 2018 didn't give these details, nor it contains your localized items.sdata (If it was sent by PM, thank to send it again).

All these reasons explain why the bug hasn't been fixed for years; it requires 10mn to fix it but years wasn't enough to collect the few required information.

An alternative to getting the correct conversion is possibly not to convert at all and let the client do what it uses to doing. An option was planned for that but this item wasn't inserted in the codepages list. My bad. The option "OEM Character Set" is defined in the attached release; let's know if it fixes the issue.

[[ADM]Sky]

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

[castor4878]

Where
Головной убор, сочетающийся с призрачными доспехами. Может использоваться бойцами и хранителями.
Translates to
Headdress, combined with ghostly armor. Can be used by fighters and guardians.

[[ADM]Sky]

Originally Posted by castor4878

Where
Головной убор, сочетающийся с призрачными доспехами. Может использоваться бойцами и хранителями.
Translates to
Headdress, combined with ghostly armor. Can be used by fighters and guardians.

Your system language is English, and I have Ukrainian. When the system language is set to Russian or Ukrainian, the symbols are not displayed. Need to fix it. If you change the language of the system to English, then everything will work, but there will be a problem with other programs, and you also need to always restart the computer.