Question about Yolol

[zgrssd]

I know I put:
- The code onto a Yolol Chip
- The Chip into a socket
- And the Socket is connected via a cable* to the signal network*
- In order to affect a device, the Yolol has to set it's device field

Now the question is how this setting of a device field propagates? As I understand it it will transmot to ALL devices in the same Signal Network. To use a Networking term: it is broadcasting to all devices, letting them decide if the command is for them (they have a Device field named like that).
Wich raises the question: How do we seperate systems? So that one doors "open" button does not affect every door in the ship.

In order to not have another device in the same ship affect I would have to:
- put it into a seperate Cable network altogether
- rename the field on the other device so the order not longer matches it
- put a (then very poorly named) Network Relay (https://wiki.starbasegame.com/index.php/Network_relay) into the cable, to cut off the Signal Network. Propably I would prevent the signals of the "Door Subnet" to go into the ship.


*As I understand it there are the Signal, Power and Resource Networks.
Cables connect Power and Signal
Pipes Connect Power and Resource

[Hoki]

from what i learned so far these networks also oprates with IDs so you can be more specific about who does what.

[Stepbro]

As far as i can tell from reviewing the video again, the ability the change the NAME of a value, e.g buttons, ButtonState, which is, needless to say the state of the button, if you were to change ButtonState in your code to 0 or 1, one would logically assume it will affect all instances of ButtonState in that network, HOWEVER! On the specific button you wish to change, you can change the NAME of the value, so ButtonState could be changed to ButtonState_Laz0rDethr4y and then suddenly, if you use your YOLOL to change the value of ButtonState_Laz0rDethr4y, there is only ONE instance of the value on the network.

This is my assumption based on my observations, but it makes sense to me ;3 Hope that helped ;) And wasn't totally wrong...
Devs? xD

Edit:

https://i.imgur.com/EDjqJ0f.png

[zgrssd]

Originally posted by Citizen #S9-23:

As far as i can tell from reviewing the video again, the ability the change the NAME of a value, e.g buttons, ButtonState, which is, needless to say the state of the button, if you were to change ButtonState in your code to 0 or 1, one would logically assume it will affect all instances of ButtonState in that network, HOWEVER! On the specific button you wish to change, you can change the NAME of the value, so ButtonState could be changed to ButtonState_Laz0rDethr4y and then suddenly, if you use your YOLOL to change the value of ButtonState_Laz0rDethr4y, there is only ONE instance of the value on the network.

This is my assumption based on my observations, but it makes sense to me ;3 Hope that helped ;) And wasn't totally wrong...
Devs? xD

Edit:

https://i.imgur.com/EDjqJ0f.png

That is option 2 from my listing:
"- put it into a seperate Cable network altogether
- rename the field on the other device so the order not longer matches it"

However it scales poorly. So it is not really a solution that works for the bulk of cases.

[Stepbro]

Originally posted by zgrssd:

That is option 2 from my listing:
"- put it into a seperate Cable network altogether
- rename the field on the other device so the order not longer matches it"

However it scales poorly. So it is not really a solution that works for the bulk of cases.

I'm not understanding what you mean... 'Scales poorly'?
You're simply creating unique IDs to differentiate between separate objects/groups (e.g renaming all lights in room x with Light_X so the code will affect all lights in room x with the one ID)

Is your concern that you will need to manually edit each item and you're looking for something more accessible/easy?

I'm sorry, there just seems to be some miscommunication or a language barrier that's making it difficult to understand what you're looking for.

[AuraFB]

Originally posted by zgrssd:

I know I put:
- The code onto a Yolol Chip
- The Chip into a socket
- And the Socket is connected via a cable* to the signal network*
- In order to affect a device, the Yolol has to set it's device field

Now the question is how this setting of a device field propagates? As I understand it it will transmot to ALL devices in the same Signal Network. To use a Networking term: it is broadcasting to all devices, letting them decide if the command is for them (they have a Device field named like that).
Wich raises the question: How do we seperate systems? So that one doors "open" button does not affect every door in the ship.

Good questions. I asked the SB team for some insight and it works basically the way you already theorized here:

Originally posted by zgrssd:

In order to not have another device in the same ship affect I would have to:
- put it into a seperate Cable network altogether
- rename the field on the other device so the order not longer matches it
- put a (then very poorly named) Network Relay (https://wiki.starbasegame.com/index.php/Network_relay) into the cable, to cut off the Signal Network. Propably I would prevent the signals of the "Door Subnet" to go into the ship.

*As I understand it there are the Signal, Power and Resource Networks.
Cables connect Power and Signal
Pipes Connect Power and Resource

Pipes don't connect power, but otherwise you are correct. Those are basically all the available options, as there are no other ways to separate networks (at least not currently). To affect specific devices through YOLOL you need to either rename the device or prevent the broadcast from the reaching the devices you don't want to affect. This happens by either separating the networks entirely, or using network relays to control the broadcast.

Hope this helps, let me know if you have any other questions!

[zgrssd]

Originally posted by Citizen #S9-23:

Originally posted by zgrssd:

That is option 2 from my listing:
"- put it into a seperate Cable network altogether
- rename the field on the other device so the order not longer matches it"

However it scales poorly. So it is not really a solution that works for the bulk of cases.

I'm not understanding what you mean... 'Scales poorly'?

You got 20 doors. That would need:
20 different names for the "DoorOpen" state.
That would need 20 different sets of Yolol code - each with a different Device Field name.
And you can not reuse the same name by accident, even if it was 6 months since you added the last door to your ship. Or lost that entire doorsetup to fire, and now can not remember what the name even was.
That is way up on the list how you should never, ever go about programming.

[zgrssd]

Originally posted by LindaFB:

Pipes don't connect power, but otherwise you are correct. Those are basically all the available options, as there are no other ways to separate networks (at least not currently). To affect specific devices through YOLOL you need to either rename the device or prevent the broadcast from the reaching the devices you don't want to affect. This happens by either separating the networks entirely, or using network relays to control the broadcast.

Hope this helps, let me know if you have any other questions!

Hoki mentioned something:
That you can punch through a Network Relay, if you know the exact ID of the subnet.

However the Wiki only lists one Device Field: The enabeled state of the Network Relay.

[JLarja]

Originally posted by zgrssd:

That is way up on the list how you should never, ever go about programming.

You are more or less correct here, but the point of YOLOL really, really isn't to be an efficient programming language. Consider that it only executes five lines per second and the chips have quite limited capacity for code. Making all variables in a network global really isn't the biggest problem. That said, if you can't handle 20 variables for 20 doors in one global namespace, I don't think a better programming language would help.

-JLarja / Frozenbyte

[zgrssd]

Originally posted by JLarja:

Originally posted by zgrssd:

That is way up on the list how you should never, ever go about programming.

You are more or less correct here, but the point of YOLOL really, really isn't to be an efficient programming language. Consider that it only executes five lines per second and the chips have quite limited capacity for code. Making all variables in a network global really isn't the biggest problem. That said, if you can't handle 20 variables for 20 doors in one global namespace, I don't think a better programming language would help.

-JLarja / Frozenbyte

I can handle 20 names in a global namespace.
The same way I can handle having to work with naked pointers or moving heavy furniture.

As for the limitations: That only makes sense. This is also a Game. Strict limitations have to be applied to make certain the load from user code is not too much.

[Stepbro]

Originally posted by JLarja:

You are more or less correct here, but the point of YOLOL really, really isn't to be an efficient programming language. Consider that it only executes five lines per second and the chips have quite limited capacity for code. Making all variables in a network global really isn't the biggest problem. That said, if you can't handle 20 variables for 20 doors in one global namespace, I don't think a better programming language would help.

-JLarja / Frozenbyte

I have to assume, correct me if i'm wrong, that there will likely be improvements made as we go along aswell? I can't imagine that the YOLOL system will remain the same throughout?

[zgrssd]

Originally posted by Citizen #S9-23:

Originally posted by JLarja:

You are more or less correct here, but the point of YOLOL really, really isn't to be an efficient programming language. Consider that it only executes five lines per second and the chips have quite limited capacity for code. Making all variables in a network global really isn't the biggest problem. That said, if you can't handle 20 variables for 20 doors in one global namespace, I don't think a better programming language would help.

-JLarja / Frozenbyte

I have to assume, correct me if i'm wrong, that there will likely be improvements made as we go along aswell? I can't imagine that the YOLOL system will remain the same throughout?

What kind of improovements are you talking about?

[Stepbro]

Originally posted by zgrssd:

Originally posted by Citizen #S9-23:

I have to assume, correct me if i'm wrong, that there will likely be improvements made as we go along aswell? I can't imagine that the YOLOL system will remain the same throughout?

What kind of improovements are you talking about?

Well i'm just ASSUMING that as time goes on they will add/remove/improve various aspects of the YOLOL system, an example would be the ability to change the time between executing each line, capacity for code, various different objects that perhaps handle code differently, i don't know, i'm not a coder, i'm simply assuming that, given the fact they are aware of issues with the YOLOL system and various aspects of it which are lacking or inefficient, that as time goes on they will make adjustments and changes to improve the way it functions so on and so forth in that general fashion.

It doesn't make any sense to me that they would be aware of many different ways the current system is lacking and NOT look for ways to improve it as time goes on. I mean granted, i assume there will always be limitations that prevent them from doing certain things and so on, but i doubt they'll stop looking for ways to improve/add to the experience.

[zgrssd]

Originally posted by Citizen #S9-23:

Originally posted by zgrssd:

What kind of improovements are you talking about?

Well i'm just ASSUMING that as time goes on they will add/remove/improve various aspects of the YOLOL system, an example would be the ability to change the time between executing each line, capacity for code, various different objects that perhaps handle code differently

The code capacity is a important part of making certain it does not use too many resources.
Different execution times might be doable by using multiple Yolol chips, set to different intervalls.

There is already 3 different chips. The higher teh quality, teh more operations they can do (like Arithmathic).

[JLarja]

zgrssd put it very well: It is a game. The purpose is not to create good, general purpose programming language. Purpose is to create a something fun that fits the universe and other stuff in it.

I'm not involved with designing YOLOL or with Starbase much at all, so I don't know what sort of plans for YOLOL there are. However, it obviously isn't a serious language. Executing one line per unit of time means that writing more stuff to a line makes it faster. So using shorter variables makes it faster (if it lets you put more statements to one line). That's completely absurd, if you compare it to modern languages and processors and how they work.

You can make suggestions and speculate on how YOLOL may change or improve in the future. Looking for ideas from real programming languages may give you some ideas, but you'll probably make better guesses thinking about how games.

-JLarja / Frozenbyte

[zgrssd]

Okay, another question. This tiem about read ambiguity:
If I have two buttons in my network - one with ":ButtonState == 0" and one with ":ButtonState == 1" - what value will this line get:
"if :ButtonState == 0 THEN x ELSE y"
Or is it non-deterministic?