Jump to content

xNeroX

Member
  • Posts

    23
  • Joined

  • Last visited

Reputation Activity

  1. Like
    xNeroX got a reaction from Anonymous in Red Hat Systems   
    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
  2. Like
    xNeroX got a reaction from Cybrex in Red Hat Systems   
    Much appreciated I've responded to your pm. apologies for the delay.
  3. Like
    xNeroX reacted to GalloInfligo in Distributed Processing Units - Control Units   
    Examples of Elements are: propulsion engines, control units (computers), doors, weapons, batteries, containers, accelerometers, radars, targeters, drone bay, elevator, and many more. The way the construct orchestrates all these Elements is through scripts, and what we call "Distributed Processing Units". Let's dive into it, and see what it can do.
     
    first paragraph of the dev blog on scripting...... https://board.dualthegame.com/index.php?/topic/314-devblog-lua-scripting-and-distributed-processing-units-dpus/?hl=drone
  4. Like
    xNeroX reacted to Anslem_Vry in Red Hat Systems   
    Just going to bump this thread so that people know we are still looking for people who are willing
    xNero has been away the past couple of days, but please be sure to send in your applications
  5. Like
    xNeroX got a reaction from 1stLt_awol in Distributed Processing Units - Control Units   
    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!
  6. Like
    xNeroX got a reaction from Hunter in Selling Software on Ingame Markets   
    I'd like to see Lua Scripts sold in the markets as compiled libraries. This way the source code could be protected, but the functionality preserved. Just like in real life.
     
    Now lets say someone wanted to improve your library they could simply reference it and override certain functions and add new ones. They would still need to purchase the original library but could resell the newer updated library at a higher price.
     
    Copying and Pasting scripts manually, without being able to protect your scripts "blueprint" would kill off an entire industry. Imagine you built a ship and created a blueprint, which people could just re-use over and over again without paying the owner... You could not make money from designing ships because "piracy" would be rife - the same applies to software.
  7. Like
    xNeroX got a reaction from Ashron in Distributed Processing Units - Control Units   
    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!
  8. Like
    xNeroX got a reaction from Nothing in Distributed Processing Units - Control Units   
    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!
  9. Like
    xNeroX got a reaction from GrandMaster Apex in Distributed Processing Units - Control Units   
    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!
  10. Like
    xNeroX got a reaction from Anslem_Vry in Red Hat Systems   
    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.
  11. Like
    xNeroX got a reaction from gyurka66 in Red Hat Systems   
    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.
  12. Like
    xNeroX got a reaction from DarkNovation in Thoughts on these designs?   
    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
     
     

     

     

  13. Like
    xNeroX got a reaction from GalloInfligo in Distributed Processing Units - Control Units   
    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!
  14. Like
    xNeroX got a reaction from CosmicDragon in Distributed Processing Units - Control Units   
    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!
  15. Like
    xNeroX got a reaction from Code24 in Distributed Processing Units - Control Units   
    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!
  16. Like
    xNeroX reacted to Vyz Ejstu in Invasions   
    "Good day, MechMerchant. Conquering another planet is going to be in many ways a military campaign. For instance, let's say MechCorp decides to invade DuckNation's planet.
     
    For the sake of this example, we'll assume DuckNation owns the entire planet. Now, DuckNation was smart and affluent enough to place Territory Control Units in a large fraction of tiles (and if the developers include it, a planetary Control Unit.) 
     
    Now, MechCorp can decide to invade DuckNation's planet and conquer the Planetary Control Unit first, to weaken morale and then proceed to search and destroy each individual Territory Control Unit. But, MechCorp knows that the war will take too long and the cost of the military expenditure is too much to handle, so they switch tactics. 
     
    Instead of launching a prolonged campaign, they either send spies into DuckNation to sabotage the RDMS (which will take time as the spies need to earn the trust of DuckNation's administrators) or they decide to bribe some of the people in charge of the RDMS. 
     
    If MechCorp has the money, influence and manpower, they can even "coerce" DuckNation to pay for security, or give up certain parts of the planet to MechCorp. They could even convince one of DuckNation's allies to help in "coercing" them. Be wary of the friends you keep.
     
     From there, I leave the rest up to your imagination.
    "
  17. Like
    xNeroX got a reaction from GalloInfligo in Red Hat Systems   
    Possibly, although if they did i believe we would be better off merging in some way. I'm not here to lead, nor to create the next mega-corporation. Simply to focus talent, and hopefully make a living in the game.
     
    Anyway, linux is linux - everybody has there preferred flavour. I chose Red Hat more for the name and the logo and there is definitely a commercial side to this organization I think Red Hat suits it well.
  18. Like
    xNeroX reacted to moruvis in DevBlog: LUA Scripting and Distributed Processing Units (DPUs)   
    I would guess to safely run untrusted code they would need scan the code before it is run to make sure it doesn't try to reference any system objects that have references to the executing environment that sort of thing. If we are going to be able to script some actual AI or drones then we might get some official libraries that have thrust calculations and path finding algorithms already made, those would be able to be implemented in optimized c++ that is called from the Lua script to save on cycle time on the server end.
     
    I have a couple of questions:
    Data storage: Already been asked and I agree, if we are going to be able to make anything more than a fly-by-wire interface for ships then there will probably be need for some long term persistent data storage. At its most basic this would allow remote sensor probes, surveying mining spots, collecting data for tech research. Sensors: I don't think it was explicitly mentioned but we would need access to various different types of sensors, eg. gravimetrics, positioning, surveying, friend-or-foe etc. Would those be separate modules you add and then access through a specific interface? Communication: Autonomous drones would need some communication between each other and back to the base ship to propagate orders, will there be a messaging framework for this that would need to be coded or would work outside the scope of the scripting? Libraries: Will the code only exist on the unit that has it programmed or will there be an independent repository of code that each player has / can access that will then be deployed for execution? Similarly, will we have some sort of version control? I wouldn't be able to write much without an in-game git before it all became a mess. Testing: Could we have a sandbox within the sandbox to test code? If you were to write a drone AI it might decide to start attacking everyone and hurt your standing if you got some code wrong. Collaboration: Will groups of players be able to work on the same codebase to produce something that a single player wouldn't have the time or skill to make themselves? I know all of this would start adding quite a lot of complexity to something that might not need to be (and maybe it is because I don't know that much about Lua), but the whole idea excites me with the possibility of lots of interesting and rich gameplay ideas. 'Scripter' could be a legitimate in-game profession if scripts and be written, sold and distributed independently of actually having something that runs it. Writing a decent drone AI might be outside the skillset of almost all players, but selling a library to manufacturers or having a scripting division of a corporation adds a whole extra level to the game. The ingame skill is a real skill rather than an eve-like wait-20-hours-and-you-can-do-it skill.
     
    If communication is handled within the script then writing a communication protocol for drones would allow hacking to be a legitimate battle tack-tick. Finding a flaw in the protocol, deliberately confusing the sensors, running a DDoS attack on the baseship to block communications, destroy the communication array on the base ship and then the drones can't receive orders (without some mind bogglingly difficult code to resolve a new ship to receive new orders from without specifically having been instructed to do so), firing an EMP and wiping the installed scripts before it reboots, and so much more than I can even think of right now would all become possible.
     
    The idea that most intrigues me is the idea of boarding a ship or space station and trying to take control of it. If everything is controlled by a control panel that is just an interface for calling procedures in the installed scripts then who controls say a space station or that sub system is the person standing in front of it. Does that mean that on a public space station there needs to be some locked doors to prevent people that shouldn't have access from entering the control room? Is that locked door controlled with a password? Can I get that password from a traitor or spy? Can I blow a hole in the side of the station to get me into the controlled area? Can I cut through the door? Can I lead a mutant with some other players to take over the station? Is there some subsystem outside the controlled area that I can use with a hole in the physical logic of the station to start gaining access? What if I own it and I've accidentally locked myself out? So many possibilities that would lead to some amazing organic gameplay that a game maker would never be able to design.
     
     
    I'm getting too excited by this...
  19. Like
    xNeroX reacted to NQ-Nyzaltar in DevBlog: LUA Scripting and Distributed Processing Units (DPUs)   
    (Posted Friday 18th of September 2015 on the DevBlog)     Big news! We just finished designing and implementing one of the most critical and distinguishing feature of Dual: the capability to script any construct that you make. A construct is anything that you build in the game, it can be a ship, a building, a space station, or whatever. It is a physical object, it can move, collide with stuff and potentially include hundreds of "Elements", which are operational units that you can craft or buy, and freely position inside your construct to add functionalities to it. Examples of Elements are: propulsion engines, control units (computers), doors, weapons, batteries, containers, accelerometers, radars, targeters, drone bay, elevator, and many more. The way the construct orchestrates all these Elements is through scripts, and what we call "Distributed Processing Units". Let's dive into it, and see what it can do.   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.   This is going to be a slightly more technical and longer post than usual, but I hope people interested in the topic will find it entertaining. In any case, remember an important point: you don't need to understand anything about scripting or ship building to actually buy a ship and fly it. You actually don't even need to use a ship at all if you don't want, there are plenty of activities to do besides this in the game. It's a bit like in real life: you don't need to be a mechanics to drive a car, and some people just never drive anyway, they take a taxi. It all depends on your playing style, and what you expect from the game. But if you are interested in creating your constructs and scripting their behavior, I hope you won't be disappointed by the deepness of the gameplay experience we propose.   So, let's summarize again what a "construct" is: in Dual, you can assemble chunks of matter (stone, wood, iron, kevlar, etc...) in any way you like, a bit like in Minecraft, but instead of simple cubes, you can forge almost any shape you like. The technology behind this is called "Dual Contouring". This can be used to build the hull of a spaceship, the walls of a castle or a gigantic statue. Up to you. Attached to this inert structural skeleton, you can add some components called Elements, which are actual gameplay components that you can deploy in your construct to make it functional. In a spaceship, you need propulsion engines, fuel tanks, navigation instruments, one or several cockpits, etc. All of these are Elements. The collection of all Shapes and Elements are what constitutes a construct, which is a whole that can be moved once created and is subject to the laws of physics (for example, it falls if dropped in a gravitational field). A construct can be owned, traded, copied, etc, but this is another story we will discuss in another post. Right now we will concentrate on one particular aspect: how do you orchestrate all the Elements so that they can work together? We will take the particular viewpoint of a spaceship, which is a good way to illustrate the concepts involved, but this can apply to anything you like, including a giant spaghetti monster robot or whatnot.   In terms of game design, we could opt for an easy strategy here. If you have the required number of engines in the right direction (no matter where they are), and you check the list of instruments needed, it would "magically" fly. With this approach, all ships would fly the same. Trying to put more engines, or optimizing their position would be more or less useless. Hoping to have an AI helping with automatic navigation would be up to the engineers of Novaquark only. Fancy a new way to drive your ship? Impossible. How about the weapons system? How about drones? All this would be predefined and more or less rigidly identical for all players. That's not what we have in mind for Dual Universe. While we will provide basic templates to start with, you?ll be able to engineer your construct the way you want. Engines are real (they physically push your ship where they are, with the power they have), gravity is real, weapons have to turn and target (which also requires a targeter). If you are smarter than others, you can get the job done in a better way, get an edge in battle, or in trade by launching the new Falcon X-42 superfighter and change the balance of game combat with new tactics and possibilities. It?s not only about how you can use the predefined capabilities of ships within a predefined classical game setting, but it?s also about how you can redefine these capabilities. We call it: emergent gameplay.   Each Element is an active unit. It can do basically two things: emit "events" and execute "functions". Let's give some examples: a radar unit can emit events like "new enemy detected at (x,y,z)", a jet engine can execute a function like "set thrusting power to 45%", a weapon can execute the function "fire", etc. Technically events and functions are described a bit the same way: a name followed by parameters written between parentheses. The above examples would become something like:   enemyAt(x,y,z) setPower(45) fire()   Events are emitted spontaneously by the Element when something happens for which it has been designed to react to, and functions are services that the element can fulfill when it is asked to by some external agent. When considering a particular Element, you want to know the list of events it can emit and the list of functions it can fulfill. This is entirely defining what this Element is, from the point of view of the gameplay. We call it its "Type".
      Now, how do you orchestrate the interactions between several Elements, each emitting events and reacting to them, fulfilling functions in return, etc? The central notion we introduce here is what we call a "Distributed Processing Unit", or DPU in short. A DPU is a bit like a computer program, an orchestrator. It has several slots in which it is possible to plug Elements, and it contains a list of event handlers that can react to events emitted by the Elements plugged inside its slots. The schema below illustrate this:     Events handlers are conceptually quite simple: they are "condition => action" managers. On one side, there is a conditional filter, which is a generalization of an event from a given slot, with certain parameters set to given expected values, while other parameters can take a variable "free" value. A particular event emitted by an Element in a slot will be examined by all event handlers, and it will trigger the event handlers if the event signature matches the event handler filter.   To give an example: suppose that we have a filter like ?enemyAt(x, 42, y)?, associated to the ?radar? slot. Now the radar slot emits the event ?enemyAt(11,42,66)?. This event matched the filter and so will trigger the event handler. If the event ?enemyAt(12,13,66)? is emitted however, it will not match the filter (because 13 is not equal to 42). The schema below illustrate this point:     On the other side of an event handler is the action that the handler can trigger when the filter is matched. This is where LUA really enters the scene. The action is simply a piece of LUA code. LUA is a very simple and efficient scripting language, for which you can get many tutorials online. You can try this for a start.   Now what kind of code will you write on the LUA side? Basically anything you want, but, as you guessed, it will ultimately contain some calls to functions among those provided by the Elements plugged in the DPU slots. The syntax will be something like: "self.engine2.setPower(42)". The "self" prefix is a requirement of LUA, then comes the name of the slot, and then the name of a function available from the Element in that slot, together with its parameters between parenthesis.   That's it. That's the basics of what a DPU is and how scripting works. Let me summarize: a DPU is an orchestrator, it has several slots in which you can plug Elements. You can then define event handlers to catch events emitted by these plugged Elements, and react by executing LUA code, which includes calls to functions taken amongst the set of available functions of your plugged Elements.   To be more precise, I have to refine this picture a little bit: I talked about customizing a DPU, but exactly what DPU are we talking about? Where is it? In fact, the DPU you want to customize is stored inside a special Element called a "Control Unit". The DPU is started when you activate the Control Unit (go next to it and press the activation key). Notice that there is no problem with having several Control Units (hence, DPUs) inside the same construct, potentially all activated at the same time.   Now, the DPU inside a Control Unit is special because you'll have a GUI to freely customize it (plug stuff into the slots, define event handlers, etc). Actually, you can do even more than what I just described: you can define a set of events that your DPU is capable of emitting (event emission is done via a special LUA syntax inside your scripts). You can also define a set of functions associated to your DPU, and the corresponding LUA code that should be executed when this function is requested. If you remember, I presented the type of an Element as the set of events and functions exposed by this Element when plugged inside a DPU. Actually, the truth is that there is in fact a DPU inside each Element (albeit not a customizable one), and the events and functions of this Element are actually the events and functions of its DPU. Now to the important conclusion: it is not really Elements that you plug inside the slots of your Control Unit's customizable DPU. It is in fact DPUs. It can be the DPU of Elements, when you plug Elements, but it can be more generic or abstract DPUs. More about this now.   One particularly important "abstract" DPU is the System DPU. This DPU is capable of emitting events when keys are pressed. You almost always want to plug the System DPU, because you want to control your scripts with keystrokes bound to actions. So, typically, you will have several event handlers in your custom DPU to catch action events emitted by the System DPU. The System DPU is also capable of emitting "timeout" events when a timer is due, or at regular intervals, and many other useful functionalities.   You know enough now to script a simple spaceship controller. You need to put a least one Control Unit in the ship, and customize its DPU. Inside this DPU, you will plug the System DPU (typically in the "system" slot), plus at least 3 engines pointing upwards to lift the ship, and 2 more engines at the back of the ship to make it move forward. You need also to plug a gyro (more exactly: an inclinometer), which is an Element that provides the getPitch and getRoll functions, to know about the pitch/roll angles of your ship. And that's it. Now you set a timer with the system DPU (call the system.setTimer(0.1) function to set the update every 0.1 second) and catch the corresponding timeout event. When caught, you can then associate the LUA script that will query the gyro about the pitch/roll and use these values to correct the intensity of thrust power in your motors (using the setPower function) to stabilize the ship tilting. And of course, you will also catch the action events from the System DPU to inform your script about the direction in which the player wants to stir the ship. The exact details of how this is done in terms of control and dynamics are beyond the range of this post, but it involves simple Newtonian physics about torques and forces.   This above custom made Control Unit DPU could be seen as a black box, a ?Stabilizer?, with 7 slots (5 engines, 1 gyro and the System DPU). You can move this black box in what we call a Component DPU, so that you can sell/exchange it. Now players possessing your ?Stabilizer? can plug it in their own Control Unit DPU along with their own Elements, and then connect these Elements in the Component slots, with a simple drag and drop interface, or a smart ?autoconfigure? system, making the whole process of scripting a ship very simple for those who don?t want to put their hand on code:     The DPU system goes ways beyond this simple ship stabilization example. Weapon control, whether in FPS direct view on a jet fighter, or in tactical overall view in a battleship, will be handled with DPUs. Scripting a drone can be done with DPUs. Setting the automatic defense mechanism of your castle can be made with DPUs. Factories can be automated with DPUs, etc. It's all about orchestrating Elements and Component DPUs via scripts that react to events and execute LUA code. The user interface is also scriptable to decide what happens when the Control Unit is activated, how Elements can display their status and give access to parameters (we will probably talk about this in another blog post).   Novaquark will be providing several useful "starter" Component DPUs to start with, as well as smart autoconfigure options to handle the most basic cases. You can get a ship to fly without knowing a thing about DPUs. But, if you are interested in this aspect of the game, it will be up to you to build from there and create the most amazing control system and contraptions, win the markets or the wars with them and leave your mark in the Dual Universe history of innovation and engineering!   JC Baillie, Project Lead.
  20. Like
    xNeroX reacted to Cornflakes in Sensor arrays and distribution of information   
    theres nothing about "gradually", just more frequent
     
    your certain area doesnt get old data, it just gets more rarely the current data set.
     
    when your shard gets the update "ship x at position y" you dont get the data from 20 minutes ago when it first arrived in the system.
    you get its current position.
     
    thats not how lightspeed works
    thats not how anything works
  21. Like
    xNeroX reacted to NERDFIGURE in Red Hat Systems   
    Excellent idea. Can't wait to find out what the limitations are within the game.
  22. Like
    xNeroX reacted to SteveMcFarlane in Red Hat Systems   
    Oh I'm sure there will be a big demand for that from the various alliances and groupings. And then the commanders could remotely issue orders which would appear on fleet vessels displays, including waypoints and information on enemy fleets.
  23. Like
    xNeroX got a reaction from NERDFIGURE in Red Hat Systems   
    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.
  24. Like
    xNeroX got a reaction from Xorkil in Red Hat Systems   
    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.
  25. Like
    xNeroX got a reaction from UNIX101 in Private Contractor - Science and Technology   
    You won't need to know know Java here, it's all done in LUA script which i assume they will be using to expose wrapped C/C++ code written by the game's developers.
     
    The experience you mentioned actually seems highly relevant to what may be available in Dual Universe.
     
    Hopefully see you there.
×
×
  • Create New...