Would you rather Reject a craft when the game crashed or disconnected?

Even though we are utmost careful when crafting, things can go wrong anytime.
Your internet connection can drop, Your game can crash. Your house can be on fire.
So, what if something bad happened and your crafting session ended abruptly.

As it stands now, it will complete the craft giving you the product whether you like it or not.

My suggestion is to make "Reject" the default option in a crash, a disconnect or accidental closure of the crafting window.

What do you think?

 

no.. because it can be abused. let's say they do what you suggest.. every undesired craft that we now revert would end with a "LAN Cable disconnected" or forced shut down..or ..... well you name it , there are many ways to simulate a "crash"

i am for an "accept" if it's a real crash (with error message) and with the option that support revers it upon request, provided the user requesting it can prove it was a crash(screen-shot of the error, with time stamp, etc)

 

What Arx_X said is valid.

I don't know you already read my thread about this issue. If you haven't you might want to check it out.
You'll also found out that the solution already being offered earlier as craft 2.0 feedback.

In short, discussion participants prefer the "Reject" & "Accept" button still available when we back on the game.
The reason is as simple as no decision yet being made whether to reject or accept the craft result.

I almost forgot..
Welcome to the club

 

How can anyone abuse it?
It is not going to be free. The charge is still going to apply.
You are not going to get a free reject.

 

Neither reject or accept are acceptable. Imagine with some luck you crafted 4x dmg torso and crashed. Do you want to reject it and spend another month or two crafting?

BP has to implement a state 'pending', so in case of a crash, closing the craft window or whatever, all the items including pending crafting result remain there.

I have wasted many items already thanks to a crash during crafting, and I do not see them fixing the crash. They do not even recognize this as an issue.

So that interim state is the only solution.

 

This would be the best soplution but tecnically speaking, probably the hardest to create (as long as they will have to implement the whole logging system needed which actually they don't have otherwise it would be possible to restore crafted items).
In the meanwhile they implement the best solution, it would be a great step ahead if they do what cdeepal proposed (with almost 0 effort to implement it) because we all know that you should lose something but you will never lose ALL and, in the largest number of cases, you won't lose anything.

 

The way I see it. Below is what the system have, once the craft button being clicked:
1. Item on slot 1 (Bag)
2. Item on slot 2 (Bag)
3. Item on slot 3 (Bag)
4. Item on slot 4 (Bag)
5. New item as craft result (It has reference to no.1-4, or vise versa, does not matter)

Then there are these scenarios:
1. Event triggered reject by player
System delete Item on slot 3 & 4, also delete the new item as craft result.

2. Event triggered accept by player
System delete Item on slot 1-4, move the new item as craft result to bag.

3. Unconfirmed craft process by crash or whatever reason outside event triggered by user
There are at least 2 possibilities where system can make some check:
a. The client status from connected to disconnected.
b. When client connected back to the game later.
Both may serve as trigger to check is there any New item as craft result for this player in database?
If yes, then do number 2 scenario.
As we can see no additional logging system required. Because actually all items still there including the craft result, as long as the system does not do number 1 or 2 scenario on (a) or (b).

So what've they missed? The answer is the status of the process.. where user have not made their decision yet whether to reject or accept.
If they really listen to feedback, this solution should cover what they missed and make adjustment for the sake of better user experience and win-win condition.

And the solution is simple, which is to mark ingredient items as temporary unavailable to sell, melt, upgrade, moved, or any other action other than to be put back to workbench and set it status to wait for reject or accept.

They did work with item marking all this time, like this:


This is considered simple routine task for them.

Do this, crafter happy

 

Not really, that "solution" has basic flaws.
You can set an attribute for items you've putted in the benchwork but you need attributes to indicate the slot they were occuping and which were the other items involved, otherwise you could simply:
- craft first item
- interrupt the process
- craft a second item (using useless items both in the junk slot and the "recoverable items" slot)
- interrupt the process again
- do this multiple times (every time in the process use a "fake craft")
- re-arrange the items in the best way
- accept what you would have gotten (the good items) but use in that craft only the "junk" stuff, put, intestad, the good items in the craft you are gonna revert (to recover em).

Conclusion:
you still have all the good ingredients, you got all the good results, you only destroyed the junk/useless items.

What you need to "keep a track" of the ingredients, their position and the results is definatly a logging system that not so fast to implement.
In the meanwhile, they can, at least, simply change what happens if you "do nothing" where there would be needed just 2 "if" in the check:
- amount of gold
- amount of andermant

 

The solution in case of crash, or for some other problem, is that the craft is "completed" only if you press Accept, Reject or X.

If client disconnect and server didn't receive one of the 3 "signal" the server must "remember it" and at next logon a craft window must appear with the 4 original item, the item crafted before "crash" and let you choose to Accept or Reject.

I lost a 2H weapon with 3 golden bonus and another with 2 in a client crash.

 

This is the "meta-item"



Whenever the workbench is being closed without pressing the "Accept" button it gets stored in the server's database. After that whenever you open the workbench you get this exact screen with exactly the same items ... you can't start another crafting you can't do anything until you click "Accept" or "Revert".
How can this be exploited?
Now ... go to the workbench ...craft one item until you get to this state (shown in the screenshot).
Try to put another item instead of the used ones. Can you do that? No you can't.
Try to swap the used items in your inventory with each other or different items (not used in the crafting process). Can you do that? No you can't.
You can pull off the LAN cable as much as you like ... you can request your internet provider to temporary reject you from their services... you can call up your neighbors to massacre your LAN cable with a machete or axe ... you can shot down your PC ... you can even rip your network adapter off ... but every time you open the workbench you will see exactly the same screen with exactly the same items as long as you don't press "Accept"or "Revert".
You can even manipulate the memory or the game files if you like ... but you won't achieve anything because the information is being stored at the server.

 

The system should already have the items, position & result data stored in back end.
If the data is in front end, that would be a big mistake.
So instead to delete or keep the items, position & result data when the interruption happen, it should just have to be given a mark/lock.
Thus making them only available in workbench in the same position and same result.
The status stays the same, user must decide to reject or accept.

 

Are you talking about what is actually happening or what you would like to happen?

No ATM whenever you close that window the system will automatically ACCEPT the craft.

Did they rollback the items you crafted with the "bugged" static enchants? They didn't.
Do they restore any crafted item? No they don't.

The fact that you think anything in this games is "stored" somewhere in the DB is far from true.

Again, this could be done if they ever had "stored" anything but all the proof you got ATM lead to think they aren't storing anything.
Would you want to know why they "automatically accept" the craft?
Because it doesn't even need to check if you had enough gold/andermant to make the revert.

BTW, on a side note, you could slightly spoil this system because, whenever you don't have enought gold to revert a craft, you could simply close the window, farm a little to earn enough gold for the revert, get back to the workbench, re-open the window, use a revert that you weren't able to use before, so you should not just keep track of what were the items, you need to track how many gold/andermant you had... this is only a dissertion.
The point is always the same: everyone knows what should be the best solution, the problem is how much it takes to implement it.

Everything you are saying revolves around a traking/logging system of any craft attemp, a system that probably doesn't exist, that should be developed (CODE to be written, new tables on the DB to keep the datas) and this isn't an easy work.

You seemed to suggest something "different": to create an attribute for the items you used for a craft and I proved that the "attribute" wouldn't have been enough.

We all know that the "best" solution would be to keep track of EVERY craft attemp (with a logging system) so it would be possible to "recover" what was happening during a crash. The problem is IT TAKES A LOT OF WORK (if you have BASIC knowledge of programmation and if you don't have them, just use some common sense).

For everything, you got several ways to solve a problem and relative effort:
- best solution -> max difficult (implement the logging system and recover any craft)
- decent solution -> average difficult (turn the "automatic accept" into an "automatic revert", just add the check to the current gold/andermant disposal to see if you can revert otherwise automatically accept)
- worst solution -> no difficult (accept whatever was the result)

ATM we got the worst solution (accept the trade, no check needed), the OP suggests to implement the "decent solution" so AT LEAST we got something back because the "best solution" probably won't see the light anytime soon.
I support this because I'm one of those that prefer to get something instead of nothing at all: it's called compromise.

 

The crafted result is always stored in server even now.
That is exactly the reason why in a game client crash, the server accepts the craft and place the resulting item in your inventory.
If it was not stored on server, it wouldn't have been able to do that during a client crash.
Therefore, doing what sebastian and Trakilaki suggests (which I prefer better than my original suggestion) is entirely possible and very easily achievable by the game developers. I know how easy is to implement something like this because I am a developer myself.

Everything in this game is stored on server databases. Your items, Your stash, inventory, sticker book, leader board results, your talents, fame. Pretty much everything.

 

There is already a storage place for what trakilaki is saying. YOUR character. The status of what is being crafted is there. I know that your character and all it's equipment is not stored on your machine. If it was, you wouldn't be able to play from multiple machines with the same character as I have done (home computer and out of town laptop). Storage is easy (I'm an industrial programmer).

So I'm with trakilaki on this one. Hold the status till player gets back.

 

crafting is a fraud to steal your gold.....dont go there

 

If they can't make the workbench keep the items and result until you return to it so that you can accept or revert, I'd rather have it revert the craft than lose my gold lines (items from slots 1&2 returned).

 

This isn't how it works.

The fact you are storing a RESULTING item doesn't mean that you are logging whatever were the items BEFORE the craft and how they changed their stat after the craft.
You are confusing a logging system with stored informations, different functions different things.

By your thinkin' we should have "stored" every single dmg you've seen on the screen when you hit a mob, every single step you did to walk from point A to point B, every single transaction you did with any vendor, every map, every group, every amount of gold you collected. I could go on very long with the list and I know pretty well my job as weel to be sure that 90% of those transaction are just updates on the same record and many of them are just temporary information that aren't even handled server side because traking EVERY single changement in the game is just too heavy.
Again, don't confuse temporary information with stored information.

I handle datas that are way more important than the ones from a game and reality is a whole differente thing.

Obviusly, there's always the option that they already collect all the datas about the crafting we do and they don't want use the system suggested because they consider it a waste of time but, if this was the case, why to keep the logs in the first place? It surly costed time to log the transactions (because you can be ignorant how much you want, but everyone with a grain of salt in his brain would understand that any logging system doesn't come for free).

 

You would loose 4/4 too bLaind..

 

Everything is being stored.
Otherwise they could not restore your items https://board-en.drakensang.com/thr...estoration-of-deleted-characters-items.70578/

 

Infact they cannot:

We cannot restore:

• Items that existed as loot drop but you did not manage to collect. The Support team is unable to check the validity of those situations and therefore cannot restore items that have never been in your inventory.
• Consumables: essences, teleportation items that are needed to access some maps, health potions, other kinds of potions, etc.
• Items that have been melted or combined at the workbench. Those items are lost forever no matter their value and they will not be restored.
• Items that are rewards from quests: the Support team will not reactivate the quest in order to help you recover lost items.

And this is a good evidence (read carefully):

Support team is unable to check the validity of those situations and therefore cannot restore items that have never been in your inventory.

Which, in other words, means: we do NOT track everything