Toggle Displays Like Rails

[Edymnion]

The rail system lets us use logic to basically hotswap blocks out, change one one block into another at will.

Can we make this apply to display monitors as well?

In my capitol ship, I have a big main viewscreen made of displays that the original plan was to just draw some ASCII stars and planets on to pretend it was an actual viewscreen, but got thinking about damage indicator logic and the rails, and it hit me.

We could combine the two in order to make useful real-time updates to displays as to damage.

For example, I have four docked power generators in my capitol ship. If I peppered each generator with some activators and AND'ed them all together and output to a wireless logic, I could have an indicator for when a generator is damage. I could use logic to then choose between a multitude of displays to then trade out the one on my main monitor to list the statuses of each reactor. As in, have a display that says "Reactor 1: Okay, Reactor 2: Okay etc", one that says "Reactor 1: Damaged, Reactor 2: Okay, etc". Use logic to swap out which one the one on the bridge mirrors, and I've got real time status updates on the conditions of all of my generators right there on the bridge.

Same could be done for turrets, with multiple turret statuses being displayed to one screen.

Sure, it would get a little crowded below decks (would require 24 displays to choose between to show the correct status of 4 different entities on the same screen), but it would at least let us get actual useful information displayed while only using the current game mechanics.

 

[Sven_The_Slayer]

Yes, this is a feature I would love to see.

 

[Yetimania]

That would be absolutely awesome. Block-intensive, but I couldn't imagine anyone even really wanting to do this on a small ship, so that's not a big problem. You could even turn the extra display blocks upside-down and use them as hull or floor to save blocks.

 

[Edymnion]

That would be absolutely awesome. Block-intensive, but I couldn't imagine anyone even really wanting to do this on a small ship, so that's not a big problem. You could even turn the extra display blocks upside-down and use them as hull or floor to save blocks.

Yup, the backs of monitors look a great deal like grey hull pieces...
You could literally line the floors in display butts. Heck, you wouldn't be lining the floors in display butts, the floors would BE the display butts!

 

[NeonSturm]

The rail system lets us use logic to basically hotswap blocks out, change one one block into another at will.

Can we make this apply to display monitors as well?

In my capitol ship, I have a big main viewscreen made of displays that the original plan was to just draw some ASCII stars and planets on to pretend it was an actual viewscreen, but got thinking about damage indicator logic and the rails, and it hit me.

We could combine the two in order to make useful real-time updates to displays as to damage.

For example, I have four docked power generators in my capitol ship. If I peppered each generator with some activators and AND'ed them all together and output to a wireless logic, I could have an indicator for when a generator is damage. I could use logic to then choose between a multitude of displays to then trade out the one on my main monitor to list the statuses of each reactor. As in, have a display that says "Reactor 1: Okay, Reactor 2: Okay etc", one that says "Reactor 1: Damaged, Reactor 2: Okay, etc". Use logic to swap out which one the one on the bridge mirrors, and I've got real time status updates on the conditions of all of my generators right there on the bridge.

Same could be done for turrets, with multiple turret statuses being displayed to one screen.

Sure, it would get a little crowded below decks (would require 24 displays to choose between to show the correct status of 4 different entities on the same screen), but it would at least let us get actual useful information displayed while only using the current game mechanics.

Please explain.

Example:
You can make dock(+core)+display entities in an rail-loop.

The last element has a trailing block, not activating rails, but stop others to follow it.
Send blocks on their path, until this block reaches the desired location → displays visible through a hole in your wall will switch.​

Is your suggestion to do the same in less time, don't require rails and no path between source and destination display block?​

What's the point in this brute-force?

You would need 1 Display Block for each text-combination.​

If you could use "memory cells" to copy indexed text into a stream which outputs to a display, it would be a much better feature.

There is similar in C (a programming language)

Display << cin // c-in is the standard user input; similar c-out is the standard user output
cout << "Text" << TextAt( 1..4 = Status-Bits(00, 01, 10, 11) ) << "More text (including line breaks)"​

I can imagine blocks in one line (similar to warp-gate blocks), each holding text.

Then you activate the (warp-gate-controller -like) display-transfer-controller

and all display blocks which have logic-on input are part of the output.​

Else you get a very low frame-rate for either your display block or the source code.

Each NEW string allocates memory.
Except you just fill a 255 byte buffer.​

Just one problem is, that strings (aka "lists made of many letters") either

fragments memory (longer text = longer memory space)
or is not using it very effectively (always occupy 256 byte/letters, independent of how many bytes are used).​

Spoiler: A time-consuming solution is to de-fragment a string-buffer. (WARNING: you may learn something complicated!)

Use memory for 4096 byte/letters and have each string have a "start and length".

​

Then, every time you delete a string, you close the gap by moving other strings.

1111.222.33333.4444444.5555.00000...0 (all sorted, followed by empty=0)
1111.000.33333.4444444.5555.00000...0 (after deletion of 2)
1111.33333.4444444.5555.00000....0000 (after de-fragmentation)
1111.33333.4444444.5555.22222.000...0 (after inserting another 2)

And this de-fragmentation costs TIME → creates lag, even if you don't have to program this yourself in Java, it is done.
​

A compromise : 3+ 1.

Store text of 3+ memory blocks in the same memory (maximum only depends on individual size)
Agree, that you may waste space for "almost" 1 display block = average 1/8 RAM-space loss

You can also have a special array for the 8 letters or less,

as it is not worth all that memory-management for few-letter-each + display-block spam
if position+length is already 16 or 32 +8 bit (=3-4 byte) of meta-data.​

Thus here you have to use the wasteful method all the time!!!

And that also gives you a size-limit of 8<=X<=256 letters per display block and 1024= 4..128 blocks.​

Then you can just store the address of the next empty index in an empty index and remember the first empty like with a single-linked list.

As all are equally sized, no need for de-fragmentation.

You see letters, for the computer is "Space" just 32 and "A" is 96, "a" is 126 if I remember correctly (ASCII, different for unicode).
Letters don't ever be 0, thus (empty cells : length=0 .. index>0) vs (empty strings : length=0, index=0) is distinguishable​

As you agree on wasting at most 255 byte per 1024 byte, you don't have to de-fragment all your memory, just these 1024 byte.

It's always a compromise:

1. More optimal memory usage : more CPU-time consumption for de-fragmentation.
2. More optimal CPU usage : less optimal memory.

You always want to get to the point where:

1. (loading all data * times you load it) - minimum loading time
2. equals
   
3. (time reduction * times you load it) + de-fragmentation time + time for managing cases.

 

[Ithirahad]

I like this, but there's probably a better solution. Personally, I'm a fan of some kind of "status broadcast block" system. Basically, there would be a logic block that you could name and assign two text lines to, one for the on state and one for off. (One field could also be left blank, for reasons I'll explain below.) Then when you put the assigned [name] of the block into a display block, it would display text matching the current state of the block. For instance, if I wanted a status readout for deployable armour, I would hook a status block up to the deployment switch, with its ON text being 'ACTIVE' and its OFF text being 'READY FOR DEPLOYMENT'. I could then type into the display block something like:

Armour Plate Status:
[ArmPlate]

If I wanted, I could also use a clock and stuff to check if the armour is still alive... In this case, I would remove the ON text from the first status block, then have two separate status blocks, both with only on-state text hooked up to some other logic so that they would read "ACTIVE" or "COMPROMISED". Then I could write:

Armour Plate Status:
[ArmPlate][ArmDpl][ArmDed]

And since the three only come up when their logic blocks are set up right, it'll only show one readout.

Stowed:

Armour Plate Status:
READY FOR DEPLOYMENT

Deployed:

Armour Plate Status:
ACTIVE

Broken/detached/bugged:

Armour Plate Status:
COMPROMISED

...Ideally, it would be possible to even put a variable inside the format line. So, I could have a status block named StatColour with ON-state as #FF0000 and OFF-state as #FFFFFF, and then another named AlertStatus with ON-state as "RED" and OFF-state as "N/A" and then do this:

<style>c=[StatColour]</style>
ALERT STATUS [AlertStatus]

And then when the status block is turned on, the text turns red - possibly for a red-alert function or some such thing:

Alert off:

ALERT STATUS N/A

Alert on:

ALERT STATUS RED

EDIT: I think I'm gonna post this as a new thread.

 

[Edymnion]

Please explain.

Example:
You can make dock(+core)+display entities in an rail-loop.

The last element has a trailing block, not activating rails, but stop others to follow it.
Send blocks on their path, until this block reaches the desired location → displays visible through a hole in your wall will switch.​

Is your suggestion to do the same in less time, don't require rails and no path between source and destination display block?​

What's the point in this brute-force?

You would need 1 Display Block for each text-combination.​

Point in brute force is that it would piggyback on a system that is already in place, and wouldn't require extensive new coding to make it happen.

And it would take a massive amount of rails and logic to try and create a conveyor belt system to slowly move cores around simply to move a monitor into place. The practical layout of trying to get that many routes set up that didn't conflict on a purely mechanical level are seriously not worth the effort.
​