![]() Tag is an unused argument to differentiate different instances of the same script. Scp ( ls ( "home", "script" ), "home", h ) While ( ! consumeSignal ( ) ) sleep ( 10000 ) Tprint ( "notifying hack-dist.script of a rescheduling condition" ) Įxec ( "touch.script", "home", 1, f ) reschedule our initial weaken/flexihack work. Other scripts can import this and use it to signal us to BITBURNER BLACK HAND HOW TOI'd love to hear criticism, but try to only base it on things I'm likely to already know about the game as someone who has been playing it for two days! :) Pointers on how to write better JS are super helpful, since I've never spent much time in this language before. BITBURNER BLACK HAND CODEPlease see the source code listings for all non-trivial scripts. That said, it's fun to talk about code, even when it's incorrect! I think the work scheduling stuff is pretty useful, but I'm not sure about the prioritization. I'm not sure whether any of this is really optimal, since I'm just playing around with this new system. flexihack keeps server money at about 95% of max. We accomplish this by adding a final, meaningless tag argument to the flexihack.script invocation, and using scriptKill to kill flexihack. To prevent overshooting hack/grow thresholds, we schedule flexihack workers in small batches. It's totally worth the gain in simplicity. 5 GB more RAM than hack and grow separately, but that isn't even an order of magnitude. The signal is just the presence of a certain file on the home computer. if you have bought servers manually, or grown your home server's RAM). You can also run a small script called "signal.script" to manually reschedule (e.g. The signal can come from either the spider, when it gains enough strength to hack a new server, or the watcher, when a server has been sufficiently weakened (or, soon, grown). My current stance is to use one weaken worker per six flexihack workers, which seems to be about as much as is required to keep up with either six grow threads or six hack threads. We also schedule a small group of flexihack workers on any totally weakened target, even if it's not the most optimal one, so that we can at least have some income from hacking early on. ![]() I found the task of balancing grow and hack calls tedious, so my flexihack worker calls grow and hack adaptively (when the available money drops below 95% of max, grow is called). We try to schedule these backwards in the targets list, focusing on the highest growth servers first. The second priority is to schedule "flexihack" workers. It also spawns a small watcher script to notify the distributor when a node like this has been weakened down to the minimum level.Ĭurrently, I only do this preparation step for security level, but I should probably also grow servers before beginning to hack them. If it encounters any that are significanly more secure than their minimum security level, it will dedicate as many threads as possible among all the hosts to weakening that server. It iterates through the targets in the order the spider observed them (i.e. ![]() The first priority is to focus on weakening the weakest pending node. The new worker scheduling algorithm currently has two basic priorities. We'll be able to spend more time thinking about algorithmic improvements if we don't have to do fiddly things like managing state. Cancelling all our existing workers has some minor drawbacks in terms of performance, but what it wins us in simplicity dominates such considerations. Netscripts programming capabilities are some of the most challenging and inconsistent I've ever worked with, so I want to write as little complex code as possible. We cancel all existing workers because it is easier to solve this problem if you don't have to keep track of state. You can define a loop frequency time by passing an additional script argument. Clear the file and paste the code below there.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |