xNeroX

All facts unless otherwise stated as opinions. Lifted from here.

Great to see so much discussion on this page, don't worry about derailing the thread! If it's interesting then i want to read, as do others i assume. Some excellent points have been made regarding the self-replicating scenario, and what happens to scripts when players log out. The devs certainly have their work cut out for them to make this work, (although, i think i read somewhere that the lua scripting mechanics have already been implemented? i'll try and find where i saw this and post it) We already know that we will be writing event driven code, whereby functions will be executed based on another event. This could provide half of the answer as there will be no long running scripts. I could see a scenario where player 1 has a lua script on his ship listening for, lets say "Arrived at X,Y,Z" event (think warp drones travelling unmanned long distance trips). The arrival event would be triggered by the server when the ship arrives. Similarly if player 1 implemented an event handler to listen out for "Enemy Detected At X,Y,Z" and then player 2 intercepts player 1 whilst player 1 is offline. player 2's position stored on the server would trigger the event and the server would call player 1's event handler. Thinking about the warp drone scenario, i'd say the only option would be that the server handles everything. Considering the pay monthly model, i'd say this is in fact the case. More info from the devs would be clear this up, especially if it has already been implemented?

Shame on me, but i had no idea there was a wiki for dual universe? Either way, you have my blessing Not that you need my permission anyway, feel free to do as you please... Let me know if you do decide to wikify this, if you don't have the time to do so - i'll certainly look into it in the near future

Difficulty is entirely subjective, what's easy for some may be difficult for others and vice versa. I'd encourage everyone to have a play around with it, you can do a quick google search for LUA scripting tutorials, which will give you an idea of whether its something you may enjoy. It's easy to feel overwhelmed at first and the learning curve is usually steep, but you get to a point where everything just makes sense and you feel proud of your achievements. So i'd say hang in there, and don't ever be afraid to ask for help As we grow in numbers we'll also look to teach others who want to learn this

Much appreciated I've responded to your pm. apologies for the delay.

Valid point I figured i would go for something instantly recognizable, something that would appeal to the inner geek within us That being said, if the members want a change of name, then a change of name they shall receive

Thought i'd share my own (first attempt, work in progress). I'm going for the star citizen banu merchantman style, with a modern twist and sleek stealthy lines. I'd like a frigate sized ship that handles more like a fighter. I have a dream ship in my head - this kind of resembles it

I think your designs are fantastic! You have excellent technical skills and creativity! No doubt such advanced and complicated ships would require an array of advanced Component DPU's to handle all the automation and C+C tasks. To this end Red Hat Systems could be of assistance. I'd love to work with you in the game, that is of course if you think having a team of programmers on side would be beneficial to your ship building enterprises. If you are interested we could hash out the details over PM Either way, i look forward to seeing your designs come to fruition. Good luck

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!

I think i read somewhere that the dev's plan to use the planet's core heat as a natural barrier to digging below 2km, drill any further and you'll start to melt Limitless drilling would be epic, but 2km is fine too. I would love to build hidden bases 2km under ground, so long as we don't have placholders over heads that give away our location. I wonder if we can dig beneath the Arkship?

Gladly received, and responded

Glad to hear your enthusiasm As with anything at this very early stage, only time will tell. There seems to be huge potential in this game, i can't wait to see how things pan out. On the point of newbies, its still early days. A lot will depend on how many members we have, their willingness to teach etc (i will teach, but i can't teach everyone), and ofcourse whether there is even demand from people wanting to learn. I'm of the opinion that the more people there are engaged with the scripting elements of the game, and the bigger and better things we do with it - the more priority the devs will give to improving and expanding those features. And being developers themselves they might be eager to expand those features. To that end, and for the time being, i may work on some documentation for those who want it. I could even write some sample scripts based on what the devs have said already (Doubtful they will work straight out of the box (as it's all guesswork at this stage), but it would give people an idea of what they would be doing in this organization, should they choose to do so)

Absolutely, the tech is there... The devs have mentioned that elements like Radars would emit events such as "Enemy Detected At X,Y,Z", now if we also had a GPS-type system and a radio system, we could build a distributed radar network that feeds data back to a NORAD-like military HQ. All friendly ships would then broadcast the location of all enemy ships to a central location. Knowledge is Power...

I only just noticed your reply (sorry). If we get the tools to do this... Wow! The possibilities.... Fleet Management System? Black Market? Automated Trade Routes? Call For Reinforcements? I hope we not only have some form of "networking" ability, but also some form of storage (perhaps a set amount of data stored on a DPU, accessible by code). But i may just be getting carried away... Fingers crossed hey

+1. Although in absence of this, fuzzy logic should work. Simply use a naming convention, so a certain prefix would mean "This function is meant to be wired to the GUI". Still guesswork at this stage - but where there is a will, there is a way