ricky92

You need to apply a transformation matrix to the mesh, just search in the granny documentation. You'll probably want to keep different copies of the same mesh with different scale values in order to avoid having to transform the same model over and over again.

Do you even have the eyes to read and compare YOUR code to MY code? Your tool even has glitches, you should at least try to fix them before attempting to say my work is a derivative of yours.

Was just about to post this tool on here, and I saw your post... xD Don't worry, it's perfectly fine! However, I just think this is not the right section, as it more rightfully belongs to the "Tools" section. The video is pretty good, so I thank you for it, even though it only shows the export part. Just one last thing, if the mega link ever goes down, here's a direct download link from my site: [Hidden Content]

File char_affect.cpp, function: bool CHARACTER::RemoveAffect(CAffect * pkAff) scroll a little bit down and find this portion of code: if (AFFECT_REVIVE_INVISIBLE != pkAff->dwType) { ComputePoints(); } after that, add: else { UpdatePacket(); } When the character attacks or skills against a monster/another player when it is still invisible, the bug shows up. It's caused by the explicit removal of the affect, as the affect flag is indeed removed from the character, but the client can't know that as it doesn't receive an UpdatePacket (which is handled internally in the ComputePoints function).

It's not. The client launcher is perfectly fine, it's the gamefile that is missing a piece of code to make it work properly.

An encryption algorithm can't be changed, improved or fixed while mantaining compatibility with a previous version. It might have been named "TEA", but it was instead an XTEA implementation, and implementations can be improved: that's the case with the two functions you're mentioning, one had a for loop while the other was "unfolded" (for better performance). Anyway, if you're compiling using the "improved packet encryption", I urge to let you know that packet encryption is a completely different process, and very far from the old and insecure XTEA, so you probably made a worthless effort, sadly :

What I'm trying to say is that the function lua_resume returning LUA_YIELD is normal behaviour: that's exactly how Lua coroutines work. Every function that "pauses" lua execution is able to do so because it is yielding, and that's why lua scripts can "interact" with the user in a non-blocking way. Check in the questlib.lua file and you'll see what I mean: function select(...) return q.yield('select', arg) end

If you still haven't found a solution for this problem, try treating LUA_YIELD as a valid return value. I upgraded to 5.1 and had to make this modification to make it work correctly, and I suspect that's the solution for Lua 5.2 as well. Afterall, it makes more sense than in Lua 5.0: if a coroutine "pauses", there's a need to know from outside of it if whether it just ended or if it yielded (which would mean that it's then waiting for a resume call). As a side note, may I suggest you make your core open-source? Afterall the base sources are Ymir's, and since you're offering your work to the community for free you might as well benefit from the community in return, and accept users' fixes.

The singleton class in Ymir's sources does not make use of lazy initialization, so you actually need to explicitly initialize it somewhere. Open up the main.cpp file and you'll see many (if not all) of the singleton classes initialized on the stack there: do the same for your class and it should work fine.

Your game might have syslogs disabled, then. You need to revert the difference: just find the dif file and swap the two bytes at the end of each row, and then reapply it.

On the line of the array "kingdoms", you are initializing the array using regular brackets "(" and ")", instead of curly ones "{" and "}". That's what's giving that error, just fix it and it should compile fine.

Well, as Shogun suggested, you should post a snippet of your sysLOG (not sysERR) at the moment the server crashed. It might give a hint on what that person was doing to make the process crash.

There is a buffer overflow in the function CHARACTER::GetPoint: if (val > max_val) sys_err("POINT_ERROR: %s type %d val %d (max: %d)", GetName(), val, max_val); As you can see, the variadic-argument function references 4 variables, while only 3 values are passed to it. But I'm not quite sure that's the real reason of those crashes... Anyway, the checkpointing thing makes the game crash when it detects the game has been unresponsive for a defined amount of time (I don't remember exactly how long it was, tbh): there might be an endless loop somewhere in your quests (or in the game itself, who knows).