Jump to content

Search the Community

Showing results for tags 'Control Unit'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Starting Zone
    • Rules & Announcements
    • The Arkship Pub
    • Novark's Organization Registry
    • General Discussions
    • Off Topic Discussions
  • Ideas & Gameplay discussions
    • Idea Box
    • The Builder's Corner
    • The Gameplay Mechanics Assembly
    • DevBlog Feedback
  • Fan Art, Fan Fictions & Roleplay
    • Novark Agora
    • Novark Archives
    • Novark Art Gallery

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location:


Interests


backer_title


Alpha

Found 1 result

  1. 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!
×
×
  • Create New...