Page 69 of 69 FirstFirst ... 64676869
Results 1,021 to 1,024 of 1024

Thread: EDDI 2.4 - Bring your cockpit to life

  1. #1021
    Originally Posted by punkerich View Post (Source)
    I got some probs on getting some variables from EDDI to VA, mission related.
    e.g., mission completed type returns 'mission completed', not the actual type (like Donation);
    missionid returns 'not set' (estimating INT value?), on mission accepted + mission completed

    Further, i'd like a hint on how to approach my designated outcome, lemme explain what i'm trying to achieve:

    I'd like to make a VA command 'BGS report' (per session), which should create a (clipboard? file?) like:

    HIP 105408: 6 missions completed for The Kuun-Lan
    2.5m Bounties redeemed for The Kuun-Lan
    256k worth of Exploration Data cashed in at Binney Horizons
    ...

    Things like that, basically all mayor events effecting the BGS, resetting the values after creating a session report.

    How'd you approach that? Stored variables? Write to file (i don't have any clue how to summarize entries in files)? Maybe a DB like sql (basic sql knowledge)?
    Atm, the only consistent value would be the missionid, which i don't seem to get.
    Any ideas?
    Hey punkerich,

    The event 'type' is part of the the 'raw' event data and will always give you the name of the event. The mission 'type' is a derived value and is only available in the mission object via Cottle.

    Not sure why 'missionid' is 'not set' in the Mission accepted event. It a 'long' in in EDDI, which should convert to a VA int... I will look into it and get back to you.

    Meanwhile, seems like your best bet to get all that data would be to modify the 'Mission accepted' personality script to 'SetState' the variables you want VA to have access to.

    For example, add...

    Code:
    {SetState('eddi_context_mission_type', mission.type)}
    {SetState('eddi_context_mission _id', mission.missionid)}

    after the "{set mission to MissionDetails(event.missionid)}" statement in the script.

  2. #1022
    Hi,

    last time, when I was experimenting with mission variables, in VA missionid could be read as DEC.

    BR!

  3. #1023
    Originally Posted by Hoodathunk View Post (Source)
    Hey punkerich,

    The event 'type' is part of the the 'raw' event data and will always give you the name of the event. The mission 'type' is a derived value and is only available in the mission object via Cottle.

    Not sure why 'missionid' is 'not set' in the Mission accepted event. It a 'long' in in EDDI, which should convert to a VA int... I will look into it and get back to you.

    Meanwhile, seems like your best bet to get all that data would be to modify the 'Mission accepted' personality script to 'SetState' the variables you want VA to have access to.

    For example, add...

    Code:
    {SetState('eddi_context_mission_type', mission.type)}
    {SetState('eddi_context_mission _id', mission.missionid)}

    after the "{set mission to MissionDetails(event.missionid)}" statement in the script.
    Thanks Hoodathunk, ofc that would work, too. It's not just the id, things like originstation / originsystem deliver the same 'not set' value. The only things constant seem to be the faction, inf when appropriate. Some values are not like described, like type being returned as 'completed' or such. Would be nice to varify the list shown under 'variables' in EDDI. If it would be too much work i'll go for the setstates.

    Originally Posted by Brigetiol1 View Post (Source)
    Hi,

    last time, when I was experimenting with mission variables, in VA missionid could be read as DEC.

    BR!
    A decimal? Who would've thought that. Thanks mate.

  4. #1024
    Originally Posted by BumbleB View Post (Source)
    Not sure if this has been mentioned in the ED Beta 3.3 but it seems when scanning bodies and re scanning them again the EDDI body scanned gets triggered again so you can scan the same body lots of times and it registers each time.
    As may have already been mentioned, chapter 4 breaks scanning a bit for EDDI. We're used to reacting to each scan logged to the journal as a discrete event. FDev have increased the quantity of scans being written to the journal and we're going to need to be more selective about the events we vocalize than we have in the past. So we're aware that the same scan event can be triggered multiple times and are considering options to make scanning feel like a smoother process again.

Page 69 of 69 FirstFirst ... 64676869