Make YOLOL playable

Joined
Nov 27, 2021
Messages
5
#1
Hello! I would like to buy a game, but some things stop me from doint it.
One of it is current YOLOL work method.
Delay between lines is frustrating. I code, but delay makes heavy code useless.
I suggest to make all the core run instantly, but with delay 500 ms between executions. At least for high tier chips.
Or something like that:
Tier:
  1. Delay 200-400 ms between lines.
  2. Delay 500-1000 ms between executions.
  3. Delay 200-500 ms between executions.
 
Joined
Nov 27, 2021
Messages
5
#2
Additional idea: make YOLOL heat while being active. Connect it to radiators to cool down. And add additional modes.
Tier:
  1. Delay 100-400 ms between lines. Heat 200-2000 watts (min-max exponentially). Passive cool down 200 watts. No underclock on overheat.
  2. Delay 1000-4000 ms between executions or 50-200 ms between lines. Heat 200-2500 watts. Passive cool down 200 watts. Optional underclock on overheat.
  3. Delay 200-1000 ms between executions. Heat 200-8000 watts. Making 900 ms delay between executions makes it heat 500 watts. With 500 ms delay it would be 2 kW. Passive cool down 200 watts. Additional slow work mode for 4000 ms delay between lines and 200 watts heat. Optional underclock on overheat. More overheat durability.
On overheat chips slowly damage slowing their work speed. Passive cool down data is for higher working temperature.
 
Last edited:
Joined
Sep 7, 2021
Messages
12
#3
Appreciate the feedback, here's my take;

The line delay being so slow is very intentional. If you've ever played a gmod sandbox map where a spinning cube kills everyone on the map as soon as they spawn with LUA you'll see the reason for that. It's a limitation that's intended to be worked within and compensated for, and people have dome some pretty impressive stuff with it. I've seen arcade machines, auto-turrets, autopilot systems, autominers and casinos running off just Yolol. Personally I find the limitations kinda fun in themselves, makes things feel clunky and analogue.
 
Joined
Nov 27, 2021
Messages
5
#4
Text updated.
Appreciate the feedback, here's my take;

The line delay being so slow is very intentional. If you've ever played a gmod sandbox map where a spinning cube kills everyone on the map as soon as they spawn with LUA you'll see the reason for that. It's a limitation that's intended to be worked within and compensated for, and people have dome some pretty impressive stuff with it. I've seen arcade machines, auto-turrets, autopilot systems, autominers and casinos running off just Yolol. Personally I find the limitations kinda fun in themselves, makes things feel clunky and analogue.
Thank you for your answer. Here is more ways to avoid it. Here is many limitation have already i wrote.
Here is a way to make YOLOL overclocked chips heat so much so one chip would require 4 radiators. 4 radiators require additional armor. It is cost, mass and signature size incremence.
Let's take cube with autoaim. It is possible to be killed with guided missile running on YOLOL chip very easy. Just lock it at safe distance and launch long ranged missile or by autoaim itself. Also that cube will have code running every approximately 500 ms delay. It is making possible of killing it. The cube being easy-to-kill target with expensive chip (cost may be raised for t2 and t3 chip) would be pointless to be build. Running that script would be impossible on t2 chip (must be done so).
Additional idea: make EMP weapons which will stop for some time or kill that chips. I saw that mechanics. It would paralize unprotected ships not controlled by players (or ship parts). Protecting a ship against EMP would raise it cost and size making them very expensive. Also make t1 chips more sustain against EMP attacks (wider wires, internal EMP protection allows that in real life). So basic systems would continue to run. Other systems are not affected by EMP. So it affects only t2 and t3 YOLOL chips.
 
Joined
Sep 4, 2021
Messages
61
#5
Appreciate the feedback, here's my take;

The line delay being so slow is very intentional. If you've ever played a gmod sandbox map where a spinning cube kills everyone on the map as soon as they spawn with LUA you'll see the reason for that. It's a limitation that's intended to be worked within and compensated for, and people have dome some pretty impressive stuff with it. I've seen arcade machines, auto-turrets, autopilot systems, autominers and casinos running off just Yolol. Personally I find the limitations kinda fun in themselves, makes things feel clunky and analogue.
I personally find it very discouraging to be limited to 5 Hz. While I understand the reason behind it I would like to stress that 5 Hz is not enough to make any sort of sophisticated weaponry just like a ping of 200ms is not suitable for any shooter game.
Especially regarding torpedos and automation. Torpedos could be made more potent by allowing them to work with higher clocking.
Automation however is pretty useless with 5 Hz. Yes, it is possible to create an automated mining ship but from what I have seen, it takes something around 30 minutes to mine one asteroid with it. Maybe that's okay to discourage an automated mining metagame or an automation meta in general but on the other side it is already very limited since it works only within one kilometer of an endo...
I don't think that we need several thousand operations per second like with LUA but more freedom would actually be nice.
I like jijiji's idea to make more computing power achievable but expensive.
Like, for every 10% reduction of delay between lines you could demand 50% more energy or something like that making sophisticated and high tech very costly indeed.
That way you allow for more flexible design while avoiding spinning killer cubes.
 
Joined
Mar 19, 2021
Messages
133
#6
The torpedo-brain should definitely be faster then 5Hz.
As for long-range autominers - they are considered heartical by the devs. but if there is a away to attach a mininng-laser to a torpedo brain there can be some sort of automining. I never used a torpedo. Does it send back any data or it just follows the trageting ray and reacts to proximity?
 

CalenLoki

Master endo
Joined
Aug 9, 2019
Messages
741
#7
The torpedo-brain should definitely be faster then 5Hz.
As for long-range autominers - they are considered heartical by the devs. but if there is a away to attach a mininng-laser to a torpedo brain there can be some sort of automining. I never used a torpedo. Does it send back any data or it just follows the trageting ray and reacts to proximity?
Torpedo brain is just yolol + laser sensor.
Laser sensor outputs distance, pitch and yaw offset from the target painted with laser designator
It can be hooked to the ship yolol simply by keeping the torpedo inside the launcher.
Auto miners have been done, and devs are pretty ok with that idea. Only limitation is that you need to leave your AFK character in the ship so it can stay loaded. And there are no ways to load/unload ships automatically yet.
 
Joined
Nov 1, 2021
Messages
39
#8
I personally find it very discouraging to be limited to 5 Hz. While I understand the reason behind it I would like to stress that 5 Hz is not enough to make any sort of sophisticated weaponry just like a ping of 200ms is not suitable for any shooter game.
Especially regarding torpedos and automation. Torpedos could be made more potent by allowing them to work with higher clocking.
Automation however is pretty useless with 5 Hz. Yes, it is possible to create an automated mining ship but from what I have seen, it takes something around 30 minutes to mine one asteroid with it. Maybe that's okay to discourage an automated mining metagame or an automation meta in general but on the other side it is already very limited since it works only within one kilometer of an endo...
I don't think that we need several thousand operations per second like with LUA but more freedom would actually be nice.
I like jijiji's idea to make more computing power achievable but expensive.
Like, for every 10% reduction of delay between lines you could demand 50% more energy or something like that making sophisticated and high tech very costly indeed.
That way you allow for more flexible design while avoiding spinning killer cubes.

.5 hz is more than sufficient to guide a torpedo to a target. It's been done.


Remember we used to do this shit back when the most advanced computers were damn near that slow - and primarily we did it by ruthlessly optimizing or delegating more to mechanical devices than to code or processors.

Like for example, that automated mining ship that takes a ridiculous 30 minutes to mine an asteroid could accomplish pretty much the same task in 5 minutes or less by:

A) Not attempting to find the absolute closest asteroid
B) Making a mining setup that doesn't try to exactly efficiently mine an asteroid and instead use an array of lasers and drive over it slowly.


.2 seconds is actually a totally fine delay for almost anything except for advanced weapons systems, which I think is probably the design goal here - if it were much faster, auto-aim for turrets would be somewhat trivial to do. That would get really bad - allowing the computer to aim for you makes games not fun VERY fast.
 
Joined
Sep 4, 2021
Messages
61
#9
.5 hz is more than sufficient to guide a torpedo to a target. It's been done.


Remember we used to do this shit back when the most advanced computers were damn near that slow - and primarily we did it by ruthlessly optimizing or delegating more to mechanical devices than to code or processors.
Yes, but you are not talking about 500mph Cruise Missiles here but 26kts slow Mk37 Torpedos in an environment that was limited to 40-50 kts maximum speed. Also, we don't have a lot of mechanical devices to work with
Perhaps I have a faulty perspective on torpedos here though. They aren't able to lead and pursue targets on their own anyways since they lack sensors to generate Information on their own. Probably, they are actually intended for the really big ships that do indeed not need much more than 5 Hz.

Like for example, that automated mining ship that takes a ridiculous 30 minutes to mine an asteroid could accomplish pretty much the same task in 5 minutes or less by:

A) Not attempting to find the absolute closest asteroid No auto-miner project I saw did that.
B) Making a mining setup that doesn't try to exactly efficiently mine an asteroid and instead use an array of lasers and drive over it slowly. This is not the core of the problem.
The real issue is navigation. You cannot really navigate very accurately in an automated system with 0.2 seconds delay if you want to make it fast. You are pretty much forced to use minimum thrust to minutely adjust your course and nudge your ship in the right direction just that tad bit more. This is what takes really long. Especially because your ship doesn't always fly straight when you accelerate which adds to the problem and it adds a lot. Finding an asteroid, that's not a big concern, nor is mining. The act of getting from A to actual B is what kills it here.


More computing power would speed this process up. And binding higher clock speeds to an exponentially increasing energy and/or heat cost would be a compelling aspect of trying to squeeze maximum use out of an automated mining ship. More computing power means possibly much more complexity which is almost always a welcome aspect to sandbox games at least as long as it does not completely go out and beyond the capabilities of the standard player. I am not talking about Harvard University stuff and I am not trying to advocate for Silicon Valley type of systems here but please let us have the possibility of speeding up the clock, at least somewhat decently.

.2 seconds is actually a totally fine delay for almost anything except for advanced weapons systems, which I think is probably the design goal here - if it were much faster, auto-aim for turrets would be somewhat trivial to do. That would get really bad - allowing the computer to aim for you makes games not fun VERY fast.
That is the reason why high computing power must be bound to a very steep energy demand. These kinds of weapon systems would only be feasable on larger ships that really can provide the power for that. Yes, that would mean that it is very hard to attack and you actually need to think about what you are doing if you do not plan on zerg-rushing it. On the other hand, it is a very easy target since it is really big and one precise strike on its power banks would already cripple it severely. You could also think about tactics like focussing fire on one spot to create an opening or deploying long range weapons to pull some of its teeth from afar. Also, having to invest a lot into power supply means that you are shorter on other things like speed for example.
It would significantly impact the meta game, no doubt about that, but we cannot say yet if in a negative or positive way.
To not try it out (once enough players are there to actually have a metagame) would be a wasted opportunity though, imho.
 

XenoCow

Master endo
Joined
Dec 10, 2019
Messages
588
#12
I personally find it very discouraging to be limited to 5 Hz
We are only limited to 5Hz for output. There are no such constraints, aside from line character limits, for operations per second. If you can parallelize a program sufficiently, you can have thousands of operations per second. The problem is then figuring out how to make your program run without knowing whether you are working with the last cycle's data or the current cycle's. The exact timing of the operations per-chip is not known and not the same across chips.

For time sensitive things (like auto-pilot kind of stuff) as long as your system is robust against a delay of 0.2s, you can do as much as you want in that time.

For example, a rangefinder based missile might have one chip that reads the data from the range finders and ranks the directions based on the read distances, then another might order those directions to find out which is the best direction to go in. Meanwhile another chip updates the thrusters based on the current best direction. With very small variable names, :A, :B, etc, this can all be done at one line per chip. If you then did some predictive calculations, you may be able to beat the limited update time by preparing the missile for not only this cycle's necessary action but put it in the best position to easily interpret the next cycle's data.

When I design complicated YOLOL projects, I don't think of the project as a programming problem, I instead think of it as a circuitry problem. Each chip is like an integrated circuit that has inputs and outputs and the whole system runs simultaneously.
 
Top