- Joined
- Mar 7, 2022
- Messages
- 40
Last article, we talked about the cycle of life with Starbase ships. In this article, I’d like to discuss YOLOL and what changes can be made to enhance our ship designs. Currently, YOLOL allows for chips with 20 lines of up to 70 characters, and each line takes 0.2 seconds to execute. The only manner of segmentation of different YOLOL chip tiers is through limiting what instructions can be executed on certain chips (e.g. trigonometry is only support on Professional YOLOL Chips). If YOLOL is kept in the game, I propose that these limitations be altered to be more intuitive and a little less restrictive.
I think that YOLOL should be free-form character limited and operation rate limited instead of the current setup. Instead of 20 lines of 70 characters, you could have any number of lines that add up to 1400 characters. Another option is to raise the character limit slightly and enforce spacing between words. Because spaces can be omitted in current YOLOL, variable names with keywords like “if” or “end” can be parsed incorrectly as an if logical operator in the midst of two variable names. Removing the character per line and line limit also allows for more readable code because line breaks can be used to split up code, or longer lines could be used when complicated operations are necessary.
The operator rate limit would replace the line rate limit, but it would serve a similar role in keeping code from consuming too much execution time and can still be used for timekeeping in YOLOL. Any operation, whether it’s a variable assignment, mathematical operation, or logical operation would all carry the same “execution cost”. Currently lines can be executed every 0.2 seconds. If an operation had an execution cost of 0.02 seconds, this would mean that you could execute 10 operations in the same time as executing one line of code under the current setup. Please see some examples of how operations would be counted:
A = 5: One operation, as it is a single variable assignment.
A = (B-C): Two operations, as there is a mathematical operation and then the output is used as a variable assignment:
if (A > B) then
C = 5-3
end
Three operations, as there is a logical operation, a mathematical operation, and then the output is used as a variable assignment. The “end” keyword does not count as an operation as it doesn’t do anything besides close the if statement.
A final plausible addition to YOLOL is arrays. Being able to add values to arrays via operations like A[3] = “Hello” would add some additional flexibility to managing sets of data and could lead to shorter code in some circumstances. Through all of these changes, YOLOL is liberated from the constraints of trying to squish code onto as few lines as possible with tiny variable names to make the code execute as fast as possible. Now, more human readable code can be created and shared.
The other option worth considering is completely replacing YOLOL with another language, like Lua or another preferred language. However, before speculating on what a ‘real’ programming language could do, it’s important to consider one of the design motivations behind YOLOL that isn’t readily apparent. According to my sources, YOLOL was designed in such a way that YOLOL equipped ships couldn’t be too radically different from ships controlled entirely manually. For example, a ship with a generator control script can’t do anything that a ship with an attentive endo could do with a lever tied to the fuel chamber rate limit. I’d like to argue that this point doesn’t stand up to what even YOLOL can do. With the existing setup, I’ve seen fully automated miners that can depart, find an asteroid, mine it, and then return to the host station or capital ship with the ore. The only thing that stops whole fleets of these from mining everything in sight is that each needs an endo to host the ship. As such, I think this design guidance should be adjusted or discarded in the face of what any programming language, no matter how simple, can accomplish.
Discarding YOLOL and introducing another programming language is a significant change that involves a lot of work for Frozenbyte, and more work for players than a little reworking of scripts. However, I think that it offers sizeable advantages that are worth considering. I’m drawing a lot of this from the OpenComputers mod for Minecraft (https://github.com/MightyPirates/OpenComputers), which adds simple and limited computers with a heavily sandboxed Lua environment. Instead of interacting with device fields, components could expose libraries and methods that could be called to interact with them. This would simplify coding and open up options that would be clunky with device fields. For example, instead of setting the Reset device field to 1 on a Material Scanner, you could simply call the reset parameter for it. For scanners, you could call a method that tells the scanner to orient to a specific angle and scan with a certain level of power rather than setting all that through multiple device fields.
Whether it’s through overhauling YOLOL to make it slightly more flexible or replacing it entirely, ship programming has quite a lot of room to expand and become more user-friendly. I encourage players and Frozenbyte to look beyond how YOLOL is configured now and think about how powerful ships and systems can become if players are granted the flexibility to interact with them more meaningfully. In the next article, I plan to discuss various types of Ship and Blueprint Deeds and how they can add more social and gameplay flavor in interacting with other people’s ships.
I think that YOLOL should be free-form character limited and operation rate limited instead of the current setup. Instead of 20 lines of 70 characters, you could have any number of lines that add up to 1400 characters. Another option is to raise the character limit slightly and enforce spacing between words. Because spaces can be omitted in current YOLOL, variable names with keywords like “if” or “end” can be parsed incorrectly as an if logical operator in the midst of two variable names. Removing the character per line and line limit also allows for more readable code because line breaks can be used to split up code, or longer lines could be used when complicated operations are necessary.
The operator rate limit would replace the line rate limit, but it would serve a similar role in keeping code from consuming too much execution time and can still be used for timekeeping in YOLOL. Any operation, whether it’s a variable assignment, mathematical operation, or logical operation would all carry the same “execution cost”. Currently lines can be executed every 0.2 seconds. If an operation had an execution cost of 0.02 seconds, this would mean that you could execute 10 operations in the same time as executing one line of code under the current setup. Please see some examples of how operations would be counted:
A = 5: One operation, as it is a single variable assignment.
A = (B-C): Two operations, as there is a mathematical operation and then the output is used as a variable assignment:
if (A > B) then
C = 5-3
end
Three operations, as there is a logical operation, a mathematical operation, and then the output is used as a variable assignment. The “end” keyword does not count as an operation as it doesn’t do anything besides close the if statement.
A final plausible addition to YOLOL is arrays. Being able to add values to arrays via operations like A[3] = “Hello” would add some additional flexibility to managing sets of data and could lead to shorter code in some circumstances. Through all of these changes, YOLOL is liberated from the constraints of trying to squish code onto as few lines as possible with tiny variable names to make the code execute as fast as possible. Now, more human readable code can be created and shared.
The other option worth considering is completely replacing YOLOL with another language, like Lua or another preferred language. However, before speculating on what a ‘real’ programming language could do, it’s important to consider one of the design motivations behind YOLOL that isn’t readily apparent. According to my sources, YOLOL was designed in such a way that YOLOL equipped ships couldn’t be too radically different from ships controlled entirely manually. For example, a ship with a generator control script can’t do anything that a ship with an attentive endo could do with a lever tied to the fuel chamber rate limit. I’d like to argue that this point doesn’t stand up to what even YOLOL can do. With the existing setup, I’ve seen fully automated miners that can depart, find an asteroid, mine it, and then return to the host station or capital ship with the ore. The only thing that stops whole fleets of these from mining everything in sight is that each needs an endo to host the ship. As such, I think this design guidance should be adjusted or discarded in the face of what any programming language, no matter how simple, can accomplish.
Discarding YOLOL and introducing another programming language is a significant change that involves a lot of work for Frozenbyte, and more work for players than a little reworking of scripts. However, I think that it offers sizeable advantages that are worth considering. I’m drawing a lot of this from the OpenComputers mod for Minecraft (https://github.com/MightyPirates/OpenComputers), which adds simple and limited computers with a heavily sandboxed Lua environment. Instead of interacting with device fields, components could expose libraries and methods that could be called to interact with them. This would simplify coding and open up options that would be clunky with device fields. For example, instead of setting the Reset device field to 1 on a Material Scanner, you could simply call the reset parameter for it. For scanners, you could call a method that tells the scanner to orient to a specific angle and scan with a certain level of power rather than setting all that through multiple device fields.
Whether it’s through overhauling YOLOL to make it slightly more flexible or replacing it entirely, ship programming has quite a lot of room to expand and become more user-friendly. I encourage players and Frozenbyte to look beyond how YOLOL is configured now and think about how powerful ships and systems can become if players are granted the flexibility to interact with them more meaningfully. In the next article, I plan to discuss various types of Ship and Blueprint Deeds and how they can add more social and gameplay flavor in interacting with other people’s ships.