Posts made by SystemParadox

This has been bugging me all this time so thank you!

I wonder why they're doing that.

I've seen this many times over the years but I have never managed to find out what causes it. A reinstall usually seems to fix it, but I wish I knew what the problem was.

Once I got it working on my current server it hasn't done it again since so maybe it is a bad install issue.

@o4kapuk @artch We're now on season 3 and this still hasn't been addressed. I know you're busy but this should be a simple change and I really think it needs to be fixed as a priority.

This appears to be broken still.

Some of your creeps seem to be sitting around in the portal room until they die: https://screeps.com/a/#!/history/shard2/W20N10?t=32797633

Wow that's a lot of portals in one path!

If some of the shards aren't normally ticking then you may well be running into the issue where the creep arrives but it takes ages for your code to wake up and start ticking.

One trick you might find helpful to avoid this is to add a construction site for a road into a wall (so noone can step on it and destroy it) in the portal rooms. This is enough to keep that shard ticking.

How do you know your creep names are unique? If your naming is at all based on checking what you already have you might find that it's creating creeps with a name that's already been used on a creep that's gone to another shard.

Just seen the issue here https://screeps.com/season/#!/history/shardSeason/E28S19?t=2407645, the terminal became invisible when the rampart over the tower was destroyed. If you go back a bit in the history you'll see that one of the towers also went invisible. It seems to change when ramparts are removed.

Only happened in Chrome on Linux. Firefox on Linux was fine, as was the steam client. Chrome on Windows was fine, even on the same machine. Issue persists after a restart.

I will try and find a test case on the main server to see if anyone else sees the issue at the same time.

@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!

One strange thing I noticed is the roads seem to be highlighted. I initially thought it was just because of alpha blending but that doesn't seem to fit as it's exactly the same colour across the different parts of the creep.

I'd argue that incentive is still there, it's just a little harder to make use of.

All you really have to do is make sure that you don't exceed your CPU allocation on the tick you run generatePixel or the following tick where you've got hardly any bucket.

Most optimisations tend to be done by remaining bucket amount, which mostly works ok if like most new players you're well under your CPU allocation on almost every tick. To completely avoid resetting yourself you'll need to do a bit of work to check against Game.cpu.getUsed() as well.

Cleanse the outer rooms!