yeah, literally the only advantage to running the legacy VM is to not worry about heap size.

agreed. that isnt consistent with the pre-existing API...

@artch, i fully agree with @Hernanduer when he said "Permanent loss in a game like this is ridiculous," when specifically referring to losing a power level. And to answer you, the games that I've seen that let you respecialize a character do have a cost, but the cost is never a skill point itself... Looks at Mind Wipe Tonic in Ark for an example in a "persistent online game" and Token of Absolution in Diablo II in general... Both of those were wildly successful games and they did have a cost to respec, but neither cost skill points themselves. To draw a parallel, you should make deleting a power creep cost a boatload of Ghodium or any T3 boost. We're not saying a respec shouldnt have a cost, we're saying the cost shouldn't be a power level...

Edit: another comparison: losing a GPL for deleting a power creep would be the equivalent of downgrading someone's GCL for respawning... Both are a horrible idea, and would upset players.

ducky, did you renew your PTR subscription? Iirc, PTR requires you to renew it (for free) every 24 hrs. if you let it lapse, it would definitely stop running your code...

@deft-code @wtfrank you can also manually do what LoAN is doing and look at creep names, structure layouts, and controller signs to determine if it's a bot or not...

@galaxyowl The sim room is available for free. you can run through the tutorials, and even set up custom rooms to see whether you like the game or not. I think that'd count as an infinite "trial period," as it doesnt even require you to log in to access.

@MrFaul @Communication @Davaned if the market were to totally vanish, it'd prob revert to exactly how it was pre-market. ppl in #trading would advertise what they needed to get rid of, and other players would agree to a trade, 10k of 1 mineral for 10k of another, etc

the Market was a game changer, in that you could automate that. getting rid of it would be bad for the game, as it would do exactly the opposite of the entire premise of this game: automate things.

yeah, it'll ask you to pay on the initial spawn-in, but you can ignore it and keep playing with 20 CPU max (if you bought the steam version). Paying for a CPU subscription would give you 20+(GCL*10) CPU, increasing as your GCL increases. If you have not purchased the steam version and dont have a CPU subscription, then yeah, thats an issue.

I've gamed out on paper that 20 second timeslots with 10 second guard periods would make it safe enough. even at 10 sec/tick, it'd allow for 1 tick to request, and a 2nd tick to access/save in each timeslot. the guard period would just be a buffer between accesses. if you really wanted to be paranoid, a 40/20 would be overkill but almost guarantee safety. regardless, it's not like you need any immediate traffic b/t them. if you've got a creep traveling between shards, there is plenty of time between when they initially spawn (you should know that theyre intended to go cross-shard at this point) and reaching the portal.

@systemparadox said in InterShardSegments for each shard rather than a shared one.:

NOTE: It is impossible to guarantee that RawMemory.interShardSegment isn't overwritten by another shard with a slow tick rate. No amount of locking can fix this - the existing API is fundamentally broken (it is impossible to implement locking when your only shared memory is a single asynchronous block).

I would like to say that this is incredibly false. You can use TDMA with large enough time slots and guard periods for each shard to access and save it safely. The synchronization between shards would be based on Date.now() calls, verifying the current time on the system. I doubt that any of the game's servers will be so skewed that it becomes desynced.

That being said, I am looking forward to the new API as this solution seems excessive for what it was intended to be for and adds far more complexity than should be needed.

Edit: spelling is hard...