PTR Changelog 2016-10-08

artch

This post describes changes on the Public Test Realm. The estimated launch date is October 13.

When remainingAmount property of a market order becomes equal to 0, the order now does not get deleted, but becomes inactive instead. You can call extendOrder and reactivate it keeping the same persistent ID. You must call cancelOrder explicitly in order to remove this order from your list.

Tell us what do you think about these upcoming changes in the comments below!

Bleem

If we now have to keep track of our own order IDs in code, it might help if createOrder returned the order ID.

artch

There is no way to get a database ID on the same tick, it is assigned only after the tick is processed.

You don’t need to keep track of your orders, they are all available in Game.market.orders object. You can do something like this:

_.forEach(Game.market.orders, order => {
  if(order.remainingAmount === 0) {
    Game.market.cancelOrder(order.id);
  }
});

Admiral

I don't know your code base, but when I have had this problem in the past, I have had an asynchronous process that fills a pool (a queue) of IDs from the database, and then when the IDs are needed before actually being put into the database, this in-application pool pulls one out and uses it.

I've done this with PostgreSQL sequences, for example. I'm not sufficiently conversant with MongoDB to know if you can do something akin to that.

artch

Don't forget that Screeps is running many isolated script machines concurrently within a parallelized architecture (you can learn more about it here). Each of them would require its own separate pool, that complicates the system a lot and isn't worth it.

Admiral

Yep, I've read the document. I do the aforementioned technique on a cluster of machines. It does result sometimes in IDs not getting used, but IDs are cheap. It's no big deal. The way you propose to do it works fine as far as I'm concerned.