Jump to content
NQ-Nyzaltar

DevBlog: LUA Scripting and Distributed Processing Units (DPUs)

Recommended Posts

As soon as we get hands on with LUA inside of DU then tutorials and other articles will be posted for the players that aren't coders, to at least give them a chance to understand and maybe fiddle with it themselves :)

Share this post


Link to post
Share on other sites

I'm very hopeful that in time, and with a good community, those who had never been able to use LUA and scripts may be taking their first steps into the world of coding and through such the game promotes interactive teaching to people who had only dreamed of being able to write their own scripts. That would be another great stride forward for NQ and DU!

Don't worry. Lua was made for non-programmers in the 90s, and in those years people were savage beasts who couldn't tell ROM from RAM. If you know how to do the whole with putting words together and write, you will be a Lua hotshot coder in no time.

 

 

Its manual is literally 10 pages long. A printer has 30 pages long manual. Just saying.

Share this post


Link to post
Share on other sites

There are plenty of videos and tutorials online, it really looks not that hard

It's really coming down to "If XX then" and before that "While XX do".

 

"While XX do" goes before "if XX then", calculations are done with the standard mathematical model of putting things inside parenthesies and stuff and the in-between need the 10-page manual of entries you can insert for functions like creating a table for inventories of items in a game, or having even input readouts on the interpreter for keybinds.

Share this post


Link to post
Share on other sites

Don't worry. Lua was made for non-programmers in the 90s, and in those years people were savage beasts who couldn't tell ROM from RAM. If you know how to do the whole with putting words together and write, you will be a Lua hotshot coder in no time.

 

 

Its manual is literally 10 pages long. A printer has 30 pages long manual. Just saying.

 

Exactly but I am sure many new players will be scared about this because to those who know nothing about it they probably think it's going to be much harder than it is .. and because of that never try to master it. With a good community, people will see how easy it can be and might even spark interest in those who had never thought it a reality to take it even further than just LUA.

Share this post


Link to post
Share on other sites

Exactly but I am sure many new players will be scared about this because to those who know nothing about it they probably think it's going to be much harder than it is .. and because of that never try to master it. With a good community, people will see how easy it can be and might even spark interest in those who had never thought it a reality to take it even further than just LUA.

I know, which is jarring. Anyone who looks at Lua quickly figures out the toughest part are the "==" part of the syntax :P I guess it's people's fear that programming is some form of witchcraft and that makes them hesitant. Of course, it's not.

Share this post


Link to post
Share on other sites

Writing code for use in games is one of my favorite ways to play (I was going to implement the Nand2Tetris ALU in Fallout 4 but their logic gate implemention is flawed), so the LUA scripting is one of the more interesting parts of the DU project to me.

 

That said, I'm somewhat concerned about the potential for abuse that it represents -- and that the response to the abuse by the developers will ruin the fun for the non-abusing scripters.

 

The problem as I see it is that:

 

  • LUA scripts have to run inside the client, and
  • You can't trust the client, and
  • Any closed control loop (ie: while (true) { sense_environment(); change_environment(); } ) == a bot, and
  • Even if you can't script a closed loop, any external regular trigger (ie: a keypresser) closes the loop.

As soon as you have bots (drones, aimbots, miningbots, etc.), everything goes to hell. Aimbots destroy the fun of combat, miningbots destroy the economy, etc.

 

It occurs to me that one way to begin to address this concern is to place limits on what aspects of the environment LUA scripts can sense; in particular, the external sensors available to them should be restricted in what information they can provide. So for example, a proximity radar might simply return the distance to the closest object within a 90-degree arc; this coupled with a GPS (Galactic Positioning System  :D ) device would let you build a collision-avoiding autopilot, but not a useful combat autopilot/aimbot.

 

I look forward to seeing more information from the developers about the scripting aspects of the game, so that the community can tiger-team potential problems and solutions. And, of course, I will do my best during Alpha to explore the edge cases of the scripting environment.

Share this post


Link to post
Share on other sites

It has been stated that you will be able to make AI drones, and I've assumed your own targeting system as well. We have similar intentions with drone swarms and automated defenses. We are a few in number but tend to operate on the scale of a large group so we need to be able to automate things. But I'd say you're thinking to small.

 

My group has been developing a much more sinister plan. We're just waiting to see if all the features we need to pull it off will be implemented.

You're going to slave a fleet of battleships to a drone hive aren't you?

Share this post


Link to post
Share on other sites

Writing code for use in games is one of my favorite ways to play (I was going to implement the Nand2Tetris ALU in Fallout 4 but their logic gate implemention is flawed), so the LUA scripting is one of the more interesting parts of the DU project to me.

 

That said, I'm somewhat concerned about the potential for abuse that it represents -- and that the response to the abuse by the developers will ruin the fun for the non-abusing scripters.

 

The problem as I see it is that:

 

  • LUA scripts have to run inside the client, and
  • You can't trust the client, and
  • Any closed control loop (ie: while (true) { sense_environment(); change_environment(); } ) == a bot, and
  • Even if you can't script a closed loop, any external regular trigger (ie: a keypresser) closes the loop.

As soon as you have bots (drones, aimbots, miningbots, etc.), everything goes to hell. Aimbots destroy the fun of combat, miningbots destroy the economy, etc.

 

It occurs to me that one way to begin to address this concern is to place limits on what aspects of the environment LUA scripts can sense; in particular, the external sensors available to them should be restricted in what information they can provide. So for example, a proximity radar might simply return the distance to the closest object within a 90-degree arc; this coupled with a GPS (Galactic Positioning System  :D ) device would let you build a collision-avoiding autopilot, but not a useful combat autopilot/aimbot.

 

I look forward to seeing more information from the developers about the scripting aspects of the game, so that the community can tiger-team potential problems and solutions. And, of course, I will do my best during Alpha to explore the edge cases of the scripting environment.

I'm pretty sure they said that pvp would be done on a lock and fire system.  So if you had an advanced aimbot it would be the same but with higher probabilities to hit.  And as far as mining drones, I think I remember them saying you had to be within a certain range of AI controlled vessels for them to be active?  Maybe I'm remembering a suggestion with the second one.

Share this post


Link to post
Share on other sites

Writing code for use in games is one of my favorite ways to play (I was going to implement the Nand2Tetris ALU in Fallout 4 but their logic gate implemention is flawed), so the LUA scripting is one of the more interesting parts of the DU project to me.

 

That said, I'm somewhat concerned about the potential for abuse that it represents -- and that the response to the abuse by the developers will ruin the fun for the non-abusing scripters.

 

The problem as I see it is that:

 

  • LUA scripts have to run inside the client, and
  • You can't trust the client, and
  • Any closed control loop (ie: while (true) { sense_environment(); change_environment(); } ) == a bot, and
  • Even if you can't script a closed loop, any external regular trigger (ie: a keypresser) closes the loop.

As soon as you have bots (drones, aimbots, miningbots, etc.), everything goes to hell. Aimbots destroy the fun of combat, miningbots destroy the economy, etc.

 

It occurs to me that one way to begin to address this concern is to place limits on what aspects of the environment LUA scripts can sense; in particular, the external sensors available to them should be restricted in what information they can provide. So for example, a proximity radar might simply return the distance to the closest object within a 90-degree arc; this coupled with a GPS (Galactic Positioning System  :D ) device would let you build a collision-avoiding autopilot, but not a useful combat autopilot/aimbot.

 

I look forward to seeing more information from the developers about the scripting aspects of the game, so that the community can tiger-team potential problems and solutions. And, of course, I will do my best during Alpha to explore the edge cases of the scripting environment.

Scripts run locally on your PC, which requires you to be present near the DPU blocks. You can assign operators in your organisation to run the automated factories in your stead, while you run around space, meeting new people and prying open their hulls with superior firepower.

 

 

The locally-run aspect, also reduces the framerate issue on other players, just because a person may elect to make the equivalent of a Drone Swarm for their private drone fleet. So, DUAL, does it the way Space Engineers should have done it :P

Share this post


Link to post
Share on other sites

Scripts run locally on your PC, which requires you to be present near the DPU blocks. You can assign operators in your organisation to run the automated factories in your stead, while you run around space, meeting new people and prying open their hulls with superior firepower.

 

 

The locally-run aspect, also reduces the framerate issue on other players, just because a person may elect to make the equivalent of a Drone Swarm for their private drone fleet. So, DUAL, does it the way Space Engineers should have done it :P

Firstly, do you have any confirmation whether or not scripts will run locally on the users PC? This is a massively important feature, as it determines whether or not the game could be feasible to begin with. I have put thought into a number of systems, any one of which, would brutally murder a server.

 

One is an accidentally bugged code which features an infinite loop that runs a bunch of intensive commands. If these ran on a server, you could on-demand crash local nodes.

 

Another is an cleverly constructed code designed to replicate itself. That is, teach a robot to mine resources, develop them into another robot, and copy it's data morphed for cooperative play for that other robot. In other words, a literal hive mind that, once started, will reproduce exponentially.

 

While you're building your hive mind, you could incorporate machine learning to spontaneously adapt and develop new code automatically to improve the hive-mind's function. Granted no one has done this in real life yet, but it is still possible someone could reach the singularity in-game and no one can know what will happen next. (Although perhaps the developers of Dual Universe would be more than happy to facilitate that development)

 

IFF code ran on local computers, this sort of game play would merely crash the users PC, and not the server as a whole.

 

Of course, there are also a number of things that can be done to limit the above from ever becoming an issue at all. For example, if you made it local to a certain distance ®, you'd prevent players from using more than r^3 DPU's which could potentially have their own limits on computational power. If you made it local to the player with some upper threshold of active DPU's or DPU operations per second, then you could prevent players from expanding too much by slowing down their operations (like EvE's time dilation).

 

There are also a number of things that could be done that would eliminate various methods of play (in my opinion, less desirable), for example preventing AI from creating or activating other AI.

 

Of course, if you let players crash their own PC, now you've opened the door to effectively installing a virus via your game, by allowing players to sell code that potentially damages the buyers PC. Which might now have legal ramifications for the developers, since it might be unreasonable to expect a reasonable video-game to burn out your recommended spec meeting hardware.

 

I'm still quite the skeptic, though, so it'd be really nice if the devs have already thought of this stuff before I have.

Share this post


Link to post
Share on other sites

Firstly, do you have any confirmation whether or not scripts will run locally on the users PC? This is a massively important feature, as it determines whether or not the game could be feasible to begin with. I have put thought into a number of systems, any one of which, would brutally murder a server.

JC has already cobfirmed that they run locally in a few videos, as well as the Kickstarter lunch video.

Share this post


Link to post
Share on other sites

Firstly, do you have any confirmation whether or not scripts will run locally on the users PC? This is a massively important feature, as it determines whether or not the game could be feasible to begin with. I have put thought into a number of systems, any one of which, would brutally murder a server.

 

One is an accidentally bugged code which features an infinite loop that runs a bunch of intensive commands. If these ran on a server, you could on-demand crash local nodes.

 

Another is an cleverly constructed code designed to replicate itself. That is, teach a robot to mine resources, develop them into another robot, and copy it's data morphed for cooperative play for that other robot. In other words, a literal hive mind that, once started, will reproduce exponentially.

 

While you're building your hive mind, you could incorporate machine learning to spontaneously adapt and develop new code automatically to improve the hive-mind's function. Granted no one has done this in real life yet, but it is still possible someone could reach the singularity in-game and no one can know what will happen next. (Although perhaps the developers of Dual Universe would be more than happy to facilitate that development)

 

IFF code ran on local computers, this sort of game play would merely crash the users PC, and not the server as a whole.

 

Of course, there are also a number of things that can be done to limit the above from ever becoming an issue at all. For example, if you made it local to a certain distance ®, you'd prevent players from using more than r^3 DPU's which could potentially have their own limits on computational power. If you made it local to the player with some upper threshold of active DPU's or DPU operations per second, then you could prevent players from expanding too much by slowing down their operations (like EvE's time dilation).

 

There are also a number of things that could be done that would eliminate various methods of play (in my opinion, less desirable), for example preventing AI from creating or activating other AI.

 

Of course, if you let players crash their own PC, now you've opened the door to effectively installing a virus via your game, by allowing players to sell code that potentially damages the buyers PC. Which might now have legal ramifications for the developers, since it might be unreasonable to expect a reasonable video-game to burn out your recommended spec meeting hardware.

 

I'm still quite the skeptic, though, so it'd be really nice if the devs have already thought of this stuff before I have.

It's in the Kickstarter video champ.

Share this post


Link to post
Share on other sites

So scripts on objects you own will only run when you're online.  So your building's automated defenses will only be operable when you are playing but when you're on vacation, your building is just sitting there waiting to be turned into scrap.  Is it possible for the scripts to run on a server leased by the player or an organization, for example, instead of on the client?

Share this post


Link to post
Share on other sites

 

One question about the constructs and DPU devices... Where will they be executing?  On the user's local machine if they are in the area, or is there a hosted cloud / server service for processing all of these DPU events?  
 
My question is largely because if run locally, the effectiveness of DPU code would be higher on machines they have stronger CPU power, giving a possible advantage to more powerful machines as they theoretically can run more DPUs at once without lagging down the game.

 

If you had any early experiences with Second Life then this scripting architecture is relatively familiar. It's a big improvement on linden labs original LSL but many of the features that people are debating have been in the linden scripting language for 8 years.  Home computer processing power is not a major variable. The scripts in many cases, even the turret attacking you, is running at your end.  The fun starts when either a script is out of date or does not load at all.  The protections and permissions systems is not easy but not new. 

Share this post


Link to post
Share on other sites

Apart from the mentioned stuff todo with flying ships. What other sorts of API do you expect to give designers access to?

 

Personally I would be interested in things like:

 

- Making changes to the local rights management such as tagging players in response to certain events.

- Handling events when trades are executed in market blocks.

- Observing weapon fire, and damage to attached structures.

- Conducting trades, accepting deposits and giving out items (yes I know this is done by the market block but there are scenarios where being able to have experct control would be interesting)

- Showing GUIs on terminals and interacting with players.

- Sending messages, to individuals and groups of players

 

Additionally, if DPUs are run on each client that comes into contact will there a way to be persist state and keep it synchronized between players using the same DPU? 

Share this post


Link to post
Share on other sites

Apart from the mentioned stuff todo with flying ships. What other sorts of API do you expect to give designers access to?

 

Personally I would be interested in things like:

 

- Making changes to the local rights management such as tagging players in response to certain events.

- Handling events when trades are executed in market blocks.

- Observing weapon fire, and damage to attached structures.

- Conducting trades, accepting deposits and giving out items (yes I know this is done by the market block but there are scenarios where being able to have experct control would be interesting)

- Showing GUIs on terminals and interacting with players.

- Sending messages, to individuals and groups of players

 

Additionally, if DPUs are run on each client that comes into contact will there a way to be persist state and keep it synchronized between players using the same DPU? 

Lua allows for database connections, so I think that will allow us to build distributed networks for our scripted objects even though they're hosted on our clients. That's essential for trading systems.  Also I think it may be possible for an organization to lease space on a server and run the scripts there, allowing organizationally owned equipment to be constantly in operation.  It wouldn't do for your building's defense turrets to go dead when the chairman logs off.

 

The devs said that they plan to have players script outputs to displays.  For now they're using placeholders on the elements they're providing but they expect players to design their own elements with active displays.  I imagine you could use an iframe to display a web page that's hosted on your client so you can basically make a screen show basically anything.

Share this post


Link to post
Share on other sites

So scripts on objects you own will only run when you're online.  So your building's automated defenses will only be operable when you are playing but when you're on vacation, your building is just sitting there waiting to be turned into scrap.  Is it possible for the scripts to run on a server leased by the player or an organization, for example, instead of on the client?

I guess you plan on being a loner without friends or an organisation that you can delegate to keep your building running, right?

 

You can always do an AirBnB on your buildings, ren them for the period you are on vacation, or hire people to look after them on your stead. Pay them with DACs or whatever.

 

I at least, will be having some friends of mine to look after my crib when I'm offline. Or even better, I won't even build a base somewhere. It's not a mandatory thing to have a home in the game, you can always roll as a space nomad. The only thing you need is renting parking spots.

 

Share this post


Link to post
Share on other sites

Oh twerk motor, I thought they had got to you when they disabled pink text, good to see you are still talking smack to the carebears.

 

 

So scripts on objects you own will only run when you're online.  So your building's automated defenses will only be operable when you are playing but when you're on vacation, your building is just sitting there waiting to be turned into scrap.  Is it possible for the scripts to run on a server leased by the player or an organization, for example, instead of on the client?

 

I don't think that how its going to work, the way I understand DPUs will operate on any players clients when its loaded into their game? So they might be running the code that is causing the defenses to shoot at them, if that makes any sense.

 

I think we all need to cool it and see how it works in Alpha. It seems fairly certain that there is going to be ways to protect your stuff when its offline although it will be much harder going it alone versus being part of a city or nation that have better collective defense against people like TwerkMotor

Share this post


Link to post
Share on other sites
 
Warning: The following Blog Post implies you already have some basic programming knowledge.
If you don't, some parts may seem a bit obscure or difficult to understand.
 
JC Baillie,
Project Lead.

 

Not to be a pain in the butt...and not that LUA would be that hard to learn...but could I write these scripts in C or C++?  Do you know of any online converters that would take C or C++ code and convert to LUA?  LUA looks like it might be similar to python which I also know.  

Share this post


Link to post
Share on other sites

I guess you plan on being a loner without friends or an organisation that you can delegate to keep your building running, right?

 

You can always do an AirBnB on your buildings, ren them for the period you are on vacation, or hire people to look after them on your stead. Pay them with DACs or whatever.

 

I at least, will be having some friends of mine to look after my crib when I'm offline. Or even better, I won't even build a base somewhere. It's not a mandatory thing to have a home in the game, you can always roll as a space nomad. The only thing you need is renting parking spots.

 

Yea I'll watch your crib!  Build it under mine or above or w/e ...then we can take turns!

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...