Asenna Steam
kirjaudu sisään
|
kieli
简体中文 (yksinkertaistettu kiina)
繁體中文 (perinteinen kiina)
日本語 (japani)
한국어 (korea)
ไทย (thai)
български (bulgaria)
Čeština (tšekki)
Dansk (tanska)
Deutsch (saksa)
English (englanti)
Español – España (espanja – Espanja)
Español – Latinoamérica (espanja – Lat. Am.)
Ελληνικά (kreikka)
Français (ranska)
Italiano (italia)
Bahasa Indonesia (indonesia)
Magyar (unkari)
Nederlands (hollanti)
Norsk (norja)
Polski (puola)
Português (portugali – Portugali)
Português – Brasil (portugali – Brasilia)
Română (romania)
Русский (venäjä)
Svenska (ruotsi)
Türkçe (turkki)
Tiếng Việt (vietnam)
Українська (ukraina)
Ilmoita käännösongelmasta
Reason its not listening to the lines at the same time is gate-updates cost time/processing power, so if every card would always be handling every signal shiz would get really laggy real fast once you have 10 or so cards going, this way at least it can decide to 'not listen' to the data signal part of it
i wasn't aware that it uses two way sequencial transmission to transport data in only one direction.
couldn't you then simply -
double the setup to listen to data and adress line simultaneously and ensure packet health by some kind of checksum instead of sending the data afer a "valid" adress was recieved, and not using a header and end to validate integraty
- to speedup communication ?
or was your goal to limit block number ?
well these are only my idears for a concept - currently i could not think of a way how to create the checksum but maybe the workshop holds anything usable or one could port a concept from wikipedia or some other more special wiki or forum to scrap mechanic
- On the data line it once again requires a start signal/package/whatever, after receiving that a counter starts counting to 8 (and it resets any previously stored data)
- During each of the above counting steps it checks if theres a signal coming in at the same time, if so that signal is stored in the card's memory
- Once it receives an end signal/package/whatever it makes the stored data available (i mean its available while its processing too, but theres another row of gates that only starts giving out the binary signal once the whole process is done) and toggles back to listening to the address line.
Re-reading the above description, i guess i never thought about adding a description on how it works, i wanna preface this again with saying its been almost a year, but here goes:
- There are two signal lines, one is used for address, the other is used for data
- Every card pretty much constantly 'listens to' the address signal line (unless its detected that it should be the receiver of something from the data signal line)
- When a card receives a start signal over the address signal line it starts 'playing' a sequence of its own address turned into a binary signal
- This sequence is then compared to the incoming signal, if its an exact match & has an valid ending signal/package/whatever then the card goes into a state of listening to the data line instead of listening to the address line.
Bout the vanilla wireless, i was hoping to use the spud guns to make a wireless setup (not unlike what that guy did with the modpack) but as soon as i've built it i realized why that guy added a new spudgun to the modpack for that very purpose, the vanilla spudgun has too much randomness, potato's can go slightly slower or faster, and since the entire system is based on ticks that could mean 2 signals meant to be one tick apart could become 0 or 2 ticks apart, destroying the actual data it was sending.
1/4:
Yea theres start and end signals/packets/whatever-to-call-these (from the top of my head i think it sends 3 pulses for the start signal and 2 for the end signal, but not 100% sure about this, its been almost a year since i've made this hehe) reason behind it is so it will be less prone to try do things with messed up data, as if it doesnt get a proper start and end package it will just stop processing the data signal. (and if multiple signals start going over eachother, the start & end signals will instantly get ruined)
so it has to be done like in your version where the transciever devides if it can occupy the lines.
whit this concept i see the problem which occurs when the sender automatically stars sending after the line isn't busy anymore and two or more senders waited
anothe issue joining my world in scrap mechanic could be all the mods i use. if installation of some of them isn't an issue for you i'd be happy to welcome you. Maybe the answer to a faster data transmission is allready in my analysation tools
well i've nothing to show you at the moment , just some demo setup to see how signals are modulated to represent the bits. one with the edited spudnet 2.0 reciever and another seperate setup with your cards. Reagrding your cards i see so many impulses that it makes me wonder if you use start/stop bits to encapsulate the data bits.
if by vanilla wireless you mean the glich where you can delete a piece between two bearings then i strongly advice against it because i've made the experience that every edit after using the glich results in a separation of the logic connection. the edit can be as subtle as painting one part and putting one of the connected parts on a lift will also result in the loss of connection