Maintenance Signalling

Marcin Sciesinski

Marcin Sciesinski

Code ALL the Ages!
Contributor
World
Architecture
Producers, consumers and transmitters already define which side they connect to. Also I'd like to avoid pulsing if possible (as described above in comments), due to introducing unnecessary processing. If a consumer has to do some action, the consumer itself should be specifying the interval. So for example, a dispenser should dispense an object every X ticks (configurable by clicking on the dispenser) while it receives a signal. This avoids recalculating signal for network and puts the logic where it belongs - at the consumer that does the action.

I'm ok with a block that introduces a delay - say you switch a lever and want something that it powers to work for an extra 5 seconds after you switch it off (for example like in case of break-in alarm that gives you time to leave home after you turn it on). But straight pulsing, as you described in "Pulse Width Modulator" - I'd rather not do that, or at least strongly discourage people from using it.
 
Marcin Sciesinski

Marcin Sciesinski

Code ALL the Ages!
Contributor
World
Architecture
To sum it up:
In addition to what you have in MUST, here is what else we've got already:
- pressure plate - emits signal while player is standing on it, does not stay on, this could be achieved with a signal ON delay or something similar,
- can define sided emitting/consuming/transmission of signals,
- Logic block: AND,
- Logic block: OR,
- Logic block: XOR,
- Logic block: NAND (can be used as a NOT if with one input),

At the moment the gates cannot be rotated but will add that after the ActivatedEvent will have the item entity that was used to activate.

All the time affected features have to wait, till issue #614 will be resolved.
 
UberWaffe

UberWaffe

Member
Contributor
Design
Yup, figured the PWM would likely not have a use with the design decision to avoid edge-triggers.

Great to see sided inputs and logic gates already in. :D
Apparently you code quicker than I write requirements.:eek:

--Full release Boolean Signal version requirements--
MUST:
  • [Achieved] Have low performance impact
  • Allow signal network framework that:
    • [Achieved] Can transmit boolean (on/off) signals
    • [Achieved] Can define emitters of the network signal
    • [Achieved] Emitters have a range component (defining range of emitted signal
    • [Achieved] Can define consumers of the network signal
    • [Achieved] Can define transmitters/conductors of the network signa
    • [Achieved] [+] Can define sided emitting/consuming/transmission of signals
  • Implements basic components:
    • Emitters:
      • [Achieved] Switch
    • Consumers:
      • [Achieved] Light
    • Transmitters:
      • [Achieved] Cable
SHOULD:
  • Implements basic components:
    • Emitters:
      • [?] Button
      • [Achieved] Pressure plate
    • [-] Consumers:
      • [-] Pistons
      • [-] Dispenser (Ejects an item)
      • [-] Collector (Picks up adjacent item)
COULD:
  • [-]Allow signal networks that:
    • [-] Can define sided emitting/consuming/transmission of signals
  • Implements basic components:
    • Mixed functionality:
      • [Achieved] Logic block: AND
      • [Achieved] Logic block: OR
      • [Achieved] [+] Logic block: XOR
      • [Achieved] [~] Logic block: NAND NOT
      • Logic block: Off Delay Timer
      • Logic block: On Delay Timer
      • [?] Logic block: Set-Reset
    • [+] Allow changing of input/output sides of a block after placement
    • [+?] Consumers:
      • [+?] Pistons
      • [+?] Dispenser (Ejects an item)
      • [+?] Collector (Picks up adjacent item)
WOULD LIKE TO:
  • N/A
Sidenote on MoSCoW:
[+] Means a new requirement.
[-] Means a requirement was removed.
[~] Means the requirement was slightly changed (or just reworded).
[?] Means the requirement is undecided, and requires debate/revision.
An requirement changing priorities would be shown as a [-] on the old priority, and a [+] in the new priority.

Are you happy with the requirements as they are now?
(Specifically with the few content suggestions [?] that remain and are arguably better suited to an extension module rather than being here).

As stated, the requirement's list is probably a bit pointless here, but it is a nice example of how ticking off requirements as [Achieved] shows well defined progress. A nice flagship.

You'll soon be flooded by non-participants pretending to having had an input and then congratulating themselves for the project's success. Like someone chiming in with a list of requirements after the fact and... then...
Oh...:oops:
 
Marcin Sciesinski

Marcin Sciesinski

Code ALL the Ages!
Contributor
World
Architecture
An update on progress:
- Logic block: Off Delay Timer (missing texture, fixed time only, will add configuration screen later)
- Logic block: On Delay Timer (missing texture, fixed time only, will add configuration screen later)
- Allow changing of input/output sides of a block after placement

Core engine doesn't support moving blocks (with entities) at the moment, so piston is not achievable at the moment, until such support will be added (low priority).
I'm not sure about the Dispenser and Collector as well. For dispenser - do you just want to eject the items into the ground, as if player threw them? For collector - should it pick up items on the ground in the 1x1 are in front of it?
 
UberWaffe

UberWaffe

Member
Contributor
Design
Neat o'!

For dispenser: Yes, just as if the player had thrown it as hard as possible, straight ahead in the direction the dispenser is facing.
For collector: I would make it 3x3. Smallish but large enough to be of practical use without spamming collectors.

All of this is already solidly in the scope creep department, but...
Would it be possible to make the dispenser and collector use adjacent storage? (such as chests)
I'm just thinking of having the mechanical equivalent of conveyor belts, by using chains of C(ollector)S(torage)D(ispenser)
I.e:
Temp.png

Watching the items getting shot around, sucked up, and then again passed along would be pretty neat and useful.
Though, again, scope creep.:cautious:
 
Marcin Sciesinski

Marcin Sciesinski

Code ALL the Ages!
Contributor
World
Architecture
I'm pretty sure we can come up with more efficient way of transporting goods. I fail to see any other uses for dispenser, so I will skip it for now. I'll also hold on with the collector, until the Inventory classes get some better design. So the collector is not going to be released in the first release.
 
Marcin Sciesinski

Marcin Sciesinski

Code ALL the Ages!
Contributor
World
Architecture
On Delay and Off Delay can now be configured after activating the block ("e" key) which opens a simple GUI screen to configure it.

So, what's left before release:
- texture for OnDelay and OffDelay,
- button,
- Set-Reset block.
 
UberWaffe

UberWaffe

Member
Contributor
Design
Yay! :thumbsup:


Updated MoSCoW:
--Full release Boolean Signal version requirements--
MUST:
  • [Achieved] Have low performance impact
  • Allow signal network framework that:
    • [Achieved] Can transmit boolean (on/off) signals
    • [Achieved] Can define emitters of the network signal
    • [Achieved] Emitters have a range component (defining range of emitted signal
    • [Achieved] Can define consumers of the network signal
    • [Achieved] Can define transmitters/conductors of the network signa
    • [Achieved] Can define sided emitting/consuming/transmission of signals
  • Implements basic components:
    • Emitters:
      • [Achieved] Switch
    • Consumers:
      • [Achieved] Light
    • Transmitters:
      • [Achieved] Cable
SHOULD:
  • Implements basic components:
    • Emitters:
      • Button
      • [Achieved] Pressure plate
COULD:
  • Implements basic components:
    • Mixed functionality:
      • [Achieved] Logic block: AND
      • [Achieved] Logic block: OR
      • [Achieved] Logic block: XOR
      • [Achieved] Logic block: NAND NOT
      • [Achieved] Logic block: Off Delay Timer
      • [Achieved] Logic block: On Delay Timer
      • Logic block: Set-Reset
    • [Achieved] Allow changing of input/output sides of a block after placement
    • [-] Consumers:
      • [-] Pistons
      • [-] Dispenser (Ejects an item)
      • [-] Collector (Picks up adjacent item)
WOULD LIKE TO:
  • N/A
Sidenote on MoSCoW:
[+] Means a new requirement.
[-] Means a requirement was removed.
[~] Means the requirement was slightly changed (or just reworded).
[?] Means the requirement is undecided, and requires debate/revision.
An requirement changing priorities would be shown as a [-] on the old priority, and a [+] in the new priority.
 
Marcin Sciesinski

Marcin Sciesinski

Code ALL the Ages!
Contributor
World
Architecture
Added:
- "button" block - after activated - sends signal for 0.5 sec.
- "Set/Reset" block
- Missing textures (ugly)

So I'm ready for 0.99 version release. I'm missing nice textures and/or shapes and some pending fixes in the Terasology core to remove workarounds. Once all this is there, I should be able to release 1.0 version of Signalling.
 
Cervator

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
I went ahead and gave Adeon access to the signalling repo, as he had worked out a fix. The commits got a little messy (gradlew createModule vs fetchModule) but it should all be there and looks to be working :)
 
You must log in or register to reply here.
Top