@o4kapuk I've noticed that I'm getting a couple of these messages in the console for each room I look at:

[.WebGL-0x223445f49c00] GL_INVALID_OPERATION: Feedback loop formed between Framebuffer and active Texture

This would explain the issues, if screeps is using some sort of render-texture and there's a loop then I can definitely see how it would cause this problem with rendering order.

Additionally, there's another issue that's even more annoying which I'm noticing more and more lately - sometimes some structures are invisible in certain rooms. It only seems to affect complex structures like storage, factory, terminal, labs and nuker, and I've only noticed it for structures under ramparts. I think this is the same bug manifesting in different ways. They momentarily become visible when zooming in/out, but it's just a brief flicker and then they're gone again. As with roads, it seems to persist after navigating to other rooms and across a full refresh and even after closing the browser. Again, an issue with a texture loop would seem to explain this.

I'd be interested in this precisely because I've never done it. Maybe programming with hex tiles is actually easier?

I can't see this happening though. I know arena is going to be very different but this will change literally everything.

I've overridden console.log in browsers before and it does work but I did have to fiddle to get it to work properly as for some reason the this context doesn't work how you would normally expect. Also you can end up with devtools giving you the wrong file/line numbers.

The simplest option would be to make your own global Log object and just use that everywhere instead of using console.log directly. I think this is what most people are doing.

The pixels/decorations have various suffixes like W-00048:NA:A, W-00048:NA:B, etc. Some of them are fairly obvious, but in case anyone else has been wondering what these actually mean here is a full list:

Graffiti (G)

• G:A Normal
• G:B Adjustable brightness and lighting animation.
• G:C (Doesn't exist?)
• G:D Visible on world map.
• G:E Visible on world map. Adjustable brightness and lighting animation.
• G:X Choose your own color. Visible on the world map. Adjustable brightness and lighting animation.

Walls (W)

• W:A Very dark
• W:B Dark
• W:C Light
• W:D Very light
• W:X Adjustable brightness

Floors (F)

• F:A Dark
• F:B Medium
• F:C Light
• F:X Adjustable brightness

Creep decorations (C)

• C:A Normal
• C:B Flipped vertical
• C:X Custom colour
• C:Y Custom colour (flipped vertical)

@CrAzYDubC, I read through the article but it didn't seem like it was doing anything other than changing the weight. Unless it was changing dynamically during the search? Not sure what the implication of that is?

I'm really intrigued to know what you are using this for!

Have you seen the heuristicWeight option?

@robalian said in Season #2 concept:

@systemparadox I don't see how public segments or terminal.send descriptions don't fulfill that role.

Public segments are a pain to work with. You have to constantly poll it instead of receiving an event. There's no way for the other side to know that you got the message unless you setup some sort of acknowledgment system and they also poll you.

If you've got two people closely cooperating you can make it work, but it becomes messy fast if you start to involve more people. Everyone has to parse the entire segment all the time, even if most of it is meant for other people, which is a waste, it's confusing, and there's no privacy - everyone can see everything in the public segment. If you've got a large alliance the best option is to designate some as a "master" to coordinate everything, but then that person has to poll everyone else, and you can only read one at a time so now it's really slow.

It's completely useless for ad-hoc communication. If I want to setup something where my bot will automatically negotiate and provide some service for exchange or fee, I can use controller signs or creep.say to broadcast this and public segments to provide information. The only way someone else can engage with this is to move a creep into my room and use creep.say, which is far too limited.

Descriptions for terminal.send do nothing to help this (as an aside, why can we only add descriptions to terminal.send and not terminal.deal?). Why do I have to waste terminal cooldown time to send a simple message? What if I don't have a terminal, or any resources to send, or I'm busy, you know, using it to actually trade!!? Or you don't have a terminal, or your terminal is full?

Besides, terminal.send isn't even an option in seasonal, as it's disabled between players.

@artch before you do a coop season I think you're really going to need to implement a way for player scripts to send messages to each other directly. The public segment is ok for alliances, but it's no good for more ad-hoc interactions, and creep.say() is far too limited for this purpose.

Edit: "public segment", not interShardSegment!

@artch please can we make this a priority to implement before season 2?

They previously shrank shard0 to speed up the tick rate. I seem to recall some players graciously respawned and a few players helped with an attack effort to clear the others.

The current outer rooms are a lot more dense and I don't think it's a high priority at the moment, but I'm pretty sure that they're deliberately avoiding placing respawn zones in the outer areas.

I am sure that the devs would close blocks of outer rooms if they became empty and eventually shrink the shard again. The inactive rooms and all the portals are a horrible mess and it would be really nice to cleanup shard0 and bring it in line with the other shards.

As soon as I get some decent combat code I'm going on a crusade!