I believe Artem only wanted to make sure it is a durable approach, with few future changes
Posts made by cyberblast
-
RE: get attackers details
-
RE: get attackers details
How about a simple array of damage objects?
room.damage = [{dealingPlayer, dealingCreepId, takingPlayer, takingObjectId, damageAmount}]
I understand your concerns regarding a temporary API. But it also wouldn't need to be 100% perfect. I think something like the above would be suitable for most szenarios.
If "my" script can't handle a leaving hostile creep (into an other room out of my sight), it shouldn't be your fault, right? At least it wasn't before this topic. If that damage dealing creep is dead already, why should I care about it, but I still know the player.
The above approach could also simply be extended with further metadata about the attacker, like dealingCreepPos, if that is required, or any other future requirement. Or you can make it even more generic using dealingObjectId and dealingObjectType instead of dealingCreepId, to support nuke or power bank damage...
-
RE: PTR Changelog 2017-07-30
I don't care about the change.
But I wanted to note, that the old documentation indeed contained mode values as well.
There is a cached version of that page here. Well, it's not loking the same anymore, I guess it's lacking some stylesheets...Whatever. Keep up the good work
-
RE: What is considered "abusive api usage"?
I think it is important to mention that this is a game for developers (or aspiring ones). Offering such an API, it must be assumed to be used. And finally this means it becomes/is (an advanced) part of the game.
This would mean there is no such thing like abusive use, except when using exploits or the like.But I’m unsure as well if this is what game developers had in mind when creating the API or if its consequences could be foreseen. It can give very powerful advantages.
So I am with W4rl0ck – maybe we need a discussion about what should and what should not be possible to do with the API in terms of what it offers. What may be too powerful at all. What needs sensitive limitation. Some things may be missing as well.
But I wouldn’t call using powerful implementations of given functions abusive, as it has that “illegal” touch. I’d consider it more like Atavus calls it “unfair”.And in no way should the usage of given functions result in something like "banning" (well, again except regarding exploits, explicit abuse...)
It could also be an option to introduce another currency, to be used for API calls to limit its use. This offers a lot of more options, regarding its implementation, e.g. when and how it increases/reloads or how API call costs are calculated.Like it could refill faster by killing other creeps ^^
Just an idea… I guess there are a lot of possibilities. -
RE: Announcing the Collaborative Coder Coalition
I'm not interested in arguing about this interpretation, only want to note that OCS officially exists since Sept. 10th 2016, founded on github, not the date mentioned above.
But never mind... -
RE: Memory.creeps have no names?
Well, `memCreeps[deadCreep] != Game.creeps[deadCreep]`.
Are you storing a property .name in your creep's memory? If not, then `memCreeps[deadCreep].name === undefined`.
Unsure about your spawn. You may want to log homeSpawnID as well...
-
RE: Better Simulation Errors.
How do you get better error messages then?
You can't. Or well, you may try an other browser.
But what really can improve your bug fixing experience is to use the debugger. Most current browsers offer a debugging tool, commonly you can open it hitting F12 or have a look in the options.
You can also set "break points" by writing
debugger;
within your code.
The browser's debugger will halt at that location and you can step through your code. -
RE: Respawn areas not appearing
There are some novice areas around... Are you waiting for a respawn area to appear in a certain area?
If not, whats wrong with the novice areas?I guess respawn areas will only appear under restricted cicumstances...
-
RE: Creep keeps switching between 2 rooms
There are some “common” cases which may lead to strange movement behavior.
- If you are using a different target pos for moving into the room and are calculating a new path as soon as you enter the room, the new path may be a route through the room where you actually came from (entering through an other entrance). As soon as the creep is leaving again, your other code part may calculate a simple path into the room again (e.g. to pos 25/25), and the procedure repeats.
Setting maxRooms = 1 for path calculation after entering the target room, will force to take a path through that room only. It’s a quick solution for the problem. While it may still be an issue in “certain” scenarios, where you have to take another path into the room at all…
- There may be some scenarios, where path calculation becomes expensive (cpu operations). There is a maxOps parameter, preventing to exceed a threshold (default:2000 (~2cpu)). You will not get a valid path if that threshold is reached.
Increasing that threshold can solve the problem, but may lead to cpu issues if you are not caching paths. But I guess this one is more relevant for inter-room paths…
- If you are using a different target pos for moving into the room and are calculating a new path as soon as you enter the room, the new path may be a route through the room where you actually came from (entering through an other entrance). As soon as the creep is leaving again, your other code part may calculate a simple path into the room again (e.g. to pos 25/25), and the procedure repeats.
-
RE: Make game object properties configurable
Hmm, maybe I found a dirty workaround.
// only for testing purposes. Stores all creep memory in Memory.test instead of Memory.creeps
Memory.test = Memory.test || {};
Creep.prototype = Object.create(Creep.prototype, {
memory: {
get: function () {
return Memory.test[this.name] = Memory.test[this.name] || {};
},
set: function (value) {
Memory.test[this.name] = value;
}
}
});But I'd still prefer to override properties the classical way using Object.defineProperty...
Edit: This approach doesn't seem to work for ticks when node recreates objects. Object instances get created before the new prototype can be defined
Or to get even more dirty, we need to recreate such objects in those ticks...
_.forEach(Game.creeps, creep => {
Game.creeps[creep.name] = new Creep(creep.id);
}); -
Make game object properties configurable
Hi,
I'd like to encourage to flag properties on game objects as configurable.
Like that:Object.defineProperty(Creep.prototype, 'memory', {
configurable:true,
get:function() {This would make it possible to override existing properties.Best example is the code snippet above. We could implement raw memory access or usage of segments for creeps, using the common memory property. Without having to rewrite every creep memory access in the whole code.Currently we are getting an exception when trying to do that, due to the missing configurable flag:TypeError: Cannot redefine property: memory
-
RE: Terms of Service question on 3rd party Account Operation
I'm not getting it why there are so many concerns about OCS.
1. Sharing a codebase
When I started playing screeps, there was this option to publish my code to github. Offered by the screeps application itself. I never used github before. But having a code repository seemed to be a good idea, I'm used to other repos.
But Github is a public place (by default, without paying higher fees). After I loaded my code to Github, I added a little readme file (if anyone would enter) and explored Github, started to add tons of issues (simply to organize my own work, remind me of what I wanted to do). Quite fast the first collaborators showed up. Which was great, of course, and it was the beginning of what we have now.
So, what the hell is the problem with collaborating on a shared codebase? codeBASE!It is intended to alter our code. We provide simplified code injection, lots of parameters etc. Also, there are a lot of different combinable branches.
So each OCS player, in general, is running it's very own code.
There could be some players who are simply running the "default" raw codebase, but that wouldn't make any sense at all in the long run.However. If it wasn't intended to collaborate on code, that github option wouldn't/shouldn't have been there.
2. Current Hive Hunt EventWe may be the largest alliance regarding player count. But most of them are novice or low GCL players (compared to other alliances). Focusing on offending them means focusing on offending new players.
Personally, I don't think this is a good idea.3. 3rd party account operation
I can understand that there are some concers about this idea. This is why Karl did the right thing to discuss this topic openly.
Please try to stick at that topic. -
RE: Spawn created without a name
Did you check display options in the panel on the right side? (show my names -> my spawns)
-
RE: findPath from a border adjacent to a swamp returns an empty path
confirmative.
Unbelievable it's still not fixed
-
RE: Count the number of screeps in room with a certain role?
you need to use a filter. There are some examples in the docs
-
RE: Find closest across rooms
I also posted a custom implementation to calulate room distance here:
But this will only calculate how far away the rooms are to each other (in rooms), not exact pos distance from within two different rooms.
-
RE: Find closest across rooms
Yes, thats closestByPath, surely quite costly.
But he seems to be interested in closestByRange. Thats calculatable using coordinates only - at a medium cost.
-
RE: Spawn.spawning doesn't update until the following tick
Yes that would make some thing easier. Well, other things harder.
This is how the game works.
When you call creep.say multiple times, only the last command is executed.
When you call creep.move multiple times, only the last command is executed.Each of those commands will return OK, as long as the command itself is executable and it will overwrite the command before.
It's the same with the spawn. You may call createCreep multiple times in a loop. It will return OK and overwrite the same command (to create an other creep) you entered before.
If I understand game mechanics right,
all those commands you are entering will be executed AFTER the loop (on client side) has ended. like a post to the server.The immidiate OK response is only a first check against some defined cases, but still no guarantee.
You can use this behaviour to your advantage. This (current) way you can revise a given order within the same loop by simply giving a new one.
So it's not a real 'Problem'. It's simply a kind how things are designed and working. If you know it, you can handle it.
If you need to know wether you already gave an order to create a new creep, you can set spawn.busy = true and check for that value afterwards...