Jump to content

Search the Community

Showing results for tags 'Programming'.

  • 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 12 results

  1. Like the title says, this is probably a simple question but I'm having an issue getting any kind of custom tweaking done in my ship. Hopefully one of you knowledgeable folks can let me know where I've gone wrong. Currently my ship is setup as a flying construct with the mouse-point control method. I figured I'd start with some 'simple' adjustments so that the ship behaved differently when below a certain speed to simplify the landing process. Apparently I was too ambitious, because when I try to fly the ship it locks up the controls and I get a lovely red "LUA Error" message. I did my best to stick to pretty simple code based on what was already in the script so I'm pretty sure my syntax is correct, but I'm new to LUA so I could be way off base. Here's the code I've tried starting with: local autoRollVelThreshold = 50.0 --my created variable local constructVelocity = vec3(core.getWorldVelocity()) --pre-existing variable -- rolls wings level if velocity is below a certain limit defined by the variable autoRollVelThreshold if constructVelocity < autoRollVelThreshold then local targetRollDeg = utils.clamp(0,currentRollDegAbs-30, currentRollDegAbs+30); -- we go back to 0 within a certain limit if (rollPID == nil) then rollPID = pid.new(autoRollFactor * 0.01, 0, autoRollFactor * 0.1) -- magic number tweaked to have a default factor in the 1-10 range end rollPID:inject(targetRollDeg - currentRollDeg) local autoRollInput = rollPID:get() targetAngularVelocity = targetAngularVelocity + autoRollInput * constructForward end It's based on the pre-existing code for the auto-roll parameter, except instead of using the true/false autoRoll variable I'm using the local variable constructVelocity defined elsewhere in flush() alongside my local variable autoRollVelThreshold which sets the speed at which the action takes place. I thought this would be a simple start to something more complex but it appears I've got some basic issues I still need to get sorted. Any help would be greatly appreciated, thanks.
  2. So I was wondering. We will be able to script in LUA, which is pretty cool. But what if we were able to have databases as well to store and fetch data? Think about the world of programming it would open : statistics, history, logging, stock situation of a warehouse, forecast... basically all information-based services! It could be done with a database element that would whether : - Connect to a reserved database on NQ servers, one on each account to which you could assign rights (to allow organizations to use it) - Connect to an external database on the user's PC or on online. Thoughts?
  3. Hello everyone, I think I've got a cool idea that to my knowledge isn't in the game. When you're coding you need to connect all the lights and buttons etc. one by one. My idea was to make a tool that you could select a big area of lights and buttons etc. with instead of just doing it one by one. example: you're in a freighter's bay, you want that if you walk in all the lights turn on. If you need to do it one by one it's going to become tedious pretty fast. So instead you aim in one corner, hold down a buttons, then aim diagonally at the other side, and voila! you've got a box in which all the electronics will connect to the programming board. I know i can't explain so questions are welcome.
  4. I've been thinking a lot about communication with other players not associated with the character. Perhaps you can add a function that could send limited text messages to the designated ship which displays it on UI. In that way you could have a ship or station constantly sending out messages like "Restricted area" or "Open for buisness" Anyway it's just an idea of mine, tell me what you think.
  5. I'm unsure if this has been posted before so bear with me. I was wondering how the player will be able to work with onboard weapons of ships like small fighters. Will the player be able to link the weapons so they may fire multiple simultaneously or will fighters on have one main that they may operate(I've seen elsewhere that one gun means one player)? If we can somehow link the weapons, would we be able to control sequence of fire in any way? Or be able to link different groups of weapons to different keys? Any help is appreciated, this post should be treated as informational with responses so please keep it civil if you disagree with someone.
  6. How much do you plan to script in-game and what experience do you have?
  7. Hi everyone! In this topic I want to discuss with all of you a topic of 3rd party interface extensions, or to be precise, 2 concepts: 1) API for extracting in-game information 2) API for modifying player interface I will start from vision DU team is trying to achieve. Sandbox in its truest sense, DU first and foremost trying to be not a predefined experience, but a world with a set of rules defining how it works (with many of them being in place to make life in world enjoyable). It is unknown what end experience in world will be, and will ultimately be decided how player community organises itself. All cities, all factions, all markets, laws, interactions and social standarts are going to be built by players, and devs have no idea what those will be by design (although they are trying to influence it in enjoyable direction). This is basicly what emergent gameplay means. And now we move to the topic of User Interface. Naturally, DU team can only build interface for mechanics that they know everything about, so this will be our basic gathering, ship building and piloting interfaces. But very little is known about what actual player interactions will be. For example market, pretty basic structure, but we don't even know what will end up as curency. Will it be some in-game curency? or barter through some common resource? or perhaps pure virtual curency managed by player bank, that is directly tied to game time(PLEX)? On top of it all, market trading requires very sophisticated interface. Product price and volume history graphics being simpliest esential tools for example. Thats why I propose implemeneting API that will allow playerbase to design tools for those tasks. For example, it can be simple addon for traders, that records all transactions and sends to some server, that puts it all together and gives open information to traders in form they need. And it all being managed completely without DU team supervision. Another example can be security rating system, that records aggresive actions against players who use, and creates database of players and organisations to watch out for. We can also take it one step further, and allow complete customisation of in-game UI. For example, players piloting ships can use 3rd party interface, that outputs whatever information in whatever way, that is most convinient for them. Players who afraid of being ganked can have extra window feeding them info whenever another ship enters sensor range, other players may feel vital ship statistics should be better visible and chose such UI, and many would want to have just super cool looking ship interface. That is why propose implementing API for extracting information from objects and player, what they can see and feel, as well as API that would allow to replace objects UI with 3rd party one. Cheers!
  8. 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. Hi! Can a programmed block attached to a ship scan the other blocks attached to it? For example a programmable block could behave in a certain way if some other block is also attached. Or just for calculating the size and shape of the ship so that an automated cannon doesn't fire at the ship itself. Or something, I think you get the idea. Bonus points if the block can also detect nearby but not attached blocks. Such as loose cargo or passengers. Cheers! - Finnboy11
  10. 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.
  11. 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. If not, I think it would be really awesome if this could be implemented. I'd say there'd be the basic missiles which wouldn't need programming but if people knew Lua they could code them. Meaning we'd see missiles acting differently and targeting different things.
  12. Hi, I know that DU is not planned to be easy, and scripting will be irremovable part of game mechanic. It is something cool... but write hundreds lines of code can be bothersome task for non-programmer players; beside this, scripting is quite boring in form (you know - lines and lines of numbers and letters, nothing fancy). So. Maybe we can made scripting mini-game itself and give it some interesting graphical interface, easier to understand by "normals"? Of course "text hard mode" will be always available as second option and even "graphical programming" can have less options than text one, like "beginner" and "veteran" versions I not talk about simplification of programming language itself, but more about some kind of GUI/IDE for that - with auto-complete and - most important - easy graphical interface like "blocks" of code for building apps. I know at last two projects, which use this kind of editors ; LEGO Mindstorm and Scratch. Here are pictures of programs build in them: [sCRATCH] [LEGO] EDT: Here is wiki about this style of programming. And you can even use some like this for LUA, too! In my opinion it will decrease "starting cost" for lot of people, and it can be even inspiration for someone for start learn "true" programming Toughs?
×
×
  • Create New...