Posts made by Xenofix

I've got the same problem with chrome just recently. But hardware acceleration does work with firefox.

Is anything happening about this issue?

Luckily I know A* very well. But I always thought there are two implementations in screeps. One PathFinder written in C++ by General and a JS JPS version, which is the default in moveTo. The C++ PathFinder could be activated as default for moveTo by PathFinder.use(true), which is deprecated now. Did something change here? Is JPS still the default path finder or is it all PathFinder only now?

Right now overhealing is supported, but damage is applied first, then it's healed. What if it would be swapped, heal first, then damage. You would always know exactly how much to heal to make perfect use of the tough-parts. It's a small change with almost no impact for basic players and high impact for high end players.

Yes, some players already know this one. At another position is a check to set the invaderGoal to 100k if it is 0. It was surely not intended this way, but it also has never been fixed. I would also prefer to choose either invaderGoal *= Math.random() > 0.5 ? 2 : 0; to document clearly that the current behaviour is intended or to change it to invaderGoal = Math.floor(invaderGoal * (Math.random() > 0.5 ? 2 : 0.5 )); and announce that change.

Another problem: JSON.stringify(new RoomPosition(18,49,'E54S19').findPathTo(new RoomPosition(0,44,'E54S19'),{maxOps:100000})) returns [] every second tick and a path every other second tick. It seems to depend on https://screeps.com/a/#!/history/shard2/E54S19?t=20105689 Every time when the creep at 18,49 is in the room, that expression returns [] (tested in the console). The result is, that the creep doesn't move at all.

Detail: The creep calls moveTo with the pathOptions: { visualizePathStyle: { stroke: '#ff0000' }, ignoreCreeps: false, reusePath: 0, maxOps: 100000 }

Thanks Tigga. That's really interesting. It shouldn't fail like this, should it? I guess my problem is solved.

However the problem is still there for other players: I believe that it should always be possible to find a path inside of one room without any extra options. Most newbies rely on it. Maybe someone increases the default maxOps?

Recently I've found some of my creeps unable to reach their targets using moveTo. So I've tried to reproduce at shard2:

JSON.stringify(new RoomPosition(42,19,'E51S18').findPathTo(new RoomPosition(34,12,'E51S18'))) returns: [{"x":41,"y":20,"dx":-1,"dy":1,"direction":6}] another time it returns: [{"x":41,"y":20,"dx":-1,"dy":1,"direction":6},{"x":34,"y":12,"dx":-7,"dy":-8,"direction":8}]

Obviously an unexpected result.

Or this one: JSON.stringify(new RoomPosition(1,44,'E54S19').findPathTo(new RoomPosition(4,11,'E54S19'))) returns [{"x":0,"y":43,"dx":-1,"dy":-1,"direction":8}]

Maybe someone has a look?

(Edited: Nothing passed a wall, but the paths are incomplete)

Bug in Replay here

First Bug: In this replay you can see a room under attack of an invader and the first tower is just finished the next tick. But instead the tower is invisible. However, the invisible tower can be clicked and inspected.

Second Bug: After death of the invader after t=16691971, clicking the back button tick by tick, the invader does not reappear in time.

Third Bug: The creep RangeHarvesterS24_6 who will be refilling the tower is missing in the replay until t=16692000, going backwards from there, you can see the tower and that he was refilling the tower after t=16691968

Maybe market system changes should be discussed in a separate threat. I'm also not a friend of order fees and I'm more a friend of transaction fees, but it would be too offtopic to deepen this topic now.

The current changes show what we'll expect but there is still something missing:

• The regional commodities need different resources, so their production cost varies a lot between different regions. What will be the market prices for these commodities?
• How much ops will OPERATE_FACTORY need for which effect duration? ( I know proposed is 100 ops for 1000 ticks, but they are "still considering other timings too" )

Maybe a non-general-purpose and multiple-resource structure needs capacityFor of e.g. {G:5000,energy:250000}.

capacity, getUsedCapacity() and getFreeCapacity() just makes sense for general-purpose (Storage, ...) and single-resource structures (Tower, Extension, ...). For all structures with mixed resources (powerSpawn, lab, nuke, ...) there needs to be more methods. Maybe getCapacityFor(resourceType), getUsedCapacityFor(resourceType), getFreeCapacityFor(resourceType). These can be implemented for general-purpose Store, too. So that the API for both types is the same.

I also welcome the API change but without deprecation of energy. If energy must be deprecated, then please make sure they are configurable to deactivate any warnings.

I think professional players already know how to overwrite prototypes and have aliases and getters for their needs already. Everyone can already model a unified store, and properties for energy and whatever. Keeping that in mind, the API change is mainly for newbies and those who cannot change prototypes using typescript or have found ugly ways around the inconsistent API which they like to simplify.

As a newbie I did often access creep.energy directly instead of creep.carry.energy. The same for storages, it was just so annoying that I always have to access either carry.energy or store.energy or energy when at first all I care about is just simple energy. The tower has no store, the creep has no energy and no store but carry instead; just not consistent. But I can make it consistent with prototypes. So yes, this change would not really help me, but it will help other newbies. One store for all kind of objects is a great change for the API.

About the database change: Please just choose the most efficient model.

I think every high-level player at 300 cpu cap and those who are looking forward to be one agrees with me that performance is more important than convenience. The database is hidden from us, so I prefer an efficient database model over a simple engine code. I have no idea if your proposed database change will have a positive or negative impact on overall performance, but I just fear that it's a negative impact because it looks more complex than before. In my eyes, the API and the database change are two different changes.

In the end these proposed convenience changes should meet the following requirements:

1. one store for every relevant object to allow a unified way to access energy and resources for convenience.
2. It shall not increase overall tick rate, better decrease it.
3. It shall not significantly decrease the free memory we can use
4. It shall not increase our cpu consumption, better decrease it.

If that's all met, then I believe every single player in the community will be happy about this change.

To me, carry is inconsistent. I would want to have it be named store instead. And a Store-object for general purpose stores is also very welcomed.

But for every other non-general-purpose structure this is only a little nice-to-have feature to simplify withdraw/transfer. If dealing with structure-specific code, I would prefer to access energy and other fields directly. If it's general purpose refiller/robbery code, then I would go for store.

Important to be is that such a change does not have a negative performance impact.

@artch said in Draft: Store prototype API:

• Two separate stores energyStore and ghodiumStore each with its own capacity.

With any other property than store it's not a simple unified API anymore. It has to be one store or no store, but we don't win anything if we wrap number fields in xxxStore-objects.

For developing I must disagree with making the energy and energyCapacity deprecated. If you know the structure you are using, then these fields are the preferred way to access these values. The function of store is just to simplify some code for generic transfer/withdraw.

I like the idea with store-properties returning 0. I think what @TuN9aN0 pointed out is an implementation detail here. I would be against Proxy. Store-objects for Extension or Tower could be using a Prototype which is just a view to the Structure without own memory, which has a property defined in the prototype to be const 0 for each resourceType and energy is a getter to the (hopefully not deprecated) energy field of structure.

I like the idea of a unified Store-object, but only for Structure, Terminal, Creep and PowerCreep. But for 'other structures' it would be nice to have a unified way to access resources.

Almost every structure depends on energy, so it's good to be never undefined. energy===0 is an ugly exception in store, but it's not ugly in 'other structures' like extensions, towers, spawns, etc.

But every player can change the prototypes to get the desired behaviour, so it's not a big deal.

I'm worried that a preinitialized store for 'other structures' just increases memory consumption a lot more, which is already an issue for some players.

@tun9an0 You get me wrong. It will affect me, so I am supporting to get more memory but I'm also against restricting memory more than necessary.

Your argument seems to be: You hit the memory limit with many rooms, so everyone else should also hit the memory limit with less rooms.

I'm against that for obvious reasons.

The memory limit is there because of physical restrictions. That has nothing to do with fairness. Everyone can go intershard to prevent memory problems. That is fair. While I agree that it would be optimal to just have enough cheap memory, after all nowadays 8 GB is nothing...., I assume that we won't get it because of economic reasons.

A new architecture can also solve these problems. But I am still and again very much against a stricter memory cap. The original topic was that memory is not enough for 50+ rooms, it was not that other people's memory is too much.

I think it's not documented that the memory in the UI shows you the sum of every Memory from each shard. But the limit is just shown per shard. But you can have 2 MB per shard. Maybe you still have some old unused Memory in shard 0. CPU is a little different. Maybe shard0 is busy with parsing and seriallization of its Memory, but if you respawned then the script shouldn't run in shard 0, so there should be no cpu cost for the Memory. Except something keeps the script in shard 0 active. Is maybe a creep or a power creep alive there?

No, that's the very wrong direction. Memory should not be another limiting factor. We are not writing code in C++ here where we have full control of the memory. If it's just limited because of limitations of the node servers then that's pity for you but that's not a reason to make memory a limiting factor for all the other players!

Btw. intersharding is more complex than staying in one shard, it also adds more overhead for each shard. The extra memory can be seen as an incentive for intersharding. Maybe you take the challenge? What about this idea: Every player gets 20+GCL*10 cpu without a cap, but can only assign max. 300 cpu to one shard. Would that be incentive enough to go intershard? Then players wouldn't hit the memory limit as they strive for intersharding empires to receive full cpu.

One last thing I would like to know from you Totalschaden: How much code can be executed per tick? Is the first line of your main.js executed? Is the first line in your loop executed? How much memory is used before you initialize any modules at the very first lines of your main.js and what's the memory consumption there? That first line should just be executed once per vm reset and the memory consumption there, before you initialize anything shows how much the engine really takes.

Summary of some memory optimizations:

1. Replace spatial and findCache by Map instead of {}. Likely increases performance, impact on memory consumption is unknown. Easy to implement.
2. Replace elements of spatial: new Array(2500) by Map. Maybe increases performance, impact on memory consumption is unknown. Easy to implement.
3. Lazy creation of spatial and subtracting the cpu cost from user cpu time. Can decrease engine cpu comsumption for bots which don't depend on look. Decreases memory consumption.
4. Compress terrain data from 2500 bytes down to 625 bytes. Decreases memory consumption, may increase cpu cost a little, breaking change for Room.Terrain.getRawBuffer, but that's already documented.
5. Replace pos of all RoomObjects by a property which wraps the new integer field __packedPos. into a RoomPosition. Just like the previous change of RoomPosition this decreases memory consumption a little and adds a little more cpu cost for accessing pos.
6. Write about memory problems with large empires in the documentation, so that players are prepared that intersharding is a 'must have' for large empires.

Every of these points can be done independently. @o4kapuk Which changes would you support?