Member of the EVE Tweet Fleet

Friday, July 30, 2010

Nerd rage

Not mine. But the EGA stuff that's been hitting the news wires. There are all sorts of reactions going around. Both from inside and outside the EVE community. From the shock of people who don't play EVE at the virulence of the reaction to the (few) who are quitting EVE over it (can I haz your stuffz???).

I realize that a bunch of you are up in arms over the development plan and what's been going on. From a certain point of view it's justified. And it must be said that CCP to a certain degree has made their own bed over this one. However comparisons to SWG's NGE debacle are probably premature. There are a bunch of reasons for this.

1) This is not about ripping things away from players.

SWG's mistake was removing working content and mechanics without substituting equivalent content/mechanics. CCP has avoided this sweeping type of mistake. Their big problem is they have this vision of where the game should be and they have a whole bunch of content that are approaching completion and they are over focussed on that atm. If CCP suddenly removed a whole ship class or 5 - like say HACs - then that might cause something like the SWG's NGE.

2) There (still) is nothing else like EVE out there.

One of the other reasons that this has a good chance of blowing over is that EVE has no competition in it's domain. There are no other PvP/Sandbox/Economic/MMOs out there that even try to do anything remotely like EVE. On the fantasy side you've got Darkfall (not really familiar with it, but from what I've heard) and that's it... Heck it's production and economics game play is complex enough that spreadsheets are not optional to game play for those of us who get into it (how many pages is your main production spreadsheet up to? Mine is at 21 sheets). Welcome to the hardcore. There are no fluffy pink kitties here.

3) We are the hardcore, we hold CCP to a higher standard.

The reality is that we DO hold CCP to a higher standard than other developers. Sometimes they can be hard of hearing, and need to be reminded of it. The reason is that for all it's flaws we can see just how great EVE could be. When it's working well and "a plan comes together", there's absolutely nothing else out there like it. Nothing. This provides CCP with both an advantage and a dis-advantage. On one hand they won't be loosing too many players over this. I mean where would we go? Most other MMOs are bland and tasteless compared to EVE. It is like a technicolor show in the days of black and white. On the other hand you'll get incidents like the threadnaught on that voting page when we feel that CCP is making serious mistakes.

4) Part of the problem is historical.

Right up to Apocrypha there was constant improvement in the lag situation, while good working new content was brought to the table. Everyone agrees that Apocrypha was probably the greatest EVE expansion to date. The wheels came off the cart after that. Lag started to get worse. Even more problematic it got asymmetrical (i.e. attackers got worse lag than the defenders on any grid). It's been getting progressively worse in the two main expansions after Apocrypha. All of this just after CCP was boasting about "Excellence". That right there is the reason for most of the nerd rage. Don't go boasting about excellence when the situation is getting worse. Welcome to getting hoisted on your own petard.

5) The real rock and a hard place

The problem is that the features that CCP is working on and have promised to deliver are things they've been working on for the last 3/4 years. It's been going on so long that it's starting to resemble vaporware (I'm Canadian, as you can see by my unfailing politeness there). So regardless of the nerd rage going on, they ARE going to have to deliver some form of full body avatar soon. Their plan showed that. The problem is they still over allocated resources to the detriment of exiting code. There comes a point where you seriously need to work on your basic infrastructure. Because if it's shaky it does not matter how many new features you put out there, people are going to notice the cracks in the pavement.

Having a vocal player base is a disadvantage in that you occasionally get the rose glasses ripped off your face. The advantage is that you get those rose glasses ripped of your face. At least CCP now knows it needs to re-focus a bit. And although they can be a bit hard of hearing, at least they are not deaf (like the SWG developers were during the NGE thing).

Now I'm not CCP. However I would advise them to seriously consider forming a permanent "balancing" team (or two) who's job is to make sure that fixes and adjustments go out every update (not just every expansion). The backlog of stuff to address is big enough to justify permanent teams (side note: the teams are permanent - the personnel in them do not have to be). Also just because you plan to revise an entire area of the game does not mean that interim fixes on that area should not be done. With your development cycle on revising stuff running multi-year backlogs, it's worthwhile to get smaller fixes out there until the big ones can be done properly.

Another problem is with the Agile method they've been using. It's very good for making sure things are getting delivered. The problem is the "unfinished" feel it leaves behind if there is no follow up after the initial delivery. This is not necessarily a call to abandon Agile. It is a call to make sure there is follow up.

It's per planet.

Well the completion bug is per planet. Since I only have one production planet, it took proving that extractor submits caused the bug not to show up. Once I did that, I set up one planet at 3:55 eve time to have the bug by doing all processing submits last. Then I did my other 4 planets extractor submits and the results came in this morning.

Instant completion on all production during downtime.

At this point there's not much left to prove about this mechanic, except to test it outside of the narrow time band I'm currently testing it with. Which I'll do over the weekend. At least I've moved off starting my tests at ridiculous hours in the morning.

Aside to CCP: Originally PI derived blue prints were a) research-able and b) the items they built were reprocess-able. You originally screwed this up by a knee-jerk reaction to the reprocess debacle you engineered by your screwed up deployment plan (CCP Chronotis I'm looking at you and/or whoever you were listening to). Are you ever going to move those BPO items off the type of material definitions they currently have back to the type that have waste and are reprocess-able?

p.s. a knee-jerk reaction is best described by removing the word knee...

Wednesday, July 28, 2010

Next experiment

Ok, now to see if doing the extractors as the last submit before downtime has any effect on the instant completion.

setup 3 separate schematics in the 6 advanced processors
get all the materials in place.

Stagger the starts.
3:29
3:36
3:39
And lastly I get the extractors scanned and cycling at:
3:41

Now we wait for after downtime to see what the results are...

and at 12:42 eve time, I can confirm that none of the production plans got instant completed. So the bug/exploit is only kicked off by the most recent submit. Tomorrow we test if this is per planet or per character.

Incidentally I would have expected to see some material losses by now. It may be that CCP has fixed that (possibly causing the instant completion bug). Would have been nice if they had let us know if this is the case. Otherwise I've just been lucky with my start times....

This time

I almost got to use one of my Vagabonds last night... We had a Cyclone in Chaos Central. Unfortunately by the time I had fleeted up, he had exited the system. Ah well, can't win them all.

For the next test I am going to try to re-prove that only the latest submit on a planet gets the bug. So I setup a 20h job and a 40h job. 4 processors setup All materials there. This time I start both jobs one after the other. First the 20 h job. Hit submit. Then the 40h job. Started at 3:53 and 3:55 respectively. No further submits happen on character. We'll see what happens. I also intend to only log in after 12:00 eve time and hopefully I will cause the system to be loaded at that time. Here's what I'm hoping the results will be:

20h job on track but with 1 cycle gone poof (the destroyed materials bug)
40h job finished completely.

Lets see what we get...

12:05... extended downtime ... again ... time for a shower...

(incidentally all times I state are EVE times - in case that was not made clear).

Ok I did get the 40h finishing off at downtime - as expected and the 20h not finishing. Someone else caused the system to load so I was not able to get a positive result for that part of the test (the theory that the loss is related to the system loading...)

This at least confirms that the actual hour before downtime is irrelevant (I'm still setting it up withing the 15min before the hour though) and the bug shows up based on the most recent submit (no idea if it's for that planet or for the character though). Tomorrow's test will be to see if the submit for the extractors also causes the bug not to show up.

Tuesday, July 27, 2010

Back to testing

Man these 24h testing cycles are crazy.

Anyways, still trying to test whether this bug/exploit handles multi-day instant completion. I'll get to trying to nail down specific parameters that make it not occur once this is done. So without further adieu, here is today's experiment:

3200 x Proteins
3200 x Biofuels
1600 x Industrial Fibers
1600 x Silicon

2 x Advanced Industry Facility with Livestock Schematic installed
2 x Advanced Industry Facility with Microfiber Shielding Schematic installed

All materials in place and routes setup and ready to hit submit by 10:42.
Submit hit at 10:50

Now just need to wait for downtime...

11:58 hits and bingo - got:

200 x Microfiber Shielding
400 x Livestock

in the storage shed.

This confirms that if you set up multiple day runs they WILL get finished off in 40 minutes. Sweet.

Monday, July 26, 2010

In other news

In preparations for changed in the month of September, I have taken down the tower of my high sec research corporation.

I can see everyone going "wait a sec... what high sec research tower?".

It works like this: I've blogged on the workings of towers and high sec research towers in specific before. So subject covered. This time around I decided that operational security demanded that I not reveal anything about it's existence out side the obvious. So for over a year I've had some alts up in high sec quietly researching and copying my entire blue print collection (currently at 822 BPOs). True if you knew what to look for you'd have found it quite easily. Any spies who spotted it (we're pretty inconsequential in the grand scheme of EVE so its unlikely large alliances we have sent too many spies our way) congratulations. Pat yourselves on the back. If not, *shrug*, it's not like it matters now, does it?

Now for the major reason for taking it down: It used to be that researching at a tower, IF you could keep the slots fully occupied, was not only faster than research at high sec/low sec slots, it was actually cheaper. Now it is just faster (both in the literal per job sense and in the wait sense). Fuel prices have increased to the past the tipping point. I also reached end of the projected research needs for the foreseeable future. All my current ship BPOs have reached ME:20 (30 in the case of the Typhoon). All rig BPOs have been researched to perfect ME/20 PE. Just about all modules, ammo, and deploy-ables have been researched to 20 ME/20 PE. I've made massive "copy sets" for deployment to POS'es to enable them to be "self supporting" in T1 gear (damn handy if you don't want to risk your BPOs in wormhole space).

The point here is that the amount of PI necessary to support the tower, while not excessive was a bit too much considering I was reaching the end of what I want to research. Sure there's more PE research I could do, but CPP Chronotis never pushed through his desire to make PE more relevant. So time to close down the shop pending a pile up of serious research.

Of my 3 research alts, two of them are able to run 10 slots each of plain Jane research jobs, with the 3rd also at 10 slots but with a few necessary science skills thrown in to handle research on items needing science skills (Prototype Cloaks anyone?). Not up to T2 levels but that would be the next plan. These 3 guys are spread over two accounts, but hey can't have everything.

Moar results

Woke up Sunday at the correct time (barely) to get the experiment setup. Still had a bauble due to some materials being in the wrong place at the wrong time. The bauble revealed some interesting things however.

Here is the setup prior to waking up and logging in. Including the mistake. There are 4 relevant processors attached to my storage and in the storage I have the following:

1600 x Proteins
1600 x Biofuels (the mistake - lucky I had over 1600 Bacterias in a nearby spaceport)
3200 x Reactive Metals
3200 x Precious Metals

2 processors setup for Fertilizer
2 processors setup for Mechanical parts.

So I log in with 5 min to go (told you it was a little close to downtime). Rush to route the inputs. Have a problem with the biofuels not being accepted. Look at the configured schematic. Realize the Biofuels are wrong. Need Bacterias. Lucky enough bacterias are nearby. Hit submit for the existing routes which starts of the 40h of mechanical parts processing on two processors. Then I expedite the Biofuels out of the storage and the Bacterias into the storage. Route those and it submit a 2nd time. Lucky with 2 minutes to spare before downtime. So 40h reaction started at 10:56 and 20h of reactions started at 10:58...

Then I log back in at 11:35 to check what happened. Interesting the 40h reaction is proceeding as planed - currently with no losses. The 20h reaction however got insta-completed. From this I deduce that the instant completion on downtime bug is related to the most recent submit button. Whether it's relative to downtime or simply the most recent submit button is undetermined (more shit to test out - Yay!). However this is the 4th downtime where this effect has been observed when I setup the routing just before downtime. I'm beginning to suspect that it's related to the most recent submit button before downtime. Is this per planet or absolute per character? No clue (again more testing).

Again I still do not have enough of a handle to submit a bug report. Too many questions remain unanswered... Although the repeatability of the effect leads me to believe I'm getting closer to correctly understanding the mechanism.

Friday, July 23, 2010

More results

So this morning - 6 advanced processors - 20h of production each. Routed and hit submit at 10:50.

As usual - there was an extended downtime due to db issues.

Then when I actually log in at around 13:10 I find that I'm not the one to spawn the system. No, no, there are Russian core probes in the system. I find it amusing that we can at least figure out the client of the ship that launched probes language wise since the name of the probes seems to be client assigned.

However this makes the 3rd time I'm able to confirm full production completion if the production starts at 10:50... That at least looks mighty reproducible.

Results

And the results from the staggered start:

The first two were no problem no losses (maybe that's fixed?) but they were on the correct schedule. Of course I could not test my "delayed startup of system" theory since I have no idea when the system got loaded. So I still need to test that part of the theory. The last set - the ones started at 10:50 however had accelerated production in the sense that the entire run got done. by the time I checked. Weather it was finished immediately or part way through the day - no clue.

The next test is to have all 6 processors start at 10:50. We'll see the results if there's no extended downtime in 40 minutes or so.

Thursday, July 22, 2010

Figures

So, I finally get up in time. Setup 3 separate start times for 3 separate schematics spread over 6 advanced processors. 10:25, 10:35, 10:50... Come to log back on at 11:40 to get the system in place and what happens? DB problems and extended downtime... Sometimes you just can't win...

Tuesday, July 20, 2010

500!

And for my 500th post, I didn't wake up in time to do a good test this morning... ah well there's always tomorrow...

Monday, July 19, 2010

Back to testing

1) Finally I get my first Tech 2 BS weaponry skill: Large Artillery Specialization. And I immediately refit my POS bash BS... 49.3 mil SP only 700k untill I hit 50mil.

2) I've manufactured a Minmatar Control Tower Small out of resources I produced myself. Time to go sell it.

3) With that out of the way it's time to try and get the resource loss problem sorted so a series of experiments are going to be underway this week to try and determine what's causing the problem.

4) So after much cogitation and much trying to figure out what was causing the losses, I came up with a Theory. My theory is that the element that may be causing the problem was the fact that the loss may be related to the fact that wormhole systems are not loaded until the first person in that wormhole logs in or jumps in. This may be (in conjunction with downtime unloading the system) what is causing the losses and that would make it very hard to reproduce on Sisi but rather easy to reproduce on TQ.

5) So step one for testing out my theory is to setup a baseline. Make sure that a production cycle is started before downtime. Make sure the system is loaded before the cycle hits after downtime. Confirm there are no losses...

6) So I setup my P2/3/4 production planet with only 2 advanced processors locked and loaded with schematics and outbound routes (Biocells). Move 1600 of each of the materials (Biofuels and Precious Metals) into the storage shed (this is enough P1 material for 20h of processing for 2 advanced processors). setup the input routes and wait until 10:50 eve time to hit the submit. 10:50 rolls around and I hit submit. Confirm that the cycle has started - take screenshot etc...

7) Log back in at 11:35 eve time (downtimes are nice and short now). Confirm that I am the cause of the system being loaded (wormholers will know what I mean). Head over to the storage shed and see if we're still on track for the 11:50 cycle...

8) WTF???

9) Note that there are now 200 P2's (Biocells) in my storage locker... 20h of processing finished in 45 minutes...

Um... Exploit maybe? Going to see tomorrow if this is repeatable. Wish me luck. Incidentally thank you CCP for blowing up my baseline in such a creative way.

Is it just me or, between the SNAFU that we saw with the reprocessing of the stations into P4's and other shenanigans due to the screwed up deployment plans and the number of what seems to be different and unrelated bugs we've seen in PI, is PI the buggiest feature that CCP has released to date?

Friday, July 16, 2010

PI Cogitation

Well, I finally got around to updating my spreadsheet to include PI. Some interesting things are popping out: Raw materials are worth more than I thought. P1 and P4 are where the isk is. P2 and P3 are spotty. There has been a fundamental paradigm shift in infrastructure to fuel ratios. Now that fuel prices are actually tied to structure prices (since all the fuels area also components in a lot of structures), the ratio of fuel cost per month to structure cost are loosely linked. They used to be fixed. And the ratio has changed.

It's now cheaper than ever before to buy towers and POS modules (for the most part). However it is now much more expensive to run a tower. It's a good thing ice products are so cheap or this really would have hit the fan. It should be noted that this should not affect the small time tower operator in any way. Usually if you're a small time operator you'll be able to setup your main or your alt to do fuels and you'll be able to to keep going much as before. However once the pre-PI stockpiles run out, the major industriallists will need to take into account the new fuel costs for their moon harvesting and moon goo reaction towers.

There is good news: It is now cheaper than ever to replace infrastructure. The bad news: it's now more expensive to run the towers. This will have a long term impact on the price of moon goo, as well as POS research. Tower operators will now have to take the increased fuel costs into account when calculating the cost of their end products. We should see a reduction in proliferation of towers in the long run as the increased cost forces people to normalize their POS situation and make sure each POS they have out there is serving it's purpose in a cost effective manner. It also means that POSes are going to be easier to replace than they were in the past. This should lead to a reduction of the "fear" of pos loss being a limiting factor on POS placement decisions. But should lead to a more "cost centric" restriction on POS deployment as a whole.

One thing I think CCP has messed up in it's concept with PI is that it's mostly safe time wasting for a carebear. This is a nice change of pace compared to most other activities. Mining? constant exposure for the entire operation. Moon and refining? risk your infrastructure. Need to move goods from A to B? run the blockade. With this endeavor (PI) you only need to be exposed to danger during the hauling phase of the operation. And there are ways to minimize your exposure to danger during that phase as well. This makes it one of the safest ways to make isk in the game - but seriously time consuming. CCP might have done better to reduce the amount of time it takes to run repeated operations (as opposed to setting things up) thus allowing more time for the carebears to be at risk (like their other designs seem to want).

Oh well. No one ever said CCP's design team was consistent in sticking to principles.

CSM's Rock and Hardplace thing

Mynxee, in this post, complained that being on the CSM is like being between a rock and a hard place. This is true. But one cannot loose sight of the parameters under which they need to operate. The truth of the mater is that the parameters they are operating under back in April still apply.

CCP has overcommitment issues. Regardless of the fact that they have more personnel than they've ever had before, they also have more irons in the fire than they've ever had before. Even with the commitment to assign resources to address existing issues, there is still the truth that until DUST 514, Incarna and World of Darkness (possibly the worst kept secret in the universe based on CCP's corporate hiring page) have been deployed, there really is a limited amount of resources they can throw at the problems (admittedly, since WOD is not yet announced, they shouldn't have expectation issues on that front yet...).

As an asside to CCP - a little more staggered planning might be worthwhile if you want to avoid these programmer resource starvation issues you keep running into....

As for the Eva thing. Look there's an NDA they CSM members sign. CCP internal affairs is reputed to be rather anal retentive since the T20 incident that caused it's formation. The Larconis incident shows that CCP takes it's NDA seriously with regards to the CSM, and this includes making use of the privileged information granted the CSM members. Due to the amount of FUD and rumor mongering being thrown up around this issue, I can only conclude that something similar happened again. Draw your own conclusions. Personally I think it's a tempest in a teapot (no refference to Teadaze).

Tuesday, July 13, 2010

Back

And I'm back. Did some fuel runs and I must say that ice fuels are highly reasonable at the moment. I will admit that I need to add to my "costing spreadsheet of DOOM™". There is some stuff to fill out, I need to add PI stuff.

Ah PI how you love to frustrate me. As you can see I'm writing this during downtime. I did find out some nice effects due to a fuck up. Did you know that if part of your input hoppers are full but you need to change the schematic. If the next schematic uses some of the same material(s) that are in the input hopper - you don't loose what's in the input hoppers? Nice.

I will potentially find out in about 20min if the downtime material destruction bug kills material in the input hoppers. There is material in the input hoppers but no output cycle expected since not all the hoppers are full. We'll see if all materials survive the downtime. Probably, my personal suspicion is that it's the output cycle that gets killed during downtime.

My next post will concern the latest CSM shenanigans.

Thursday, July 8, 2010

Way to f-ing early...

Hi all, my prediction that my presence online during my vacation would prove "sporadic" has come true. I have however managed to keep going with PI. I have even confirmed a way to AVOID losses. This is however not making me very happy with EVE online. Since it forces me to be up and online between the times of 7:30 and 8:30 am right before I go to work...

Fuck I thought we'd gotten rid of the forced timer stuff with skill queues... But nooooo, CCP has to go and resurect that thing with PI...

Not happy. No losses of materials so long as I make sure all P1->P2, P2->P3, P3/1->P4 production avoids downtime entirely. What a surprise.