Posts made by Voronoi

Seems to be the portal model. Creep never goes to position 9.

Hi there,

I didn't find any good description of exactly how inter room movements occurs. This would be a great addition to the documentation, as it is the source of a lot of WTF

In general I think we need to know if the "portal" at the room edges and those in the wild acts as "Portal" or "Teleporter".

Here is how I would describe the differences:

Goal: crossing from room A to room B
assuming rooms of size 10 and height 1.
room A [0123456789][0123456789] room B

Inter room coordinates: 89][01
89 are right coordinates of room A
01 are left coordinates of room B
9 and 0 are inter room "portals"

C is a creep
x is a portal
. is an empty cell

T.0 means tick 0
C->9 means Creep intend to move to pos 9

Portal scenario

Move between rooms is immediate.
If you attempt to move on a portal and your intent is satisfied, you appear on the other side on the next tick

T.0     T.1     T.2

8901

Cxx.    .xC.    .xxC 
C->9    C->1    at 1

T.0 (C)reep intend to move to pos 9
T.1 (C)reep moved to pos 9 but appears immediately on pos 0 (and was never on pos 9). It intend to move to pos 1.
T.2 (C)reep moved to pos 1

Teleporter scenario

Move between rooms takes a tick If you are on a portal at the end of tick then you will appear on the other side on the next tick

T.0     T.1     T.2    T.3

8901

Cxx.    .Cx.    .xC.   .xxC  
C->9    idle    C->1    at 1

T.0 (C)reep intend to move to pos 9
T.1 (C)reep moved to pos 9 and wait to be teleported to pos 0
T.2 (C)reep was teleported to pos 0 and intend to move to pos 1
T.3 (C)reep moved to pos 1

So which is it ?

And is the inter room behavior the same than for portals ? Have a great day.

Same here with Linux Mint 18.1

IsActive() on Link structure return True while the structure is not active.
(Due to room level degradation)

In room E41S48
Link 5825b46c995ae8292897b33f (top left)
is inactive (marked in red)
as my room goes from level 8 to level 7.

But calling the function isActive() on the link return true.
Expected behavior: return false.

This makes it very hard to properly handle the situation.

---
Is there any other way to discriminate that a structure is not active than calling isActive() ?

Here below is the documentation for the method :

Hi Artem,
I have an infrastructure question.
Can you confirm or infirm this assumption:
* Every player code run in isolation as separated process (V8 instances)
This means that the garbage collection we have to face is almost completely due to our own codebase (And a bit due to the API codebase.) since every process have they own GC tracker. 

If true, then it is worth to try to keep the garbage to a minimum (object pooling etc).
If not, then there is a possibility to be very mean to other players by doing nasty stuff like allocating huge memory buffer at the end of the tick, which will most probably triggers Garbage Collection call for ANOTHER player while having a very small cpu overhead to our tick turn.

Thanks Artem, I'll look into this further.
The extra time on the first loads could be due to V8 hidden classes compilation.
I'll try to roll out a consistent test, if this is the case, there is nothing you could do about it I guess.
But WE could do something about it, consistency pay off in javascript

Placing an extension manually using the web interface reduce the amount of available extension by more than the number of extension placed.

Steps to reproduce:
(using chrome browser)
* select build structure (the box on the top bar)
* select extension (assume you have 10 available)
* click on the map to add an extension
* click on the map to add a second extension
--> Expected result: 8 more extensions available
--> Result: 5 extensions available (or less)

Reloading the page fixes the available extension count
But placing extensions stay bugged.

So you have to refresh 3 to 4 times to be able to place 10 extensions manually.

You rocks !
Thank you !

Errata:
If I profile the memory explicitely:

var log = console.log;
var stringified = JSON.stringify(Memory);
var startCpu = Game.cpu.getUsed();

var memory = null;
var count = 10;

for (var i = 0; i < count; i++) {
memory = JSON.parse(stringified);
}
var endCpu = Game.cpu.getUsed();
log('CPU spent on Memory parsing:', + (endCpu - startCpu) / count);


I have a consistent time which is half the time of my initial parse triggered when accessing memory for the first time.
This means, 2.3 vs 4.6 on average.

@artem Could you check that you don't parse the memory twice for some reason ?
Sounds silly but ... 

@dissi mine is relatively steady.
Doesn't look to be a db fetch issue.
Peaks on my case are pbly GC related or process slowdown/switch server side.

I have the same issue.
I don't understand why FIND_MY_CREEPS does not return creeps in spawning.
Same for FIND_CREEPS which I supposed would be exhaustive, turns out it is not.

ATM I iterate over all creeps in Game.creeps and split them by room just because this is the only way I found to retrieve ALL my creeps in the room.
imho the default behavior should be complete and if you don't want creep in spawning, then you can filter them.

If this is the intended design, maybe you should update the documentation... 

For clarity, here is a picture of how the "range" would pan out.
(dark squares are rooms that execute deals)
All the rooms at energy transfer range <=3 are colored.
With 3 scenario, center (red), edge center(blue) and corners (green).
Consider that at the moment, the corner player only has "access" to the upper left green square.
and the edge player to the upper blue rectangle.
While the red players has access to the whole center square.

I'd like that the distance computation between two rooms when computing the energy cost for a transaction on the market be continuous on the edges of the map.
That mean that the top of the map is considered close to the bottom. And  the left edge considered close to the right edge.

Assuming
* room1, room2: the room positions (in continuous world space)
* W = world width (now 120)
* H = world height (now 120

The distance is ATM computed like this :
dx = abs(room1.x - room2.x)
dy = abs(room1.x - room2.x)

distance = Max( dx, dy)

Proposal is:
distance = Max ( min(dx, W-dx), min (dy, H-dy))

The main effect of this change is that every player regardless of where they spawned the first time will have access to a similar amount of rooms (with a logarithmic fee cost).
At the moment the world is a square of 120x120.
If you are on the center the biggest energy fee you pay is for a distance of 60. If you are on a corner or an edge it is 120.

Assuming that it is not economically viable to trade up to a distance of 50.
(this value is arbitrary, you could make it bigger it doesn't change the principle).

If you are on the center you have access to 100 * 100 rooms = 10000.
If you are on the corner you have access to 50 * 50 = 2500.

This will not change the intended regional effect of trading, as it will stay beneficial to trade with your close neighbors due to the logarithmic cost of the energy fee.
Hell, you could even increase the fee to recenter the markets to smaller regions if you think they are too broad

Errata:
Players at the center of the map will keep a competitive advantage because they have access to more developed players and markets and don't have in their radius inaccessible block rooms. (block which already exist on the edge of the map but are not accessible yet to spawn into). 
Which is a fair advantage imho, it is good to keep the center more desirable, but not to extents it is now.

ho well, this is also the reason of my post about notification cost.

Dear awesome Devs,

I'd like you to rethink the 0.2 CPU of the notifyWhenAttacked function.
Since it is enabled by default, the only reason to use it is to disable notifications...
Which reduce the cpu pressure on the server.

For example, I disable them on my miner and fighters in keepers room since they create notification bloat/spam.

I don't think we should have to 'pay' in CPU term for this.
Also I don't consider these notification to be part of the Game state in term of gameplay, but this is opinionated so not very important.

Potentials proposal:
* disable it by default and make it cost 0.2 to ACTIVATE it.
* make the value as an optional arguments in Spawn.createCreep function.
* Remove the (0.2) CPU cost of this function call altogether.

PS: not sure if it should be in technical issues or feature request.
PS2: the amortized CPU cost of the call is very low, I know it is a bit nitpicking.

I guess the issue is either fat dependencies or too much data in code form.
Pbly Lodash is the issue here. (being non gzipped)

If you need to use a newer version than the one provided, couldn't a simple upgrade of the lodash version do the trick ?
Artem would that be possible ?

Also, if you are really crafty (and desperate for lodash sugar) it is possible to compress lodash in a js string in a static file and then uncompress and eval it at runtime.
e.g. with something like that
https://github.com/pieroxy/lz-string/blob/master/libs/lz-string.min.js

To be honest a big part of what I like in this game are the constraints.
CPU, Memory, number of constructions site etc...
Each of them is a challenge and raise the 'fun' part of the game, at least for me.
1MB of source code of is a ridiculously high limit in that regard :s
If anything I thing it is too high.
Unless you store data in your code. (e.g. store static part of the map, or Cost Matrix preset for the rooms around your empire)

What you do with your MB of code is up to you.
If you choose to throw half of that to load external code, this is a decision you made, I don't see why this would require the limit to change.

In the spirit of:
When you hit the CPU limit, the anwser is: optimize your code and/or change your logic.
And not, ask the dev to increase the CPU limit.

My 2 cents.

"1000 flags per GCL"
@ All. Also take into consideration that from a scaling perspective we should assume everyone use all that is at its disposal.
(If not, it will only be an issue later)

So we are talking about 15 to 30 millions flags to serialize deserialize every tick.
This looks like a lot...

@N00bish  this is a highly abusable mechanism..
This would be close to unlimited memory for everyone

Here is middle ground proposal.

* Truncate the flag name at 50 characters in 2 weeks.
Even if there are abuse from the consensual pov, nobody is abusing anything as long as they stick to the API.
* extend the memory by 500 kb or better imho make it scale with gcl with e.g.  500kb +[100 kb per GCL.
in 2/3 more weeks. (so 4/5 from now)
But provide us with an API entry point that we can surcharge to optimize the flags implementation.
(And make it per room, not global so we can factor in the room name :p)

Wall of text incoming.

As I previously stated I consider flags(as it is now) to be a mechanism that can be abused at the expense of the whole community.
So it MUST be nerfed one way or another. E.G. my previous example, a 'free' 10 cpu user could fuck the tick time for everyone by covering ALL the rooms in the world with flags.

This being said, here is a couple of suggestions:
* About PTR: It should be possible for anybody to test code in PTR.
Proposal: Anybody should be able to register for a session of 12 hours on ptr every 48 hours. (Reduce that time if you fear overcrowding)
On activation the state of all the game objects of the player should be copied on ptr.
(structures, creeps, flags, memory)
Two players could then also test combat strategy there, but with a slower pace.

* About flags:
a) Make it part of the Memory with a default implementation that we can surcharge so we benefits from our own optimization.
And make the memory scale with GCL with an higher limit.
something like 500k + 100k per GCL.

b) Alternatively, keep it free but make the amount of flags scale per GCL.
E.G. 100 or 200 per GCL.

c) Even better replace that with an api for graphical hint with a default implementation that we can surcharge
but then make the memory scaling proposed in a)
(as proposed by Dissi)

* Optimize your engine.
This may look pedantic, but if your engine is written mostly in js and with a programming scheme similar to what we can see by looking at prototypes in the console there are a LOT of potential for optimization.
I would be in favor of replacing big parts of the server side logic by native code, but hell, even in js, there a lot of hanging fruits.
Don't get me wrong, I don't intend to criticize nor underestimate your coding capabilities.
I feel like you are hitting some scaling wall and just didn't have time to do this.
And my theory is that some of the current rebalance are also CPU sink of some sort in order to help with that.
Hopefully the OSS will allow us to help you with that. Assuming you'll reintegrate PR in the main code

@tedivm
Please cool down a bit, you are an important part of the community, and your opinion matter a lot to us. (at least to me)
It doesn't help to go all UPPERCASE on the devs, I completely understand that in your particular position (and N00bish and Anisoptera) this is a VERY hard pill to swallow, but consider that as the devs already proved, the proposal on PTR is usually not definitive.
So stay constructive, we will find a way

(PS: If you leave, can I use your avatar ?)