Changelog 2018-03-05
-
@artch i have no clue what that ID went to. Whenever I tried a
Game.getObjectById()
for it, it returnedundefined
instead ofnull
, but it seems to have resolved itself. whatever yall did, thank you
-
@warinternal said in Changelog 2018-03-05:
The default object serializer that use to return something like
[Object object]
is now printingundefined
, which is very confusing.a hack around that would be defining
Object.prototype.toString = ()=>"[Object object]";
. Just one option to get it working again if your code was expecting that...
-
Update:
-
Fixed an issue with
undefined
console output. -
"Reset storms" now shouldn't affect isolated-vm users in any way, neither by resetting their VMs nor by giving bonus CPU.
-
Heap memory limit now varies depending on the shard's terrain shared buffer size:
- shard0 - 355 MB
- shard1 - 292 MB
- shard2 - 292 MB
New npm packages published:
2.13.0
and3.0.0-beta.5
.
-
-
@artch said in Changelog 2018-03-05:
@SteveTrov @Kenji Game.market.orders should be fixed now, thanks for reporting.
I can confirm this issue appears to be fixed for me.
-
This may help some folks. Seems to be a common question on Slack asking how to figure out actual usage.
if (typeof Game.cpu.getHeapStatistics === "function") { let heapStats = Game.cpu.getHeapStatistics(); let heapPercent = Math.round(((heapStats.total_heap_size + heapStats.externally_allocated_size) / heapStats.heap_size_limit) * 100); console.log("heap usage:",Math.round((heapStats.total_heap_size)/1048576),"MB +",Math.round((heapStats.externally_allocated_size)/1048576),"MB of",Math.round(heapStats.heap_size_limit/1048576),"MB (",heapPercent,"% )"); }
-
I think I have found a few bugs relating to tombstones and caravans
- The creep lost stats now seem to include a lot of creeps that have died of natural causes. IIRC these stats used to show creeps lost in combat. From looking at replays for the last hour I have confirmed that the stats include some creeps that timed out.
- The caravan haulers now drop tombstones instead of containers and those tombstones have a much shorter TTL than the containers did. Was this intended?
- Caravans are still getting stuck https://screeps.com/a/#!/history/shard1/E0S20?t=6618000
And one Iso-vm bug
- At 30 minutes past the hour or just after I get
Script execution timed out ungracefully, restarting virtual machine
errors nearly every hour I am on ISO-vm.
Despite these issues, the new release is looking really good.
-
Update about caravans and tombstones.
https://screeps.com/a/#!/history/shard1/W10S19?t=6637767
Caravans drop containers when damaged, but when the creeps are destroyed their loot goes into a tombstone that has ttl of 250 opposed to the containers 5000 ticks.
-
Game.market.orders-limits seem to be broken. There are much too much active orders. Dont know if you already fixed the boundary, I haven`t tried it myself. But currently Im looking at: Object.keys(Game.market.getAllOrders({roomName:"E9S69"})).length => 142 on Shard0 (and that is not the only broken limit)
No wonder Game.market.getAllOrders based trading code has become so slow.
Edit: just one hour later: Object.keys(Game.market.getAllOrders()).length dropped from 4800 to 771 (on Shard0).. what gives a much better trading performance.. this gives a much better trading code performance..
-
So it turns out I had 4027 open orders on shard0, which seems to have been the primary contributor to slow
getAllOrders
performance. I've deleted them all and things seem to have returned to normal. There must've been a period of about 600 ticks whereGame.market.orders
was empty for both my code and the server, which both prompted and allowed me to create so many orders.
-
just wanted to thank you guys for work on the ivm it's really working great and a huge lift of the experience.
I was (particulary since the node 8 update) literally getting hundrets of hard reset mails every day... and they are all gone now. I only had a very small percentage of those high cpu ticks, and they are all gone with ivm.
I switched to lvm this morning... and cpu usage looks really smooth now... I hope it also has a nice advantage on backend site for you guys.
-
I also want to say: Thank you! CPU usage is much more stable and predictable, hopefully this is also helping server side too. Looking forward to being able to push it up to S+ once it leaves beta
-
The creep lost stats now seem to include a lot of creeps that have died of natural causes. IIRC these stats used to show creeps lost in combat. From looking at replays for the last hour I have confirmed that the stats include some creeps that timed out.
Fixed in screeps/engine#d5657f.
The caravan haulers now drop tombstones instead of containers and those tombstones have a much shorter TTL than the containers did. Was this intended?
Now their tombstones will have 5000 TTL, and their body will have only 1
CARRY
part as the last one, so no partial drop is possible. The capacity is hard coded to 5000 (yes, this single body part is boosted a lot :)).
-
@ags131 @W4rl0ck Good to know! You also may say thanks to Marcel by starring his repo on GitHub.
-
@artch said in Changelog 2018-03-05:
Now their tombstones will have 5000 TTL, and their body will have only 1 CARRY part as the last one, so no partial drop is possible. The capacity is hard coded to 5000 (yes, this single body part is boosted a lot ).
@artch unfortunately this doesn't seem to be working as intended, as soon as I hit the hauler it dropped most of the resources it was carrying into a pile on the ground (not container)
https://screeps.com/a/#!/history/shard2/E20S10?t=4352964
I can confirm that creeps lost stats appear to be correct.
-
@stevetrov This should not happen again, please report if it does.
-
Ok, will do, thanks for the speedy response.