Project 137

[PurpleYouko]

So tried downloading the windows SDK that is supposed to contain gflags..... It doesn't. Still don't have it anywhere on my PC.

Meh.....

[Raven0123]

https://msdn.microsoft.com/en-us/librar ... 63(v=vs.85).aspx

I grabbed it from the wdk. Anyway, you can still use visual studio to debug it. Gflags will crash the program as soon as it does something it shouldn't do.

[Dagnarus]

Good to see someone else making progress with the released EVO source!
Nice work Purple it looks really good!
As you might know I also created my own server (from scratch) for the same EVO source, and I also noticed that you can change the your characters stats by creating server side commands. There is even a packet in the server that overwrites the moving speed (0x07b8) as you can see here (my packetlist tool):



You can play with that it is kinda fun:


But, let me say this. It is very nice to see that you have done a lot of work and made a lot of features work! Hope you'll continue and I would love to see it operational one day! Good luck to you.

P.S. I saw somewhere a discussion about not being able to change the max damage. Here is the proof that you can:

[L3nn0x]

Wow That's great Dagnarus!

You should share more of your server

[PurpleYouko]

https://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx

I grabbed it from the wdk. Anyway, you can still use visual studio to debug it. Gflags will crash the program as soon as it does something it shouldn't do.

That page doesn't exist according to my browser.

Ah well back to figuring it out the old fashioned way

[L3nn0x]

https://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx

I grabbed it from the wdk. Anyway, you can still use visual studio to debug it. Gflags will crash the program as soon as it does something it shouldn't do.

That page doesn't exist according to my browser.

Ah well back to figuring it out the old fashioned way

It's actually https://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx

[PurpleYouko]

Managed to get it.
It didn't really tell me anything that I wasn't already aware of. It just stops at the first operation involving the offending vector.
I couldn't really make any sense of all the numbers it spewed out

So anyhow there's another weird feature of this bug.
After crashing and debugging if i close the debugger, the worldserver continues to run and I can actually continue to play the game as normal. Every subsequent time that it writes to the vector it works perfectly. It's just that first time.
But... The worldserver console is greyed out and cannot be closed except by using task manager.

Going through the code very carefully i did manage to find a whole bunch of places where the code was attempting to write beyond the bounds of an array. the worst offender was my QuestFlag loading code which was loading 1024 entries into an array that was dimensioned with 64 slots. I'm a little surprised that the compiler didn't catch that one.

[L3nn0x]

Lol 1024 entries in a 64 array, that's what you call a buffer overflow

The compiler can't catch those errors, because it doesn't know how many times your loop will run. If you use C++11 features with constexpr (compile-time expression) which is evaluated at compile time then yes it'd have complained but you can't use it if you don't know the size in advance...

Maybe you could post the numbers it spewed out, just in case Raven can read it (cause he seems used to dev on Windows)

[PurpleYouko]

I think I've figured out the problem

It's a very oblique and weird error.
Just after I made my last post I added some debug printouts to the top of teh visibility processes code to figure out what's going on.
Logged in and it worked perfectly so i carried on making a few mods to streamline the same visibility processes, testing at each point.
Got monsters working with a single vector using push_back and erase.
In order to use erase though I had to know the iterator value and since the function was calling a Boolean to see if the present monster is in the list or not, I had to actually run the search locally to get that value. Either that or change the IsVisible functions to return an integer instead of true/false and that seems like a ton of work since those things get called all over the place.

So.... Still working after all the monsters are done.

Repeated the process on the NPCs and it still worked.
Found one tiny bug. I wasn't correctly using the erase command when moving out of visibility range of an NPC.
Fixed that and at teh same time took out the debug print code (cuz i didn't need it any more)
CRASH but not the same heap error.
This time every variable being accessed in the visibility processes is simply not there. It's like they haven't been assigned yet

Every variable associated with the visibility process is like that no matter how far i follow the stack down.

The root source of the function call is in the main Visibilty Process.

Line number On/Off | Expand/Contract | Select all

1. // Visibility Process
2. PVOID VisibilityProcess(PVOID TS)
3. {
4.     while(GServer->ServerOnline)
5.     {
6.         pthread_mutex_lock( &GServer->PlayerMutex );
7.         pthread_mutex_lock( &GServer->MapMutex );
8.         for(UINT i=0;i<GServer->MapList.Map.size();i++)
9.         {
10.             CMap* map = GServer->MapList.Map.at(i);
11.             if( map->PlayerList.size()<1 )
12.                 continue;
13.             for(UINT j=0;j<map->PlayerList.size();j++)
14.             {
15.                 CPlayer* player = map->PlayerList.at(j);
16.                 if(!player->Session->inGame)
17.                 {
18.                     continue;
19.                 }
20.                 if(!player->VisiblityList()) Log(MSG_WARNING, "Visibility False: %u", player->clientid );
21.                 if( GServer->Config.AUTOSAVE == 1 )
22.                 {
23.                     clock_t etime = clock() - player->lastSaveTime;
24.                     if( etime >= GServer->Config.SAVETIME*1000 )
25.                     {
26.                         player->savedata();
27.                         player->lastSaveTime = clock();
28.                     }
29.                 }
30.             }
31.         }
32.         pthread_mutex_unlock( &GServer->MapMutex );
33.         pthread_mutex_unlock( &GServer->PlayerMutex );
34.         #ifdef _WIN32
35.         Sleep(GServer->Config.VisualDelay);
36.         #else
37.         usleep(GServer->Config.VisualDelay);
38.         #endif
39.     }
40.     pthread_exit(NULL);
41.     return 0;
42. }

It's unable to run the player->VisiblityList() function because there's simply nothing there yet as far as I can tell.
As it's in a completely different thread I'm wondering if it's trying to run the visibility code before the player structure is being completely set up

Does that sound feasible?
I've never come across this before.

ABE
Nope that's not it.
Added a 100 loop delay timer before it was allowed to call visibilty. Loaded up fine but died the first time it called visibility.
This is starting to get on my nerves.
First it works then it doesn't then it does again and then just when I think I'm winning it fails again.

Update
Some more digging shows that it's not the first time it tries to touch the visibility lists any more.
It's successfully scanning through 184 of 185 monsters in map->MonsterList
as it tries to enter the final iteration it dies and doesn't even show me that line of code that's at fault. I figured this out by adding log messages.
I could try

Line number On/Off | Expand/Contract | Select all

1. for(UINT i=0;i<map->MonsterList.size()-1;i++)

but that seems a bit retarded and would potentially leave a single monster on each map that nobody could ever see

Duh.... I'm being dumb here. The size of a vector is always one bigger than the index value of the last element
So that means it's clearing the monster list completely while debug log messages are present

[PurpleYouko]

Finally working, at least for character ShaiDaran who has no skills.

Now I need to try it with one that does have skills and then I will be back at the point i should have been 2 days ago.

The latest problem turned out to be because somehow I was scanning the VisibleNPCs but using VisbleMonster.size() to do it... OOPs
But that still doesn't really explain why it all stopped working in the first place.
Chances are that was due to the other errors that I found with loading up arrays but the problems were being masked by this latest one.

OK so now trying with my Dealer....
Back to char select
Select her and......

DOUBLE CRASH. Both worldserver AND trose.

Good grief!!!!!
*bangs head on keyboard*

closed down both and started up again. This time the server didn't crash but the client did. Some kind of znzin error that happens when a node can't find valid parent information.
I'm taking a break from this for a while.....