[Release] shStudio 0.7.5

First, of all, I would like to apologize because I did not describe the problem very well, so my client is reading just the files from BinarySdata he does not read Item.Sdata, cash.sdata, etc, and yes you are right when I try to save the file the shtudio deploy a "Save As" dialog and save it as being Empty (cause i need it to be like the original one i think it's ep 8 judging that client that i use) or it get corrupted idk yet.


Client Information: The official client that Shaiya US is using.

And about your first question :
- I would really enjoy if you could release a version that can edit DBItemData.Sdata and save them without having problems, thank you for your attention, Castor.

Quote:

Originally Posted by castor4878 The friendliness of the tool is not a concern. (It doesn't compete for the most beautiful or fun interface.) If you really have a problem that is not already solved by posts 466 to 506; please describe it correctly, so starting with your settings (page code ...) and the actions you have done.

Sorry, I think my English is not good. The soft is very good.

The soft runs under the Chinese system, some Chinese display garbled

It has been set lang Chinese, ACP 936.

The picture I uploaded shows that.

Quote:

Originally Posted by aipca The soft runs under the Chinese system, some Chinese display garbled It has been set lang Chinese, ACP 936.

The Settings/Font panel of shStudio lists 2 different "Chinese languages" (because at least 2 different systems (codepages) are used.). You do *not* indicate which is the one of your system; the numerical value of CP indicated on line "System ACP" is *required* (because if u're using a third value, nothing will work).

You indicate that you're processing files with a CP settled to 936. OS files, at least those coming from [Only registered and activated users can see links. Click Here To Register...] indeed use the CP 936.

When I open the OS chinese cash.sdata, the description for the first item is *not* garbage, it is: "冲锋礼包，包含技能回归石1个，铁匠之锤8个，时空道标20个，全能恢复神水20个，普通道具袋1个." ; and google success to translate it into: "The charge package includes 1 skill return stone, 8 blacksmith hammers, 20 time and space markers, 20 all-round restoration of Shenshui, and 1 common prop bag.".
So it appears that the tool decodes the text as expected.

If I change that description (while my chosen CP is still 936) to "该软件包包括几个东西和一组常见对象。" and save cash.sdata, and quit shStudio, and restart it, and reload cash.sdata I still have the correct product name & description (pictures below).

OOH, we have to note that your file is not an official file; your pict show only 7 items whose product codes are also tailored. So you have edited that file (or you're using a file edited by someone else), and we don't know how such edition was performed.
From my point of view, this cash.sdata file also displays garbage when viewed with the OS client and you simply have to fix it (edit it again with a finely tuned shStudio) to obtain correct results.
Of course, you can mail me your cash.sdata and upload it on any file server to let me check (try to guess) which CP was used instead of 936.

In my previous post, I asked: "please describe [...] the actions you have done.".
You have not indicated the slightest operation ... so just do it.

[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]

Quote:

Originally Posted by castor4878 The Settings/Font panel of shStudio lists 2 different "Chinese languages" (because at least 2 different systems (codepages) are used.). You do *not* indicate which is the one of your system; the numerical value of CP indicated on line "System ACP" is *required* (because if u're using a third value, nothing will work). You indicate that you're processing files with a CP settled to 936. OS files, at least those coming from [Only registered and activated users can see links. Click Here To Register...] indeed use the CP 936. In my previous post, I asked: "please describe [...] the actions you have done.". You have not indicated the slightest operation ... so just do it.

Thank you very much for your reply.

My system (win7) ACP 936, I confirm again.

I downloaded the installation again from [Only registered and activated users can see links. Click Here To Register...] and unpacked it with shStudio 2 v0803, which still shows scrambled code.

So I uploaded Cash. SData file with garbage code.

Please help me see what's wrong.

Thanks for this additional information.

I'm puzzled by the different displays that you obtained.
The cash.sdata (img 3) shows an invalid name for the 1st item but valid names for all others and invalid descriptions for all; all names and all descriptions are managed the same way by a unique method.

Similarly, the Name & Desc columns of the skill.sdata view (img 5) are managed the same way by the same method, and Desc are fine while Names contain garbage.
And for "some" reasons, the exact inverse case occurs with item.sdata (img 7) where Names are fine and Desc dirty.

On my European system, the cash.sdata file you pinned is correctly displayed. Of course :-/

The basis of shStudio was designed for European and American language (this does include Russian & Turkey), all these languages use specific codepage to manage their specific characters but all required glyphs fit in a "short map" (less than 256 characters, so handling char8 (character type defined on 8 bits) is fine.

Asian languages are different, they all (or quite all) manage "string operations" with wchar_t type (16-bits char); there it appears that this introduces trouble. Possibly (very likely) the garbages come from a double conversion "from Multi-Byte to Wide-Char". (I convert MB stream read from shaiya files (which is *not* Unicode) to wide-char and initializes Windows UI items with it, and Windows does (or doesn't) perform the same conversion a second time.

The issue can not be fixed with basic changes; the best way to properly manage the issue is to recode the whole application with Unicode strings only.
Obviously, in 2019 nobody would start to develop something w/o using Unicode (often because it's simply not possible to not use Unicode), but the basis of shStudio was developed by beginning 2011.

My best advice, for short term solution, is to use an English system to edit your Chinese sentences (!), Win7 may not offer free language pack (they are now free for W10).

Regarding some alleged "fix for shStudio" it is likely ... crap. Changing several significant parts of the code, changing the handling of tens of xxxA msg to xxxW msg is, of course, possible with efficient code injector, but that's not the same job.


Edit: I do not read Chinese so I cannot understand the purpose of the "Unicode settings" (?) panel (image 9); if there is something like "fix that appl (shStudio) to make it Unicode compliant" you may try other settings - actually you should try all and every option provided by this ctrl panel since it is possibly the sole way to change the hidden conversions done by the System. Thanks to let's know if shStudio displays are impacted in any way.

Quote:

Originally Posted by castor4878 The issue can not be fixed with basic changes; the best way to properly manage the issue is to recode the whole application with Unicode strings only. Obviously, in 2019 nobody would start to develop something w/o using Unicode (often because it's simply not possible to not use Unicode), but the basis of shStudio was developed by beginning 2011

My friend is from Shaiya game

He is a programmer, he said:

First, let's talk about the normal conversion of English and numbers. First, convert the 123456 into Uicode through the API function MultiByteToWideChar, which is shown in the figure. Then the Uicode code will be combined by taking the odd-numbered bytes (such as this: 31 00) 32 00 33 00 34 00 35 00 36 00, taking odd numbers and combining them is 31 32 33 34 35 36,
That is the last ASCII code to display)
img1

Besides, why is Chinese garbled: First convert to Uicode (35 8D CD 91 20 00 97 7C 36 52 55 53 4B 62 51 52), take the odd digit combination, that is (35 CD 20 97 36 55 4B 51), but convert After this (35 CD 20 97 36 55 4B 51) in ASCII code display is garbled as shown
img2,3

What I solved is that after the MultiByteToWideChar conversion, modify the conversion result, 35 8D CD 91 20 00 97 7C 36 52 55 53 4B 62 51 52 to B9 00 F3 00 D6 D8 00 20 00 B4 00 D6 00 D6 00 C6 00 B5 00 A5 00 CA 00 D6 00 BD 00 A3
00, this will become B9 F3 D6 D8 20 B4 D6 D6 C6 B5 A5 CA D6 BD A3 after taking the odd number combination, it is normal
img4

Use WideCharToMultiByte when converting back

I hope these will help solve this problem.

Castor, I did not tell you in the upper reply that I already own an episode 8 server stable version and if you need a server to test your tool, I will be more then happy to help you, can you let me know if you are planning to make an update to ShStudio that let us edit BinarySData and save it without having problems ? thank you for your attention.

What you explained regarding encoding is correct ... but the issue is not there.

First, advices are obviously welcome but the problem is not the lack of a solution, it is the lack of time to code it.
To solve the problem, I mean properly solve the pb for all roman (not english) languages (it does work with last change but only if codepages of system and sdata are the same) and solve it for asian languages that will continue to randomly bug; I just have to recode all processes involving strings (Windows msg, displays, ...) in Unicode, as simple as that.

Currently I decode the MBS coded in sdata-codepage to MSB coded in system-codepage (actually to Unicode but it is managed as MBS and so let system default codepage applies). It appears that it works in some cases, but it's not reliable.

Let's review the cash.sdata to explain some points.

The Plain cash.sdata (w/o encryption header) is:

there D6C7BEABD2A9BCC120B5C8BCB633283130290000
and
3130B7D6D6D3C4DAD6C7C1A6BACDBEAB
C9F1B8F7C9FD31322CCBC0CDF6CAB1D0
A7B9FBCFFBCAA72EBDF6CFDECAB9D3C3
BDC7C9AB3CCFDED6C6BDBBD2D7B5C0BE
DF3E0000

are multi-bytes chars encoded with a "given system".
"multi-bytes" means that each individual character or glyph (pictogram) is coded with 1 or several bytes; '3130' is "10", subsequent bytes encode glyphs on 2 bytes.

The used encoding system can be figured out by Notepad++

The current code performs:
(where name is a ""buffer with string facilities"" that contains the data read from .sdata w/o any change, so)
// name = D6C7 BEAB D2A9 BCC1 20 B5C8 BCB6 33 28 31 30 29
wchar_t temp[256] = { 0 };
::MultiByteToWideChar(936, MB_PRECOMPOSED, (LPCCH) name, name.length(), temp, 256);
and obtains (for the name):
667A 7CBE 836F 5242 0020 7B49 7EA7 0033 0028 0031 0030 0029
which displays: 智精药剂 等级3(10).

The issue is that the decoded strings ("智精药剂 等级" there) are not used as wchar_t[] but still as a MBS; it appears that "sometime" Windows understands it as Unicode (WS), possibly on systems for lazy where a lot of softs didn't care about Unicode, and quite always fail on systems like your where all appl must be fully Unicode compliant.

One last time: shStudio is not fully Unicode-based (because shaiya files were not Unicode-encoded) and a recoding (not some pseudo-magic-fix) is required.

Quote:

Originally Posted by LibPor22 Castor, I did not tell you in the upper reply that I already own an episode 8 server stable version [...]

Several fixes of the edition of BDxxx.sdata files are also planned - saving as DB file is corrupted for several (incl items) and some use the old list-view w/o support of the tailored editors.

The global change to Unicode and the support of the DB files (the DBxxxTextxx are finally Unicode encoded) will occur in the same phase.
Regarding a test server, I no longer have my own svr since years; a package "ready to be used" will significantly help me. ("ready to use" means for tests purpose, any weakness if used as prod svr won't be relevant).

Thank you to drop me private mail if you wanna help me on this point.

Done Castor, I've sent the email, let me know if you got it, thank you.

hey castor i was Working on my Item.SData but when i saved it and tried to open it again it doesn't load anymore! can you please help me what's the problem with it.
the only thing i guess i did wrong is that i changed some Fighter/defender gears into other classes gears that's all.

Quote:

Originally Posted by castor4878 What you explained regarding encoding is correct ... but the issue is not there.

I set my system language non-Unicon code to English (EN)(英语＝English).

This problem has been solved.

But, my other software will have problems, it is not a good solution.:o

Quote:

Originally Posted by aipca I set my system language non-Unicon code to English (EN)(英语＝English). This problem has been solved.

Thank for this confirmation, so my understanding of the internal handling of strings by the OS was (sufficiently) correct.

Quote:

Originally Posted by aipca But, my other software will have problems, it is not a good solution.:o

Definitively ! and I never said it was an acceptable solution ;)

Hello, developer. I am saving Monster.SData. The data has changed. MobID starts at 0. Normally starting from 1
this time before saving：
[IMG=border: 2, expandable: 1, float: right][Only registered and activated users can see links. Click Here To Register...][/IMG]

After saving：
[IMG=expandable: 1][Only registered and activated users can see links. Click Here To Register...][/IMG]

easy fix use the brain

Quote:

Originally Posted by rn4444 I am saving Monster.SData. The data has changed. MobID starts at 0. Normally starting from 1

You forgot to indicate the used version of the tool, the operations you've done prior to save the file.

On my current version, all DBxxxData.sdata files are broken when saved; a global correction is under progress as indicated at end of post [Only registered and activated users can see links. Click Here To Register...].

Edit:
Your SS compare a Monster.sdata with a DBMonsterData.sdata; since the export from BD format to former one is broken in current version, the "after saving" statement is quite mysterious.