YOLOL-rack is too physical.

[anton_stezhkin]

To fully understand what I mean - watch the video. It's over 4 hours and in russian
But the problem is understandable without words. The poor guys spend as mauch time trying to catch the chip and stick it into the rack as on writing the script.
Sometimes having a programmable chip is fun (e.g. in combat or during a crash).
Sometimes - NOT. When you try to use it for programming.

That's why i have a suggestion.
1. Make coding and chips independent. So it's posible to code a script now, save it to some library and record it to a chip later.
2. Once you grab the chip it goes to the inventory
3. Add script name to the chip's surface. Add readme to the script
4. Add user rights to the scripts

I made a mockup of what the interface could be like Figure-1 is scripting interface. Figure-2 is YOLOL-rack interface

 

[Cavilier210]

A primary core would be a nice addition, where we can add code directly, but its not removable easily from the ship. Which would risk its capture.

 

[XenoCow]

I think there are some good parts about this. I think that coding directly to chips shouldn't have to be forced on players, just as building in the universe isn't.

In thinking about a way to make this idea Starbase-y, I think I might have an idea that fits the bill.

I'm imagining a "programming terminal" It has a screen that can be interacted with much like a current chip (focus or write to with alt+click). On that screen is an advanced YOLOL editor that has features of an IDE where you can set up environmental variables (what would be devices on your ship) and errors are pointed out in more detail.

In addition to the IDE, you could stamp chips like you are suggesting so that you can copy a saved program to chips to then plug into your ships.

All the saved programs would have to be saved on a new type of YOLOL chip called a "template" that is as able as a professional ship with the addition of a description/title section. Both these and memory chips would then plug into the terminal or an external database so that the environmental variables could be stored and the templates written and read from.

The templates could be moved around, edited in-universe, or even plugged into ships, but they wouldn't benefit from the IDE of the terminal and would be more expensive than normal chips.

 

[anton_stezhkin]

A primary core would be a nice addition, where we can add code directly, but its not removable easily from the ship. Which would risk its capture.

I didin't suggest a "primary core", whatever that means.
1. The script library is a part of the player's profile, not the ship. Because players will have them anyway. By saving their scripts to text files or something. Why not make it an ingame mechanics. I's more handy and reduces the number of unique scripts.
2. According to my vision the YOLOL rack is still a physical object like now (the chips fly around if it crashes), but the chips are pluged in and out by players not like physical objects, but like inventory items. And it's not necessary to pull the chip out to edit it. You just press a button and if you have rights you access the rack interface to quickly browse and edit the scripts.
3. The chip also has access rights.
4. maybe hacking chips you are not allowed to read or edit colud be a part od the game.

 

[anton_stezhkin]

I think there are some good parts about this. I think that coding directly to chips shouldn't have to be forced on players, just as building in the universe isn't.
In thinking about a way to make this idea Starbase-y, I think I might have an idea that fits the bill...

- I like your idea about programmator (IDE-terminal) as a separate block. Maybe a special body part or a tool is even better.
- The idea of "template chips" however is controversial. Why buy thmplate chip if you can have a text file on your computer? What happens if you loose the chip? What if you need to paste a script and your template chip is far-far away? My main point is that ingame mechanics should be more handy then workarounds, using other programs.
- I suggest yet other blocks instead of template chips: a ship block - router, that connects to the antenna block and gives access to Eosnet, where you can upload/download scripts. And a station block - retranslator that makes Eosnet available in some radius. Eosnet is something like an ingame software market and a quick way to get information on global things like ore prices, current pirate locations, where to fly and whom to shoot...
- I think that chips should always have visible name and a simple way to get the idea what the script is about. If all goes well, SB will have many players, and 70-90% of them will want to just fly around and do PEW-PEW!, not reading someone's code.