Posts made by Amadox

Is this for steam buyers only or completely free?

...I just had the titular tip of the day and although I thought I know the game well, it don't understand that one. Anyone care to elaborate?

Amazing update. Haven't played in a while but reading that makes me itch for it again

Creep.name and StructureSpawn.name properties can now be accessed by other players.

I'm curious what the reasoning behind this change is. any insight?

I'd love having this as well.

mh..  do not underestimate the cpu usage of require. sure, once the code is up and running, it doesn't matter too much, but I had a codebase with a lot of requires at first, and whenever I updated my code it would result in my entire, usually full bucket being completely drained over the next few ticks. Which is annoying if you're the type of coder who likes to do quick iterations, working on live code.

Since I rewrote my code and started concating with grunt instead of requireing everything, this is not happening anymore.

On the bottom of page 1 of this thread, dissi suggested something I wanna repeat so it doesn't get lost:

I think if we can emit events for the game to display:

Game.rooms['someRoom'].displayIcon(SomeRoomPosition, COLOR_BLUE, COLOR_RED, "path.to.memory") // Maybe public/private? vision required!

A lot of people would be happy. Of course you can still choose to use the flags, but at a cost.

I was wondering for quite some time if this would be a possibility: adding methods that let us influence the game rendering, like drawing an icon at a certain position, a line between 2 positions, etc - just to visualize what our scripts are doing, for debug purposes or whatever. so far I've been using flags for that, but that never felt quite right. i don't need actual persistent objects there, i just want some visuals.

hrm.. I'd rather see a cap on reserved rooms as well than a reduction of source capacity, mostly for CPU reasons...

I just ran into an issue where creep.moveTo would throw an exception; but sadly it was not a real exception, catch would just get an empty object or something like that, which was not helpful at all.

After tinkering around an hour or two I finally figured out that it was apparently caused by some error in the costCallback function I gave it. I'm not quite sure what that error had been, might have been an endless loop or something.

point being: errors in the costCallback function are not very well handled. You might wanna look into that.

Not sure if this is a bug report or a feature request, but anyway: 

Today I noticed that my allies can't access my storage (withdraw) because of a rampart beneath it (good) - even if I set that rampart to public (bad). 

I'd kinda expect it to be public when I set it to public.. not just for movement, but also in regards to any other protections a rampart offers.

I was just gonna post about this and stumbled about this thread in the procedure, and I very much agree to what chris said, especially the two examples he gave which I was gonna post myself (damage identifying the source; construction finished - identifying the new structure). I believe something needs to be done to let us REACT to stuff instead of just ACTING - if events aren't possible, some other solution needs to be found. I believe this could potentially even reduce CPU usage overall and thus reduce server load, since we wouldn't need to actively scan and monitor stuff quite as much as we do now. 

and btw:

> Case 1 - it's really not important which of the enemy creeps attacked you, what is important, is their potential for the attack, which you would have to check for anyway.

yes it is important, if those creeps belong to different players, or to a player and invaders, in terms of diplomacy. For example, I might wanna have code that makes sure that my creeps do not attack a certain player unless he attacks me first - which is basically impossible with the current API, because scripts are completely unable to know who attacked.

you could just add some code to your defenders to ignore invaders that are on  .pos.y === 0 

you are running 10 rooms at 11 CPU total...? oO how!?

I'd guess it just randomly picked the same target twice. Randomness being random and all...

it had been at 2.5 seconds per tick looong before steam release, actually. Also, Screeps used to have that "pay for what you use" system before it was scraped for the current payment model, and it made the game way more approachable and interesting at the same time.

The GCL restrictions aren't the problem though, the problem is just that there's more and more players and the whole server structure doesn't seem to scale that well. that'd be the same no matter how you bill the players.

Think of it this way: Your actions (.move, .upgradeController) do not execute said action right away. They check if they could be executed, and if possible, schedule them to happen after the tick.

so what this code...

creep.moveTo(creep.room.controller);
creep.upgradeController(creep.room.controller);

...is doing is, it checks: can I move? Yes I can, so schedule that. then it checks: can I upgrade? No, I'm not in range -> ERR_NOT_IN_RANGE.

and then, when all is done and the tick ends, the creep actually moves.

another scenario: imagine the creep is just in range of the controller, and you execute these two statements (except moving away from the controller instead of towards it). what happens? it checks: can I move? Yes I can, so schedule that. then it checks: Can i upgrade? yes, because I am in range, so schedule that. And then as the tick ends, it moves, and even though it then is no longer in range of the controller, still upgrades because it was when it was scheduled. that's what it means when the docs say these actions can be combined.

Nothing you do actually happens right when you do it, except as Fou_Lou says, memory changes. It is all just scheduled to happen after the tick.

I actually thought that's how it was gonna work in the first place when I saw the 4x4s.. ^^

if (creep.upgradeController(creep.room.controller) == ERR_NOT_IN_RANGE
            {
                creep.moveTo(creep.room.controller);
                creep.upgradeController(creep.room.controller);
            }

The second upgradeController there is rather pointless and can be safely removed. moveTo, like all other actions, is not executed immedately, but between ticks, thus that second upgradeController call will never return anything else than ERR_NOT_IN_RANGE, because the creep hasn't moved yet. however, in the next iteration, after the creep has moved, the first upgradeController might return something else and thus this condition won't be entered anymore.

if (creep.harvest(source) == ERR_NOT_IN_RANGE)
                {
                    creep.moveTo(source);
                    creep.harvest(source);
                }

same thing here, the second creep.harvest is entirely pointless, you can safely remove it and the script would still do exactly the same it did before.

I'm surprised to even see code managing this task without the use of memory though, but it looks like it might actually work. Will have to play around with that some time.. 

the truth of the matter is that someone can indeed make use of the mechanism you describe to engage in noob bashing.

Yes, they can, but there is absolutely nothing to be gained from this and it isn't even "unfair", since that person has to respawn himself and start from scratch to do so. He has no advantage other than experience, and experience is what his target is gaining as well - very valuable experience at that. You won't get far in this game if you don't learn certain lessons early, or if you take being attacked personal, and blaming the other player.

It does feel like specific restrictions should be placed to limit such potential abuse.

There are. You are in a newbie zone that experienced players can't enter without restarting themselves, and you get walls that defend your room against everything for about a day. A day is more than enough time to spin up some defenses: a tower, some walls, that's very achievable IF you manage to optimize energy gathering to a somewhat useful level and organize the construction. If they do not manage to do that, they won't come far anyway. Instead of being salty about being attacked, people need to realize this is part of the game, and that they can learn from it and be better next time. Nearly everyone of the players that are now considered big went through those lessons.

You seem to be under the impression that getting attacked is a mean thing and getting wrecked is a huge issue. It shouldn't be though. The game is competitive, attacking and defending is a big part of it, especially early on. If you can't manage to have a tower up before the walls go down, you are doing something wrong, and its actually good to learn that as soon as possible.

I have no idea who you are talking about but I do not believe that he or she just respawned (multiple times?) to kill more newbies - there is absolutely nothing gained by that. You don't get points for killing people, it is something you waste time and energy on to achieve some bigger goal. Goals he can't have if he just respawns again. But even if he did: so what. Be the better player. You certainly can.

I would support newbie protection being longer, at least the very first time you spawn, not after respawns though.

As for unwritten rules, there's just my personal list:
* Don't take defeat personal, take it as motivation to do better, and as a learning opportunity
* Don't be too cocky when you win.

Whenever I wiped somebody out or cleared a room, I made sure to send them a friendly message, making sure there's no hard feelings, and giving them hints and tips on what their weakspots were and how to improve or solve them.

But other than that... All is fair in love and war...

creep.moveTo(sourceFlag.pos, {maxRooms: 1})