Posts made by Skorp

Please fix this soon, this needs attention ASAP. 

The Spark - Let me just clarify the events that began the war. I will do my best to remain unbiased and just give the facts. 

Bonzai had previously expressed interest in a portion of sector E15S15 before the portal to ThyReapers sector had opened and it was difficult to get to due to Skorp's rooms forming a blockade on the eastern side of E15S15. Skorp cleared out eric in the north of E15S15 planning to develop better defenses where he felt weak, intending to clear out TooAngels rooms shortly after. Bonzai seeing Skorp attack eric felt he was ready for a conflict and cleared out TooAngel's rooms in E15S15 from ThyReapers side of the sector with the intention of giving Jeb room to expand. Skorp saw this as Bonzai following up on his previously expressed desires and took a room in the area Bonzai had cleared in an attempt to strategically secure his borders and protect himself from a direction he felt he was weak from. Bonzai expressed that he had cleared the rooms for Jeb and would attack in the future when Jeb was needing the space. Skorp requested a diplomatic agreement that involved a long term peace that Bonzai did not feel comfortable agreeing to. Skorp felt a threat hanging over his head and The Culture determined it was not acceptable for Bonzai to threaten its members without any recourse. Thus the war began. 

Please correct me or add details or perspective if anyone disagrees. 

I'm sure I'll have more later but mineral stuff has been on my mind: 

• carveDeposit(mineralDeposit)

Allows a power creep to mine a mineral deposit in a room that is not owned. Alternative would be buildExtractor(mineralDeposit) which allows the powerCreep to place an extractor construction site in an un-owned/reserved room and allow other creeps to mine from it.

• buildConverter(roomPosition) 

Someone mentioned in slack the idea to be able to convert ULKZOH minerals to a different one in that group with some conversion loss. This could allow the creep to place a construction site for such a building or to allow the creep to do the conversion itself. 

I agree that harvest and carry should change and I like the proposed ideas. 

In response to Atavus's concern that boosts are not intended to be usable 24/7 I think it really depends on the type of boost. I think everyone agrees 24/7 XGH2O is bad, but for a harvest boost nobody is going to use it unless it is possible 24/7. 

After some discussion in slack I would suggest something like this: 

Economy boosts - usable 24/7
War boosts - harder to use
Upgrade boosts - harder to use

How to make economy boosts more available is a problem I'm not sure how to address. But I do think this is a good direction to aim for. 

I agree with you Steeler, but I don't think your solution is enough to stop the problem. A sector has 72 rooms? If you make the delay a week, it takes a week or more to get a room from 1 to 8 when you're big enough. That means you just need 2 rooms. If you're smaller there is less of a need for more rooms to do the same thing. If you make it a month its a little more difficult but you'd still be able to cycle through 3 or 4 rooms to do the same thing. 

The root controller is way too restrictive if it is the only room that can contribute to GCL. Even if you get a second root at GCL 10. What if you got 2 root controllers to start and then a third at GCL 10 and a fourth at GCL 20? Or something along those lines. 

It seems like the intention is that minerals get balanced while energy gets funneled. What if all rooms had a max energy into the controller which then resulted in a cooldown period. This would allow you to put as much energy into a controller as you wanted at a time but once you hit the limit you see the cooldown and have to move energy to a different controller until the cooldown expires. The cooldown could be different depending on your GCL. Shorter for low GCL, longer for high GCL. You'd have to do some modeling to see what the cooldown should be and how it scales with GCL, otherwise you could just dump energy from storage when a controller is in cooldown and then stock up until its available again. i.e. the cooldown needs to be long enough at higher levels such that storages would overflow if you had a clump of 3 or 4 rooms you filled to 1 million energy. But alternatively, I do feel this would allow people to develop different strategies to deal with it. 

Still think caps should be universal whether they exist or they don't. 

>>> "No, non-root rooms simply don’t contribute to GCL at all, i.e. the limit is zero."

While I think the root controller idea is interesting, this seems very prohibitive to me. I'd be curious to see how the root controller idea works without imposing this restriction on other rooms. This allows the player to choose whether they want to live with the limit or choose to route energy to the root. Otherwise you force everyone to route energy to the root. I assume the root will usually be the newest room your are building up. 

At the very least I'd request that this change would be rolled out in two updates where the first adds the root controller and the second later removes the GCL contribution of other rooms. 

Shouldn't be a surprise that I agree with Bonzai. The increase to the POW constant was what I was trying to suggest. Ultimately having a cap at all is very restrictive. Artem's idea for the root controller is interesting, but if you can change it I would just save up energy in one area until another area has put everything it has into the root and then move the root to another area. Then you want to limit how often you can move the root controller and really its just adding mechanics to be nerfed again. 

This is intended to be a sandbox game and really it should do as much as possible to give players the freedom to choose how they upgrade rather than adding mechanics to force one way of doing things. The goal should be for the player to have options that are balanced rather than everyone doing the same thing. Lastly I don't think the point about having a reason to mine efficiently is being given the weight it should be. My remote mining operations could use a lot of tweaking and I really can't be arsed because there isn't any reason for me to bother right now. You should really be rewarded for how efficient you are by being able to make use of every extra bit you can preserve over your neighbor. 

>>> "Another solution could be introducing a long cooldown period after unclaiming the controller for the same player to claim it again. What do you think about it?"

If you wish to maintain the 15 energy/tick limit another idea might be that if you unclaim a room and then reclaim it that the limit of 15 energy/tick starts from GCL 3 or so. This would mean that if you want to pump up rooms you would be forced to continually seek out new rooms as the ones you've used become consumed. It also provides a consequence of sorts to unclaiming a room. To bonzai's point, gaining levels will very much be a waiting game again as it is now. 

What I like about this approach is that the most successful player who chooses not to be in the waiting game becomes one who is nomadic and is always seeking out new territory. I could see this also increase the need for player vs player interaction since you need to take new territory after you've used up old ones. It also gives a more poignant reason to improve new room build up code. Personally I'd be too lazy to go that direction but I'd be happy to see people get the rewards of putting in that effort. 

I don't think the issue is the structures or terminals. You can easily get around this by just using a room next to a level 8 room. It is a bigger conception of limiting energy into controllers at level 8. As it stands there is two worldviews. 

1. Don't limit controller upgrade in any way. 
2. Limit level 8 rooms to 15 energy/tick. Don't limit lower level rooms. 

I would argue both of these are the same. Either you have a world where people upgrade controllers how they feel they want. Or you have a world where if you want to be successful you force the player to funnel energy to lower level rooms. If the goal is to limit upgrade for larger players, a larger player will eventually implement #2 anyway. Give it six months and everyone in the top 20 will be using this method or they won't remain in the top 20. New players will observe and emulate top players and you have the same problem that was intended to be solved with limiting level 8 rooms. I strongly feel the limit needs to be removed and higher and higher GCL should require a greater jump in control points. This allows newer players to get a foothold, removes the arbitrary limit on level 8 rooms, and slows bigger players down. 

I do like Stybbe's idea. But I do think something needs to change. The 15 energy/tick limit seems very arbitrary, all levels should be limited or no level should be limited. The current limit does not given incentive to optimizing economy, you can mine fairly inefficiently and reach that limit in a room, without a limit there is a lot of incentive to be as efficient as possible. 

Not sure what plans are exactly with Power outside of heroes, but what if power would be required to upgrade buildings? 

Would really love to be able to have more capacity in the terminal. Even just 200k would be much more manageable given the numerous types of minerals to store and move around. 

I'm having the same problem with creep.moveTo when the target is a flag when PathFinder.use(false) is set. These include paths just one room away that were all working fine before the update. 

Not sure if this is intentional, but if you transfer energy from a link to itself it will result in an OK code and you lose 3% energy. I would expect that this should result in an error code other than OK. 

Update: Dissi suggested forcing a reaction with a console command. I did so and then the code started working without any changes to the code. 

TypeError: Cannot read property 'UH' of undefined
at Object.module.exports.loop (main:382:44)
at __mainLoop:1:52

TypeError: Cannot read property 'ZH' of undefined
at Object.module.exports.loop (main:382:44)
at __mainLoop:1:52

Nothing changed in the code from yesterday in today. The error line (382) is the line that runs the lab reactions. 

depositOne.runReaction(reactorOne, reactorTwo);

Can place construction site for a lab on top of a terminal. Have not tried with other structures. 

@Amadox - I'd personally agree that ramparts should start a little higher if they are going to decay so quickly, but its also not too hard to prioritize repairing ramparts with less than 1000 hits over other things, if you're building a new rampart there isn't really a reason you need to repair anything else first. I use something like this: 

var upgradeTarget = creep.pos.findClosestByRange(FIND_STRUCTURES, {
 filter: function(object) {
   return object.structureType == STRUCTURE_RAMPART && object.hits < 1000;
 }
});

Granted with a lot of structures in a room this can be somewhat CPU intensive so I only search for them when a flag is set in the room to indicate that new ramparts or walls have been built and I remove the flag when the search comes up with nothing left. I also have the same creep building and repairing so there isn't downtime between the built rampart and the repairing of it. Unless I'm building 100 new ramparts.. maybe one day soon. I'm sure there's probably better ways to do it. 

So I got an email saying the following: 

"Your CPU subscription has been expired, and your script is STOPPED. Please renew the subscription to resume execution."

First, I thought I was given 20 extra days when I purchased my first month due to a promotion. Second, I tried to pay using a credit card and then I got the following error message. 

"3026: The subscription was successfully created before and is being used now"

Lastly, as far as I can tell my scripts are still running on the server. Was this an email from the PTR? Am I missing something or do I need to do anything?

Are you attacking the enemies in the room with enemies? Usually when something like this happens to me it is because when you enter the new room you're moving into, something in your code triggers such that you don't get a move command when you're on pos.x = 0 or 49, or pos.y = 0 or 49 and the creep just rubberbands between the two rooms. Old room = move to new room. New room = do something so can't move off edge tiles. I usually have code to not do anything in the new room until I'm off the edge tiles. 

I basically did the simulation with waves of attackers until I was able to make it to level 6 or so, I didn't really pump the controller at all in simulation but it would have been nice if I had a little of that working. That said, it wouldn't have been a problem if I started in the world a little earlier because you have some time before the walls come down around your room. Just expect if you start in the world that you'll want code to build up walls and pump up the controller. If you start in a room with some buffer most likely you won't be disturbed till you have a tower. Just make sure you're working toward that (i.e. controller level 3).