Project : Motion Tracker Computer (Updated with RAM-Module. ToDo: Upload)

[NeonSturm]

Related Discussions and Projects:

1. http://starmadedock.net/threads/pro...ter-updated-with-ram-module-todo-upload.2920/
2. http://starmadedock.net/threads/rp-what-if-we-would-have-security-and-crew-fully-customizable.2953/

Related Community Content:

1. http://starmadedock.net/content/logic-palette_ram_-_neonsturm.1317/

Related Suggested Features:

1. http://starmadedock.net/threads/new-block-logic-user-reference.2404/#post-35427
2. http://starmadedock.net/threads/improvements-to-display-block-variables.2807/

If you want to support many players you have to do a ramp or door where they all go in (else too many area triggers)

2 blocks are sufficient to detect the direction, 3 (A XOR B + B XOR C) should be sufficient to detect another player. The counting circuit will be more complex.

Use bench's counter (has to have an increment (+1) and decrement (-1) feature).
But if 2 players walk next to each other instead of after each other, there is no way ...


You could also set up motion sensors = area triggers in a checker-board style connected to 2 different controllers which refresh a timed shut-down clock.


Or make a more complex position tracker and counter for each player (will be more like a computer). Nice idea BTW - will try that
(finally a reason for having computers!

Request: Computer, detect Lieutenant Hidden-Markov
Answer: Lieutenant Hidden-Markov is on deck 7 section C room 42​

But this will fail if he goes to another players position, stops and this player walks away he stole HM's identity)


You can detect 2 players walking next to each other if the trigger triggers twice instead of once.

We need that! for our Enterprices
I can build a 3D vector ram (xyz=256 areas = 24 bit ?) what functionality do we need for this tracker?



BTW: I really want this done: http://starmadedock.net/threads/new-block-logic-user-reference.2404/#post-35152

Right now gravity modules work only if triggered by the first activation block either pressed directly or activated through area triggers.

I guess it is because other logic blocks (and even the second logic block) do not forward which user activated the logic.


@schema: please implement:
link buttons (activator blocks) to a "logic user reference" block (LUR). This block then allows user-dependent actions.


LURs forward their reference to other linked LURs when-ever they change their own reference (not when they change -for example- from active user 215 to 215).

(( Mabye a line-shaped array of LURs should store each active user ID only once. ))​

Linked to any other logic block, a LUR should return true if the user's name, his faction's name or his rank is listed in a nearby display block and false if it is not.

[faction=name] [rank=01234|name]​

If gravity blocks are next to LURs, they affect all users referenced by these LURs.

[INDENT]button -> LUR
button -> and
some flip-flop logic -> and
and -> gravity (nearby LUR)
// only activate gravity if -for example- step ons didn't trigger recently.
// only change gravity on destination floor (gravity lifts)[/INDENT]

Even Calbiri responded and poked AndyP

Now we have the perfect case where this could be of use (prevent identity stealing as player A walks into same area as player B and player B starts walking away)



Modules which could be useful :

1. Entrance/Exit (trackers and counters)
   1. Detects if a user enters/leaves the ship. Sends [area xyz, action NEW | EXIT] to the computer
   2. A global tracker could remember recent players and know who is likely to re-enter the ship.
2. Room Connectors (counters and notifies tracker)
   1. May detect if 1 or 2+ users go through the same area
   2. If activation pattern is like "A, B, A, B, C, C, D, D", C triggered twice without any other inbetween (even though it is not the first or last detector)
      1. the number of triggering the same connector can detect a group walking together.
   3. It can also increase the room-counter whenever someone passes through (but not twice for one)
   4. Signal [area xyz, action ENTER | LEAVE]
3. Identity and security tracker
   1. Each person has an identity (can be determined by password) which is set to UNIDENTIFIED (ID = 0) after 2 players enter an indistinguishable position.
   2. Security is either a counter (privilege levels = 2 * 2^bit) or a bitmask (number privileges = number bits) When 2 entities enter a not distinguishable state, the lowest common privileges are set for both (can be refreshed by entering a password).
      • or a mix of 1 general bitmask, 1 or even 4+ levels for different areas with a bit-mask for fine-tuning some aspects of this level.
      • What do we need?
4. Password Field
   1. Bench made a great example that could easily be extended to 8 fields (=3 bit) * 8 times (total = 24 bit) if the logic is centrally managed (thus smaller).

Major features I hope to archive:

I hope it will be possible to easily downsize it to your needs just by cutting optional things away.

I want to give it a server-room look, but also the ability to have the core separated (for more RP or to put extra hard hulls with 99% armour around it).

As it is intended for use on big ships, I think nobody complains if I leave 13 blocks space between the core and any logic.​

I intend to make it look like a server-room.​

Questions:

Should it be in front or behind the core?

1. Behind is better for running away
2. In front better for frontal assault and ships which have their core generally far behind.
3. Default: Without may wanting the opposite I will put it behind the core.

Should I put deck-separators between each 4th or 8th logic blocks?

I think it would be nice to leave some space (3 wide) for metal meshes in-between logic banks (2 block thick walls or hollow 4xYx4)​

Known Issues:

1. Can easily exceed 1000 mass (10'000 blocks) just for the position, identity and permission tracker, thus it is meant
   1. only for big ship
   2. mainly for RP (I don't support battle-cubes! :p Not intentionally :D)
   3. doubling ship size (or position resolution) should only add a tiny fraction to requirements, but doubling permissions bits will add greatly to requirements
2. Unlock of privileges may get lost with 2 players in the same room.
   1. Without knowing which user triggers logic, there is no way to give just 1 of 2 in the same room privileges the other doesn't have.

Possibilities

1. Blocks dedicated to store a user identity or String-logic (= compare words, ...) can greatly decrease the size and performance impact.

Don't feel shame helping.

1. Any ideas that will make it into the final project will be credited in Display blocks by a name
   1. roughly sorted by how helpful and how much (obvious or known) effort it required.
   2. not including peoples for just quoting things others made.
   3. including (where possible) the original author of things.
   4. maybe including information or sorting for type of help like (staff, moderator for this thread, ...)
      1. EDIT: Thread bumpers :D *no, just joking, or maybe the top 5? *
2. Peoples that really helped much and share something >50 blocks when implemented can post text for the display block and I will likely include it probably without change "as part of the lore"
   1. Custom display blocks will be placed in a way that somebody who deletes the whole feature (to make it fit smaller ships or have less mass/cost) also remove the display block mentioning the author of this part (should not pay for display block with credits of parts he is not using).
      1. Peoples may still be mentioned by name in the name-only display blocks.
      2. 2 peoples with <50 blocks can share a display block if they reach together >50 blocks (this is to prevent >1/2 resources spent for display blocks)
   2. Limits on number of characters, text color or size are only restricted by abilities of (the current) display blocks.
      1. Words exclusively in upper case or bad formatting is bad behaviour.
      2. offending content will be censored, (at a rather low offence level, will ask contributors if they accept a change before using it)
      3. Disclaimer: I can't decide what peoples will make with these blocks after downloading)

References:

4-Digit Programmable Combination Lock

This is a 4-digit programmable combination lock using logic in Starmade. You can copy and paste it onto a ship or station and using activation modules you can input a combination that then will send an unlock signal if the correct combination is entered. It can be cleared and a new combination programmed in, and using public permission modules you can enable non-faction players a bit more secure control over things. I'll be using this circuit to enable players to lock down a hangar while they park there, and when they leave trigger a circuit reset to open it up for a new player to temporarily reside there.

 

[idiotplaysgames]

Really looking forward to seeing this develop...

 

[NeonSturm]

Ping subscribers
Edited (added orange and green stuff. Basically everything except the first two quotes).

Module : RAM

Spoiler: Quite long with the ASCII graphics

2x2x2 Flip-Flop

Rear (where the magic happens)

O1 N1
O0 N0​

Front (where you control the magic)

W1 R1
W0 R0​

O = or
N = not
W+R =and

W = write
R = read​

1 = high state
0 = low state


Connections: (A --slaves-> B)

Write-And -> Or ( behind Write-And )
Not -> Read-And ( in front of Not )
high Or -> low Not -> low Or
low Or -> high Not -> high Or​

2x 9y 9z Bank

Front
R | WR | WR | WR | WR
__|_WR_|_WR_|_WR_|_WR_
R | WR | WR | WR | WR
__|_WR_|_WR_|_WR_|_WR_
R | WR | WR | WR | WR
__|_WR_|_WR_|_WR_|_WR_
R | WR | WR | WR | WR
__|_WR_|_WR_|_WR_|_WR_
B | OO | OO | OO | OO

W = Write ANDs (high + low)
R = Read ANDs (high + low)
R(left) = Row-Selectors

Connects to all 16 W|R ANDs in a 2x2x2 Flip-Flop row​

B = Bank-Selector
O = Compress All 1 and 0 outputs

from 8 into 4 blocks and
from 8 rows into 1
Left = Low R (per 2x2)
Right = High R (per 2x2)​

Rear
. | ON | ON | ON | ON
__|_ON_|_ON_|_ON_|_ON_
R | ON | ON | ON | ON
__|_ON_|_ON_|_ON_|_ON_
W | ON | ON | ON | ON
__|_ON_|_ON_|_ON_|_ON_
. | ON | ON | ON | ON
__|_ON_|_ON_|_ON_|_ON_
. | .. | .. | .. | ..

R = connects to all R-ANDs at front
W = connects to all W-ANDs at front
O|N = Or|Not (look above into the Flip-Flop section)​

1st Block-Column:

Write-All (And) -> slaves each Write-And
Read-All (And) -> slaves each Read-And
Row-Selector(And) (connected to all Read+Write Ands of a row - both high and low state)

Controller -> slaves bank 0 -> slaves bank 1, ... (forward only for read, write and row-selector, not the bank-selctor)​

Bank-Selector(Any) -> slaves each Row-Selector​

2nd to 9th Block-Column:

1 Flip-Flop column = 2 blocks​

top 8 Block-Rows:

1 Flip-Flop row = 2 blocks​

bottom 1 Block-Row:

8 ORs in a line

left of two ORs connects from all R0 and to all W0
right of two ORs connects from all R1 and to all W1​

1x 9y 9z Bank-Controller

4 bits Data in 4 states - 1 per 2 columns (matching position with Banks):

Left active = Low State
Right active = High State​

4 bits Address as

2 bits Row selector:

00 = row 0 at bottom
01 = row 1
10 = row 2
11 = row 3 at top​

2 bits Bank selector:

00 = bank 0 (near controller)
01 = bank 1
10 = bank 2
11 = bank 3 (far from controller)​

Connect Address to Row/Bank-Selectors (= ANDs)

Address-Bit = Position
0 = right
1
2
3 = left


+Bit 0 to row 0 + 2 = a T_T_ pattern
-Not 0 to row 1 + 3 = a _T_T pattern
--
+Bit 1 to row 0 + 1 = a TT__ pattern
-Not 1 to row 2 + 3 = a __TT pattern


+Bit 2 to bank 0 + 2 = a T_T_ pattern
-Not 2 to bank 1 + 3 = a _T_T pattern
--
+Bit 3 to bank 0 + 1 = a TT__ pattern
-Not 3 to bank 2 + 3 = a __TT pattern​

I decided for a 4 bit, 16 slots RAM, because it is the best to copy+paste

1. It fits with 3 banks into a 10x9x9 box and more banks are very easy to add
2. It can even be compressed to a 9^3 with 4 banks = 16 slots.
3. The new dev has fixed the copy+paste bug (but you still have to connect to everything outside the copy-box)
   1. Which is not hard (Controller data bits -> Bank1 bottom ORs -> Bank 1 bottom ORs ... -> last Bank back to Controller's data bits)

Also a 16 slot ram with 4 bits can store 1 address to a slot of itself in 1 slot.



But you can add any amount of memory slots you want by just

1. adding enough Bank-selector Address-Bits and connect these to the banks
2. keep the ControllerOR->BankOR->BankOR->ControllerOR loop intact (Controller needs to mirror it's data in each bank's bottom ORs)
   
3. forward a change for Read+Write Mode to the banks.

Need more bits? Just copy+paste the whole (in the new dev it's fixed!) for every 4 bits more you want.



How to use:

1. Write should be set to read before changing the address and set to write after an address is set (use rising-edge and falling-edge detectors)
   
2. Data should be Read from the interface (of bank-controller) 1/2+ cycles after address got changed.
3. Write should Write to the interface 1/2+ cycles after write mode got set and 1/2+ cycles before it gets changed back (for reading the next address for example)

Multiplexers can increase the performance for multiple reads/writes to multiple memory modules, but that is stuff for experienced users and huge ships


Edit: Screenies!

http://imgur.com/a/Sb5D5#QyT9MnF
More