@maikeru said in Migration from Slack to Discord:

@artch What does it take to be an early adopter?

i hope i'll be corrected if necessary, but they currently seem to be looking for people who can help with getting everything running for now. early adopter might be misleading in that (at least i believe) they're not looking for anything monetary

@gadjung said in Ideas for Season #2:

SnakeMaze:

Every room has maximum of 2 joined rooms thus forming a one-way-in, one-way-out tunnel-like rooms so in order to expand / reach highways / reach SK rooms going through someone else room would be mandatory (either with force or diplomacy)

Oh, i like this. Should be really simple to do and change the general dynamic up a good bit.

An idea that came to mind was a War for the Underworld (was it?) kinda season, where we have to dig out the rooms.
So basically all (or most) of the plain tiles are filled with constructed walls and paths to points of interest have to be dug out by dismantling the walls there. A random number could be 10k hits on them by default and maybe more/less around certain objects (e.g. 100k at range 1 to controllers, 50k around exits etc.), possibly leaving out certain other spots - like around the sources.
Placing one's initial spawn on constructed walls would have to be enabled and successful placement should probably remove walls on the selected tile and the 8 surrounding tiles, but other than that it should be fairly easy to implement.

Not sure if this would be enough for a whole season by itself, but it could be a mechanic at least.

@donatzor said in Ideas for Season #2:

Paint the World

• Each player is assigned a color value.
• Either signing a controller or 'moving onto' a room position 'paints' that room/roomPosition the player's color
• mapVis shows painted rooms/positions
• Player with the most 'pixels' (roomPositions) or rooms painted wins, can score from 'most covered area'.
• Could also 'paint' with energy and have some low eng to build walkable structure as a 'claim' on that room position as well.

I honestly love this idea. It'd be so visually pleasing to have whole rooms just painted in your color alone, but it'd also be a nice take on the gameplay in general, i think. I didnt know until now, but i really want this to be a season theme.

So first things first, i think you've done a lot things right in this season. I havent had the chance to participate, but it's been fun to watch and read along in slack. Initially i thought releasing the mod in advance would be better, but now i think it might be good this way.
That said, i think that the rules should be released further in advance, both so people can decide whether the season is one they would like to participate in, and also to enable speculative coding and deliberations.

I also think there should be a while between seasons. Now it's all new and shiny, so it might not matter too much, but i think further down the line even 2 weeks between seasons might be too little – maybe a month or two? For SWC/BA and other current community hosted competitions it works well because the objective is generally always the same, but with changing rulesets and mechanics i think it'd just lead to people burning out - and it's a lot of work for you devs as well, i reckon. Might work better to keep it somewhat "special" in the long run.

One last thought is kind of a question: Will seasons stay somewhat close to vanilla Screeps in general? I.e. season mechanics wont stack up too much, straying away further and further.. The occasional really far off season might be fun, but if that were to become a standard i could see season becoming more of a top dog / elite playground. Just wanted to ask since i'm curious what your stance on that is.

Now, for actual suggestions:

• I also think that there should be coop modes (obviously not all the time). A few ideas:
• • For team management:
• • • Have the quarter of the world you spawn in decide which team you're on. Each of the 4 teams would then work towards their goal. To make for competition within the teams as well and keep all the big guys from playing on the same team, it could be reflected in a split in the rewards: I.e. one part of the rewards for the rank your team places at and one (more interesting / better) part of the rewards for the rank within the team. Of course players could also sabotage other teams by using portals or just walking over if they're close enough to center roads, expand there, etc.
• • • Smaller teams (e.g. 3-5 players). This would be more difficult to pull off, especially if it should be a fair split between more and less experienced players. It could maybe be figured out using metrics on MMO (restricted to those spawned in for X time if necessary), like power processed, GCL upgraded, creeps killed etc. Alternatively the game mode could be one with relative (in-team) performance measured instead of absolute (global) performance.
• • For goals:
• • • Something like bogden's idea with the artifact could be nice, but it would need to be worked out better. Some problems i can see with it is that:
      a.) It could be cheesed with 1m creeps that get suicided once they've pulled and incurred the 5k fatigue. A possible solution could be a target lock, where it's locked to the same creep for say 100+ creeps after a pull. With a 50m creep you could then pull once every 50 ticks, with the break even point point being a 25m creep in this example. The target lock would have to be modified to reflect whatever you want to be the break even point.
      b.) It would pretty much lock out anyone who isnt on the line to the center. An easy solution for this is to have several artifacts, which would have the nice side effect of it not being a "done and over" kind of situation where a team can finish too quickly.
• A hitman/handyman mode - the system gives each bot targets to either kill or assist:
• • In the case of an assist:
• • • The target gets notified about helper(s)
• • • Points get awarded for contributing to target's economy (construction sites, resources, ...) and clearing their owned and reserved rooms of hostile creeps
• • • Points get awarded to both target and helper(s) for
• • In the case of a kill order:
• • • Target gets notified about attacker(s)
• • • Helper(s) gets notified about attacker(s)
• • • Points get awarded for damaging target's economy (attacking owned/reserved controllers, destroying structures, killing creeps, ...)
• • Rate of attack and assist orders could be dependent on players' performance - higher up means more attacks and less assistance and vice versa
• • Target selection based on performance (weighted random):
• • • High performance players attack high performance players
• • • Low performance players attack low performance players
• • • High performance players assist low performance players
• • • Low performance players assist anyone

Heh, that actually took more time than expected. Might have been thinking about the actual implementations too much already ^^'

@explicit said in Creep not following moveTo() pathing:

move this into the main loop.

var gameSpawns = Game.spawns;
var gameCreeps = Game.creeps;

this will be it, yes. since you have it outside the loop, spawns and creeps only get initialized on global resets and not get updated until the next one. this means that the position data on your creeps is the same as on the global reset tick and they end up thinking they havent moved yet. for spawns this could also have side effects like it throwing not enough energy when it's full or spawning when it's not. since it looks like you're playing in sim, you'll have those resets every 10 seconds, fixing the problem and beginning the ordeal anew

i would also advise against using [0] like this. while certain databases generally return objects in the same order, it is undocumented behavior and not guaranteed. it could also lead to your creeps running back and forth because sources[0] returns a different source suddenly

@artch said in Game.cpu.generatePixel change:

@rayderblitz Unfortunately the community can only help in discussing the ideas rather than implementing them. And we lack developer resources to refactor this mechanic currently. Season and Arena are much more important projects than pixel generation. But we may revisit it some day in the future.

Yeah, that I definitely get. Even if the community provides you with fleshed out code you need to verify it does what you want the way you want etc. Though that makes me wonder why you decided to push this change now, given there is so much going on. You guys are working on Seasonal, Arena and other planned content like the other power creeps.

Personally speaking - though I'm certain I may as well speak on behalf of a majority of the community - I would rather see you invest the time you have into those features than time you already don't have into barely to not at all worked out concepts like this currently discussed change. Sometimes no update for a while is better than a forced one - not that that even is the case with everything coming up.

@artch said in Game.cpu.generatePixel change:

No, there will be no timeout. The limit is on the execution time, not CPU points. You will be able to continue running your script until your min(tick_start_bucket, 500) execution time is over, regardless how much extra CPU points you has spent during the tick. All extra will be simply subtracted from the bucket (which can even go negative).

Ah, I see. No timeout then, but the different intent cost would be doable?

That's one aspect gone of course, but there are still many good ideas remaining. If there is really no changing your mind about any options other than the two you mentioned then I'm still for the (not quite, to be safe) 10k cost. I think it would be a shame though, as both solutions would generally just lead to players ignoring the change, ignoring the system or switching over to a slave shard (which is basically no effort, much less a challenge).

As this change is supposed to be for the players, however, I do think it's important to invest more time into working out an interesting system that will be a worthwhile change and adds to the players' experience - even if it takes a little more effort to work it out. If you give us more information about the criteria, restrictions etc. the community is very much willing to help out and I think you should take advantage of that. "[A] simple elegant solution" is not something easy to work with when the only two currently accepted solutions are not that at all.

@artch said in Game.cpu.generatePixel change:

@rayderblitz Your script has execution limit that is predefined before it starts. It is always min(bucket, 500). No in-game calls can change this hard execution limit.

Basically, there is no such thing as active / bucket CPU as in your description. It is all the same. All CPU used during the tick decreases your bucket. All intents decrease the bucket too. Every tick your bucket increases. And the limit is just min(bucket, 500). I can't seem to get what do you mean by active CPU.

Huh, wasnt "active CPU" a term you introduced?

Anyway, since both normal (processing) cpu and intent cpu seem to work with the same pool (a min of 500 and bucket), it seems to me that it's doable. All an intent does is just add an artificial (predetermined) 0.2 cpu to whatever the checks of that intent cost, right? So if you have 250 in normal cpu doing calculations and 256 in intents in a tick, that should give you a timeout as far as my understanding goes, since you go over the 500 limit. The same would apply to 400 in calculations and 105 in intents, 50 in processing and 450 in intents and so on, did I get that right?

Now, the idea is to have generatePixel clone the behavior of intents and replace the 0.2 cost with a 400 cost. Assuming I understood the above correctly, that should be doable. That way we would effectively (but not factually) reduce the available cpu in this tick to 100. In doing so we would then be able to implement many if not all of the ideas proposed by @NeyaZayah and others.

As for the change you currently have in mind, one thing that I'm not yet sure is clear to me but would be critical is how exactly adding the current tick's cpu to the bucket (since it is used as the base for the cpu calculations) works. Is it calculated before the tick with a min(10000, bucket+cpu) or can you have more than 10k (bucket + cpu) during that tick and afterwards it's min'd out? Depending on what is the case here it might lead to the problems the player isn't to blame for I mentioned above. Then there are also issues like Game.cpu.getUsed() sometimes not accurately reporting the up to date cpu usage I and others have observed (assuming that hasn't been fixed in the meantime, haven't noticed it in a while).

@artch said in Game.cpu.generatePixel change:

Intents do not have the ability to do this:

it'll result in premature script cut-off due to going over the limit

Intents operate on your bucket, not on the "active CPU".

I see, that seems to be a common misconception then. I think for the community to better understand the implications the change entails it is important for this to be cleared up.

So the 0.2 operate on the bucket, does that mean the other cpu used does too? If not, how do those work together for the 500(-ish) cut-off per tick? https://docs.screeps.com/cpu-limit.html only mentions how averaging it out works, but does not mention what to expect when you skirt the edge of this system. According to my current understanding (including these facts you mentioned) the 10k could lead to some problems caused by not the user, but the system.

@artch said in Game.cpu.generatePixel change:

@neyazayah said in Game.cpu.generatePixel change:

MOST IMPORTANTLY: If the player uses more than 100 CPU in a tick while using chargePixel, it'll result in premature script cut-off due to going over the limit.

This can't be done. It's not how CPU limits in Screeps work, an in-game call cannot reduce CPU execution limit within the current tick.

You seem to misunderstand the idea, we already have it in the game - intents. The difference would just be that this intent doesn't cost the usual 0.2, but 400 cpu.

While I agree that accusing you of not caring for the community does not help the discussion, you just disregarding any and all propositions that don't fit the idea of change you already have in mind does not help your image here either. I do think it is unfair for you to just disregard genuinely good ideas by only giving pseudo arguments. And while you say you want a simple and elegant solution, the only ones you even consider are the exact opposite of that - unless you mean simple and elegant for you devs to implement, in which case you're right, but that line of thinking just increases the already abysmal chasm between devs and players.

Since everything else - no matter how good, actually elegant and practicable - seems off the table anyway, my vote is on increasing the generation cost. I do however also think that the whole 10k are not a good idea, as they will just cause too many edge cases - a good portion of which the players will presumably not be able to influence -, so somewhere in the 9.5k-9.9k range should make that workable.