Revisiting crafting continuation after disconnecting.

[Rongway]

and then when the user logs back in, a small timer starts and the character is frozen from doing anything but moving (10 seconds or so?) after which the craft resumes exactly where it was at when the user disconnected. The short timer would allow for someone to move to a slightly different location if they were in an instanced area like a house and logged back in outside, possibly stacking on other users which I find to be a bit visually overwhelming.

I like the save state / resume state part of your suggestion.

I don't like the movement part. It adds a level of complication that doesn't need to be there -- just finish the one craft that you had in progress and then move. While it may be visually unappealing if multiple people relog in medias fabrica, all the relevant state info is in your crafting window and buff bar, so you can still finish your synth without seeing yourself. If it's still distracting, step away from the computer and grab a drink while the other person finishes and repositions.

[KisaiTenshi]

With the current issues of constant disconnects we're having I thought it might be nice to revisit the idea of disconnect proofing crafts. It obviously would take awhile to program in, but it feels like this is something that should have been dealt with by now considering the elaborate nature of the crafting system.

No matter how it's approached, it's exploitable. The developers would have to change how crafting states are changed on the server, which would mean they take significantly more time, and crafting macro's would fail if the macro executes faster than state saving.

Like in all honesty, the right angle to take with this is to "deposit" the materials for crafting, save that, and should a DC happen before the first step is executed, the materials remain available to reclaim. If the first step has been executed, then the materials are no longer available to reclaim, and are mailed back after an hour if a finishing step was not attempted. Exploitable, yes, but abuse is less likely if there is a cooldown. Another way to approach this is to actually put a CD straight onto the crafting toolbar, and if a DC happens while being a crafter, there is a CD on all crafting skills, and it gets longer if the same item is disconnected again.

To use your idea, (let's assume the DDoS's aren't actually crashing the servers for this scenario) they would need to log each action taken (hey they do this already with combat) and determine if the crafting was aborted due to client disconnection, or due to server reboot/crash. For practical reasons however, this would only work if the crafting was performed in an individualized instance (eg house, apartment, inn) so that the server can save the state of the instance rather than trying to save the crafting state for everyone in the zone.

Thus if you craft in your house/apartment/inn/barracks, you would get a "resumable" icon, and if you disconnect, there would be an object in the house/apartment/inn/barracks that goes "inside you find a partially completed <item name>, would you like to try and finish it? (switch to <crafter name> to select) and it would restore the progress as the instance recorded it. It would also allow crafts to be paused without loss if queued for DF.

If the servers are actually being crashed by the DDoS, then it's very likely that steps would get rolled back system-wide, hence the issue with being disconnected is that it may "roll back" items a few steps, and if that rolls it back before it starts, the items don't come back. Hence some kind of deposit system is needed to ensure that the materials aren't lost, but it's an engineering issue.

So "world" crafting would behave as it is, and "resumable crafting" could be done inside specific instances to put less load on the the zones in saving the state of all the crafting activity. Who knows, maybe the load isn't really as significant, and it's just "too much effort" to sync after every crafting step, and then put a "partially completed <item name>" in the players inventory.

[ChameleonMS]

No matter how it's approached, it's exploitable. The developers would have to change how crafting states are changed on the server, which would mean they take significantly more time, and crafting macro's would fail if the macro executes faster than state saving.

Crafting macros executing faster than the server/connection can process has been an issue since the beginning. I have all my macros set to <wait.3> for absolutely everything because <wait.2> just is not long enough for reliability if there is any latency going on. FYI, I use to have them set to <wait.4> back in 2013 when I still playing this game on PS3 with only a 6mb connection, and ~200ms ping.

OP, as for the actual request, it is something that has been asked nearly as often as the tackle box. I want it, just about every crafter wants it. But, it will not come until the next incarnation of the game (I do not mean expansion, I am mean the next game like the transition from FFXI to FFXIV).

[Tiraelina]

No matter how it's approached, it's exploitable. The developers would have to change how crafting states are changed on the server, which would mean they take significantly more time, and crafting macro's would fail if the macro executes faster than state saving.

Like in all honesty, the right angle to take with this is to "deposit" the materials for crafting, save that, and should a DC happen before the first step is executed, the materials remain available to reclaim. If the first step has been executed, then the materials are no longer available to reclaim, and are mailed back after an hour if a finishing step was not attempted. Exploitable, yes, but abuse is less likely if there is a cooldown. Another way to approach this is to actually put a CD straight onto the crafting toolbar, and if a DC happens while being a crafter, there is a CD on all crafting skills, and it gets longer if the same item is disconnected again.

To use your idea, (let's assume the DDoS's aren't actually crashing the servers for this scenario) they would need to log each action taken (hey they do this already with combat) and determine if the crafting was aborted due to client disconnection, or due to server reboot/crash. For practical reasons however, this would only work if the crafting was performed in an individualized instance (eg house, apartment, inn) so that the server can save the state of the instance rather than trying to save the crafting state for everyone in the zone.

Thus if you craft in your house/apartment/inn/barracks, you would get a "resumable" icon, and if you disconnect, there would be an object in the house/apartment/inn/barracks that goes "inside you find a partially completed <item name>, would you like to try and finish it? (switch to <crafter name> to select) and it would restore the progress as the instance recorded it. It would also allow crafts to be paused without loss if queued for DF.

If the servers are actually being crashed by the DDoS, then it's very likely that steps would get rolled back system-wide, hence the issue with being disconnected is that it may "roll back" items a few steps, and if that rolls it back before it starts, the items don't come back. Hence some kind of deposit system is needed to ensure that the materials aren't lost, but it's an engineering issue.

So "world" crafting would behave as it is, and "resumable crafting" could be done inside specific instances to put less load on the the zones in saving the state of all the crafting activity. Who knows, maybe the load isn't really as significant, and it's just "too much effort" to sync after every crafting step, and then put a "partially completed <item name>" in the players inventory.

You're taking something that wouldn't be exploitable and making it exploitable and severely over-complicating it. Saving the synthesis progress would practically be a server side change aside from the pop up on the client when it applies. The game is already talking to the server to perform actions. Logging the entire process is overkill, it only needs the last known state, which is entirely up to the server.

Trying to prevent losing items from a rollback (if this even happens at all) because the database and game are out of step would need them to verify it somehow with the database with new entries for being-working-on items before trashing them from your inventory entirely.

[KisaiTenshi]

You're taking something that wouldn't be exploitable and making it exploitable and severely over-complicating it. Saving the synthesis progress would practically be a server side change aside from the pop up on the client when it applies. The game is already talking to the server to perform actions. Logging the entire process is overkill, it only needs the last known state, which is entirely up to the server.

Trying to prevent losing items from a rollback (if this even happens at all) because the database and game are out of step would need them to verify it somehow with the database with new entries for being-working-on items before trashing them from your inventory entirely.

Logging the last known state requires logging the state of all 30-something buffs, and their time/steps remaining. It wouldn't verify that the player actually crafted the item correctly and isn't actively abusing an exploit. You want what any good database does and "replay" the log file to the state it was in so that any consumables and gear changes don't cheese the end result.

Anyway, the point agreed on is that the game should have a way to resume crafting, and if the easiest way to accomplish that is to "use the workbench in an instance" then that isn't an unreasonable request.

[Final-Fantasy]

I can't see them doing anything, because it would have to be related to " Cancel " and this would make it easy for people to abuse the progress bars.
And if they did change to " Disconnect " well, you could just disconnect if you were not happy with the progress.


And thus, it will never be changed, and shouldn't because it opens up the system for exploits.

[Tiraelina]

Logging the last known state requires logging the state of all 30-something buffs, and their time/steps remaining. It wouldn't verify that the player actually crafted the item correctly and isn't actively abusing an exploit. You want what any good database does and "replay" the log file to the state it was in so that any consumables and gear changes don't cheese the end result.

Anyway, the point agreed on is that the game should have a way to resume crafting, and if the easiest way to accomplish that is to "use the workbench in an instance" then that isn't an unreasonable request.

When I say last known state I mean a snapshot of your character before you disconnected while crafting. Something you can't influence as a player. Logging back in would give you the prompt to either continue and be forced into that snapshot at your current location (because housing areas) or take a standard failure like if you had stopped crafting before allowing you to do anything else. We all know SE isn't averse to locking up the interface.

Either way it wouldn't matter if you replayed the entire thing or just the last known state if there was that big of a flaw in how their system works. It would end up at the same outcome because the server is the one in charge. If someone can influence that we have much bigger problems. You still need a snapshot of some point because you can't trust the client if someone somehow managed to change their gear or take a consumable through non-standard means.