Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

BARABAS (universal base and ship script)

Discussion in 'Programming Released Codes' started by Burillo, Feb 22, 2015.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. Smokey McDoob Trainee Engineer

    Messages:
    38
    Well, welcome back!

    Yeah, I'm glad your script has worked as well as it has. I've already acquired and tested Wico's version, and it works like 1.3 did.

    Since you're here, I'd like to point out a couple of issues I've had. One: It seems like my refinery is not switching ores after finishing a 1k bundle. For example, I had some Uranium, Iron, and other ores loaded, with the expected 1k portions, and the remainder after that. But, when the Uranium portion was used up, the refinery kept mining more Uranium, instead of switching to Iron. [EDIT: Manually dragging another ore to the front of the queue does cause the refinery to switch.] This also applies to Arc Furnaces. Not sure if this is a script issue, or a game engine issue, but I thought I'd mention it.

    Also, the script flat-out refused to work with the 'Large Refinery Mod' (http://steamcommunity.com/sharedfiles/filedetails/?id=351103963). The script works, but never loads the refinery. This mod hasn't been updated for DX11, so I no longer use it.
     
  2. Wicorel Senior Engineer

    Messages:
    1,243
    FYI: I had a bug pop up a little bit ago that I modified in my copy of 1.3.

    Here's the changed code:
    Code:
    			Decimal cur_vol = (Decimal) dst_inv.CurrentVolume * 1000M;
    			src_inv.TransferItemTo(dst_inv, i, null, true, (VRage.MyFixedPoint) 1);
    			Decimal new_vol = (Decimal) dst_inv.CurrentVolume * 1000M;
    			Decimal item_vol = new_vol - cur_vol;
    			if(item_vol==0)
    			{
    Echo("Error transfering from: " + blocks[maxIndex].CustomName );
    Echo("Check conveyors for missing/damage and\nblock ownership");
    				continue;
    			}
    			int target_amount = (int) Math.Floor(target_volume / item_vol);
    
    It was getting a divide by zero crash that I traced to the last line above. I put in the checks.

    It was caused by a drill that I had not properly conveyored back up and it had no connection.
    BARABAS couldn't transfer any ore from the drill, and it got the divide by zero.

    It is likely that the other routines that do similar things will have the same problem.
     
  3. Burillo Junior Engineer

    Messages:
    648
    Hi all

    I'm currently updating the script to the new realities (a lot has happened since i was away from the game). I don't expect to get a lot of work done right away, but i've fixed compile errors and a few other issues, this will all appear in BARABAS-next.

    @Smokey McDoob, regarding your issues, depending on your situation, this might have been intentional. when BARABAS thinks you are low on Uranium (that is, your uranium stock is under thresholds), it will prioritize it, regardless of whatever else you have (because Uranium is considered most important element). Does that sound plausible? Or was it indeed a bug? regarding mods, i explicitly do not support them as it's way too much effort to make allowances for that.

    @Wicorel, thanks, i'll look into that.

    Does anyone experience any unusual material shortages? I.e. does BARABAS tell you e.g. "you're OK for Nickel" while actually you constantly running out? there was a balancing patch not too long ago that rebalanced lots of components to use or not use this or that element, and likely had thrown off my "reasonable stock" estimations which are mainly obtained empirically. i will of course play on survival and see if anything needs tweaking, but maybe you guys already have some ideas on what to change.

    I'm also not yet sure what to do with the new Hydrogen thingies. technically, this could count as fuel, but i'm not sure how would that work and, more importantly, what would i need to support a hybrid uranium/hydrogen ship. or maybe it's an opportunity to generalize on battery/uranium/hydrogen as generic "fuel" concept and finally support ships with various sources of power... any ideas on that front?
     
  4. Smokey McDoob Trainee Engineer

    Messages:
    38
    Got a lot of work to do, now, buddy, what with the Planets update :)

    I'd have to re-test to be sure it wasn't a Uranium shortage situation, because I don't remember. But the problem also affects arc furnaces, which obviously can't process Uranium. When the first 1k unit is done, the system continues processing the same ore, if there's any in the cargo. If I manually remove the ore, it switches.

    It seems it could be a bug with refineries/furnaces rather than with your code. I'll get you better details when I have a chance to re-test.

    I definitely think your script could do with oxygen and hydrogen indicators (also needs improvement for power; doesn't see batteries/solar), but I'm not sure if you have enough room on the LCD screen. Hydrogen thrusters don't seem to consume any electricity, so I don't think you'd need any special changes for a hybrid ship. Perhaps it might be smart to set up the ice delivery to only send ice to the oxygen generators when you're low on hydrogen or oxygen, rather than just pushing it all, as it does now.

    Now, if only I could find some freakin' ore on these planets! Seems like the ore detector is totally useless, now...
     
  5. Burillo Junior Engineer

    Messages:
    648
    @Smokey McDoob yeah, that power management again... i always said it was out of scope for BARABAS, but now that solar and batteries are the thing you should use when you're on planets as Uranium is scarce... not sure what i will do yet. i have to think about it.

    regarding hydrogen and oxygen, i did some investigation into it, and really, the only thing i can do is show percentage of filled hydrogen tanks. everything else is pointless.

    regarding your ore problem, it could be a simple race condition. when ore is reprioritized, ore status is refreshed once every few cycles (so once every 2-6 seconds depending on your base, given a one second timer). maybe by the time you tried reprioritizing it, BARABAS still thought the ore was scarce, and so tried to refine it. remember that reaction time is non-zero and it takes a few refresh cycles to normalize situations like this.

    as @Wicorel knows, i've been also experimenting with a different method of ore distribution, taking into account refinery upgrades and other stuff, but my experiments ultimately failed - the thing i wanted to do was too complex to do in a single pass (maybe still implementable as a separate script, but not as part of BARABAS). what i ultimately ended up with is the idea of adding switches in the config file to turn off various sections of BARABAS so you can plug in your own scripts instead (e.g. disable ore management in BARABAS and use some other script for that). so this will also be added in a 1.4 release.

    i've been also a bit side-tracked with a new project of mine, JAMS, and i'm also planning to create a similar script for rotating solar panels (if i don't find any other scripts that fits my purposes). now that i'm building a modular space station, those would come in handy along with new features planned for BARABAS.
     
    Last edited: Nov 16, 2015
  6. Smokey McDoob Trainee Engineer

    Messages:
    38
    Even a percentage readout for hydrogen and oxygen would be a great asset. Same for battery charge. Just something to let me know when I'm running low. But, at least for me, it would have to be able to support multiple tanks and batteries...

    Due to the added difficulty in acquiring ore on planets, I still haven't been able to properly test the problem with the ore. But, I wasn't even aware that the script did any prioritizing. It's very possible that is exactly what I'm seeing.

    I like the idea of a modular script, to a degree, but doesn't that go directly against your simplicity ideal? Not to mention the fact that I'd prefer to keep my 'server farm' to a minimum. My ships usually only have one CPU, running BARABAS, and my stations have two or three, rarely more, depending on their design and purpose.

    If you can come up with a good script to control solar panels, let me know! I've been trying to find one that works for me since sun rotation became a thing! There's plenty out there that use gyros to align the entire ship, but my stations don't have gyros or thrusters, and a planetary base wouldn't be able to use that method anyway. I'd like to set up a system that uses rotors and scaffolds to make a large array that is tunable in both X and Y directions, but so far, the only rotor-enabled scripts I've seen will only use one. The biggest problem I've seen, though, is the difficulty in accurately determining the optimum angle of attack. It's not like the game has a photo-electric cell...maybe if Keen modified sensors to read solar radiation...

    For your JAMS script, I might suggest you take a look at the one I'm using currently:
    http://steamcommunity.com/sharedfiles/filedetails/?id=375228990
    You might find some ideas in there that will help you develop your own script. With it, I have my airlock switches toggle a different interior light for each airlock, and that light is what triggers the script, which uses tags to identify which airlock, and which parts, to interact with.
     
  7. Burillo Junior Engineer

    Messages:
    648
    not sure i'll be able to fit in the multiple tanks/batteries thing. i could probably give total wattage etc. for batteries and squeeze in hydrogen onto the same line as oxygen, but i won't be able to go much further than that.

    yes, it does do prioritizing. when you're running out of ore or are about to run out of ore, it'll prioritize it. works separately for refineries and arc furnaces. just making sure you don't find yourself out of materials when you suddenly decide to build something big :)

    it's not really making BARABAS modular. it's to turn off parts of the script that you don't like and optionally replacing them with something else. for example, you like BARABAS, but you don't want it to manage your oxygen. so you turn it off, and it'll simply not do that. whether you then use something else to do the same job better is of no concern to me. i'm not yet completely sure which parts of the script makes sense to turn off, but refinery management for sure.

    so, i'm not about to split BARABAS in parts and forego its simplicity. i'm simply adding an option to disable parts of the script in case you want to use something else for that particular thing, so BARABAS is no longer "all or nothing" proposition.

    well, so far all my thoughts on this were purely theoretical and i haven't actually tried building solar arrays and controlling them with scripts, but my goal and MO basically will be similar to JAMS - you create a group which represents one rotatable solar array (i.e. one or two rotors and however many solar cells you want), and this will operate as one unit. you will then have lots of units that will operate independently of each other and self-align. so basically, the idea is the same - utilize groups to make note of which rotor belongs to which solar array, and let everything else be automatic.

    with regards to determining the optimum angle, i'm thinking of simply looking for max value for a start. maybe later i'll figure out some kind of algorithm to determine sun position from one array and use it to align other arrays. i dunno. it's in the "thinking it through" stage for now, and i haven't really dealt with solar arrays until now.

    this is exactly the kind of thing i wanted to avoid with JAMS. as you have probably noticed, i have a particular aversion to complicated setup procedures. when i see naming conventions and overly specific set up instructions, i go "fuck that, too hard". which is why my airlock operates off sensors (so i don't even have to press a button), doesn't require any naming conventions and all this stuff you have to do to make this script work - you build an airlock, you create a group of blocks, you set up sensor ranges, and you're good to go.
     
    Last edited: Nov 17, 2015
  8. Smokey McDoob Trainee Engineer

    Messages:
    38
    I guess I didn't explain myself properly. If you could give a percentage amount of used storage versus total storage, like what you did for cargo space, that would be fine. I didn't mean a separate stat for each tank, or battery, just that the script can handle checking as many tanks/batteries as are on the grid.

    I'd like to point out that it's not perfect at this. At one point, I was desperate for some Silicon so I could extend my solar array, and the damned thing refused to touch anything but Nickel...Perhaps having the master priority list as part of the config might be a good idea...

    That's funny, the refinery management portion of your script is what brought me here in the first place!

    Again, I find myself thinking of a script I've seen in the workshop. Can't find it now, and can't remember, but it was a 'master waldo' script; the user would control one set of rotors, and all of the slaved rotors would follow the same movements. If I find it again, I'll let you know.

    So far, all the others I've seen use a method of checking the solar panel's info, moving, and rechecking the info. This isn't extremely efficient, and can often have unexpected results. And, it's even worse when you have two axes, x and y. Throwing in a moving target will probably add more problems. What we need is an in-game equivalent of a very precise photo-voltaic cell, one that can tell the difference between being pointed directly at the sun, and being one degree off, and, preferably, in what direction it's off.

    But I leave all that fun to you! I'm not a coder by any stretch of the word, so the best I can do is throw out ideas.

    Well, except for the fact that you currently need one PB per airlock :) And each running script contributes to sim lag; for some people (me), that's a big issue.

    Keep up the good work. If you can make BARABAS as nice as it is, I'm sure you can do just as well with your other projects.
     
  9. Burillo Junior Engineer

    Messages:
    648
    so... planets. since we're supposed to be using batteries and solar panels on planets (as uranium is kinda scarce), this undermines the whole premise behind BARABAS. it seems that i'll have to venture into power management after all, or at least make BARABAS more aware of batteries and solar arrays as well as reactors. this presents a bit of a challenge as to where will BARABAS go with this from now on. right now i'm toying with a few ideas on how to exist in post-uranium world (mainly to count "time at max power" as uranium plus batteries, and change meanings of "low uranium" to "low power") and not fire any alerts about "low uranium" when you still have lots of battery capacity, but i'd be really grateful if some wild suggestions were tossed my way.

    i've also toyed with the idea of a universal "fuel" concept, but this doesn't work for a number of reasons, mainly the non-universality of the actual fuel. if i have a battery and a hydrogen tank, that might mean i fly on hydrogen and work off batteries, or it might mean that i have both hydro and atmo/ion thrusters. moreover, some people (myself included) might be dynamically switching both on/off. also, some thrusters don't work in some conditions, so even if i have lots of "fuel" on paper, in actuality i might be trying to use ion thrusters on a planet and the script will be thinking it has lots of "fuel" (i.e. power in the battery/uranium) while in reality i ran out of hydrogen and can't use ion thrusters. so this idea is really a pipe dream.

    EDIT:

    i've implemented tracking battery capacities and factoring them into my calculations on how much power is left. i now count the combined kWh stored in uranium (if you have reactors) and batteries. i'm not counting solar, since those are transient sources of energy. first of all, yet again, i'm amazed by how hard it actually is to power the base off solar and batteries. i've built two (static) small solar arrays, and my base is, well, OK, as long as i don't refine anything, especially at night. seems like unless you're using solar tracking scripts and/or otherwise rotating your arrays, solar panels are still a gimmick and uranium reactors are a necessity. there is uranium to be found on planets, so that's good news - i won't have to keep everything running off batteries.

    this also presents another problem. reactors are pretty efficient when it comes to power, you might have a few kg ingots worth of uranium and they may last you an hour on max load and days in standby. batteries... they give out a reasonable amount of power, but they don't last that long. since BARABAS's "time left" is pretty pessimistic (basically telling you worse case scenario, i.e. time at max load), BARABAS comes out screaming if you start running on batteries, unless you have lots of them and they are all full. this is very annoying, especially on a battery powered-ship, where you know you aren't constantly going to be on max load unless you don't know what "headroom" is.

    which leads me to a reimagining of how i do "time left" calculations: maybe i shouldn't calculate max load, but rather average load (meaning, take a few measurements, work out average and calculate time remaining). that way, i don't show superfluous alerts when the base is in standby, but will show alerts when the base suddenly starts living the high life. this has a potential of catching the user off-guard (such as if the base has days left in standby, but actually has very little power left), so i'm not sure if this is such a good idea.

    the upside is, if i implement this and calculate current load as opposed tomax load, this will lead to various power management scripts working better with BARABAS, as BARABAS won't scream bloody murder when the base is actually in "power saving" mode. so i'm heavily leaning in this direction.

    a few more things to mention: i've removed oxygen leak tracking, and there will be no brown alerts any more. i've also implemented better tracking of oxygen and added tracking of hydrogen (total percentage). i also want to add antenna notifications (as in, activating and changing antennas' names when something goes wrong), and also HUD notifications (show on HUD) for damaged blocks and clogged refineries/assemblers. however, i've ran out of space in the script. i already had to remove most of the huge comment at the top of the script (which had usage instructions), replacing it with a link to this topic, and also removed the brown alerts thing, but this still ain't enough to add all the new features i want to add. so i think i'll have to either go through script shaving off few symbols here and there from variable names etc., or just go ahead and use minify in release version (so anyone using BARABAS code from GitHub will have to minify it first).

    note that all of these changes are so far unpublished as i haven't finished experimenting. as always, input is very welcome.

    EDIT2:

    i've caved in and now minify my script before putting it into programming block. this has an advantage of keeping clean code in Github, but still gaining ~20K worth of minified characters, which means my script will have more stuff without me worrying much about the char limit for now.

    i've brought brown alerts back (since the only reason they were removed was the space they were taking compared to usefulness), although i did remove ice prioritization and shortage tracking. i might add another alert for oxygen shortages, or maybe redefine one of the existing ones (magenta and cyan alerts are pretty redundant now that antenna and HUD notifications are implemented, so maybe i'll use cyan alert for oxygen-related stuff).

    i've also added HUD notifications and antenna renaming on alerts, thereby implementing some of the good ideas mentioned in this thread. so now, clogged refineries/assemblers and damaged blocks show up on HUD, and antennas/beacons are renamed with alerts as well. the testing isn't finished yet, but the Github branch is pretty up to date, with BARABAS-next workshop item having most of the new stuff as well.

    i've also implemented better power tracking, so now it takes into account both uranium and batteries. some other aspects of the script were improved, some corner cases better tested, and the script is also more resilient when it comes to suddenly removing blocks (it no longer generates null reference exception in the majority (if not all) cases).
     
    Last edited: Apr 10, 2016
  10. Burillo Junior Engineer

    Messages:
    648
    i've released a maintenance release v1.31, which fixes compile errors that were present for some time. meanwhile, release 1.4 is in development.
     
  11. Burillo Junior Engineer

    Messages:
    648
    the new HUD makes the HUD notifications kinda useless, but in any case, 1.4beta3 is up in BARABAS-next, and if i don't find anything else to do or fix, i'll just bump the version and move it to release.

    i've made use of the new instruction counters, so now BARABAS tries to run several states in one cycle, if it can. on smaller bases and most ships, this basically means whole BARABAS execution takes 1 timer iteration. also made some improvements and various fixes.
     
  12. Burillo Junior Engineer

    Messages:
    648
    this is an old post, but...
    if you're still interested in using BARABAS on bases with merge blocks, i think i figured out a solution. At each refresh cycle, i can look for other BARABAS programmable blocks on the same grid, and if i encounter any, i rename them (to something like "BARABAS Base CPU [DISABLED]"). whichever PB gets to rename the other first, becomes the only active BARABAS instance on this grid, while all the renamed blocks simply do nothing. once disconnected, the PB renames itself back and runs again.

    technically speaking, whenever the disabled block runs, it first checks its name, and if it sees the "[DISABLED]", it checks if there are other active BARABAS instances on the same grid. if there are, it does nothing (meaning, some other BARABAS instance renamed it). if there aren't (if this PB is the only BARABAS on the grid, which would be the case if you had disconnected from a merged grid), it renames itself back and becomes active again.

    does that sound like a workable solution to you?
     
  13. AutoMcD Senior Engineer

    Messages:
    2,369
    I'm taking a little break from SE so don't do any work on my account. But I still think your script was a good idea and hope the suggestion helps. ;)
     
  14. Burillo Junior Engineer

    Messages:
    648
    Version 1.4 has been released. change log is in the first post, workshop items have been updated. whew...
    --- Automerge ---
    i've actually implemented it, works like a charm :) i needed this functionality anyway as my orbital space station is working off merge blocks to prevent misalignment, and while i still have a "data center" module where all the brains are, i didn't like the limitation of having only one data center per station.
     
  15. Burillo Junior Engineer

    Messages:
    648
    script is broken on latest version, waiting on keen to fix issues and provide an API doc again...
     
  16. Overengineering Trainee Engineer

    Messages:
    19
    Thank you for coding this script! I think it is the most convenient automatic management script out in the SE Workshop.

    I really would love to see your script working again and I guess it also has to be updated on the next stable release (See latest patch notes).
     
  17. Burillo Junior Engineer

    Messages:
    648
    thanks, glad you like it. i'm aware of the issues after latest patch, but unfortunately i can't fix them right now, because the functionality i need was (hopefully accidentally) blacklisted. i'm waiting on Keen to whitelist MyFixedPoint, as the script can't work without it. there's this other complication of API doc not available since a few updates back for whatever reason, but this can be worked around.

    I'm also not too sure how to track stable and dev releases yet. by stable/dev branches in the workshop i mean they track development of BARABAS, not SE, and i don't test BARABAS with stable SE branch (although it seems that i should). i'll be figuring it out as well.
    --- Automerge ---
    version 1.41 released, works with the latest update
     
    Last edited: Jul 2, 2016
    • Like Like x 1
  18. Overengineering Trainee Engineer

    Messages:
    19
    Thank you for updating the script to the DEV branch. I am still on STABLE because the dedicated Server I am playing on is on STABLE too. (I managed to get a copy of the prior Version from a PBlock in game) But hopefully I can switch to the new Version as soon as the STABLE branch receives the update.

    Reading the management of the two branches: I think it is quite common to have two versions in the Workshop tagged with [DEV] or [STABLE].

    By the way, if I might ask a question, I encountered a Error message on my latest space station. The script tells me "Caught exception ... Connecting to multiple bases is not supported!" What am I doing wrong? (It is a simple space station with two small ships docked via connector.)
     
  19. Burillo Junior Engineer

    Messages:
    648
    i wish there was a way to keep both versions installed. it gets very tiring to install/reinstall SE every 5 minutes because i need to check the script in dev/stable version. also, i still can't upload new scripts to the workshop, so i can't even make a new workshop version. i'll attempt to do a stable branch in the weekends.

    you also can get previous version from GitHub, but you'll have to minify it. if you don't know how, i've written a simple Minifier - copy the github text, press the button, paste it into PB. that's the same process i use to push out BARABAS releases to the workshop.

    unless there's a bug, that usually happens when:
    1) your ships aren't running BARABAS, and
    2) your ships are of a weird configuration (base BARABAS can't find thrusters or storage on your ships)

    if you want, you can upload the world so i can take a look at it.
     
    Last edited: Jul 15, 2016
    • Like Like x 1
  20. Overengineering Trainee Engineer

    Messages:
    19
    Thank you for sharing the Minifier - I already tryed to use the github code but I was not able to find the Monifier. That is a great tool! I think it deserves it`s own topic at the "Programming guides and Tools" section.

    You nailed it with tip no. 2) - I had a "ship" connected to the station composed of three small shoip blocks (Connector, Container and a Projector). As soon as I removed that, the script stated working again.
     
  21. Burillo Junior Engineer

    Messages:
    648
    very few scripts are as big as to need minification, so i doubt many people would find it useful. however, i should probably mention it more prominently in my first post, just in case someone else might use the github code.

    yes, unfortunately that's what i have to do to autodetect stuff. from BARABAS's point of view, anything that has thrusters on it, is a ship (conversely, anything that doesn't have thrusters on it is a base). however, you just gave me an idea to make it a bit better. first of all, any small grid is a ship by definition - so i can autodetect it as one regardless of what kind of thrusters it has. bigger grids - in 99% cases if you're a base, you aren't connecting to other bases, so i guess it's safe to assume that the other entity is a ship (and treat it as one). so this error that you've had is really avoidable, and i'll certainly fix it in the next version.

    with regards to stable vs dev version... i wasn't able to find a way to make it easy for me to develop both versions, and i still can't publish my script even if i wanted to - the script publishing bug is still not fixed after 2.5 months. there were no bugs fixed in BARABAS 1.41, so you're welcome to use the 1.40 version until the stable branch catches up with the new modding changes.
     
    • Like Like x 1
  22. Overengineering Trainee Engineer

    Messages:
    19
    Yes I will stick to the 1.40 - and I guess as long as the download via github is possible it is not that big issue.

    Bad thing with the upload bug. Does it only affexts BARABAS or can`t you upload scipts at all?
     
  23. Burillo Junior Engineer

    Messages:
    648
    i can update existing ones, i can't upload new ones. i still can't upload my JAMS script, let alone a stable branch-oriented BARABAS.
     
  24. Wicorel Senior Engineer

    Messages:
    1,243
    Not any more. Small grids can now be static grids.
     
    • Informative Informative x 1
  25. Burillo Junior Engineer

    Messages:
    648
    ...so it's now possible to have a small grid base? OK, but the rest of it still stands - if we're a base, i'm pretty sure we aren't going to connect other bases to ourselves.
     
  26. Burillo Junior Engineer

    Messages:
    648
    i'm developing a new version. here are some ideas i'm toying with.

    first of all, the change i'm working on right now - additional scaling for state machine. currently, my state machine is able to execute several states in one iteration, but it can't execute one state in several iterations. normally, there's no way to ever hit a limit in one iteration, because no one in their right mind would have that many blocks. however, there's one exception: ore rebalancing code. this code loops over all refineries, many times over, per ore. this results in exponential complexity, which means that having even a moderate amount of refineries (say, 50) does indeed break BARABAS if you also have a lot of ore.

    this new state machine is meant to fix it in a very simple way - putting upper limit on how many refineries we're allowed to process at once. in other words, partitioning the refinery list, and going over it in chunks. obviously, if we're simply iterating over a list sequentially and stopping half-way, this would create a problem in that some refineries would be always underutilized, while some would be over-utilized, depending on their order in the list. however, this problem is trivially solved with random partitioning - i.e. i will only go over 30 refineries out of 60 at a time, but each time, the list of refineries will be different. this way, average utilization will be pretty much equal across all refineries, even though in certain cases, there may be local hotspots of under- or over-utilization.

    another idea i'm thinking of implementing, is customizeable text output. the way it will work is, i will have "configuration" for text panel in its private text, while the displayed text will be public. so, by default, the text panel will display the same things it always has, but you'll now be able to add or remove additional elements. the list of what would be available for output isn't there yet, for now i'll concentrate on re-implementing what is already working, but at some point, i'll sit down and think what output i would like to have but couldn't because of screen constraints. i may even be able to implement customizable multi-screen output - i have a few ideas on that front as well. feedback is very welcome here, as there may be things i didn't think of.

    the next change i'm considering, is having multiple trash connectors. throwing out stone, ton by ton, out of a single trash connector is a very slow process, so i would like to speed it up. the way i want to accomplish it is in line with how everything else works - with block groups (the reason i don't want to throw trash out of just any connector is obviously because some connectors may be at the top of a ship, which would be undesirable). naturally, this puts a question mark on the concept of "trash sensor", as i would now have to either figure out which trash sensor belongs to which connector (which is a lot of, frankly, unnecessary work), or use single (or multiple) trash sensor to stop all trash throw out. in fact, having a group of connectors and sensors marked as trash will actually make everything easier, as now i won't have to create a separate "trash" connector on my base, and can just use my existing connectors whenever there aren't any ships around. so, in essence, connectors and sensors will be part of "BARABAS Trash" group, and any active sensor will cause all trash throwout to stop. a free bonus is to be able to make use of ejectors as well! backwards compatibility with current naming scheme will be kept, of course.

    i'm also considering a feature once suggested by @AutoMcD - shutting off oxygen generators once oxygen supply is over a certain threshold. this, however, presents a problem - oxygen generators are also used to create hydrogen as well as oxygen, and some people would want hydrogen even though it has enough oxygen. what i think i'll do is change the configuration, and add low/high watermarks to hydrogen and oxygen. high watermark would be "when to stop hydrogen/oxygen production" (so production will stop whenever both high watermarks are achieved, so even if you already have enough oxygen, the production will continue until you also have enough hydrogen), while low watermark would be "when to restart production, or sound an alarm". this is how power watermarks already work, so this won't be such a big change, and would fit in with the rest of the config failry well.

    and finally, a feature that ties in to customizable text panels - i would like to detect gravity, and display how much mass engines can lift, in each direction. this is a "wishlist" feature, i may run out of space even with all the minifcation i already do, and i'm not even sure if it would be useful or feasible, since there's no way to know ship's current mass as far as i know, and without that, the information isn't remotely as useful as it could've been. so i'm not completely sure about this one, and i'm not even sure if i would want to make it part of BARABAS (instead of a separate script), to be honest. this is just an idea i'm pondering - i might not implement it after all.
     
    Last edited: Sep 2, 2016
    • Like Like x 1
  27. Burillo Junior Engineer

    Messages:
    648
    For those who might be interested, GitHub master branch, as well as BARABAS-next was updated with version 1.5alpha1, with the following changes.

    First off, the new scaling mechanism. Unfortunately, my idea of having a state executing over several ticks was a pipe dream, at least as the code is currently written, and will require much more work to implement. So instead of doing that, i've opted to just limiting the number of refineries/furnaces that are processed at once. So, if you have 100 refineries, only 50 of them will be processed at once, with up to 30 more arc furnaces. The limits aren't tested yet, i just went by my past experiences. The 50/30 refineries/furnaces are picked at random, so on average, utilization should be fairly even.

    Next, multiple trash connectors, as well as multiple trash sensors are now implemented and pretty much work. Create however many connectors and sensors, set them up, and add them to "BARABAS Trash" group. Done, they'll just work as if it was a single connector. They will also try to spread out the ore evenly, so the trash disposal would be as quick as possible. Old-style named blocks are also detected, but their usage will be discouraged.

    The config file also had a minor change, namely the addition of a "watermark" format. Power watermarks are now set as one config option instead of two (with values being set with a slash, like "30/120" - although it will later be changed into just being two numbers), and of course backwards compatibility is kept so nothing needs to be done on the user's side about this.

    Also, the above mentioned "shutting off oxygen generators" feature was also implemented. Old "threshold" config options were replaced with the new watermarks for oxygen and hydrogen, and they work similarly to power watermarks. The oxygen generators are shut off whenever oxygen and hydrogen are over the high watermark, and ice is kept inside oxygen generators (but moved out of the refineries back into storage). Again, backwards compatibility with old oxygen/hydrogen threshold options is kept, however the format will change in the future, so if you like to use alpha versions - be prepared to re-generate your config once in a while.

    So the only big feature left to be implemented is customizable multi-screen text output. I also just found out that lazy evaluation is finally working in SE, so this is something i will be looking at either in this or in next release. I've decided to drop the "directional thrust" feature as it doesn't really fit in with BARABAS. maybe i'll write a separate script. or maybe someone did already.

    And finally, as always, numerous optimizations and bug fixes are also in.
     
    Last edited: Sep 11, 2016
  28. Burillo Junior Engineer

    Messages:
    648
    Github/Workshop have been updated with 1.5beta1, with the following changes.

    First of all, the customizable multi-screen text output feature was dropped. I'm out of the character limit, but more importantly, while it would be a cool piece of technology to write, i can't really imagine any use for it. I've spent lots of time optimizing current textual output, and it covers all my needs, so i can't really imagine doing anything much more useful with the multiline text without going all nuclear and implementing something like other scripts already do anyway.

    Next small but visible improvement is, whenever BARABAS throws an exception, it will now notify the user with all available methods (text panels, red alert, HUD notification).

    The big feature is the new graph-based grid locality detection code. This fixes all of the potential issues with both local and remote grid detection. All grids are now correctly identified as belonging to their respective ships/based.

    And as always, a number of under-the-hood improvements and bug fixes as well.
     
  29. Burillo Junior Engineer

    Messages:
    648
    version 1.5 has been released.

    changelog:
    • Limit the number of refineries/furnaces active at any moment to 40 randomly chosen ones.
    • Support for multiple trash connectors/sensors (as part of "BARABAS Trash" group)
    • Power watermarks are now a single config option instead of two options
    • Added hydrogen and oxygen watermarks (anything below low watermark will sound an alarm, everything above high watermark will stop ice from refining)
    • Gravel is now thrown out along with stone
    • Improved grid detection algorithm, much more reliable and fixes all of the previous limitations
    • Version now displayed in config block
    • Exceptions are now more visible
    • Disconnected blocks are now more visible
    • Numerous optimizations, improvements and bug fixes
     
  30. Burillo Junior Engineer

    Messages:
    648
    BARABAS v1.51 has been released.

    New features:
    • Hide ship-specific config options from base config
    • Oxygen/hydrogen refuel (by settings tanks to stockpile, use with care, disabled by default)
    Bugfixes:
    • Block exclusion via "X" wasn't working since v1.5, now it's working again
    • Make crisis mode a little saner
    • Fixed potential null reference errors for unowned blocks
    • Don't hide blocks from HUD if we weren't the ones who put it there
     
Thread Status:
This last post in this thread was made more than 31 days old.