Jump to content

Search the Community

Showing results for tags 'api'.

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

  1. We had it a while back in alpha, the getConstructWorldPos(id) for everything, without transponder, then players started to make construct following construct scripts and amazing AR scripts, which displeased JC who nerfed it hard. While players outsmart limitations and already found other ways, to get a coordinate, with triangulations, why keeping this function nerfed? At least allow us the use of getConstructWorldPos(id) for all statics and space cores and why not for stopped and unboarded dynamic cores . Numbers of abandoned constructs of all types and sizes, in atmo at any altitudes, and space, agg plateforms, elevators towers, floating bases etc... are increasing day by day The multiplications of sophisticated autopiloting scripts for example, where those coordinates information are crucial for good functioning and obstacles avoidance, this getConstructWorldPos(id) nerf just making piloting scripts uselessly heavier, therefore impacts on performances
  2. OUTDATED. NOT UPDATED SINCE v0.23.0 This is the result of running the globals dumping script in-game on constructs that had various elements attached to them. Some exposed functions were called with pcall. The first value indicates whether the call was successful, the second is the actual function return value. All functions that return a vector return it as a table, not as a vec3 structure. Usually such functions will be called like this: local worldGravity = vec3(core.getWorldGravity()). Boolean values are returned as a number 0 or 1, and not as true or false. Element events are not listed here, as they cannot be detected by the dump.lua script. See the codex in-game (press F1) or outside the game (C:\ProgramData\Dual Universe\Game\documentation\web_codex.html) for event and function descriptions and other information. Anti-Gravity Generator r0.21.0 Control unit r0.23.0 Programming board exposes fewer functions compared to cockpit and seat. The control unit has references to linked elements, which are also available as local variables in each event handler. Event handlers defined in the script editor also get placed inside it. Here the control unit is a hovercraft seat that has 2 linked fuel tanks, a radar and a core. Core r0.23.0 Static cores have fewer functions compared to dynamic cores. Databank r0.21.2 Elements with a state r0.21.2 Detection areas, laser detectors and manual buttons expose the same functions. Their state is accessed using getState(). Elements with a toggle-able state r0.21.2 Force fields, ship doors, landing gears and manual switches expose the same functions. The state is accessed using getState() and can be changed by activate(), deactivate() or toggle(). Emitter r0.23.0 Engine r0.21.0 Space engines, atmospheric engines, ailerons, air-brakes, retro-engines and adjustors expose the same functions. Usually engines are controlled through unit.setEngineCommand and do not require linking to the control unit. Fuel container r0.23.0 Gyro r0.21.2 Industry r0.23.0 Item container r0.23.0 Library r0.21.2 Light r0.23.0 PVP radar (atmospheric and space) r0.22.0 Radar not available to craft or buy; for atmosphere and space radars see PVP radar instead Receiver r0.23.0 Screen r0.21.2 System r0.23.0 Telemeter r0.21.2 Warp Drive r0.23.0 Weapon r0.21.0
  3. Dear NQ, this is not really an idea but more a kind request. As a lot of us (players) are going to gather in the Dual Universe adventure, the need to decently manage our corporation will come. At FrogSwarm we are a bit elitist about security and corporation management and so, we already kindly asked for web API to be able to manage our members using our tools. So in the wait of the API, can you at least, since there is no private information to be hidden here, make the user account publicly available instead of restricting it with a dual id logon (ie: https://community.dualthegame.com/accounts/profile/Silmerias)? Then we could crawl it with our tool to start using some identity security check like we do with Star Citizen since the citizen dossier is public available (https://robertsspaceindustries.com/citizens/Silmerias) The tool behind the scene is asking a player to add a temporary code in the 'About me' section to be able to validate his account under our tool and ensure us he's the owner of the dual universe account. The idea was any
  4. I am very proud to introduce the latest product from Evil, Inc! We have been working to develop tools that benefit the community, and the first such tool is a new data tracking website for Dual Universe at www.du-stats.com This site will function very much like zkillboard.com does for EVE Online. Right now it is very basic and only shows a map of the community. This will expand as time goes on with new features coming online over time. Most of the back end tools have already been built and feature development is now more a matter of web design than anything else! Upcoming features include forum statistics, friends list tracking, in depth user profiles, change over time displays, alt detection and organization auditing! Now for some FAQ: What can I use this for? This is a good tool for checking on people who are in your organization, or want to be. It's also a good tool to see which orgs share a lot of members or figure out who that person you are talking to is. Is the data real time? No. The data is not real time and represents the last time when the website refreshed its data. How often does the data update? Depends. It generally is updated once every two days, but sometimes can be a bit faster or slower. Why isn't it real time? There is no need for real time data at this stage. Updating that frequently takes a lot of server resources. The update time will be reduced once there is a need for faster data. When the game comes out, the goal is for a 15 minute update time. Will there be new features? Yes. This is very much an in-development project. Also, I'm not great at web design, so it will be simplistic for a while. How long have you been working on it? About 4 months. What do I do if I found a bug or security flaw? Please either report it here or pm me. I want my org to be excluded from this, can you remove it? Nope. If it exists on the official site, it exists here. If you don't want people to see it, don't create it. I searched for my name and didn't find anything. Why? The map that is currently there only shows people who are in an organization. If you are not in an org, your name will not appear. Future features will show accounts even if they are not in any orgs. Does it work on mobile devices? Maybe. It isn't currently designed for that, but hopefully will be in the future.
  5. How cool & useful would it be if we could script our own (spaceship-)huds and fill them with custom data such as public and private informations. (trading price rates, popular organisation activities, private organisation activities etc.) I know they already said that they will make it possible to create (/customize) our own hud with html but I think that is not enough. I think we need atleast some possibitly to script the (spaceship-)hud and not just redesign it. Or do you think we should all use the same huds for spaceships?
  6. While reading this controversial discussion about Lua sockets: I thought about why not combine an API system with an actual ingame component. Ok, this will be technically 2 ideas in one post, but they are very much related to each other... Basically the problem is how to “manage” ingame information. yamamushi suggested Lua scripts should provide HTTP access to their ingame data, so it can be processed by external applications. But would it be the best way to rely on a "separated" server-client system for that? The problem to access data also exists if you try to build an app inside the game. (e.g. a display unit for a local market) This is a kind of complicated topic, so I'll just try to focus on the brief concept: We have DPUs which are the central hub for ALL data in DU. E.g. I assume the trading system and ship management will also run on DPUs. To exchange the internal data of DPUs we could just connect a special API component that takes some specified variables and makes them available to the PC that is actually running DU.(e.g. using a JSON-RPC or similar to EVEs API system) Thereby external applications can simply access ingame data without a dedicated API server. You might think it’s quite limiting to only be able to access data that is right in front of you, but this is where the comm-array idea comes in... The component for API access would actually be a sort of “Communication Unit”, but unlike previously suggested antennae-concepts it would provide general purpose input/output capabilities. This antenna would be able to connect to other antennae, but be limited by range and number of channels. So each antenna would be able to manage the following I/O data: - current DPU variables - API-channel variables - X other DPU-channels variables To define which variable is send to which channel, NQ would have to provide an interface to “wire up” each channel. Channels can be opened and closed dynamically, but new connection requests always have to be approved by the player operating the DPU. As all this data will have to pass through the main server, the number of possible channels should be quite low. Maybe the most expensive comm-arrays would provide up to 10 channels and be limited to have only 1 on each TU. But 1-channel-comm-arrays could be relatively cheap so they can be integrated in each ship. This would also correspond to the demand, as only big trade-hubs will be able to produce these large amounts of data. Another way to reduce server strain is to have a slower update time from 1min – 1h. Also the sending of data should only be triggered by data changes. Even if you want to access data from far away DPUs, you would be able to build an arrays of comms just to relay data back and forth. Here is a little picture to illustrate the idea: So in theory if we would build a global Network of comm-arrays you could access the status from all trade-hubs around Alioth in one place! Conclusion The main idea of this is that any accessible information inside DU (with or without API) would need to go through an actual network build by players. This would not only make it easier for NQ to channel the dataflow, but also allow exciting ingame scenarios: e.g. a spy might try to infiltrate the enemy’s comm-arrays to steal valuable military information. Of course this is only a general concept. There will be other limitations to consider, e.g. not every kind of data should be allowed to send to the API-channel. The trade-hubs are also a bad example, as this is another controversial topic. But on the long run I’d say this would be a very good system for DU, as it also fits their philosophy that the players have to build their own infrastructure. Such a system would probably take NQ a lot of time to develop, so I don’t expect this to be ready at release. Maybe the other suggestions about an API system could also coexist, or be integrated into this system… but there’s really too little information about most game features right now. The only question I have is would this actually work? I’m sure I forgot some aspects so please tell me!
  7. Idea: Please provide read-only game data APIs for user info (level, orgs joined, current planet, etc.) and market info (price, quantity, orders list, etc.) Reason: I want to build a trade platform and a credit platform with some advanced features. That requires to fetch some in-game data. PS. All trade will happen in-game, so the API could be read-only. The relationship between the game and the plat is the relationship between Steam and SteamDB. (At the level of information provision) Pros: - The platform is independent from the game. So some updates will not affect each other. - I will make a mobile app for the platform in the future. Where the main game cannot run on. - A off-game platform can promote the in-game economy. - The platform provides some advanced features, some of which may not appear in the game. - It's a third-party project, which means that the project is self-financing. - The platform also has a publicity effect on the game. - A senior financial markets can help stimulate the player's vitality. - The existence of credit platform can indirectly help maintain the order of the game. - The platform will not pose a hazard to the game mechanism. - The platform can promote the development of the gaming community. Cons: - Game developers have to maintain a set of read-only APIs. Promises: - I will not abuse the APIs and provide necessary protections to the data obtained. - Fully respect the views of game developers. - I will try to eliminate the competition between the platform and the game. - We will help counteract the behavior that undermines in-game economy. - The platform will not provide any transaction function which could bypass the game. ------------------------------------------ADDITIONAL---------------------------------------------- 1. To be clear. Here I say "trade platform" is a one with ADVANCED ECONOMICAL FEATURES (AEF). Which means auction, mortgage, futures, blockage (blacklist) and other things. It's not simply a data aggregation site nor a trade market, it will be a universal trade platform. Also, real-time data are needed for make those AEFs come true. 2. Everything in the platform involved NO REAL MONEY. RMT is dangerous. 3. When I say "need API", yes, without API access we can also build a platform. But not a convenient one. Also, ability management is a cool idea. So if NQ allowed, please provide skill API. (This is a separate request from the above one) 4. The in-game one is only a list of buy and sell orders and have some simple filter. That's why I want to make a platform with many other features. 5. When we say "first person". Our starting point is always our own rather than the character in game. You HAVE to decide whether b/s or not. You HAVE to make your own decision. And you HAVE to trade them with your in-game character. The platform, just like UI of the game, is for convenience and be concise. If we pursue the first person experience, please turn off UI components first. 6. The most important: When you leave the game. The in-game time will NOT freeze! That's different from non-Online games. We need a platform to track market when we are not online. Imagine that you are hiking now, suddenly you see some one said in the Discord "Metal prices are soaring", would you like to check by yourself or say "hey, give me a screenshot"? 7. We cannot run and understand the market in our mind. But charts and indexes can help us. We need data collected from APIs to draw charts and indexes. Also, charts and indexes are helpful to brokers and analyzers. 8. DU has no bot station but we have DIFFERENT PLANETS. Price may be varied by planets (even locations). So we still need a platform. 9. Black / Hidden market. I said in 1: "blockage (blacklist)". It will perform the function. And it can also be used in the event of war or even you just hate someone. But, if one could find the hidden market in the in-game trade system. It's not hidden any more. Therefore, confidentiality should be the player, not the API thing. Because the APIs will only provide public information. It just make the whole thing more simple. HimeIX, A member of Alpha Academy.
  8. Dear Novaquark, haven't read through all the DevBlogs yet, but the idea your transporting sounds very enticing. You yourself often take EVE Online as a comparison and want to expand on the sandbox made available there. Instead of CCP providing "Citadels" to the players, in a sandbox it should be other players constructing and selling "Citadels" and many other things a creative community will come up with. It will be interesting to see, how this added freedom and sandbox will play out. Getting to the point of this post, again you often refer to EVE Online and the community, the market, economy, PvP to be had there. One aspect that has helped EVE a lot is the introduction of an API, that allow to read/export game data and create applications out of game that help with the individual gameplay. The variety of such 3rd party applications has grown to a huge amount and many players use such applications/sites on a regular basis. However since this API wasn't on the plan during the creation of the game, there are certain restrictions to the data available and the possibilities. Thus the question, if a API/automated data export functionality is planned from the get-go, thus being available in a rudimentary form in the alpha or beta already? And of course if you are interested in and allowing 3rd party applications to expand on the sandbox, you are creating? Thanks and very interested in seeing how DU will evolve, Successor
×
×
  • Create New...