Jump to content

Wireless LUA/Software


Kytheum

Idea Poll  

31 members have voted

  1. 1. Should there be Wireless LUA?

    • Yes
      31
    • No
      0
  2. 2. Should there be an option for a Terminal interface?

    • Yes
      24
    • No
      7


Recommended Posts

[Notice] I did make this thread earlier but I didn't have all the information and this time I also decided I would include a poll for user input. 

 

I have two suggestions. 

 

My first suggestion is Wireless LUA. which allows you to send packets of data to other ships. The packets would have to be sent in a string form but can be converted. This would allow for more complexity into the game allowing some new business's and opportunities to open up in the area. Players and companies can set up communications networks. that you can use to privately message someone across worlds in the game. This can also be used for remote control for example. 

Someone could use this to build a drone. They could tell the program to go left 10 meters and it will send a message to a ship which will translate it and respond accordingly. There could also be a Self-destruct code for instance. Like of a ship is lost and you have a password to destroy it you can. 

 

Syntax would probably go as follows:

 

Sending packets:

packet.send(id,"message")

Reading and Responding:

if packet.read == "7789" then
    self_destruct()
end

The id function is used to represent a specific ship. Every ship would have their own ID and to get it an example of syntax would be:

get_id()

Players would store their ships ID's in a sort of phone book. And telecommunication organisations could make their own massive unified phone book of numbers used to communicate with other organisations ships.  

 

My second Suggestion.

 

My second suggestion is a complete terminal interface on which to program a ship from. Compared to dragging components into different slots and writing code into those components. This could be optional like a button to toggle which views your most comfortable with. The terminal view should allow you to see and access everything about the ship like a startup script and even file management. This would allow people to build an OS on which their ships runs and even sell it allowing more programming possibilities yet again. 

 

 

 

What do you think?

Link to comment
Share on other sites

about your first question, thats a great idea, wireless, radio, whatever

 

SL had this functions, and were very simple

 

was just by using the say and listen functions according diferent channels:

 

//say(channel,ID,msg);

 

channel:   is a integer from - infinite to + infinite

ID:   is everyone or a specific list of IDs

msg: is a string (up to you before to cript that string, and uncript it at reception)

 

//listen(channel,ID,msg);

 

common people are only able to read chat on channel 0, but you could also make a device to spy other channels and repeat it in channel 0

 

 

One big issue, is that scripts are run by clients, so if you are out of range of your scripted listening object/bot, and no one around it either, then it will never recieve the message

Link to comment
Share on other sites

about your first question, thats a great idea, wireless, radio, whatever

 

SL had this functions, and were very simple

 

was just by using the say and listen functions according diferent channels:

 

//say(channel,ID,msg);

 

channel:   is a integer from - infinite to + infinite

ID:   is everyone or a specific list of IDs

msg: is a string (up to you before to cript that string, and uncript it at reception)

 

//listen(channel,ID,msg);

 

common people are only able to read chat on channel 0, but you could also make a device to spy other channels and repeat it in channel 0

 

 

One big issue, is that scripts are run by clients, so if you are out of range of your scripted listening object/bot, and no one around it either, then it will never recieve the message

 

They. Could add a feature that allows scripts to run for a limited time if they are remotely accessed but as message flow halts so does the scripts. And if your communicating ship to ship hopefully they would be in their ship for the script to run. 

Link to comment
Share on other sites

I am not against the terminal but I don't know how it would be possible. An OS into the ship... Maybe a pre compiled coding library but not an entire OS. For the wireless exchange I'm good. During the meeting the team talked about drones circling massive stations or ships, so it will be possible to make (drone with cameras too maybe).

Link to comment
Share on other sites

I am not against the terminal but I don't know how it would be possible. An OS into the ship... Maybe a pre compiled coding library but not an entire OS. For the wireless exchange I'm good. During the meeting the team talked about drones circling massive stations or ships, so it will be possible to make (drone with cameras too maybe).

 

OS as in something like Computercraft. (Minecraft Mod) It acts like MS-DOS and allows you to create files. So you could have a startup file hat executes a command on startup. 

Link to comment
Share on other sites

I'd personally go further and allow (sandboxed) remote code execution.

 

Kinda like html5 programming, you get a "screen", a few processing resources and a link back to the "server" dpu and can execute code on the client DPU.

 

For example for remote interaction interfaces which work on any construct without people having to build complex protocols manually.

 

Say theres a big trade station with automatic dock management.

You ping the station and you get a request for remote computing.

You allow the station a screen and some computing resources and it opens up the dock interface on the screen in your ship, through which you ask for a dock and the station replies by giving you a waypoint for docking through the interface.

Then it closes the link again and the interaction is over.

 

Basically a system to draw GUI elements on cooperating computer systems/screens to allow easy access to automated functions without the community having to build complex communications protocols and software

Link to comment
Share on other sites

I'd personally go further and allow (sandboxed) remote code execution.

 

Kinda like html5 programming, you get a "screen", a few processing resources and a link back to the "server" dpu and can execute code on the client DPU.

 

For example for remote interaction interfaces which work on any construct without people having to build complex protocols manually.

 

Say theres a big trade station with automatic dock management.

You ping the station and you get a request for remote computing.

You allow the station a screen and some computing resources and it opens up the dock interface on the screen in your ship, through which you ask for a dock and the station replies by giving you a waypoint for docking through the interface.

Then it closes the link again and the interaction is over.

 

Basically a system to draw GUI elements on cooperating computer systems/screens to allow easy access to automated functions without the community having to build complex communications protocols and software

 

They could both be implemented. 

Link to comment
Share on other sites

  • 3 months later...

The more you allow me to code the cooler stuff I can do. Wireless Lua scripts would add much to the ability of the player to design complex and unique ship interactions such as a ship splitting in two or controlling drones, and I don't see why wireless codes would be bad for the game. As for terminals I think it makes sense. The terminal will be your access point to the ships computer core. And your ships computer core would have access to every part of the ship, it would streamline coding and also make coding more immersive due to the feeling that your actually entering code into a computer core vs writing code in an engine which makes no logical sense.

Link to comment
Share on other sites

The more you allow me to code the cooler stuff I can do. Wireless Lua scripts would add much to the ability of the player to design complex and unique ship interactions such as a ship splitting in two or controlling drones, and I don't see why wireless codes would be bad for the game. As for terminals I think it makes sense. The terminal will be your access point to the ships computer core. And your ships computer core would have access to every part of the ship, it would streamline coding and also make coding more immersive due to the feeling that your actually entering code into a computer core vs writing code in an engine which makes no logical sense.

Hi new person on the forums.

 

Read on the server tech behind the game's vision. If you can understand what cloud-computing is, you will understand why wireless Lua scripts are not so easy to implement.

 

Lua scripts are operated on a local-grid (your very own RAM) and the update rate from the server is linked to the LOD system (the further you are, the less the rate of updates is).

 

Having drones being operated by the server you could ask, but there's no need for the server to have to operate your drones, on other players' expense - plus the further they reach, the less the frequency of the updates will be, thus, slower reaction times.

 

Lua, are coded onto what is called Control Units (cockpits, screens, etcetera). Their function is to automate things, no write elaboraate programs. You will not be allowed to write code that can bust a person's RAM - oh, you didn't thought of it that way, oops.

 

Feel free to also read, of see an interview with JC Baillie on why the Devs don't want automation (like drones) to begin with. It's not the focus of the game to have things doing combat for you - or mining.

Link to comment
Share on other sites

Ok, I see your points. Now that I think about it yes drones seem like a bad idea. As far as bursting someones ram, yea I wasn't expecting to be able to do that however I was thinking that getting on someones ship, typing up a self destruct protocol for it, then sending it's activation code from my ship later would be something that is possible if Wireless LUA is implemented. Last thing, I don't see why those of us who wanted to couldn't write elaborate programs. If I wanted to set up warning lights in my ship or an asteroid field detection system. Or even an evasive maneuvers pattern I don't see why that would be banned if I was willing to put in the time it would take to create it.

Link to comment
Share on other sites

Ok, I see your points. Now that I think about it yes drones seem like a bad idea. As far as bursting someones ram, yea I wasn't expecting to be able to do that however I was thinking that getting on someones ship, typing up a self destruct protocol for it, then sending it's activation code from my ship later would be something that is possible if Wireless LUA is implemented. Last thing, I don't see why those of us who wanted to couldn't write elaborate programs. If I wanted to set up warning lights in my ship or an asteroid field detection system. Or even an evasive maneuvers pattern I don't see why that would be banned if I was willing to put in the time it would take to create it.

This "Hacking" part, can be emulated by having skill training that allows a code-breaker module use - and its effieciency rate, with a person or boarding party getting to the reactor room, interacting with the engineering console, fuel input at 100% and power output from the reactor at 0% - AKA, Overloading a Reactor the old fashioned way, AKA, by using the same tools an engineer would use to handle the power core / reactor of a ship. Sounds a tad-bit more fun, doesn't it?

 

We don't have to turn hacking in the game into something that may require node.js tutorials.

 

Nobody said you can't write elaborete SCRIPTS. Pulling a flip and pitch like Starbucks from Battlestar Galactica, is a function of scripting, not a program. Calling scripting as programing is a bit of a stretch. Both are coding, but one of the two is WAY WAY WAY more complicated. And Lua are many things, but complicated they are not :P

 

Scripting automated maneuvers, will make or break a ship's reputation. Auto-pilots? All about clever scriptis with even smarter sub-routines.

 

Auto-targeting turrets ( WHEN AND IF THEY MAY COME INTO PLAY ) ? Simple, script the turrets to have functions like "Thruster focus" or "Eye-gouge" to go for the sensors of ship , or some good ol' coordination scripts for a very good headshot to a ship's bridge or cockpit of a shuttle.

 

Those, are elaborate scripts, but they are definitely not programs :P They will not act on their own, you have to flip that switch ON for them to work, similarly to GIMP or any GNU software out there, you can add scripts on it, but they are not active all the time, you have to activate them for their functions to activate.

 

Don't get me wrong, I'd love to code in C++ if possible to program a ship to do maneuvers like crazy, but we got to think of the common fella here, the person who just wants to tweak his ship juuuuust a bit, without having to open up the C Bible, and pray to Dennis Ritichie's ghost for guidance. 

 

The Devs also, have explained there will be a cap on how many lines of script can be parsed per second, so Evil McNugget can't make a script that will bluescreen even the most monstrous of PCs - as you can sell a ship with its scripts on a market via blueprints - or even worse, make a ship so heavy in scripts, that medium range in scripts can't run it solo - and I am not talking of a battleship, that needs many people to begin with for its whole functions to work, which means a crew of 8 people on a bridge, share the collective script load to operate the ship - engineering excluded, if scripts are there to make the operation of the ship's power core / reactor easier to handle.

 

 

Complex proramming, gives rise to complex issues.  If elaborate coding is allowed, backdoors are allowed. It's unavoidable, people will find away to use it to "troll" people.

Link to comment
Share on other sites

a script really is just a dynamically compiled/interpreted piece of software that runs inside/as a part of another (bigger) piece of software.

 

It says /nothing/ about the size and/or complexity of the script.

 

A script can be any size and complexity.

(I have a buddy who wrote stellar dynamics simulations in python in uni... sooo)

Link to comment
Share on other sites

a script really is just a dynamically compiled/interpreted piece of software that runs inside/as a part of another (bigger) piece of software.

 

It says /nothing/ about the size and/or complexity of the script.

 

A script can be any size and complexity.

(I have a buddy who wrote stellar dynamics simulations in python in uni... sooo)

One can also manufacture a fighter jet by hand, without using industrial grade equipment, it doesn't mean it's efficient (or sane) to do so, it means it's an interesting experience worth of a process.

 

¯\_(ツ)_/¯

Link to comment
Share on other sites

a script really is just a dynamically compiled/interpreted piece of software that runs inside/as a part of another (bigger) piece of software.

 

It says /nothing/ about the size and/or complexity of the script.

 

A script can be any size and complexity.

(I have a buddy who wrote stellar dynamics simulations in python in uni... sooo)

 

This is part of the reason why I asked about LUA modules. If we can reference external modules ("scripts") then we can reduce the overall size of our individual scripts. By allowing to do that, it also opens up the possibility for players to sell standalone modules (again, "scripts") as libraries for use in our own scripts. 

 

At first, there won't be many options available, but as time goes on more advanced scripts can be assembled through module dependencies.

 

This goes into another question of whether scripts will just be giant single-paged pieces of code, or if they can be organized into separate files and directories like any other modern software project in the world. 

 

 

As for remote communication, I imagine it could be implemented similarly to the way you do socket programming in LUA. As far as a script goes, you don't care about the way two devices are communication, so long as you can punch in an address and the hardware does the rest for you. That would extend the options from just wireless transceivers to wired network communications. 

 

I'm very interested in the possibility of remote communications through our scripts.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...