[IC] Please increase line count

[BoNes]

Could the line count of the IC be increased? 128 lines is very prohibitive. 256 or even 512 lines would be awesome. Quite often I am stuck cramming code in, and it only hurts readability.

An increased line count would allow more room for comments and blank lines (to help break up the code into sections, for ease of reading). Improving the readability of code would also help new players (who haven't programmed before) get a grip on how it all works.

[Puma]

What are you people doing when running out of lines? You don't even need to do your own sine approximation anymore.

I find myself more often limited by the number of devices on the IC housing, and have plenty of lines of code left unused. So I don't find the 128 lines prohibitive at all. Even my program that automatically searches and tracks traders, that is my most complicated IC10 program, is only 90 lines.

Like I'm just curious, what are you doing that is so complicated that it needs 512 lines?

[BoNes]

Scanning every slot in a vending machine:
- "sweeping" through the machine 1 slot at a time
- checking if any items are "decayed food" if so then dispense it, otherwise if health is under 5% then dispense it... only dispensing a single item until the vending machine is ready again.
- Determining which of the 6 possible food items has the lowest health (outputs to memory)
- Determines how damaged the most decayed item is (outputs decay percent to memory)
- Incrementing 1 of 6 unique counters based on the hash of the item.
- Encodes the 6 counters into a decimal number. Just multiplies by factors of 10, and limits each counter to 9 (outputs to itself)
- Controls the sorter that the vending machine spits straight into. It decides "is this item garbage" or "do we actually want it" (so it does the check for "decayed food" or low health again).

There are some other things that it does too, but I'm away from my game and I haven't touched that code in a couple of days, so I can't check right now.

I'd be able to get even more out of this chip, but the line count has made that impossible.
EG: Incrementing the 6 unique counters:
- 6 lines for aliases
- to reset them at the start of the "sweep" is 6 more lines
- then I have to re-alias them based on the hash of the item so 6 more, the actual hash checks are another 6
- then incrementing them is 6 more... that's 36 lines already (over 1/4 of the available 128 lines). Even without the first aliases (assigning directly to the registers, which is more difficult for non-programmers to follow) is still 30 lines.

If I want the code to be easier to read (should I ever choose to upload it) then it'd be nice to be able to have room to comment the code and leave some white-space lines in there too.

[Captain828]

+1
I've never encountered another game where the user scripting line limit is as prohibitive as this one.
It's impossible to have a human-readable complex script in 128 lines.

What about introducing a Mk2 tier of IC chips?
It would require a Mk2 Electronics Printer and superalloys.
Should support at least 512 lines.

I would still buff the Mk1 IC to 256 lines.

As for any performance concerns with such large chips just auto-force a "yield" after every 128 lines from the last yield.

[BoNes]

@Captain828: I couldn't agree more. There should be multiple tiers of IC chip, with each tier doubling or quadrupling the line count.
As for performance concerns, I've done tests to determine how big the stack is... it's 512 entries. If that's stored as 32-bit numbers that's 2Kb of RAM just for a blank chip, 64-bit numbers would be 4Kb. That's for each chip you have in your world. If they're willing to burn so much RAM for the stack, why not burn some more for adding extra lines too.

[Captain828]

@Heightmare what are your thoughts on this?

I've also seen a few upvoted reddit posts asking to increase the limit so we're not the only ones in this thread.
https://www.reddit.com/r/Stationeers/comments/lej44p/so_i_made_a_tsic_compiler_but_i_cant_use_it/
https://www.reddit.com/r/Stationeers/comments/hd1th7/dear_devs_would_you_please_consider_giving_ic/

[Puma]

BoNes, the stack is 64-bit floats, just like the registers. That is 4KiB of memory for the stack. In comparison the memory for the code is 128×128 bytes = 16KiB. So adding a stacks worth of memory for the code would only give you 32 extra lines. And that's because the code sits uncompiled in memory, with fixed length per instruction.

There is huge potential for performance optimization here. Upon export the source code could be given a globally unique reference number, and then using said reference the source could be saved to disk, and then compiled to lua bytecode that stays in memory along with the GUID number.

The bytecode would take up way less memory and run with way fewer CPU resources.

And then when you import from a chip, the game could look up the GUID, and load the source code with comments and everything from the disk.

[BoNes]

@Puma: So it saves that entire block of text you see on the computer? I figured it would at least trim the whitespaces. It makes sense to have the whole 16k block in memory for editing it on the computer, but when you hit export it should trim the whitespace (most of it is just empty spaces after all). Once trimmed, it could be compressed easily as it is all alphanumeric... you don't need the 8-bits per byte only 5-bits (so that'd save 37.5% per byte).

Then that could be saved to disk for when you need to import. It'd be easy to decompress it back. After that, then it's on to your idea of compiling it to LUA bytecode and freeing the memory up. The issue I can see would be increased load times because you'd have to load all the code from disk and compile it to bytecode whenever you load a save.

But we are splitting hairs here. 20k in today's world is bugger all. Even if you literally have 10k chips that's still only 200Mb. When Stationeers can use memory well above 4-8Gb, it's a drop in the ocean. I would happily pay an extra few meg to have the line count doubled or quadrupled, especially if we have tiered ICs where I can choose "OK this one needs the extra lines". And given how much people have mentioned it since ICs came about, I know I wouldn't be the only person.

[Puma]

No no no. The bytecode would be stored with the save. It would be insane to compile other than when exporting the code to a chip. You compile once, then keep the bytecode forever. Curretly the source is loaded and written with the save, and loading/saving the bytecode would be more efficient.

And you can't compress running code.

And the reason they can't currently trim the ends of lines, is because they need the beginning of each line to be at a specific memory address.

But you can't first make the argument that 4KiB is "they're willing to burn so much RAM for the stack" and then immediately say that 20KiB is nothing at all. It makes you look like a guber. Either 4k matters or it doesn't. Make up your mind.

[Captain828]

@Puma I think you have a good point but that sounds like a lot more work than just changing the current line limit.

As for compression, it can still be done during save/load.

[BoNes]

@Puma: I did say "they're willing to burn so much RAM for the stack" as a way of saying that the devs are willing to sacrifice memory for it, so they could be just as willing to burn some more to increase the line count. Yes, it is true that every byte counts when developing a game... less memory usually means better performance (which was what made me say it in the first place, I've messed around in the past with coding 3D engines). I didn't know that they'd used 16Kb to store the 128 lines, I'd expected a more optimised approach.

But at the end of the day we live in a world where gigabytes of RAM are easy to come by, and truth be told 20Kb (or 68Kb if we go to 512 lines) per chip is still not too much to sacrifice (but it will obviously have it's pros and cons).

[DeadMechGaming]

Originally posted by Captain828:

+1
I've never encountered another game where the user scripting line limit is as prohibitive as this one.

Space Engineers

[Captain828]

@DeadMechGaming SE Programmable Blocks support 100k lines since last year :)

[DeadMechGaming]

Originally posted by Captain828:

@DeadMechGaming SE Programmable Blocks support 100k lines since last year :)

Ah, my bad. I stopped scripting in it a long time ago :P

[Zefnoly]

I dont even love coding outside of this game and I managed to cram up my avaliable code lines two or three times on more complex code. Especially my airlock hangar code that would work as similarily as the "stock" airlocks as possible. Just being modular variant that supports multiple interior and exterior vents + the large airlock doors.

I had to do compromize in this code to make it smaller because I need 5 different states. 4 loops and one startup part where it checks the state of the airlock as the game starts. two loops where it is either exterior or interior cycled. And the cycling between the two with emptying and filling of interior and exterior gases. This code was VERY much limited by the amount of lines. I had to remove a lot of comment lines and introductional description to remind me how exactly the airlock should be setup with this code.

Personally I do not see why 128 lines should be the limit. 256 lines would be perfect. Not only would I be able to make my script work even better or even possibly allow more additions, like support for lights and multiple buttons etc... I would be able to have proper amount of comment lines and make this code far more readable.

[Celery Man]

Yeah, 128 lines is more "annoying" than "fun constraint", especially because it punishes your SOURCE code for good-practice things like comments, constant definitions, aliases etc. It just encouraged me to write a less-terrible compiler so that I can write sensible variable names, and use an external code editor. I have spent hundreds of hours playing ridiculously constrained programming games (Zachtronics etc.) and I *♥♥♥♥♥♥♥ hate* the way this has been implemented.