Snapshot? Can GGG even fix the mistake?

"

ampdecay wrote:

I just took my first programming class using C so I may be a little unclear on everything but I think I understand what you are saying.

I'm just not too good at explaining what I mean yet

basically it just declares some static integer constant instead of a global variable the other functions can refrence?

Something like that... a global variable is created before calling it and is checked at the time a function is called but the function itself cannot check that said variables are still valid while running. The function creates it own internal copy of that global variable that cannot be changed by modifying that global variable directly.


edit - and if you think desync is bad now, removing snapshotting would make it FAR worse with how much time sensitive extreme server load would be added if they removed it.

"

Jiero wrote:

No it doesn't and he was right in saying that it was hardcoded

Actually, they are both correct. First, if it was hard-coded and they DON'T have access to the source, they wouldn't be able to "fix" it. If it's hard-coded and they DO have access, then they could fix it. However, it could be that the fix is so complicated and impacts so many other parts of the code that it's not worth it to try and fix it for all the other problems it would cause. The cure being worse than the disease, etc.

As far as the philosophy, I'm impartial on snapshotting. I'm currently leveling a summoner (70 atm) and I have no desire to snapshot nor have I felt like I needed to snapshot. Mostly because I'm lazy. I've soloed all bosses (except merc Dominus) and I'm soloing fun rolled 66-68 maps (Champions/Horde, etc.). I use a zombie build and my 8-9 zombs plus 12-14 totem skellies plus Vaal summon skellies works extremely well. I run with 2-3 spectres built from whatever local mobs are in the map/zone because I'm also too lazy to go to a zone that has the "uber" spectres. I've never felt like that was needed.

Now, if I ever get Mon'treguls I would start snapshotting half my zombies but that's more for the fun of it than something I would feel is necessary.

"

Alea wrote:

"hard coding requires the program's source code to be changed any time the input data or desired format changes, when it might be more convenient to the end user to change the detail by some means outside the program."

=> so if you got the source you can still fix it (and compile it heh) isnt it ?

What that translates into is that the variables inside functions are created as static and cannot be changed easily outside a hex editor modifying the data while it is loaded into ram by the end user. Source code access has nothing to do with that in the slightest, this is more akin to local static variables compared to global dynamic variables.


and like I said, this is used to lower server resource needs and make it possible for the server to process and respond to player actions faster with weaker hardware.


edit - modifying data in the game's code without the source code is something different (reverse engineering or hacking).

^ Yep with today's multicore cpus and the ability to throw a lot of powerful hardware it isn't something that anyone would recommend using.. problem is that it goes far deeper here with the single threaded programming of the engine. You add in those global checks and the game will not be able to run on anything anymore without constantly freezing and stuttering.


Without a rewrite of the entire engine to add multithreading (read as they won't be doing this ever), I don't want them to touch it since it would render the game a broken mess. It would constantly have to check those global variables and the whole game would microfreeze and drop frames every time it did.

"

ampdecay wrote:

It all has to do with RF so you can't take the gem out once you start burning to stop yourself from dying, but what I got out of that is that snapshotting is hard coded into the engine and without a new engine they can't fix it.

I disagree with your interpretation that they would need a new engine to fix snapshotting if they were so inclined.

See here per Mark_GGG: http://www.pathofexile.com/forum/view-thread/766718/page/5#p6650775

In relevant part:

"This is my opinion, some members of the team have come to the conclusion that while still clearly non-ideal, the no-snapshotting case is still better. So that might still happen as a temporary measure at some point, which would at least allow us to start balancing things around there being no abuse of snapshotting."

The temporary measure part is versus a long term fix. If they are considering a temporary quick fix to break snapshotting functionality, then a new game engine must not be a requirement thereof.

"

Jiero wrote:

^ Yep with today's multicore cpus and the ability to throw a lot of powerful hardware it isn't something that anyone would recommend using.. problem is that it goes far deeper here with the single threaded programming of the engine. You add in those global checks and the game will not be able to run on anything anymore without constantly freezing and stuttering.


Without a rewrite of the entire engine to add multithreading (read as they won't be doing this ever), I don't want them to touch it since it would render the game a broken mess. It would constantly have to check those global variables and the whole game would microfreeze and drop frames every time it did.

OT: You are coming across like someone only vaguely familiar with programming in a client/server architecture trying to sound like you know a lot more than you actually do. What do multicore CPU's and single threaded programming have to do with hard-coding functions or values? Also, are you seriously implying that you think the server code is single threaded? That would certainly explain why I have to wait for you to log off before I can play. Er... wait...

I imagine this ties back into why that talented fellow who optimized their code found greener pastures after a few months. The code is likely sloppy, poorly documented, and a fucking nightmare to do anything more than tweak here and there. Rather understandable, being GGG's debut game. Hope they license a professional engine/support and put some of their better ideas towards a sequel going forward.

"

b15h09 wrote:

I imagine this ties back into why that talented fellow who optimized their code found greener pastures after a few months. The code is likely sloppy, poorly documented, and a fucking nightmare to do anything more than tweak here and there. Rather understandable, being GGG's debut game. Hope they license a professional engine/support and put some of their better ideas towards a sequel going forward.

I've actually had this thought for awhile. I've worked on projects where the development timeline was so ridiculously short that inevitably what you were going to end up with was a mound of (mostly) functional spaghetti code which was nearly impossible to maintain after launch. In those cases the next "update" would usually be a full on revision of the entire code base because adding new features to the original version was a nightmare. I think GGG may be suffering from something similar. In a rush to get the game done they may have cut some corners when it comes to coding best practices.

Having said that, it's also possible that they didn't cut corners but simply didn't anticipate snapshotting and therefore the way skills and items ended up being programmed makes it impossible to fix without significant rewriting. In the end I would guess we're seeing a little bit of both. Perhaps some poorly thought out code combined with an unanticipated mechanic.

In the end though, I think quite a few people complaining about snapshotting are a just jelly. They don't have builds or items which allow them to snapshot so they hate on those that do. I'm not saying all complainers are jelly, but more than a few are IMO.

"

dessloc wrote:

"

ampdecay wrote:

It all has to do with RF so you can't take the gem out once you start burning to stop yourself from dying, but what I got out of that is that snapshotting is hard coded into the engine and without a new engine they can't fix it.

I disagree with your interpretation that they would need a new engine to fix snapshotting if they were so inclined.

See here per Mark_GGG: http://www.pathofexile.com/forum/view-thread/766718/page/5#p6650775

In relevant part:

"This is my opinion, some members of the team have come to the conclusion that while still clearly non-ideal, the no-snapshotting case is still better. So that might still happen as a temporary measure at some point, which would at least allow us to start balancing things around there being no abuse of snapshotting."

The temporary measure part is versus a long term fix. If they are considering a temporary quick fix to break snapshotting functionality, then a new game engine must not be a requirement thereof.

ah thanks for the post! I don't believe I've seen that one!

"

Phaeded wrote:

OT: You are coming across like someone only vaguely familiar with programming in a client/server architecture trying to sound like you know a lot more than you actually do. What do multicore CPU's and single threaded programming have to do with hard-coding functions or values? Also, are you seriously implying that you think the server code is single threaded? That would certainly explain why I have to wait for you to log off before I can play. Er... wait...

That is like asking how hard drive read speed can impact framerate when it is slow on loading assets. There is a lot I'm leaving out and won't be talking about here because I'm not your personal tutor and it really is that complex of a subject. If the rest of the code has to wait for 1000 checks per second at a millisecond processing time each to make sure all the variables are still accurate, then the game is perma frozen in a infinite loop of checks... and since it can only do one thing at a time that means all it would do is check those variables over and over and the game itself will be frozen and unable to run anything (yes, this is a extreme case).



Single threaded does not mean only a single thread, it means only one thing at a time on one core and most likely they didn't add out of order operations, hyperthreading or thread priority either... stuff we learned back in the 90s. Its likely first in, first out all or nothing single file queue for all processing in the game (and likely per sandboxed client/zone instance in the server as well).


Basically all the old programming mistakes that we were taught in the 80s to 90s when we were still using single core cpus.



edit - as far as a bandaid fix for it... it would be.. messy... its possible but it would require quite a bit of finesse and can backfire pretty hard or break a LOT of stuff. As far as to the ways it can be implemented, that is to varied to say here because its only really limited by the skill of the coder as to how to implement such a bandaid.