Search the Community

The devs have said that automated mining will probably not be an option. As a student of business and economics, here's what I think: ABSTRACT: Limiting script automation for both mining and weapons fire will greatly limit the capacity for economic growth and in-game innovation. The mining industry, for example, will start out with individuals mining for minerals and directly selling them to other players or on an open market. It will eventually evolve into a number of mining corporations that will be able to provide minerals more cheaply through an organized workforce and semi-automated processes. This is inevitable, as it should be. But why limit the mining industry to this level of business innovation? By disallowing further automation, yes, the market for mundane repetitive tasks like mining by hand will be preserved. But what would happen to the broader job market in a simulated economy where automation is unregulated? It would expand exponentially. How would automated mining exponentially expand economic growth and job availability? Well, the whole purpose of automation is to reduce labor costs, to reduce the price of goods (raw minerals, in this case), so that, in a competitive free market economy, businesses can stay... competitive. Inevitably, reducing the price of raw minerals allows other businesses, further up the chain of production, to increase production and lower their prices (competitive market, remember). These reduced prices further up the chain of production lead to increased demand and, therefore, new market opportunities. STORY TIME: John Smith is a miner. He mines steel all day for Mineral Corp, gets a commission based on how much steel he mines, and Mineral Corp sells the steel to spaceship manufacturing facilities. One day Mineral Corp decides to cut costs by using automated mining drones. Nooooo!!!! Curse you Human Ingenuity!! Let's look at what just happened: In order to cut costs, mining corporations are now buying automated mining drones. This new demand for drones is providing jobs for programmers, industrial designers, manufacturers, and even truckers (to transport all the extra minerals that are being more cheaply produced and are increasingly in demand by all these industries)! Back to John Smith: John lost his job to robots. The Luddite fear that soulless computers will replace all the honest employees has come true! *cough cough* But when John's at home, drinking away his sorrows with some Pan Galactic Gargle Blaster, he opens up the classifieds and is shocked to see hundreds of jobs available that weren't there yesterday! Not only jobs related to the production of mining drones, but many seemingly unrelated jobs! Where did these other jobs come from? They came from the steel being cheaper. Businesses that use that steel for product production, like spaceships and buildings, can now sell their products more cheaply. Having cheaper spaceships increases the demand for spaceships because more people can afford them. In order to meet that increased demand, spaceship manufacturers must increase their production by hiring more employees (new jobs! Yay!). So now, even though less people are mining by hand, more people are building spaceships (as well as countless other things)! John Smith may not be mining anymore, but he has a new job now, that pays more, and he can enjoy a cheaper cost of living thanks to those beautiful automated mining drones. BASIC FORMULA: Automation = reduced cost. Reduced cost + competition = reduced price. Reduced price = increased demand. Increased demand = increased production. Increased production = increased job availability. Automation + competition = increased job availability. Can we please have free automation scripting? (I may touch on automated weapons-fire later)

I have no idea, other than what I keep reading about it in the forum, as to what LUA is and how to write a script. Does anyone recommended reading material with specific instruction about it or is it just an in-game "thing"? Thanks.

Hello, As you may know, it has been "decided" that scripts are only gonna run in the presence of people, and not otherwise. Trying to comprehend that choice was easy: it is a question of performance, because every loaded area uses quite a lot of server power. But i have an alternative: you may have a personal anchor that simulates your presence to be able to run your mining operations, this would allow too to avoid doing afk shenanigans. but, what if you want more? you could use DACs to enable a use of one more of them for one month, thus keeping the performance use compensated for. I hope i am not besides the point...

[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?

According to the promotional videos, there will be a limit to the range within which you can run LUA scripts. So that for example if you want to build automated mechanisms, somebody has to stand next to them or they won't work. I'd like to see the possibility to connect two blocks so that if someone is standing next to the other one, their processing power can be used to run the other one regardless (or perhaps regarding, based on item level) the distance. There is a lot of talk about drones, which would very much depend on this. However, I don't know if drones planned by people were short or long ranged ones. The cases which I'm most worried about would be guided missiles or a larger ship drones which would immediately leave any kind of local processing range when deployed due to the larger scale of things in space.

Imagine if there was functionality to contact other ships with LUA. Or even connect to them to send packets of data which can Control the ship or simply send an order. Imagine being in one ship sand sending a request to open a voice channel to speak to whoever owns it. It would be great to have some form of wireless scripting. So maybe I can send a key to a ship of mine which disables it if it's stolen? I feel this can be a creative aspect to explore as many organisation can make heavy use of it. Similar to Computercraft which is a Minecraft Mod. They use a small function known as rednet to communicate to other devices. What do you think? -Moving this suggestion to a new one with all the details + a poll.

OUR GOAL: The main goal of Solaris Industries is to create the best ships modifications that one can buy - Whether it be for a small fighting ship, or for a massive space station. OPERATIONS: Everyone has ideas, if your idea sounds like a good/profitable one, discussions will be held on whether or not this is feasible, and if so, how it can be expanded on further to make a profit. THE PROBLEM THAT IS MONEY: If an idea has been developed and sells well on the market, a designer would want to know how the money would be split. Here at Solaris Industries we only believe it is fair that the person who first came up with the idea gets 50% of the overall earning of the modification. The other 50% will be split around to the rest of the people in the organisation who worked on this specific modification. (depending on how much they contributed and so on.) LEADERSHIP: While I am the founder of this organisation I believe that everyone is of equal worth, which is why everyone in this organisation will be valued as such. CUSTOMERS: Band of Outlaws - Confirmed Red Hat Systems - Still in the works... Apply now! https://community.dualthegame.com/organization/solaris-industries

As a future developer in Dual Universe, the idea of DACs as payment seems like an interesting prospect. But the more I think about it, the more it seems like a bit of a d-bag move on the part of the developers. I don't want this to be an overtly negative post, but bear with me.. I intend to be creating a whole lot of stuff in game, ships, defenses, tools, etc. with full Lua scripting to back them all up. These things will take a TON of time to develop if you hope to have a decent result from them. However, with the Dual Access Coupons being the only *real* form of payment I can hope to receive in game, it kind of feels like a bit of a face slap. Think about it. I spend 25 hours working on a super awesome engine control module with advanced auto-maneuvering for someone who requested it custom. Joe Space Captain goes to the Dual website and buys himself two DACs to give to me as payment for the work I did. Great, I got this month and next in game for free as payment. = 30 Euro savings or whatever for me. Now, instead of a custom job, I make a super awesome base turret blueprint that I sell on open market. Let's say 250 people buy it at 500 credits each, and I trade those 125,000 credits for 5 DACs that people are selling on the market. What happened here? I now have 5 free months in game, which I may or may not ever use, but NovaQuark just made 75 euro in real money cash for all of that work that I did. Once I start collecting DACs like candy because now 10,000 users have realized how good it is and have purchased my super-awesome turret, NQ is rolling in the money for work I did, and those DACs I accrued have become virtually useless to me. Obviously, I made assumptions the monthly fee is 12 euro and DAC are 15 euro. Actual cost doesn't really matter. The more I make and sell on market, the more trivial the DACs will become. Meanwhile, NQ makes tons of constant value cash on my work. My alternative would be to just hoard the in-game currency, which has equally nil real-world value. I have to imagine that with this system of payments, serious developers and builders will eventually just start dealing outside of the game and make contracts to do in-game work with payments in real cash. That's the only way it would actually be worth it to build things over the long term. All of the really good stuff in game will only be accessible through various user-run black markets outside of game, with in-game market only used for trivial purchases just to get items transferred and to earn the in-game money needed for resource accumulation. I could be wrong, but that's what I foresee happening. What are your thoughts?

Hello Dualiers, You are building your new starbase, with a magnificent hangar, and other amazing things, and you decide to let an AI manage it, yet it is all bland and lifeless, but you just remember there is the Text to speech api!!! so you give life and activity to your starbase, hearing the resonant control tower voices in the main hangar (note it is pressurized ofc) I think it would be great to add it, there is an open source cpp lib for it: http://www.speech.cs.cmu.edu/flite/index.html it would be great if you added these sounds to the echo features for great spaces. api bindings would be like: (if user not specified, everyone can hear it) speak('hello world' [, user]); shout('stop'[, user]); whisper('come in'[, user]); and aimanager.setVoice(voice); (or anything equivalent) voices could be cosmetic goodies, with generic male and female available by default. Hope you like it!

RED HAT SYSTEMS This topic, sponsored by Red Hat Systems, aims to inform players about the LUA scripting side of the game and clarify the facts. KNOWN ELEMENTS Propulsion Engines, Fuel Tanks, Cockpit, Navigation Instruments, Doors, Weapons, Batteries, Containers, Accelerometers, Radars, Targeters, Drone Bay, Elevator, Inclinometer (Gyroscope), and last but not least… CONTROLS UNITS / DISTRIBUTED PROCESSING UNITS Control Units – A control unit is the computer hardware, whereas the DPU (Distributed Processing Unit) is the computer's software. In fact, every element in the game will have a built-in DPU. The difference between control units and other elements is that the control units exist specifically to run player-customized DPU's, whilst the DPU's embedded in other elements are not customizable. DPU's will be distributed (sold, copied, transferred, etc) in black boxes. Think of the black box as a USB Memory Stick. Only a single black box can be inserted into a control unit at any one time, however a construct (ship, car, boat, factory, etc) can have many control units and therefore many black boxes. The black box is therefore simply a transport mechanism for the DPU. More on black boxes later. Each DPU will be capable of emitting events (standard pre-defined events written by the devs and also player-defined events written in LUA) and exposing executable functions (again, predefined + custom). The DPU will also have a collection of event handlers (again, predefined + custom: you get the idea). An event handler simply listens out for events, and then executes a function if a player-defined expression evaluates as true. Each DPU has multiple slots where other elements can be plugged into (Think of USB Ports). KNOWN EVENTS (EXAMPLES) self.radar1.enemyAt(x,y,z) KNOWN FUNCTIONS (EXAMPLES) self.inclinometer2.getRoll() self.Inclinometer4.getPitch() self.engine1.setPower(100) self.weapon7.fire() In the example events and functions above, “self” is simply a Lua keyword that implies the code is referring to its own scope. “radar1”, “weapon7”, etc are the names of the slot that is emitting the event or is being targeted to execute a function. “getRoll()” is an example of a function being invoked (safe to assume it will return a numeric value with roll angle). SYSTEM DPU The system DPU is rather special. It handles user input (emit event when a key is pressed) and also controls the flow of procedural code (as opposed to event driven) via the use of timers. I.E you could call system.setTimer(0.1) and provide a function that will be invoked every 100 milliseconds. Another awesome feature of the system API – Customizable GUI! That's right, via calls to system you can customize the games GUI. BLACK BOX/COMPONENT DPU A Component DPU is an element that you, as a programmer, will be selling to other players. It will abstract the functionality of your custom DPU into what can be seen as a compiled library. The end user will be able to consume your functions and events without seeing the underlying code. If the end-user is another programmer then they can use your Component DPU as a module to write their own Component DPU which requires your Component DPU in order to work. If the end-user is not a developer they can either drag and drop the required functionality via a simple UI, or they can make use of an auto-configure system (Think Plug and Play). SUMMARY What the devs have done here is give us access to the very tools they themselves use to build the game. When you use a Propulsion Engine, its functionality was written by the devs in the same way a player might customize a DPU. The Propulsion Engine has its own pre-defined fully functional DPU inside it. By introducing the concept of Control Units we as players can fully mod the game, from within the game. If we don't like the way the Propulsion Engine handles, that's fine, we can just overide the behaviour with our own code. The same for almost every element in the game. The devs has basicly created an in-game IoT (Internet-of-Things). This system literally redefines Emergent Gameplay, in fact it laughs in the face of Emergent Gameplay. Nothing else comes close. Intrigued? Love to code, or hungry to learn? Join the most advanced organization in Dual Universe. Red Hat Systems needs you!

OUR VALUES We expect nothing of our members, other than a passion for coding and/or a desire to learn. Your time is your own, we will never try to manage our members in any way shape or form. Simply put, you have absolute freedom to do what you want in Dual Universe. OBJECTIVE To become a hub of individuals who love to code and game, and to make in-game money along the way. As a software developer, hacker or a scripting enthusiast you are in a unique position to make your mark in Dual Universe. You have skills that others do not posses, we are here to organize and focus our efforts and create world class code that will be used over and over again by Dual Universe players, willing to pay for the privilege. HOW WE OPERATE We will maintain a list of planned features. Any member is then free to contribute to those features. When we release a DPU, the lifetime profits will be shared amongst the contributors depending on the share of their contribution. So if you write half of a module that goes on to make in-game money, you'll get half the profit. You'll also get a cut for other contributions such as testing, or even for simply coming up with the idea in the first place. LEADERSHIP xNerox is the founder, however we are a self organizing meritocracy. You simply have to prove your worth, and could become the de-facto Leader until the next genius comes along and unseats you. NEWBIES PROGRAM Red Hat Systems recognizes the value of sharing knowledge with those who desire to learn. If you are thirsty for knowledge we will do our best to bring you on board and bring you up to speed. AFFILIATIONS Band Of Outlaws - We are proud members of the Band Of Outlaws. We are bound by one universal value: Freedom! The freedom to do what you want, where you want, when you want. We encourage all members and non-members alike to take a look and join Band Of Outlaws. There awaits your place in the dual universe.

First of all, it would be cool to even have the ability to use the 'require' keyword in LUA for importing libraries for use in our LUA scripts. Even if that was limited to a list of provided libraries from NQ, that would be awesome. However, I'd like to take that a step further and let people distribute their own code via disks/memory units/whatever ingame. Thus people could actually make a living ingame doing nothing but selling their own software. Not only do I see standalone LUA scripts being distributed this way, but also libraries. So instead of a programmer having to go to your elements and manually copy in code for each one on your ship, if you don't want to code everything yourself, you might just go buy the premade software off the market for installation in elements like consoles. As was discussed in the GrayStillPlays interview, the stated goal was to allow us to buy a ship off the market, change it up a bit or improve it somehow, and then sell the differences on the market as an "upgrade" to the base ship. That could even be extended to software, so you might add a better navigation UI into a ship you buy and decide to sell it on the market. We're likely going to be sharing code online anyways, it would be cool to see it integrated as a game mechanic.

Hey guys, Very excited about this game. I have just been reading about the LUA scripting side of things here: https://devblog.dualthegame.com/2015/09/18/lua-script-and-distributed-processing-units/ I'm kinda curious, how deep will the LUA system go? So, for example, will we be able to chain event handlers together for multiple constructs to build fully autonomous factories with conveyor systems that would mass produce a certain item through a production chain? What about super high energy weapons such as nukes? I'm assuming the more powerful something is, the more energy it is going to consume, therefore more materials it will need to build it.

The devs said that we will be able to program things in Lua(Programming Language). It could mean there will be simulated computer OSs, Networks and other things. I like the idea of being able to hack an enemy ship or machine.

"Good day, fellow members of the Dual Universe Forum. Like an astounding fraction of people here, I have found a great interest in the creation process Dual Universe has created. Most wonderful of all, I believe, is the fact that while templates are going to be available, most or all of the code can and will be done by the players. While this may allow for stunning creations like "Pacific Rim meets Gears of War"; inventions to darker "George Orwell's "1984" meets Ex Machina", the real problem lies with the benefit itself: codes. Where the player inventions simply to be tried and tested against NPCs, who am I to complain? (after all, we humans like battering digital units without any conscience coming to sting us later on...like Witcher 3...or Doom...or soon to be harassed Dual Universe NPCs...) My concern is that codes, basically interact with other codes that can be decoded, recoded or bloody well explode in your face. What happens when a designer creates a weapon with a kill range of 70,000 units and a damage variable thrice that amount? Or.... A ship with a hilariously high health value and a repair snippet that adds twice the maximum health every millisecond? Or... Codes that change the values of their coded targets, leaving the attack or defence in a quite proverbial "Waterloo"? I do hope that I'm not sounding like a Prophet of Doom to the poor inhabitants of Pompeii, but I do hope the developers have this volcano in check, or at least a force field to keep the lava from raining down on our heads. Lastly, player created AI is going to be as much a blessing to people here as the electric bulb was to our ancestors in the late nineteenth century. In retrospect, it would be a curse to many as much as a future "SkyNet" may be to our descendants in years to come. To be quite frank, some people here may already be working on a doomsday "SkyNet" for the poor people who are unlucky enough to come across it. The point is, some clear controls need to be put in place. And I hope the Guardians of the Dual Universe are several steps ahead of us. Pax Vobiscum. "

I've been wondering for a while now, and I can't find the answer even if it is most likely lurking somewhere. Will be able to create our own missiles and code their targeting/trajectory using Lua. If you know about the the game From the Depths, that's what I'm getting at. If not, I think it would be really awesome if this could be implemented. I'd say there'd be the basic missiles which wouldn't need programming but if people knew Lua they could code them. Meaning we'd see missiles acting differently and targeting different things.

I've been wondering for a while now, and I can't find the answer even if it is most likely lurking somewhere. Will be able to create our own missiles and code their targeting/trajectory using Lua. If you know about the the game From the Depths, that's what I'm getting at.

Hi, I know that DU is not planned to be easy, and scripting will be irremovable part of game mechanic. It is something cool... but write hundreds lines of code can be bothersome task for non-programmer players; beside this, scripting is quite boring in form (you know - lines and lines of numbers and letters, nothing fancy). So. Maybe we can made scripting mini-game itself and give it some interesting graphical interface, easier to understand by "normals"? Of course "text hard mode" will be always available as second option and even "graphical programming" can have less options than text one, like "beginner" and "veteran" versions I not talk about simplification of programming language itself, but more about some kind of GUI/IDE for that - with auto-complete and - most important - easy graphical interface like "blocks" of code for building apps. I know at last two projects, which use this kind of editors ; LEGO Mindstorm and Scratch. Here are pictures of programs build in them: [sCRATCH] [LEGO] EDT: Here is wiki about this style of programming. And you can even use some like this for LUA, too! In my opinion it will decrease "starting cost" for lot of people, and it can be even inspiration for someone for start learn "true" programming Toughs?

https://devblog.dualthegame.com/2016/02/20/builder-gameplay-voxel-tools-elements/ I was reading this in the devblog, meditating about the possible relationship between the "virtual simulator" and the LUA code... Starting from the point that in the "real game" you could use LUA only to interact with the "Mesh-based Elements"; should it be possible to use the code in the simulator to automatically build complex (or repetitive) voxel patterns? What do you all think about it?