Posts made by Rhef

it's not about coding, but placing a construction site and doing basic stuff such as spawning a creep or setting memory

Reposting interesting thoughts from slack:

Snowgoose 9:50 PM

I don’t think the top players need to make any deals, if they could kill you they can just take out your towers, or just heal there way to the collector

Snowgoose 9:52 PM

Once your towers are gone they can probably keep a room down with small creeps

Snowgoose 9:56 PM

Perhaps there is a way to tweak it so that if the room owner keeps the collector ‘awake’ then it is twice as efficient, so that barging in is worse than coop

QzarSTB 11:59 PM

Could force-assign players to a random sector to spawn in to remove premade teams

There was also a great discussion about boosting, especially late game. If the game mode promotes alliances, it's easy to imagine a situation where several players cooperate fully until some point, and after that whoever has the highest score gets a full boost from the others. The alliance that does it will win (ok technically their representative will but I'd still call it a win). Actually, the alliance which starts it earliest, should win...

Do I smell cpu steal on shared VMs?

(unless fully automated) Sometimes you need to help your creeps during vacation, away from your computer. Current screeps web interface almost works, the only two major things that don't are:

• clicking on a field with more than one type of object (creep and road, for example) renders a little tooltip but that tooltip is then not clickable (Android, Chromium)
• in the console you can't type anything because every other letter is "eaten" by something (autocomplete I guess?)

Everything else seems to work fine. A minor bug that I spotted is that you can't switch between rooms with the popup buttons that appear in 4 sides of it, because those appear when you hover above them and on mobile there is no hover, but that's minor since you can just click World and pick a room.

@crazydubc post ^ on feature suggestions. Or we can always do a community-driven initiative, purge-the-outskirts style.

Ok, so listen, you seem to be fighting for an apology, not for yourself, but for some other people. The thing is, most if not all of those people said they don't want an apology and your crusade is really annoying to most of us to the point where it does more harm than good. It doesn't look like it's going to turn around any time soon, too.

Please stop.

Generally there are quite a few interesting game modes in other games, we could even imagine a Battle Royale 10x10 shard (an obvious limit of 100 players), GCL limit 1, no corridor rooms. 100 players start, but in the end (in a voice of Christopher Lambert): there can be only one!

This thing could keep restarting, too, people seem to think it's not repetitive, some matchmaking can be added so that you can have a chance to win and the excitement from being one of the last few is quite a thrill.

I think I would buy into almost any coop, but some team-based thing could also work wonders, though that needs to be balanced to prevent noobs becoming energy farms for the big guys.

Any other mode + limit controllers to level X (say, 3 or 4), but have a lot of CPU (or, haha, lower CPU action cost) and low GCL. With no boosts we'll now have massive zerg-like armies instead of T3 phat quad meta.

Bro, please, let it go. Chill. It's enough. You've made your point.

No need to appologize, this is not kidergarden. It's a discussion between adult men aware of a language barrier between them. I believe mutual respect was there most of the way, we all are trying to make things better. Lets use this as an opportinuty to make things better in the future.

This change was meant to be small and non-invasive, but as it turns out it broke some stuff for some people, and, well, if you break a hobby project of another person, they might understandably get frustrated.

I do believe that this project is, whether it was intended or not, more like a "bank" than it was planned to be. Community expects a higher stability level than the developers provide, we can see it quite frequently now and it's becoming a little bit of a consistent pattern. At the same time, I can fully understand that the devs are afraid of a rigid procedure set involved with a highly stable platform as their efforts to grow the game are already sluggish due to very small team and a massive chunk of codebase (which is a different frustration of the community - but that's a story for another day).

The perspective that seems to be missing though is that those two goals are not mutually exclusive - in fact if this is done well, then the development throughput should increase (slightly in the worst case and quite massively in the best case (if crowdsourcing kicks in)). Devs are not experienced in this area, it seems, so discussing it and showing perspectives to each other seems to be the way to go. I was upset personally when the thread was locked, but once I realized the lock was temporary, it actually made a lot of sense. And it worked. I was wrong.

This thing @Shibdib mentioned is exactly the point of my point "zero" and "1" - some people can usually only see notifications and adjust their codebases over the weekend. Even a small change can break their code, even a change that relies on undocumented behavior (global ticks resets being rare is not documented nor guaranteed, yet all high-end implementations rely on it heavily, so lets not say that changing it drastically without notice would be fine).

Would releasing things on Mondays be so bad? Especially small ones like generatePixel (which was running at 5k for years without problems, change can be rolled back easily, 4 days would not make much difference) and walkable seasonal collectors (not really a gamebreaking flaw, even if it stayed like this for the entire season, I think we could endure). Those should be able to wait a couple of days on a branch.

If you don't want to create a new changelog format, some good people have standardized it already. Thanks to standard there are some opensource tools to parse the changelog styled this way, in case it needs to be reformatted or something.

Finally, if you'd call out to the community asking for someone to volounteer to translate explanations from Russian, someone might actually raise their hand and if language barrier is the problem, then that woud save you a lot of time. Doesn't have to be native, just needs to read Russian and write English well enough.

This one is pretty simple and not really an in-game feature, more of an organizational thing. Requires no coding and virtually no additional effort of any kind from the devs, really.

Recently @artch wrote here that they could use a dedicated community manager, but I think it's not really needed here. Communication about any change that may break a bot, should be:

1. Done upfront, with sufficient time before the message and deployment to adjust the code
2. Done on forums, twitter and slack #announcement
3. Recorded in a public changelog

Now lets talk about the real cost of it.

1. is free - the amount of tweets, forum posts and slack messages will stay exactly the same (though after this the changes will be communicated through official channels before deployment and not two days after)
2. is already happening usually, but it's not reliable. Costs seconds to do, but having a mindset of communicating things through all official channels will make it easier. No need to decide what gets communicated where anymore! Once the text is written, it's a 2 minute procedure to send it everywhere, but it makes sure people see it.
3. Putting the a date and the same message in a file that is published somewhere is also not a whole lot of work and it would let people catch up, if they take a pause from the game for a few months.

Even if it does slow down development of screeps, 2 min per week is worth it. I'm not going to calculate the percentage of development power that will need to be sacrificed to do this well, because this proposition is not adding the full two minutes per week - communication with the community is already on the task list - this thread is about rearranging things slightly, so that people who only play on the weekend and those who don't follow forum threads, are not surprised by their bot stopping due to unexpected changes.

To be fair, it was discussed for a while, but then officially announced less than two days before deployment without proper communication, in the middle of a week.

@artch are you trying to say that the announcement and delivery of this change has been executed perfectly and so nothing shall be improved in the future, if a similar change is going to be deployed one day?

Or maybe there is some room for improvement, we'll remember this situation and use this it as a lesson to improve our ways?

You can see the impact it had on #announcements-any slack, people started hitting global resets a lot when pixel generation ate their entire bucket unexpectedely. You can probably see a clear trend of it on a server-side chart of global resets per tick, if you are monitoring it.

My code never had to worry about bucket being at much less than 4k. I have an expensive room planner figuring out whether some new buildings or roads need to be done, sometimes it runs on the same tick as a creep scheduler - now they can burst through the limit, cause a reset, which will then on the next tick try to run pathfinder-heavy room planners for all rooms (as those set some room properties that are used by other systems to optimize the work for a small/medium/large room), which causes another reset until the server-side mechanism triggers when it sees that I'm skipping multiple ticks in a row, freezes my code completely to fill up the buffer and then brings my code back online in hope that it can plan all rooms before it bleeds out.

I guess it depends on what you mean by "this".

A tweet on Nov 23 announced that a different change (cancelling intents) is going to be deployed at a different date (December 7), requiring different changes to our codes.

A forum post on Dec 8 (20:32 CET) announced the actual change on a forum post (not even a new thread) that would happen on Dec 10. This was then reposted by o4kapuk on slack 3 minutes later. It never actually made it to twitter and the first time a lot of people (those who have not read the forum thread since Dec found out about it was a little over a day before it was actually deployed... if they read slack during the week, that is - because I for instance mostly have time for screeps during weekends and finding out that a breaking change forcing workarounds in my code to not break it was "announced" and deployed during the same week is just making me sad. There was no deadline - the revised design could have been announced through the proper channels with proper vacatio legis and deployed a week later, but it was not.

I'm just pointing out that the communication about that new design of the pixel change was not 100% perfect and I hope that we can all use that opportunity to draw conclusions and learn from it so that it is better in the future.

notification 28 hours before deployment...

Maybe they might change their mind about it? Or is it final? If it is, then why?

Creep.plantPixel() / Creep.hatchPixel() could construct a temporary structure ("egg") that would disappear if it was not sat on by said creep for EGG_TICKS_TO_MATURITY ticks. It would cost EGG_CPU_COST CPU and after the EGG_TICKS_TO_MATURITY ticks, the junior pixel would grow to maturity and would be added to your account. Then you would actually farm pixels! This method of pixel generation should be more effective Game.cpu.generatePixel().

Implementation of this mechanic is not trivial, but it seems to be fairly limited:

1. Add Creep.hatchPixel() which costs EGG_CPU_COST CPU, spawns a little pixel "egg" and flags the creep with a this.hatching = eggId;
2. If the creep moves or dies, delete the egg referenced by creep.eggId.
3. Make an egg expire like tombstone - just stays there until it expires.
4. For ease of implementation and CPU speed lets forget about the creep needing to spend 1 energy per tick to warm it up. The creep will keep it warm with its ~butt~ electromegnetic radiation. Or make hatchEgg() consume 50 energy upfront, whatever.
5. When egg expires through timer, add a pixel to the account of the player

if anyone is worried about pixels the pixel market, the deco price change with adding * 3 to constants is a solution. This change is not about the economy aspect (which can be regulated through effective means like that). The goals this request meets:

• no major coding effort
• somehow related to pixel generation
• no major changes to balance such as changing the CPU limits etc

Additional considerations:

• should be actually fun
• should be really easy to manage for the players who are just starting their adventure with Screeps (Game.cpu.generatePixel() should return to 5000 energy cost)
• should NOT be really easy to manage for the players who are playing for a while now (the effectiveness of Game.cpu.generatePixel() will be a fraction of what you can do with planting the pixels, even if you'd just make your miners farm it, but then you can't afford to do it with all miners or you'll ruin your bucket - you need a mechanism in place to properly assign pixel farming to miners, taking into account the amount of CPU you want to burn on this, the fact that some miners will die from old age and would waste the egg and so on)
• should not be really stupid for balance causing smurf accounts etc (like pixel generation cost getting higher with higher GCL)
• should not cause a massive community outrage, such as a) cancelling all intents in the pixel generation tick b) causing massive trouble to sophisticated code which currently relies on the bucket being non-empty right after a global reset which may happen just after your bucket is reset to zero by the pixel generator

OPTIONAL: allow the creep to move/die while it is on the egg, but that would add the egg to a list that would be checked by the server at the end of the tick. If by the end of the tick there is no new creep on the egg, THEN the egg dies. This lets us change EGG_TICKS_TO_MATURITY to something > CREEP_LIFE_TIME which makes it an even more interesting mechanic as creeps need to either get renewed (which as we know is not so CPU-friendly) or take turns hatching the egg.

Names are far from final, it can be planting sprouts instead of hatching eggs, that doesn't matter much.

C.CONSTRUCTION_COST is not defined for ruins. A new player who spawned in a room filled with ruins has to endure the ugliness of the ruins for a very, very long time, as those ruins decay super slowly. If the construction cost was defined for the ruins, the player could just dismantle them to clean his room up. Currently the only method is to nuke yourself and that's just silly.