Jump to content

Search the Community

Showing results for tags 'scripting'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Forum Rules & Announcements
    • Forum Rules & Guidelines
    • Announcements
    • Patch Notes
  • New Player Landing Zone
    • New Player Help
    • FAQ & Information Desk
    • Gameplay Tutorials
    • Player Introductions
  • General (EN)
    • General Discussions
    • Lua Forum
    • Builder Forum
    • Industry Forum
    • PvP Forum
    • Public Test Server Feedback
    • The Gameplay Mechanics Assembly
    • Idea Box
    • Off Topic Discussions
  • General (DE)
    • Allgemeine Diskussionen
  • General (FR)
    • Discussions générales
  • Social Corner
    • Org Updates & Announcements
    • Roleplay & Lore
    • Fan Art

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 15 results

  1. Hello Dualiers, You are building your new starbase, with a magnificent hangar, and other amazing things, and you decide to let an AI manage it, yet it is all bland and lifeless, but you just remember there is the Text to speech api!!! so you give life and activity to your starbase, hearing the resonant control tower voices in the main hangar (note it is pressurized ofc) I think it would be great to add it, there is an open source cpp lib for it: http://www.speech.cs.cmu.edu/flite/index.html it would be great if you added these sounds to the echo features for great spaces. api bindings would be like: (if user not specified, everyone can hear it) speak('hello world' [, user]); shout('stop'[, user]); whisper('come in'[, user]); and aimanager.setVoice(voice); (or anything equivalent) voices could be cosmetic goodies, with generic male and female available by default. Hope you like it!
  2. The devs have said that automated mining will probably not be an option. As a student of business and economics, here's what I think: ABSTRACT: Limiting script automation for both mining and weapons fire will greatly limit the capacity for economic growth and in-game innovation. The mining industry, for example, will start out with individuals mining for minerals and directly selling them to other players or on an open market. It will eventually evolve into a number of mining corporations that will be able to provide minerals more cheaply through an organized workforce and semi-automated processes. This is inevitable, as it should be. But why limit the mining industry to this level of business innovation? By disallowing further automation, yes, the market for mundane repetitive tasks like mining by hand will be preserved. But what would happen to the broader job market in a simulated economy where automation is unregulated? It would expand exponentially. How would automated mining exponentially expand economic growth and job availability? Well, the whole purpose of automation is to reduce labor costs, to reduce the price of goods (raw minerals, in this case), so that, in a competitive free market economy, businesses can stay... competitive. Inevitably, reducing the price of raw minerals allows other businesses, further up the chain of production, to increase production and lower their prices (competitive market, remember). These reduced prices further up the chain of production lead to increased demand and, therefore, new market opportunities. STORY TIME: John Smith is a miner. He mines steel all day for Mineral Corp, gets a commission based on how much steel he mines, and Mineral Corp sells the steel to spaceship manufacturing facilities. One day Mineral Corp decides to cut costs by using automated mining drones. Nooooo!!!! Curse you Human Ingenuity!! Let's look at what just happened: In order to cut costs, mining corporations are now buying automated mining drones. This new demand for drones is providing jobs for programmers, industrial designers, manufacturers, and even truckers (to transport all the extra minerals that are being more cheaply produced and are increasingly in demand by all these industries)! Back to John Smith: John lost his job to robots. The Luddite fear that soulless computers will replace all the honest employees has come true! *cough cough* But when John's at home, drinking away his sorrows with some Pan Galactic Gargle Blaster, he opens up the classifieds and is shocked to see hundreds of jobs available that weren't there yesterday! Not only jobs related to the production of mining drones, but many seemingly unrelated jobs! Where did these other jobs come from? They came from the steel being cheaper. Businesses that use that steel for product production, like spaceships and buildings, can now sell their products more cheaply. Having cheaper spaceships increases the demand for spaceships because more people can afford them. In order to meet that increased demand, spaceship manufacturers must increase their production by hiring more employees (new jobs! Yay!). So now, even though less people are mining by hand, more people are building spaceships (as well as countless other things)! John Smith may not be mining anymore, but he has a new job now, that pays more, and he can enjoy a cheaper cost of living thanks to those beautiful automated mining drones. BASIC FORMULA: Automation = reduced cost. Reduced cost + competition = reduced price. Reduced price = increased demand. Increased demand = increased production. Increased production = increased job availability. Automation + competition = increased job availability. Can we please have free automation scripting? (I may touch on automated weapons-fire later)
  3. I was looking into Lua scripting and found using cookies and simple return codes you can create a simple Chatbot using Lua scripting. I know there hasn't been alot that has been explained on Lua scripting. But I was curious if there will ever be a point where you can talk or chat directly to a object that has a Lua script. I know scripting can be done for simple things like opening doors when sensors go off. The idea of a chatty command council would be interesting. Like for example if the pilot could tell the ship to change course and it would do so and reply yes sir. But would still need more complex things like landing on a planet or heading in the direction of a planet. Or let's say the ship has taken damage and you need to know where. If you could set up sensors on the ship to detect where affected areas are that could be a good way to use the chat bot to notify you where the damage exactly is. Of course it could be used for other things as well.
  4. Where did you guys learn the language Lua? I've been reading the 5.3 reference manual, but i'm worried that it is not a reliable source; it is a few years old, and I'm not sure how recently the syntax was updated. Thanks for the input. Here's the reference manual in case you want to check for relevance: https://www.lua.org/manual/5.3/manual.html
  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. Are in-game scripting and limited automation two fundamentally incompatible concepts? The reason why computers were invented is to automate, and I don't see any other practical applications for scripting other then automation (including automating in-game games).
  7. Howdy hi ho, fellow architects of this fine world! Since scripting will be a big part of the game and not everyone grew up indulging themselves in various programming languages, I thought I'd link this little LUA tutorial here that I stumbled upon while improving my own LUA skills.
  8. 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.
  9. How much do you plan to script in-game and what experience do you have?
  10. Hi, I read the LUA scripting Dev blogs, and I understand the event model and filtering approach. My question is around access to elements and attributes inside of the LUA scripts. Using the "self." mechanism to reference attributes and functions inside of the script. I was wondering if there is any object model of all the available properties and methods available in LUA. Thanks in advance!
  11. So I know that there won't be any npc's, but I've been wondering to what depth will the scripting be. EX: I build a drone and program it to search for and kill players basically will we be able to create simple AI using the in-game LUA scripting tool
  12. I've made this suggestion in another thread, but decided to break this specific suggestion into its own topic as per the Idea Box rules. Computing Power - How to balance Auto-Turrets on constructs EDIT: Before I define what I mean by Computing Power here, let me define what I mean by an Auto-Turret. Auto-Turret is a gun that can be manned by a player, but instead has an Auto-Fire module installed. When the Auto-Fire module is active, the turret with target and fire at attackers using its own gunnery and accuracy stats (no buff from a player) and will function even if there is no player online on the ship. It is a player weapon turned Automated Defense System. The purpose of this post is to describe a way where such a system could exist in a balanced way, in-line with the design intent of NQ. Let me define what I mean by Computing Power here. Computing Power would be a resource provided by core units of constructs. Each system that relies on computing power will occupy a static amount of your ship's total computing power, and only while it is "on" and in use. Flight systems, certain scripted elements, weapons, and auto turrets are examples of systems that would use Computing Power. This resource would be more or less a non-issue for most constructs and would mainly exist as a balance mechanic for PVP constructs. Here is a proposed example of the Computing Power resource at work. Medium ship core has a computing power of 80 Cells. Below is a breakdown of how my 1-2 player ship uses those cells. Flight control scripts require 40 cells. Flight controls might be a flat value, but with Lua scripting the door could be opened to have a more complex flight script that requires more cells. The ship's primary weapon (forward cannon) requires 25 Cells to aim and fire manually. The ship's secondary weapon (side-mounted gatling gun) requires 10 Cells to aim and fire manually. The ship's shield generator requires 5 cells to maintain, but requires 15 cells to re-boot if completely depleted. This means to re-boot the shields, the secondary weapon must be taken offline automatically, or manually. There is an auto-fire module attached to the primary weapon that requires another 45 cells to operate. I cannot turn this module on while the ship is flying, it must be parked. There is an auto-fire module attached to the primary weapon that requires another 25 cells to operate. I cannot turn this module on while the ship is flying and while the primary weapon is in use. This can be turned on if I'm flying solo and want to focus on maneuvering only. There are several ways the ship could be spending those 80 Cells of computing power, but I can't have it all. If I'm flying the ship solo, I can't use the Main and Secondary weapon simultaneously (since I'm just one player). I can alternate between the two, but I can't fire them simultaneously. I also don't have enough Computing Power to have my secondary weapon auto-fire while using the Cannons. If I had a 2nd player on-board, we could be using the cannons and gatling gun simultaneously, however if our shields drop completely, we would have to cease the use of one of our weapons to get our shields back. This creates some compelling pvp decisions as to when to turn off a system, when is the right opportunity to disable a weapon to re-boot the shields. If I park the ship, I can set the cannon to auto-mode, but if I do then the ship can't re-boot its own shields without taking the cannon offline. This gives the ship some means of defending itself while I'm AFK or logged off in a non safe zone, while also making it way less effective than if I were there to use the weapons. If I decided to put the Machine gun on auto mode instead of the cannon while parked, the shields could re-boot or re-charge without losing the gun's functionality, but it would be unable to drive-away a tough ship. Some other features of the Computing Power mechanic... Setting a hierarchy for use using scripting. Lets take the 2-player piloting example from above. If we are both using weapons and the shields drop, there is no longer enough Computing Power to re-boot the shields. With a scripted power-hierarchy, the ship could automatically disable certain systems to free up resources for essential ones (like shields or thrust). Sample or Default hierarchy... Shield - Passive maintenance Flight systems Shields - Reboot Primary Weapon Secondary Weapon Primary Weapon auto-system Secondary Weapon auto-system The hierarchy would disregard any system that is manually disabled. For example a Parked Ship would not consider flight systems when managing its hierarchy. That way the 2-player piloting example would immediately disable the Gatling gun when the shields drop and promptly re-boot the shields to recharge them. Similarly, when the ship is Parked, it could auto-fire the cannon and switch to the Gatling as soon as it needs the computing power to re-boot the shields. This same systems management would work for Static Construct defense systems as well, managing computing power for AFK shielding, managing which turrets should fire, etc. I envision that a large base might have an array of 12 auto-turrets defending the exterior and 6 anti-personal turrets defending the Interior. The interior turrets would be higher on the power hierarchy than the exterior turrets, since fighting off intruders would be more important than supplying Computing Power to the west side of the base (that isn't under attack). The base might only have enough Computing power to fire 3 of those exterior turrets at a time, but could power all 6 of the interior turrets (since antipersonell weapons are smaller, the targets are closer and not moving as fast). A Base might be unable to destroy a heavily armored troop transport ship, but the troops might not be able to overcome the anti-personel defenses and the Base would still be in fine shape. What happens when a player just sets up several constructs in a small area, each with automated defenses? is this haxx? Captaintwerkmotor brought up this issue. There are two environmental limiting factors on automated systems, mainly automated defensive weapons. Each Sector of Space, and each Territory on a Planet has a maximum number of entities (using a max of 3 for examples) that can have automated defenses "turned on" same time across all players (including logged-off, this removes the incentive to multibox or have alts set up stations next to yours). The server decides which entities' turrets get turned on based solely on the entity's type and size. -Mobile and Immobile entities are counted separately, but a parked ship could be counted as an immobile construct for this count. -The constructs with the largest core are counted first, ties in core size are then determined by which entity has the most cores, followed by who entered the sector/territory first. -Once an area has "counted" all of the entities that will be able to use their auto-turrets, anyone else that attempts to turn their auto turrets on will get a "too much interferance" error and they will not activate (nor will they use up computing power). -If a player owns a TU, they can unilaterally give out permissions as to which immobile constructs can turn on turrets. Even if they give out permission, the "max entities per territory" cap will kick in as it normally would. Again, parked ships could count as immobile constructs for this count (to prevent players from designing "ships" meant only to park and supplement a base's defenses). This system should help with server load, to prevent a hundred automated weapons all firing at once in a fleet engagement. It also perfectly prevents a player from setting up a ton of tiny structures with auto-turrets to protect an area.
  13. Folks, Will there be a security system for script code that's enforced by game elements, like having scripts be sealed classes (if that's possible) or will people be free to modify and copy the code of any gadget they purchase? While stealing spaceships and all is something that could be tracked easily enough in-game by a law enforcement body (i.e. the ship is registered and has a serial number engraved on the hull in Kiberium) locking code held in scripts that have to have permission to run on the owner's computer might be problematic. And easy enough to crack with Reflector anyway. If there's no way to even make it difficult to open up the code, I don't think it would be possible to prove that someone has infringed copyright law. I understand that code written in the game will be community property as part of the EULA, is that right? So no actual real world legal issues could ensue. Hmmm... are we being tricked into writing free software for robotics development? >run conspiracytheory.exe
  14. 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.
  15. 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...