Page 67 of 70 FirstFirst ... 626566676869 ... LastLast
Results 991 to 1,005 of 1036

Thread: EDDI 2.4 - Bring your cockpit to life

  1. #991
    The EDSM API does not currently support powerplay data... that's one of the holdouts where we're still using jgm's server. I've spoken to EDSM's developer (Anthor) and he's willing to expand the API but it'll probably be post chapter 4 release.

    The fate of the EDDP tab in EDDI is something that I've been pondering recently... the EDDP monitor is another substantial link to jgm's old server that I want to break, and the current implementation is very probably going to become broken with the changes coming to faction states under chapter 4. I can use the EDSM API to obtain faction data for a given system but not to look across systems like the current EDDP implementation allows. To preserve that functionality, we either need an up-to-date server that provides summary data when a BGS change is detected via EDDN (which is what jgm's old server currently provides) or we need to significantly overhaul the EDDP monitor.

    Regardless, the data from the EDDP tab shouldn't create any conflicts with EDSM data. :-)

  2. #992
    Hello. Help needed please and thank you. Fresh install of Windows 10, Elite Dangerous, and Voice Attack. I cannot get EDDI 3.1-b5 to load. I have installed, no love, uninstalled, and reinstalled, but still no love. Your input would greatly be appreciated. Many thanks in advance.

    ***UPDATE***I now have it running as Administrator in Windows 8 compatibility mode. Note sure why I had to make these changes. I was running it 24 hours ago with no issues on my previous Windows install.

  3. #993
    Originally Posted by Cinderelli View Post (Source)
    Hello. Help needed please and thank you. Fresh install of Windows 10, Elite Dangerous, and Voice Attack. I cannot get EDDI 3.1-b5 to load. I have installed, no love, uninstalled, and reinstalled, but still no love. Your input would greatly be appreciated. Many thanks in advance.

    ***UPDATE***I now have it running as Administrator in Windows 8 compatibility mode. Note sure why I had to make these changes. I was running it 24 hours ago with no issues on my previous Windows install.
    Did you enable the use of plugins in the VA settings ?

  4. #994
    We're pleased to announce that EDDI 3.1-rc1 is now available via the beta update channel and on GitHub.

    It is now considered a stable release candidate.

    Both the live version of EDDI (v3.0.3) and this release are safe to use with the beta of Chapter 4 insofar as they won't upload any data that they shouldn't. However both are currently showing minor issues due to events not triggering in exactly the same way in the beta of Chapter 4.

    Full release notes are here.

  5. #995
    Question about the latest update:

    I have a few workarounds in my scripts to deal with non accurate data from the old eddb server. With the change to the edsm server, will things like number of outposts and starports in a system be accurate?

  6. #996
    Originally Posted by Tkael View Post (Source)
    The EDSM API does not currently support powerplay data... that's one of the holdouts where we're still using jgm's server. I've spoken to EDSM's developer (Anthor) and he's willing to expand the API but it'll probably be post chapter 4 release.

    The fate of the EDDP tab in EDDI is something that I've been pondering recently... the EDDP monitor is another substantial link to jgm's old server that I want to break, and the current implementation is very probably going to become broken with the changes coming to faction states under chapter 4. I can use the EDSM API to obtain faction data for a given system but not to look across systems like the current EDDP implementation allows. To preserve that functionality, we either need an up-to-date server that provides summary data when a BGS change is detected via EDDN (which is what jgm's old server currently provides) or we need to significantly overhaul the EDDP monitor.

    Regardless, the data from the EDDP tab shouldn't create any conflicts with EDSM data. :-)
    Ahh OK, I see. Glad that it won't cause any actual problems then.

    It would appear to be a tough choice with what to do regarding the faction information. One that I do not envy you on. Sometimes I wish I had the patience to learn more of the inner workings of EDDI, and the language used to code it, so I may make helpful suggestions, but I'll just have to make do with the Cottle scripting side of things for now.

    Anyway, I have the utmost confidence that you will be able to overcome this little challenge.

    Sorry that I go on a lot about Yuri, and picking at things that are 'not quite right'. It's the perfectionist in me, and I really want EDDI to be as perfect as it can be.

    o7 to the whole team!

  7. #997
    Originally Posted by Zev Woundurlust View Post (Source)
    Question about the latest update:

    I have a few workarounds in my scripts to deal with non accurate data from the old eddb server. With the change to the edsm server, will things like number of outposts and starports in a system be accurate?
    My understanding is that things like that should be ok now, but I'm sure someone can confirm/deny this.

    On that note, would it be possible for the EDDI team to give us a brief list of things that are still dependant on the EDDP server? Or a list of things that EDSM now serves? Whichever list is shorter of course!

  8. #998
    Originally Posted by Zev Woundurlust View Post (Source)
    Question about the latest update:

    I have a few workarounds in my scripts to deal with non accurate data from the old eddb server. With the change to the edsm server, will things like number of outposts and starports in a system be accurate?
    We expect that to be a "yes" and would welcome your testing input to confirm it.

  9. #999
    Originally Posted by Zev Woundurlust View Post (Source)
    Question about the latest update:

    I have a few workarounds in my scripts to deal with non accurate data from the old eddb server. With the change to the edsm server, will things like number of outposts and starports in a system be accurate?
    Outpost and starport (dockable) station data should be quite accurate from EDSM.

    Since EDSM gathers all of its data from EDDN, it doesn't include any manually entered data. Settlement data is manually entered via ROSS and EDDB, so EDSM's data doesn't include any information on settlements. For the time being, and since we have users that may expect settlement data (at least right now), we are adding settlements via the old server data.

    We don't expect EDSM to support settlement data in the future, so when we're ready to break away from the old server entirely we may need to drop support for undockable settlements.

  10. #1000
    Originally Posted by Darkcyde View Post (Source)
    My understanding is that things like that should be ok now, but I'm sure someone can confirm/deny this.

    On that note, would it be possible for the EDDI team to give us a brief list of things that are still dependant on the EDDP server? Or a list of things that EDSM now serves? Whichever list is shorter of course!
    Sure. Here are the things that are still connected to the old server data...

    - For systems... just EDDB id's** (for generating URI's to lookup via VoiceAttack) and powerplay* data.
    - For bodies... just EDDB id's**.
    - For stations... EDDB id's**, commodity price listings*, the ships and modules sold at each station*, and undockable settlement data.
    - For the EDDP monitor... the data stream which summarizes BGS changes for the EDDP monitor.

    * I've discussed adding the marked items to EDSM's API with EDSM's developer. He already collects this data and just needs to make it accessible via the API.
    **It's possible to replace the current EDDB URIs with EDSM URIs in a future update, but for now we're still using the EDDB URIs.

    As you can see, EDSM's API is most lacking when it comes to station data. We expect much of that to improve once EDSM's dev finishes handling changes for chapter 4. Issues have been generated on EDSM's issue tracker at https://github.com/EDSM-NET/FrontEnd/issues/205 and https://github.com/EDSM-NET/FrontEnd/issues/204 for the data we've requested.

    In addition to providing greater accuracy, EDSM has also been able to provide new data that we weren't able to receive previously. The new version we've released adds detailed information about station services and very rapid identification of nearby star systems (which has substantially sped up route plotting in the mission monitor).

  11. #1001
    Awesome! Thank you T'kael.
    Originally Posted by Tkael View Post (Source)
    * I've discussed adding the marked items to EDSM's API with EDSM's developer. He already collects this data and just needs to make it accessible via the API.
    Originally Posted by Tkael View Post (Source)
    As you can see, EDSM's API is most lacking when it comes to station data. We expect much of that to improve once EDSM's dev finishes handling changes for chapter 4.
    Nice to see that this is just a matter of time then. I imagine you would prefer to be totally free from the old server as soon as possible.

    Originally Posted by Tkael View Post (Source)
    The new version we've released adds detailed information about station services and very rapid identification of nearby star systems (which has substantially sped up route plotting in the mission monitor).
    Ooh, nice! I'll be sure to check that out!

    Thanks again for the info, and of course, all your hard work! o7

  12. #1002
    I have had some time to test out the route plotting speed increase, and I must say I'm impressed at how much quicker it really is! It's only a second or two slower than the route plotting I made, and mine only does one iteration, while the EDDI default does many more. Well done guys!

    Having played about a bit I've noticed a few things I hope can be looked at maybe?

    When using the RouteDetails() for any route processing, the 'Missions route' script always seems to be executed (read out) first, before any other text in the calling script, even if RouteDetails() is placed right at the end of a long script. Is there any way at all to make this only execute when actually needed within a script, rather than first before anything else? The only way around this that I can think of right now, is to remove the script text from 'Missions route' and use this event script to only set certain variables. Then use a separate script to do all the reporting, that is called after the RouteDetails() in your first script. I've not actually tried this yet though, to see if it works.

    RouteDetails("route") doesn't seem to store your final destination (your original origin system) when taking missions from other points in your route. If you accept another mission, the current system becomes the final destination in your route.

    The RouteDetails("update") doesn't remove a destination, or recalculate a route, when you go to a system that is not the next in the route. If you go to one that is in the middle of the current route, and complete the mission there, the route remains the same and simply reports "Next mission destination is, X lightyears away." The system you just completed the mission in doesn't get removed.

    Finally, when you follow the route and have multiple missions in one system, RouteDetails("update") removes the system from the route when you hand in the first one, rather than maintaining the current system as the destination until all missions in the current system have been handed in.

    I hadn't actually noticed these things before as I have been using my own implementation of route handling, and I had already taken these things into account within my scripts.

  13. #1003
    Maybe a dumb question, but can anyone enlighten me on this 'route plotting' thing?
    As in how to use it / make it work?

  14. #1004
    Originally Posted by punkerich View Post (Source)
    Maybe a dumb question, but can anyone enlighten me on this 'route plotting' thing?
    As in how to use it / make it work?
    Not dumb at all punkerich.

    When I first made my Missions System in EDDI (one I made from an idea by Brigtiol1, and which the new built-in one is based upon) I also made it calculate an efficient route to take when completing your missions (Hoodathunk helped a lot with that part).

    Now, my original work has been superseded by the new built-in version. It has all the same functionality and a bit more too. I upgraded my personality to use all the new functions. Look up the route stuff in the EDDI help (about half way down the internal help page), or alternatively, give my personality a go.

    If you use VoiceAttack, there are VA commands in my download (in my sig below) that will automate setting a course to your next destination in the route via the Galactic Map. Even if you don't use VA, or choose not to use the VA parts, the route plotting is still useful and will simply report what your next destination along the route is.

    I don't think the default EDDI personality actually uses the route plotting part (yet), but it is all contained within one command RouteDetails(). You can put different parameters in the brackets, e.g. RouteDetails("route"), depending on what you want the function to do. "route" will create a route from all the missions you have, "update" will update the plotted route, "nearest" will tell you the closest system with a mission destination, and so on. This function will then execute the 'Missions route' script, which is used to do all the reporting.

    I had been using my own version of the route plotting as I found the built-in one was much slower. However, it is much faster now, and is on par with my own version for speed. I would like to swap over to the EDDI version, but I have encountered the difficulties I mentioned above, so I am a little reluctant to make the move just yet. Although I can find ways around those problems, I would feel better if they were addressed within EDDI so that everyone can benefit from them.

  15. #1005
    Thank you, Darkcyde, that sounds awesome!
    Sadly gametime is extremely limited atm as of RL stuff and nasty rotating flu in fam , but it really itches me to play around with that.
    I repeatedly thanked the EDDI team in generating an awesome tool to play with, but forgot the awesome community like you, which makes it really shine.

    Hat's off to you mate, and everyone else helping us noobs around here to get a grip.


    Btw., playing with VA coughing and sneezing is an experience in itself, oi.

Page 67 of 70 FirstFirst ... 626566676869 ... LastLast