Getting the Ball Rolling

DUST514_WB_CommandPito/
I had planned to enter a blog post over the weekend, but unfortunately didn’t get around to it. But don’t worry, dear readers. It was a busy weekend in-game, and now it’s time to fill you in on everything you missed. We added some people to the corp, set up a new shiny, banged our head against corp role mechanics, took advantage of a fortuitous wormhole, and conducted some diplomacy. Strap in and read on!

Recruitment

I’ve opened Kaede Industries to initial recruitment. Official launch is still some weeks off, but we’re bringing in people right now who’d like to get in on the ground floor and contribute to final corp setup. We have some good people lined up who have either already joined or are seriously considering it.

Fresh recruitment without a starting core of players is difficult. Most people prefer to join established corporations. My plan to counteract that tendency is to bring in a few experienced players who I either already know or who are interested in being part of the startup process for a corp. Combine those members with a handful of local recruits and others who respond to my initial recruitment advert, and I’m hoping that will provide us with enough critical mass. When we officially launch with a full advertising and recruitment blitz, hopefully that will be enough members that those who are skittish about joining a small startup won’t be put off.

A Base in Space

We set up a POS over the weekend. It gives us a place to research and copy blueprints and compress ore for easier transport (and better sell price). I’d like to set up a second and specialize one as a production center and the other as a mining post, but that will wait until we have more members and actually need it (instead of just wanting it).

Speaking of corp members and production, we spent a lot of time this weekend ironing out how to enable members to use the corp’s library of blueprints for their own production. Let me just say, CCP, corp mechanics need work. Not that this is news to anybody, but having just spent a weekend banging my head against awkward mechanics just to accomplish something relatively simple, I have to stress the point.

The first annoyance I ran into–and this isn’t a corp mechanics issue, so much as it is a POS mechanics issue–is that unlike station hangars, you can’t assemble and access a container from within a corp hangar array division. The main annoyance I ran into, which is related to what I was also hoping to do at the POS and couldn’t, has to do with the way the industry interface and corp hangars and their associated permissions interact.

Mechanics Woes

See, I had this idea. All members would be given take access to a particular corp hangar division. But they wouldn’t have take container access. Each member could be set up with a personal station container to which only they have the password. Then, since you can use blueprints with only query access, a separate hangar division that no one has more than query access to can hold the entirety of the corp’s owned blueprints. Then a member could deposit their own store of minerals in their station container, source input materials and output their job to their personal container.

That way, corp members who are budding industrialists can get started producing whatever they have a mind to, without having to invest upfront in the necessary blueprints. The only reason this is necessary in the first place is because the industry interface won’t allow interchangeability between personal and corp hangars. You can’t source input materials from or output jobs to your personal hangar when you’re using a blueprint stored in a corp hangar. So this was my solution to that problem.

Unfortunately, at pretty much every step of the way, I ran into issues. The first problem is that the industry interface won’t let you output a job to a container that requires a password in order to open it. I guess I can understand why that’s the case, but it creates a whole slew of problems in and of itself. To allow jobs to be deposited, I configured our test station container to not require a password to open. This lets jobs output to the container, but then you have to deal with the issue that then anyone can open the container, and since everyone will have take access for the hangar division, they could steal whatever is in someone else’s unlocked container.

To address that issue, I configured the container to lock whatever is placed inside it. That way the industry interface will let you output jobs to the container, and even though anyone can open up someone else’s container and look inside, they wouldn’t have the password to unlock whatever’s inside. This also requires the member to be given the Config Equipment role so that they have the ability to unlock their items. Unfortunately, for some inane reason, when a job is delivered to a container, even though the container is configured to lock whatever is placed inside, the delivered job doesn’t lock.

As I’m writing this, I can’t recall exactly how we addressed that problem. I’ll have to go back and check in-game to see what the solution was. Whatever it was, we figured out the output issue, because from there we moved on to the input issue. Guess what, trouble there too. Even though from everything I gathered from the various wiki descriptions of roles, take access to a hangar should allow you to take items from a container within that hangar (as long as the container configuration itself doesn’t further restrict your access). But the industry interface won’t source input materials from the container.

At first, I thought maybe this was because they were locked. So I tried unlocking the input materials (not that this would be a workable solution, because then anyone could steal those unlocked items) just to test what was going on. That didn’t work either. Even unlocked materials in a container without password restriction on access are restricted, as far as the industry interface was concerned, even though this seems to contradict the way everything is supposed to work.

It turns out that the industry interface will not allow input materials to be taken from a container within a hangar division unless you actually have take container access to that division. Well that defeats the whole purpose, because with take container access, anyone can swipe somebody else’s station container and go their merry way. Finally, I determined that the only way to make it work and get around the ridiculousness of conflicting mechanics was for a member to set their station container as the output location, queue up their job, and then drag and drop whatever the required input materials are into the hangar division itself (which everyone has access to) and immediately submit the job.

Which is horrible, really. A dishonest member could potentially swipe the materials right as you did that, though they’d have to be quick on the mark if the person submitting the job doesn’t dally. It should be fine as a makeshift solution, I guess, but I hate the awkwardness and lack of security of it. The only other solution is to scrap the whole plan and require members to submit production requests to managers instead of doing it themselves, or to request a BPC and do it themselves. But those solutions abandon the whole concept of making it easy for members to do their own industrial work off of the corp’s BP library. So final verdict, pretty much got it to work but it’s so messy. Le sigh.

CCP, maybe in the interim between now and when you get around to fixing corp mechanics, you could just tweak the way the industry interface is coded to make it a little easier to do cool things?

While on the subject of the new industry interface, CCP, love it, but can we get a per manufactured unit input material valuation display in addition to the whole job input material valuation?

Down the Rabbit Hole

So, also this weekend, I got my Orca pilot alt joined up to the corp and completely relocated him to our high-sec island home. On the one hand, this is awesome. It’s a whole lot easier to mine to support the corp’s production when I don’t have to make a round trip of 20+ jumps out to my Orca pilot’s home. Also, this gives the corp a second Orca pilot for higher uptime/availability of mining boosts. On the other hand, one of the main reasons I located my Orca pilot where he was is because there isn’t a source of high-sec nocxium in our region.

Instead of Pyroxeres, our area has Omber. Which is all well and good, I suppose, but it makes it much more difficult to source our needed nocxium. To illustrate the problem, my production queue is currently on hold (and backlogged) because I’ve run out of nocxium, even though I’m flush with other minerals after mining over the weekend. The best solution is probably going to be to mine Omber, compress it, ship it out to a hub, sell it, and use the proceeds to either buy nocxium direct or buy compressed Pyrox to ship back. I really also need to train up Margin Trading so I can put up some buy orders for nocxium (or relevant source ores) to fill in the gaps between logistics runs.

Anyway, I had been worried about bringing my Orca into the island, because I wasn’t looking forward to running it through low-sec. So, imagine my joy when a contact reported that there was a HS>HS wormhole exit one jump from the corp’s home system of Algasienan and it led to a high-sec system that was only four jumps from where my alt was set up. I had still been kind of on the fence about whether to bring my alt in, primarily because of losing convenient mining access to Pyroxeres, even though I was pretty sure I needed to have him in the corp and local, all things considered. But that wormhole pretty much made my decision. It was just too good an opportunity to pass up. So I loaded up my Orca and went down the rabbit hole.

Won’t You Be My Neighbor?

This weekend, I also made some attempts at developing some blue contacts. I was politely rebuffed by one local corp who declined mutual blue status until we had more to offer. Fair enough. There’s not much the corp can offer right now as an ally. We just don’t have the member base yet to offer any enticing incentives to blue us. And that’s fine, once we’re on our feet, diplomacy on that front will be more effective.

I’ve had better luck in developing personal contacts on behalf of the corporation, as opposed to direct corp-to-corp diplomacy. There are a couple of friendly contacts that might develop into good corp contacts if we find ourselves in need of war support or a hot drop one day. And of course there’s always individual members’ contacts.

These are all preliminary steps in the development of future allies. Once the corp is going strong, I think we’ll have a lot to offer anyone who’s been a friend. On that note, get in touch with us and invest in the future.
o7

Advertisements

2 thoughts on “Getting the Ball Rolling

  1. lowrads

    Traditionally, durable corps don’t start ex nihilo. Those that do start this way are often just farming operations, while most that are on the level tend to just peter out.

    It is more common that success forms in a larger crucible. People join a larger organization, discover reliable people in their timezone. If they find they have some leadership aptitude, a nucleus forms. As is the way of things, most organisms go extinct. In EVE, the big ones die to give birth to new offspring. Reminds me of mycelium actually, which can go much of their lifespan reproducing mitotically until conditions get bad, and then undergo meiosis, forming a great many potential new genetic variations in the form of spores, which will then confront their new changed environment.

    These functional units have the potential to grow quickly, as their effectiveness attracts new members quickly. It also puts them in a good bargaining position, allow them to filter newcomers more rigorously, and to bring more to the table if they join up with other organelles.

    Like

    Reply
    1. blackbenetavo Post author

      It’s an interesting biological take on the subject. There’s certainly a high level of attrition for startup corps. That’s what makes it a challenge. It seems to me that most startup corps fail because of a lack of drive, whether this is due to not having goals or a failure in leadership. My experience with being a member of failed small corps is that the CEO loses their enthusiasm before the corp has the necessary impetus to continue without the CEO keeping the ball rolling with their own drive to push things along.

      Like

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s