Jump to content

Search the Community

Showing results for tags 'lua'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Starting Zone (EN)
    • Rules & Announcements
    • Novark's Registry
    • General Discussions
    • Off Topic Discussions
  • Starting Zone (DE)
    • Regeln und Ankündigungen
    • Novark's Registratur
    • Allgemeine Diskussionen
  • Starting Zone (FR)
    • Règles et Annonces
    • Registres du Novark
    • Discussions générales
  • 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


community_id

Found 55 results

  1. To accomplish this some changes would be needed. The goal of these changes is to allow the automation of selling vehicles. To accomplish this permission should be able to be changed with Lua scripting. In order to automate selling a ship, the Lua scripting would change permissions once the buyer has completed the correct input (paying for the ship). On top of these changes there needs to be a permissions added that allows someone to fly and build on a structure but not be able to blueprint the structure. Otherwise you could spend hours designing a ship, sell one, and then watch everyone blue print hundreds of them without getting an in game dime. This could be accomplished 2 different ways. Method one don't allow blue printed ships to be blue printed. Only the original ship can be blueprinted. Method two add a second permissions type for blueprinting. Selling ships would be difficult and probably pointless without these features.
  2. Would be cool to see an LUA scriptable method to accept or give currency to a player. Good way to collect taxes for city functions for example. It also creates several markets in the service industry.
  3. I suggest having multiple coding language editing boards in case we can't fins a way to learn Lua before the game release. There are not a lot of online resources for learning Lua, and any of the websites that would potentially have Lua don't. I'm saying that we could keep Lua, and we could also have other languages for people to edit if they aren't knowledgeable of Lua (myself included).
  4. Suggestion to add sound devices In DU you can present visuals using html, svg, widgets, but when it comes to audio, things are not so bright. Sound is important if you want players to be able to make games. Sound can play role in interfaces, used for alarms and, of cource, playing music! So I propose adding to the game lua-controlled "SPUs"/"sound devices"/"sound units", that will allow players to do all kinds of stuff - from simply playing sound on notification in theyr programs to implementing sound effects in the game, or even creating sound trackers and sequencers (to then create music in it). sound device: -has sound memory consisting of, say 44100*8 bytes (number depends on sound device tier), which that can be read as integers using get_sample, set_sample. -has 8 channels (also depends on sound device tier). each channel can be set to play samples from area in audio memory or use oscillator. Each channel can have 1 siimple filter on it. sound device api: sound memory manipulation functions: samples_count(sample_depth) - returns how much integer values of size sample_depth in bytes sound memory can hold get_sample(sample_depth, sample_index) - interpreting sound memory as array of signed integer numbers consisting of sample_depth bytes return sample_index'th integer number from this array. sample_depth can have value 1, 2, 4, 8. On any other value get_sample returns nil sample_index wraps around if higher than number of integers in array set_sample(sample_depth, sample_index, new_value) - interpreting sound memory as array of signed integer numbers consisting of sample_depth bytes set sample_index'th integer number to new_value. getNSamples(sample_depth, sample_index, N) - same as get_sample, but instead of getting 1 integer value it returns table consisting of N values from audio memory starting from position sample_index. Can be merged with get_sample setNSamples(sample_depth, sample_index, new_value) - same as set_sample, but instead of setting 1 integer value, it sets #new_value samples to values from new_value table starting at position sample_index channel control fuctions: channels_count() -returns number of channels sound device has channel_set_sound_source_memory(channel_num, sample_depth, sample_rate, start, end, loop) -set channel to play sound from sound memory channel_set_sound_source_osc(channel_num, type, frequency, osc_param) -type is string - "noise", "sin", "tri", "square". triangular and rectangular waveforms take 1 more paramenter for rate channel_set_volume(channel_num, new_volume, time, delay) - sets channel volume to new_volume. If time arg is provided, volume will be changed gradually in time milliseonds (if not interrupted by another set_volume command). If delay arg is provided, volume change start will start in delay milliseconds after this command called. channel_set_pan(channel_num, new_pan, time, delay) - sets channel pan to new_pan. 0 is left, 1 is rigth, 0.5 is center channel_set_pitch(channel_num, new_pitch, time, delay) channel_start_note(channel_num, delay) - starts note on channel. start is delayed for delay milliseonds, if delay parameter provided. If other note was playing on this channel, it ends. channel_end_note(channel_num, delay) channel_set_filter_type(channel_num, type, delay) - filter types are "none", "highpass", "lowpass", "comb", "bandpass" channel_set_filter_base_frequency(channel_num, freq, time, delay) channel_set_filter_gain(channel_num, gain, time, delay) - in dB, if applicable to filter channel_set_filter_param(channel_num, param_num, param_amount, time, delay) - filter-specific params, such as resonance for "highpass" or "lowpass", bandwidth for "bandpass"
  5. So, it is baxically established that complete automation will be purposely nade impossible. (No fully automated luxury gay spacr communism for you), but that there will still be lua scripting. However, I imagine parts such as warp drives, TCU units, cockpits, etc will already have some sort of software that we keep quite about to automate some of the processes that run in the part. But what if we didn't do that and force everyone to use mechanical controls and have to control every little thing (no fly-by-wire for instance) or write their own firmware to operate them?
  6. Hi DU Community, I can envision the possibility of large corporations investing in the development of merchant AI (bots) using LUA scripting to interface with the various trade markets, perform analysis and make real-time automated buy/sell decisions based on a set of pre-defined objectives (minimize risk, maximize ROI, etc..) have we received any insight into what type of database architecture will be supporting the DU economy, is it going to be possible via API's or in-game interfaces for players to perform analysis and make informed data-driven decisions or will this type of thing be more of an external metagame? It would be ideal if players could download (in-game) trade/market data from the station/hub they are in to their ships computer which will be a repository for all the analytics described above - this could open the possibility of trading in data/information, for example the more stations you visit (and the more frequently you visit them) the more up-to-date your data assets will be etc.. in-game systems could emerge to enable (data storage, computing power, analysis, data protection, hacking, long-range data relay) other forms of data may include: obviously blueprints scripts/AI (running on-board) trade data (what you've purchased/sold) cargo manifests (historical record) station logs (where you've docked) comms logs (who you've communicated with) Any of this in the works?
  7. I understand that intellectual property in terms of blueprints will be protected, but what about Lua scripts? From what I've seen, they can be edited easily in game. What if I want to design a ship with a Lua script as its main selling point? Can another player steal my script if they buy a ship from me?
  8. This question came to my mind when I saw that many organisations created their own website page and discord server with bots linked to our account on DU website. Will it be possible to send information outside the game with Lua language or Html css ones. For exmple when someone activate a button it could send a message to a particular discord server. Or reverse, a certain action on a server could lead to a message in the game. However I know there will be terrible security issues in this case. But I wanted to know if something similar would exist.
  9. So I am wondering how to approach this idea. I have a construct that is running a script. The construct has 20 doors. The script wants to open or close each of the doors individually. A relay is not appropriate, because I don't know before hand which of the doors will be open or closed, so I can't do fixed wiring. I have not been able to confirm if a Control Unit will be able to handle 20+ Out Plugs from one unit or script. There seems to be a limit of 1 to other Emitting Elements. Any one have any other insights on this? I am using the published dev blogs etc as reference here. Can't wait for pre-alpha to start so I can toy around with this
  10. I would like to see more ideas based on automation. So far, I've seen JC talk about having a large number players working together... Obviously, JC doesn't watch SAO, sometimes you gotta solo... I mean, If I built a large ship with guns, I want to be able to fly it on my own, without having to ask a stranger to come on board and touch my stuff.
  11. How much do you plan to script in-game and what experience do you have?
  12. In the video just released we saw that there was a button with a getState(), but not the door. Every item in the game should have a getState() function. Also every item should have tags and a list so I can do something like "close all exterior doors of the ship", "is there any door open?", etc. Regards.
  13. So what i'm hoping for is the possibility to control things like doors and turrets using scripts. It would be awesome to be able to set certain access rights to specific members for doors, for example. This would help create personal chambers for characters as well as allow only authorized personnel into specific research labs and such. They could be controlled from a placeable terminal inside the room/facility that allows the creator to modify the users that the door will open for. I would suggest the same for turrets, so that if someone unauthorized enters the area, even if it is someone from your own corp, the turret will fire at them. This would also make for more interesting ship boarding scenarios as boarders may have to blast their way through a few doors to get to the control room. Perhaps there are also other actuators that could be controlled through a similar method? Like, floodgates to allow water to flow, or even just lights. Thoughts?
  14. Correct me if I'm wrong but so far from what I've seen and read you can program vessels but only the vessel and its functions. But what if there was a terminal you could place anywhere and program? Similar to Computercraft (Minecraft mod), Which allows you to interact with a Small virtual computer with a basic LUA os. This would be difficult for the Devs and if introduced it would most likely be after release. There are many uses, one of the biggest uses I have and I will use for an Example is, the Empire is planning on a network to keep information on every player who joins the Empire. And it will be private until you register with the Military which will extend your file and add information about you such as what Squad you're in and where you are located. It will also carry a small history and criminal record. This system could be accessed from anywhere in the Empire by members above a certain rank. From there they can write and modify reports on players files. A small LUA system that runs like this can also help run other organisations and businesses as a way to log all shipments and expenses. I see it being a real help to the Economy of the Game. And there could possibly be a way to send signals wirelessly. You could have a Computer send a transmission on a Frequency, and if another Computer receiving on frequency is loaded it can read the signal and decrypt it if needed. This could also grow the diversity of Organisations as now you will have organisations that produce software for other Organisation use. What do you think? Is it Easily Exploitable? Is it asking for the Impossible? Do I even know what I'm talking about? I'm interested.
  15. 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.
  16. [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?
  17. 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.
  18. 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.
  19. 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...
  20. 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.
  21. Ohems

    Remote processing

    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.
  22. 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!
  23. 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
  24. 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.
  25. 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.
×
×
  • Create New...