Group Details Private

[Alliance] The Culture


Member List

  • RE: Partial Boosts

    @stevetrov said in Partial Boosts:

    for most usecases its only slightly better than using recycle.

    That in lies the problem I suppose. A lot of the functionality here overlaps with recycling.

    @poma said in Partial Boosts:

    Honestly it feels like increasing the game complexity for edge cases.

    I'd argue it's not really adding complication to the end user's code. The (undefined) default would still boost the creep's parts for its entire lifespan. The new variable on boosted parts likely wouldn't affect anyone adversely, and I think it unlikely many even use the existing boost variables on the individual creep parts. This is just an idea to give us more flexibility for creativity, especially since the devs are actively trying to increase the costs of boosts. Perhaps when power creeps come out (hahahahahahha) then this idea will offer greater usability since they have the potential to legitimize many more niches for creeps.

    posted in Feature Requests
  • Partial Boosts

    Say you make a huge miner creep that has as much WORK as possible on it. To really cram that WORK in there, you sacrifice the MOVE necessary to move even once a tick on roads. Maybe as little as one move per 3 or 4 ticks. You don't want to boost this miner's move because once it's at the site it's not moving ever again, and that only takes a couple hundred ticks. It really seems like it'd be a waste. But! If we could instead boost a creep temporarily, rather than for the life of the creep, this gets to be a lot more efficient.

    I propose changing boostCreep(creep, # of parts) to boostCreep(creep, # of parts, # of ticks)

    This would also require adding a Creep.body[].boostRemaining variable to track this value.

    boostCreep would now only use a fraction of the boost compound based on either the # of ticks or the creep's remaining life if the parameter is left empty. Energy usage would remain constant to incentivize going for longer boosts as compared to the shorter ones. The scale would work in steps of 50 with 1450-1500 ticks taking 30 compound and 0-50 taking 1 compound.

    posted in Feature Requests
  • RE: WI: spawns had no 50 part limit

    Well sonny, back in my day, we only had THIRTY parts.

    posted in General Discussion
  • RE: Power Creeps update

    @gankdalf Your calculations are wrong.

    8000 energy/300 ticks = ~27 energy/tick 1600 carry/150 tick travel = ~11 energy/tick moving

    You'd need about 2.5 carriers/haulers per single mine at a distance of 75 one way to handle that volume of energy. Take 100 parts off for the two miners at home (who need slightly larger carries to not waste ticks transferring to the link). That leaves you 1100 parts for remote mining. With the numbers above, you can mine 7 sources, assuming a miner with 25 work/1 carry/13 move and a carrier of 32/16.

    I'm also not sure what you're doing with your power creep calculations. 1 PC should handle 3 mines with 100 distance between them. You need 23 levels to reach level 5 EXTEND_SOURCE. I have the highest power in the game at 329 levels and that's still only 14 operators capable of doing that. That gives me the potential to have 42 extended sources (assuming I do nothing else with these guys), giving me a whopping 210000 energy extra per cycle, or 1.05million per generation (roughly 800k/hour)

    So I'll agree with you, I don't really see how this can compare with just getting more rooms.

    posted in News & Announcements
  • RE: Power Creeps update

    I like it! Much better and more intuitive, though like others are saying, it took me a little bit to even see the super super tiny lock icon and it's not obvious when they unlock.

    It's a little annoying we still have to waste levels taking a base management skill before being able to unlock disrupt terminal, though I do like that you require all 5 levels before cap to be used if you want to cap disrupt terminal. Basically says that's all that creep is going to be the best at, as it should be since that power is very strong. Wouldn't mind seeing one more offensive power though which, with this design, should be soooo much easier to draw up and include. That way we don't have to pick something to include on the offensive creeps that will likely never get proper use.

    (Edit: I guess maybe you could give it generate ops? That'd be something for it to do while it's sitting around...)

    Another helpful bit of info would be something to tell you what the potential max level for this creep is. And maybe make the current level (of the creep and the powers) a little bigger? They too are really tiny.

    posted in News & Announcements
  • RE: Power Creeps update

    I've only quickly looked at it this morning, but the new planner seems much simpler and easier to understand than the old. I do agree with @Gankdalf though, the level lock should probably be more visible than the tiny lock icon.

    posted in News & Announcements
  • RE: Flag Bugs.

    @muon said in Flag Bugs.:

    However, you can create flags in a room you have vision and then move them to a new position where you lack vision, although this works very inconsistently as @likeafox has mentioned.

    The problem is very straightforward. The server doesn't simulate rooms with no active objects. When flags were moved from being objects to serialized assets (some time ago...) they no longer forced the server to simulate that room. Creating a construction site, using an observer to observe the room, or using some other mechanism to make the server acknowledge the existence of that room will make the flags in it visible to your code. Until this is done, any actions done on the flag "object" (which is only generated when the server recognizes the room from real objects and deserializes the flag data) will not be processed because, like I just said, the object doesn't really exist.

    This isn't to say that the [Flag NAME] object doesn't exist, just that any modifications done to it are not processed.

    posted in Technical Issues and Bugs
  • RE: More efficient client

    Agreed. If anything performance seems to be worse with the change from SVG graphics. Now when you zoom in inside a room the whole page stutters to a halt in chrome. I'm running an r9 280X and 3570k so those aren't the issue and this wasn't really a problem when SVG was in use.

    The map view is also pretty bad with larger window sizes. Having the window set to 1440p, it takes about 5 seconds to load all the rooms in the map and just panning around is incredibly slow.

    Strangely, firefox seems to have better performance at room level but worse at the map since it freezes the entire window until every room in view is loaded.

    posted in Feature Requests
  • RE: StructureSpawn causing "circular structure" error on JSON.stringify()

    I don't like the idea of having to pay extra CPU, even if its a small amount, for a feature I won't need or use, an option to disable the 'feature' would be nice. The cost would be much larger if you store many keys in Memory vs if you had few keys. I would likely end up implementing my own parsing just to avoid it.

    posted in Technical Issues and Bugs
  • RE: Document Pathfinding tends to always work, but it isn't guaranteed.

    PathFinder is the native library for pathfinding. (iirc) The default cost matrix is the same "cost matrix" used by findPath, meaning all objects that can block a creep are max path cost, swamps are more expensive than plain, and roads are 2x cheaper than road.

    If you're building a custom CostMatrix, it's best to do the whole thing yourself than rely on some interleaving between the default matrix and your custom overlay.

    findPath is the old pathfinder built entirely in js. It's good to get started with but not good if you want efficiency.

    A lot of documentation is scattered, typically the best resource is your own experience. If you want a fast and very controllable path, only use PathFinder.

    posted in Feature Requests

Looks like your connection to Screeps Forum was lost, please wait while we try to reconnect.