| Pages: [1] :: one page |
|
|
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |
MORRS
   |
Posted - 2006.08.07 13:16:00 -
[1]
OK, finally got the POS up put job in and after second thought, didn't want to go the two week me job. So cancelled the Job and guess what happened? The POS that I own with the Lab I own the slot is unavailable for two weeks. Come on CCP, is this right? What do I have to do, uninstall the Lab and re-install it to get the slot back? This is rediculous.
Fix it please.
|
Ricdics
Dreadnought Production INC
|
Posted - 2006.08.07 15:38:00 -
[2]
might not be a bug, same thing happens in labs in stations. Don't cancel jobs, and you won't screw yourself over 
Insured Research and Production Services
Queues |
Kalavoz
Caldari
Calista Industries
|
Posted - 2006.08.07 21:27:00 -
[3]
As you suggested - to get your slot back, unanchor the lab, and reanchor it.
The cancellation of your jobs (but not the time they would have taken) is designed by CCP to stop people spamming lab slots, apparently.
Good luck with your lab
|
Lab Technician071548
|
Posted - 2006.08.08 04:23:00 -
[4]
It's to stop people from reserving lab slots.
Imagine putting something slow but cheap like a frigate BPO into research while you save up for something more useful to you like a citadel torpedo BPO. You buy the BPO, cancel the frig job, and get the torp BPO cooking in its place.
Alternatively, you tie up a slot for 30 days waiting for your friend to get a slot open (maxed due to skills), and then yank your job and let him in as soon as another job finishes so that he can "chain research" to keep his BPOs cooking.
That's what they want you not to do. That's why you lose the slot and everything stays the same on timing.
|
franny
The Core Collective
|
Posted - 2006.08.08 05:42:00 -
[5]
more likely it's a remnant from when they first changed to the current sci/industry code, when you couldn't cancel jobs
|
Tachy
|
Posted - 2006.08.08 06:58:00 -
[6]
The jobs do not exist.
There is nothing the server traces.
The lab is linked to the BP.
There is an end date in a table to make the client show the remaining duration/status.
When you enter a job, the materials will be taken from you and removed from the game.
When you cancel the job, you get the BPO back.
When the time's up and you mark the job as finished, you get the linked BP and the products.
It is the most CPU-/DB-Access friendly way to do jobs as the servers don't check anything unless the user hits a button.
--*=*=*--
Even with nougat, you can have a perfect moment. |
MORRS
|
Posted - 2006.08.10 00:32:00 -
[7]
I know it's designed by CCP to keep players from spamming labs. But in this case, this lab is on a POS. I should be able to cancel my job on the lab and POS that I own and not be penalized for it and not have to unachor and reanchor to clear it out. After all I DID put 500 mil into it, I should be able to do as I wish.
|
Matthew
Caldari
BloodStar Technologies
|
Posted - 2006.08.10 11:52:00 -
[8]
 Originally by: MORRS
I know it's designed by CCP to keep players from spamming labs. But in this case, this lab is on a POS. I should be able to cancel my job on the lab and POS that I own and not be penalized for it and not have to unachor and reanchor to clear it out. After all I DID put 500 mil into it, I should be able to do as I wish.
When the call for a job cancel option was first made, it was stated that it was not possible at all, so I suspect what we have now is as far as the system can be stretched without another major re-code.
I would think the problem is that the "queue" is not really a queue at all. Each individual slot has a "becomes free at" time, each job has a "ready to deliver at" time. When a job is entered, the selected slot's "becomes free at" time is used to help calculate the job's "ready to deliver at" time. The job's build time is then used to increment the slot's "becomes free at" time.
This is a very efficient way of processing S&I jobs, as it does not require any links between the slot and job tables, and only requires server time when the job is created or delivered. This efficiency gain was very necessary, as it was explained at the time that the old system was taking 10-15% of server load.
However, that lack of association between job and slot would pose a problem for cancelling jobs. When the job is cancelled, the system would have no way of knowing which slot should have it's queue shuffled up, and the slot wouldn't know which jobs were in that queue in order to update their "ready to deliver at" times. Assuming the system does work like this, the current behaviour when cancelling jobs is the best that can be done. To be able to do what you want would require the reintroduction of a fully-linked jobs and slots table, along with the server problems that causes.
-------
There is no magic Wand of Fixing, and it is not powered by forum whines. |
|
|
| |
|
| Pages: [1] :: one page |
| First page | Previous page | Next page | Last page |