Welcome!

Join our community of MMO enthusiasts and game developers! By registering, you'll gain access to discussions on the latest developments in MMO server files and collaborate with like-minded individuals. Join us today and unlock the potential of MMO server development!

Join Today!

v5 source not able to read resource?

Elite Diviner
Joined
Aug 15, 2008
Messages
489
Reaction score
43
I'm trying to compile and get this source working with VS2017. http://forum.ragezone.com/f457/v5-v6-2005-source-1151694/

Currently, I'm having issue with Neuz failing to open the resource files and then throwing errors because variables are nullptr.

I made traces in functions to see what is happening.


The resource files I am using are these http://forum.ragezone.com/f457/flyff-version-5-offi-serverfiles-1127632/ The client is from these files also.

Any clues why it's not able to read the resource?
 
Inactive
Joined
Jan 20, 2009
Messages
1,015
Reaction score
1,830
Could be due to bad forloops i guess?

You can take a look @ my VS17 and examine how i upgraded the scanner and file?
 
Newbie Spellweaver
Joined
Oct 27, 2013
Messages
57
Reaction score
10
Quick look through that trace reveals what the likely problem is, CResManager::GetAt(501) is the last thing called, trying to fetch window 501, witch happens to be the id for the login window. That sounds right since that is the first window that would end up being displayed in an online mode client. For reference, you appear to be crashing in CWndMgr::OpenTitle() when it calls ObjectExecutor(SHORTCUT_APPLET, APP_LOGIN ); to try and open the login window.

So presumably, since it is failing to get the address for the window (lpWndApplet was nullptr), that would indicate either the window scripts haven't been loaded at all yet, for some reason, or there was some sort of issue with their loading that resulted in the windows not being created. As to exactly what the issue is, I'm not sure, if i stumble onto the fix I will let you know, but i would start by going through CResManager::Load() step by step as its loading windows and see where its failing, if its being called at all.
 
Elite Diviner
Joined
Aug 15, 2008
Messages
489
Reaction score
43
Could be due to bad forloops i guess?
You can take a look @ my VS17 and examine how i upgraded the scanner and file?
Thanks for the suggestion. I have been using your release as a reference before too and it has been a huge help. I'll check into this.

Quick look through that trace reveals what the likely problem is, CResManager::GetAt(501) is the last thing called, trying to fetch window 501, witch happens to be the id for the login window. That sounds right since that is the first window that would end up being displayed in an online mode client. For reference, you appear to be crashing in CWndMgr::OpenTitle() when it calls ObjectExecutor(SHORTCUT_APPLET, APP_LOGIN ); to try and open the login window.

So presumably, since it is failing to get the address for the window (lpWndApplet was nullptr), that would indicate either the window scripts haven't been loaded at all yet, for some reason, or there was some sort of issue with their loading that resulted in the windows not being created. As to exactly what the issue is, I'm not sure, if i stumble onto the fix I will let you know, but i would start by going through CResManager::Load() step by step as its loading windows and see where its failing, if its being called at all.
CResManager::Load() fails because CScript::Load() fails to load the script, which leads the issue to CScanner::Load(). I guess the best clue right now is to check the scanners forloops like Ketchup suggested. I'll also edit this thread with the fix if I manage to solve it.
 
Newbie Spellweaver
Joined
Oct 27, 2013
Messages
57
Reaction score
10
Thanks for the suggestion. I have been using your release as a reference before too and it has been a huge help. I'll check into this.


CResManager::Load() fails because CScript::Load() fails to load the script, which leads the issue to CScanner::Load(). I guess the best clue right now is to check the scanners forloops like Ketchup suggested. I'll also edit this thread with the fix if I manage to solve it.

I checked my commit history for CScanner and i ended up replacing the entire file with a working copy from my newer source. Not quite a drop in change, will require fixing things due to some changed variable names, but that is likely the easiest route. It likely is an issue with one of the loops somewhere, from what i can remember one of the flags was being set when it shouldn't have been, resulting in it aborting the file load. I wish you the best of luck figuring it out one way or the other! Glad at least one other person has taken an interest in this old code.
 
Elite Diviner
Joined
Aug 15, 2008
Messages
489
Reaction score
43
I checked my commit history for CScanner and i ended up replacing the entire file with a working copy from my newer source. Not quite a drop in change, will require fixing things due to some changed variable names, but that is likely the easiest route. It likely is an issue with one of the loops somewhere, from what i can remember one of the flags was being set when it shouldn't have been, resulting in it aborting the file load. I wish you the best of luck figuring it out one way or the other! Glad at least one other person has taken an interest in this old code.
I think I was somewhat able to trace the issue. I don't know where this source is made to look for the res files, but after changing the CResFile::ScanResource( "" ) in Neuz.cpp to include the client directory it's now able to scan the resource files, but now it dies at CResFile::AddResource() line 206.
Code:
memcpy( &nFileSize, &pHeader[ nHeaderPosition ], sizeof( int ) ); nHeaderPosition += sizeof( int );


It's able to finish the loop once, but dies the second time.

EDIT: For some reason the filename is char_Achaben.TGA at first, like it's supposed to be but on second time it's _Agent.TGA, without the char.

EDIT2: Managed to fix this issue by changing the 4th memcpy in loop from sizeof(time_t) to sizeof(__int32). But now I am back at getting lpWndApplet was nullptr when running CResManager::GetAt(501).

EDIT3: Well now I feel kind of stupid. I had to move the res files into the Neuz project folder and not the Output/Debug folder, which is why they were not being loaded. Now I no longer receive the error that file could not be opened, but the issue with lpWndApplet nullptr remains.

EDIT4: Finally after several hours of debugging I got it working. Now I just need a way to edit the propItem.txt into the .res, since the resource I have has an item that returns -1.

EDIT5:
Fixed the -1 item issue by removing some useless stuff from the propItem.txt. The neuz is now compiled and running properly.
 
Last edited:
Newbie Spellweaver
Joined
Oct 27, 2013
Messages
57
Reaction score
10
Congrats on getting the client working! Do continue to update us all on your progress and any other issues you run into, more then happy to help when i can. Goodluck getting the servers running and getting in game! @Wokki

Bonus in game screenshot for funs
 
Elite Diviner
Joined
Aug 15, 2008
Messages
489
Reaction score
43
Congrats on getting the client working! Do continue to update us all on your progress and any other issues you run into, more then happy to help when i can. Goodluck getting the servers running and getting in game! @Wokki

Bonus in game screenshot for funs
Are your files VS17?

Also, I'm having issues with displaying servers in Neuz. Any clues? I'm able to login though, just the server view is empty.

And that inventory, oh damn. Wasn't that changed to the current one in v5?

My AccountServer.ini is baiscally this, except the root IP's changed to the public IP.
 
Last edited:
Newbie Spellweaver
Joined
Oct 27, 2013
Messages
57
Reaction score
10
Are your files VS17?

Also, I'm having issues with displaying servers in Neuz. Any clues? I'm able to login though, just the server view is empty.

And that inventory, oh damn. Wasn't that changed to the current one in v5?

My AccountServer.ini is baiscally this, except the root IP's changed to the public IP.

Not currently using vs17, still vs2003. Decided to get things as functional as possible in the older VS before introducing more issues with the VS update.

As for the server list, not sure what the issue would be there, haven't done much testing on it since it's essentially non functional with client in offline mode anyway. Theres a few #defines that could be the issue, related to the client supporting more then one server (__MSVR), that ifdef changes the server list behavior a fair bit so it would be my first guess. Don't think the server list has actually changed much between v5 and v15 so a compare of the CWndSelectServer parts between the two would likely provide the answer.

Another thought, i would definitely check to make sure the ports are correct, if memory is right, this uses different ports then the newer sources, and many of them are hard coded rather then read from the .ini files.

Not sure when exactly the inventory was changed, whether it was v5 or v6, but that is the inventory the source is set up to use, using the newer layout would require rewriting much of WndInventory.

EDIT: Another thought after looking at your accountserver.ini, make sure the MSG_VER is the same every where, its hard coded in the client and changes between a couple different 2004xx values depending on exactly what defines are set



Slightly off topic but relevant to this old source at least, does anyone know if this flight speed gauge was ever actually used in game? Don't think the code is in v15 at all, and its commented out in this source, suggesting its from before v5
 
Last edited:
Elite Diviner
Joined
Aug 15, 2008
Messages
489
Reaction score
43
Not currently using vs17, still vs2003. Decided to get things as functional as possible in the older VS before introducing more issues with the VS update.

As for the server list, not sure what the issue would be there, haven't done much testing on it since it's essentially non functional with client in offline mode anyway. Theres a few #defines that could be the issue, related to the client supporting more then one server (__MSVR), that ifdef changes the server list behavior a fair bit so it would be my first guess. Don't think the server list has actually changed much between v5 and v15 so a compare of the CWndSelectServer parts between the two would likely provide the answer.

Another thought, i would definitely check to make sure the ports are correct, if memory is right, this uses different ports then the newer sources, and many of them are hard coded rather then read from the .ini files.

Not sure when exactly the inventory was changed, whether it was v5 or v6, but that is the inventory the source is set up to use, using the newer layout would require rewriting much of WndInventory.

EDIT: Another thought after looking at your accountserver.ini, make sure the MSG_VER is the same every where, its hard coded in the client and changes between a couple different 2004xx values depending on exactly what defines are set



Slightly off topic but relevant to this old source at least, does anyone know if this flight speed gauge was ever actually used in game? Don't think the code is in v15 at all, and its commented out in this source, suggesting its from before v5
What does your VersionCommon.h's look like? Do you have #define __MSVR in them? I'm wondering because I noticed that the Certifier was receiving the sever list length as 0 despite of the MSG_VER being same everywhere. Adding the #define __MSVR made the Certifier crash on start due to CAr::Read(). The VersionCommon_Thai.h for example has this defined in it.

I can't find this being used in any newer sources though, so I'm not sure if this is necessary or just removed altogether in newer versions.
 
Newbie Spellweaver
Joined
Oct 27, 2013
Messages
57
Reaction score
10
What does your VersionCommon.h's look like? Do you have #define __MSVR in them? I'm wondering because I noticed that the Certifier was receiving the sever list length as 0 despite of the MSG_VER being same everywhere. Adding the #define __MSVR made the Certifier crash on start due to CAr::Read(). The VersionCommon_Thai.h for example has this defined in it.

I can't find this being used in any newer sources though, so I'm not sure if this is necessary or just removed altogether in newer versions.

The define isn't used in newer sources, but the code is. Aeonsoft at some point later in development went through many of the older defines and hardcoded on things that had become absolutely necessary. After a quick check of the v15 source, it looks like all of _MSVR is hardcoded ON, so this would need to be defined everywhere.

Your crash may be due to you just adding it to the account server / client, it needs to be enabled in all the servers + client so that the packets end up being the same, otherwise you end up crashing trying to read the data needed for multiserver support because it isnt there. I do also see some slight differences between the MSVR code in v5 and the code in v15, so its quite possible theres something broken in there somewhere anyway, but i'd start with making sure its defined everywhere first.
 
Elite Diviner
Joined
Aug 15, 2008
Messages
489
Reaction score
43
The define isn't used in newer sources, but the code is. Aeonsoft at some point later in development went through many of the older defines and hardcoded on things that had become absolutely necessary. After a quick check of the v15 source, it looks like all of _MSVR is hardcoded ON, so this would need to be defined everywhere.

Your crash may be due to you just adding it to the account server / client, it needs to be enabled in all the servers + client so that the packets end up being the same, otherwise you end up crashing trying to read the data needed for multiserver support because it isnt there. I do also see some slight differences between the MSVR code in v5 and the code in v15, so its quite possible theres something broken in there somewhere anyway, but i'd start with making sure its defined everywhere first.
Added #defines for __MSRV, __BOT1021 and __18 and now the server is working properly.

Is this normal for this client?
 
Newbie Spellweaver
Joined
Oct 27, 2013
Messages
57
Reaction score
10
Added #defines for __MSRV, __BOT1021 and __18 and now the server is working properly.

Is this normal for this client?

Normal in a way, in debug configs it attempts to load the core shaders from files alongside the client rather then the copies embedded into the exe, presumably so that they could test changes rapidly without having to recompile everything. Either put the shaders where it expects them to be, or remove the _DEBUG version of the loading code and just use the internal versions (IDR_DATA1, IDR_DATA2, IDR_DATA3) . Or you can leave it as it, its rather funny looking as the lack of that shader initing properly completely breaks all the animations
 
Elite Diviner
Joined
Aug 15, 2008
Messages
489
Reaction score
43
Been stuck at this point for a while now. Able to login, select server but that's where database server crashes. It was fine at first when I created a character, but now that the character exists it's crashing on character select.


Any idea why this is happening?
 
Newbie Spellweaver
Joined
Oct 27, 2013
Messages
57
Reaction score
10
Been stuck at this point for a while now. Able to login, select server but that's where database server crashes. It was fine at first when I created a character, but now that the character exists it's crashing on character select.


Any idea why this is happening?

Unfortunately i am stuck in the same place currently. There seems to be something wrong with deleting the cMover as it goes out of scope during the player list loading but i haven't managed to figure out what or why. I'll let you know if i find a solution, and would appreciate it if you did the same. Goodluck!
 
Elite Diviner
Joined
Aug 15, 2008
Messages
489
Reaction score
43
Unfortunately i am stuck in the same place currently. There seems to be something wrong with deleting the cMover as it goes out of scope during the player list loading but i haven't managed to figure out what or why. I'll let you know if i find a solution, and would appreciate it if you did the same. Goodluck!
Any clue if this could be related to bank? Because the only other thing with m_apIndex I could find was m_apIndex_Bank. Now previously I was pretty lazy with the Database server and got it running by removing the OpenGuild() function from DpCoreSrvr, as it would crash when the Core server is launched.

Have you faced this issue and been able to fix it? I tried to take the v17 source as a reference to this, but it's done pretty much the same way.
 
Newbie Spellweaver
Joined
Oct 27, 2013
Messages
57
Reaction score
10
Any clue if this could be related to bank? Because the only other thing with m_apIndex I could find was m_apIndex_Bank. Now previously I was pretty lazy with the Database server and got it running by removing the OpenGuild() function from DpCoreSrvr, as it would crash when the Core server is launched.

Have you faced this issue and been able to fix it? I tried to take the v17 source as a reference to this, but it's done pretty much the same way.

After some more testing i've determined theres nothing wrong in the database server really, its the database itself. It looks like the database is slightly newer then this source and has extra inventory slots used for costume items, this source doesnt support those slots and thats what causes the overflow. Actuelly fixing it is going to be fairly difficult, looks like much of the main stored procedure is going to need adjustments. I did manage to bypass the m_apIndex issue by manually wiping the inventory in the database, this let it proceed to character select and then end up crashing with more DB issues while trying to go in world...
 
Newbie Spellweaver
Joined
Oct 27, 2013
Messages
57
Reaction score
10
Update: Now in world after reworking CHARACTER_STR in the db to match what the server is expecting, most of the work required was reworking how the bank table is loaded. Highly doubt its very stable, and since i've only worked on the one section of the stored proc that is used for login (S8) the rest will likely not function properly, currently waiting for the auto DB save to kick in and see where else it breaks..

Excuse the lack of clothing, previous inventory table workaround means no default equipment was given.
 
Back
Top