I’m not using 3rd party means. I’m using simconnect. As far as I’m aware simconnect does not have access to lvars.
If you are saying that’s not true, it does have access to lvars, then please enlighten me.
You mentioned needing FSUIPC to access LVARS. I’m just saying I access LVARS without this. You need WASM I believe.
So I need something in the sim
I think it will remain true that any variable that affects more than one gauge will be readable by other systems in the sim and utilities outside the sim remain as hampered / assisted by 3rd parties as always.
I don’t anticipate the event bus doing much to change that, especially since based on the documentation I’ve seen so far, 3d controls can’t drive / read an event bus - those still depend on lvars.
Exactly. But that is the concern. If a dev uses the event bus over using say an LVAR then we can’t get at the state of whatever that is. If it’s only used for minor internal stuff that would never be needed externally then that’s fine but the moment a var that we want to read/write is on this event bus and not mirrored to an LVAR or default simvar then it becomes a problem. I think the usual pattern will happen here some devs will do it one way and others do it another so this I think will introduce another variance in the already non standard way devs do things. We already don’t have access to B, I, 0 vars and others and this I see as potentially another hidden internal data exchange that we can’t easily get to.
1 Like
Well, it’s only available to screen gauges, so all “non-screen” systems, including those which would be interfaced externally normally will still be driven either by lvars, simvars, or sim events as those are what are available to control “physical” controls (for example the twist/rock/push knob on the GTC will always be firing events that are read by the gauge and which can also be fired by external systems).
The event bus is only available within the new avionics framework. It can’t be used for inter-gauge communication except if both gauges are screens.
I can’t imagine what external access you want to do with that internal information, can you? Literally it just allows for screens to interact with each other more efficiently. This is put in place because they’re moving a ton of data.
1 Like
Perhaps you are right. I did say Its a concern rather than anything I know for sure and maybe it’s nothing. But time will tell what info is passed via that. It was described as akin to a real aircraft databus and those have all types of useful information that I would want to get at. Let’s hope it doesn’t impact but I reserve judgement until we see what it ends up getting used for.
EDIT: An example I thought of. Currently the G1000 Nxi does not share its GPS vertical deviation with the requisite simvar so more behaviours like this would be an issue. I’d like all devs that plan on using this to ask themselves if the data would be needed for an external cockpit and if so either use existing means or mirror the state to the existing means. It’s hard enough as it is right now and I just don’t want to see it get worse.
1 Like
which vertical deviation are you talking about?
There’s two. The VNav one does not but I’m not sure what you are thinking you’d use it for.
The one for GPS approaches (the GP) is actually emitted as a simvar and can drive glide slope needles.
I’m genuinely curious because I’ve tried really hard to think of a variable that is sourced on one of these screens that is not itself driven by an lvar / simvar that would actually be of use to an external system. And so far, all I’m seeing is if someone wanted to make a “better” version of the avionics, but then they’d replace a lot more and would be operating with their own event bus.
1 Like
I still appreciate tentative dates - at least it gives you an idea of around when. It’s software - shipping dates often slip. If it were so easy, everyone would be doing it. Same as in other parts of life - I’ve been waiting a couple of weeks for my 2nd Arc to arrive at my local store. Should have been cross-shipped within a week from another store that’s sitting on inventory. There was a LOT of that last year, but other branches sitting on (or slow-walking trans-shipping) half a dozen video cards because they “might” sell them?
To me March 14th means "best effort for sometime in March - we said the 14th because he have to put SOMETHING on te calendar, or the date would go into perma-slip mode.
Or as one of my notes says - “Relax, you’ll live longer and be around longer and enjoy it more.”
2 Likes
I hope it is better encryption – the sooner the better, but as most selling on the MS-Marketplace will tell you --“WORTH” waiting for.
Imagine if they just put a mechanism in the star rating of “wouldn’t recommend” or similar.
Then tell devs if they get a higher than say 10% of said rating then the product gets removed from the marketplace.
Then say after three product removals you have your status revoked and you can’t release any new products until you reapply.
Something like that.
Not my work, I just described how Amazon “try to” use their review system to keep their products offered at a decent quality level.
3 Likes
Amazon? High level of quality? Look at the sellers who sold legit products, got high ratings, then swapped them out for absolute crap and didn’t get dinged.
Or the restaurants that got caught posting fake bad reviews of their competitors?
It’s like that old saying, “Quis custodiet ipsos custodes” - who will guard the guardians? Who will review the reviewers? Trust systems are HARD to create that someone won’t try to game because $$$
1 Like
“Certain” Marketplace devs have multiple products with One Star Ratings sitting in the 90’s percentage wise.
There’s a product with 93% One Stars alone…out of 500+ ratings.
1 Like
Edited my reply
Now please c’mon. I answered that question citing you yesterday. Or don’t you believe me either?
Yes, you did, but I’ve known the answer as to why Microsoft was hesitant to implement WASM to begin with: The closed ecosystem of Xbox and how WASM could pose a potential security risk.
We also got the answer to why WASM was pushed out of SU11: Jorg stated the User End experience was “clunky”.
Which makes perfect sense: you don’t want to release something that’s never been done in the history of console gaming and have it be an awkward experience.
He also did say it is working as intended. So that’s good.
But, my question still remains: Why was WASM delayed this time?
I’m trying to keep a more positive mind, because we actually are pretty darn close. Which, again, despite no official word on this new delay happened, I’m hoping it’s only because Asobo wants to have Xbox WASM content ready to release on launch day.
3 Likes
Okay, fair enough. But then again, it wasn’t really delayed because they gave us a tentative date with no strings attached, because they didn’t want people being disappointed because of broken promises. It might slip into April for that matter. It’s apparently very difficult and they depend on team XBox OS.
But maybe your point is that when they ‘slip’ you would like to have a CM tell us about the status, the reason, and expectations for the future. Am I right?
I’m working for a software company myself, and amongst other things responsible for writing the release notes. We have one section for future developments with no date promises, just ‘a future version’, and for the rest new and improved functionality. We hardly ever say why something was delayed. It’s always the same: more work than expected. A developer was ill, in hindsight someone took a wrong path to a solution, too many bugs for release, conversion, and backward compatibility issues, (3rd party) integration issues. We keep these details internal, because we only want to communicate what has been deployed. It’s a policy. But, when we mess up with deployed functionality, we then communicate clearly to all affected customers to make an apology and give a time line for a solution. A bit like what Jayne did with the weather glitch last week.
So to summarize: don’t over promise, communicate only about what’s deployed at the moment, and always stand close to your customer when you accidentally mess up.
It might be that MSobo has a similar policy. I think that Jorg has said a few times that he wanted wasm rather yesterday, because he understands that many people are waiting for this. But he also said that it’s very difficult, never done before, and not completely in their own hands.
Should they repeat this sentence like a mantra every time that they have to ‘postpone’? Or should they refrain from mentioning any date at all? For me, I tend to the latter.
Cheers!
4 Likes
In all fairness they havent actually stated SU12 is delayed specifically because of WASM…
2 Likes
This is the one I am referring to. Perhaps it’s finally working. I have been patiently waiting for a fix. The last time I checked it while flying an LPV approach I got nothing. Lateral yes but not vertical. Are you certain you’ve seen it working with GPS and the G1000 and if so what simvar was it?
I don’t think it’s WASM specifically that’s delaying anything. WU12 is the delay. They don’t want to roll out a major content update while a beta is in the works. We’ll get the beta AFTER WU12 comes out. Which would then only leave 2 weeks or less for beta testing, which really isn’t enough. Hence the extra week.
2 Likes
Normally, you would give a roadmap setting out generalities but nothing too specific - like what AMD has done for the next 2 iterations of their video cards, Intel has done for their next 2 iterations of the Arc and their CPUs.
The idea behind roadmaps is to inspire long-term confidence in your product, so that people will stick with you for the long term rather than abandon hope at the first serious setback.
It’s like the roadmap for Meteor Lake - Intel’s 14-gen CPU. Topping out at 6 p cores and 8 e cores [as of a couple of days ago(Intel's 14th Gen Meteor Lake-S Desktop CPUs May Be Delayed, Notebook Chips only Planned for Now [Report] | Hardware Times), I’ve already decided to do a processor refresh to an i9-13900 later this year.
Now if they were to come out with a chip with 10 p cores and zero e cores, I’d be all over that. And there’s enough space on the die to do it. Simplified code execution - no need to decide to schedule a load on either a p core or an e core - would make it a killer for gaming.
1 Like