49 minutes ago, Ray Proudfoot said:

Really? It will probably sell very well for MSFS but given plenty of people are staying with P3Dv5 there’s no direct competition.

Just like the Colimata Concorde is not a direct rival for this or the FSL’s one.

Ray, with all respect by what metric do you state plenty of people and what measure is plenty?

-B

@DD_Arthur and @btacon, this is not the forum to discuss a Concorde for P3D.

I only posted here to describe how Concorde flew in the real world.

The CIVA INS add-on is something I'm aware of, and we can actually code our own now, but it's whether our target market would want to do that with every flight, as Ray mentions, that is the issue. Frankly, most won't - that's just the way of the world. Despite the level of systems detail that I build my airplanes to, believe it or not I actually love high-fidelity stuff ( I also did my PPL in 2015, although it lapsed a while ago ). But I build for the broader market, not for my personal preferences, and I do genuinely know that most would not want to have to input LAT LONs endlessly for each flight. The best balance is a physically modelled INS, with an FMC running "invisibly" in the background and LAT LON data on the INS screens. We're working on how best to implement this method for navigation purposes to make trans-Atlantic flights accurately.

As they say, you can't please all the people all the time, and there are already a few comments here and there on the Internet about how "it'll be garbage" without an INS, the usual juvenile stuff. The fact that those are so vastly outnumbered by comments from excited prospective owners in itself displays what the larger market are looking for ( and by extension why my aircraft do so well. )

If I can provide a full INS experience in some way though, without compromising or putting the target user off, I'd do it in a heartbeat. I will keep thinking on it. 

 

 

44 minutes ago, rka said:

Not having a CIVA wouldn't be a dealbreaker for me, but I'd like the option to use one as well. Having this as a standalone product would make sense. I haven't heard of the one Ray linked before.

This CIVA addon might be the one required to install the FSLab ConcordeX or an adaptation, it was really good

If it's an oversimplified version of it, I see no point, as the fun part of the CIVA INS, was degradation of the accuracy and improving it with VOR/DME station

29 minutes ago, DC1973 said:

If I can provide a full INS experience in some way though, without compromising or putting the target user off, I'd do it in a heartbeat. I will keep thinking on it. 

That would be great. The target audience for a CIVA would likely be willing to pay for that, but I can see that it's a rather small audience 😄

Edited February 6, 20224 yr by rka

16 hours ago, rka said:

That would be great. The target audience for a CIVA would likely be willing to pay for that, but I can see that it's a rather small audience 😄

Both myself and my coding guy have spent some time looking into this. Currently, there is no way to code LAT LON inputs into MSFS, Asobo simply have not implemented it at this time. That would mean building an entire INS from scratch, in order to serve the small number of users who would consider it essential, so I don't think it's going to happen at this point. I won't rule it out for an upgrade though, I know it's possible to create such things but it would take quite some time.

 

ETA: Just had it confirmed that C++ and WASM gauges will be required for a CIVA INS, and WASM doesn't work yet on consoles ( hence why the DC-6 was pulled ). But at least I know it can be done now so once WASM is available for everybody, an INS will be added as an option for those that want it. Best I can do at this point.

Edited February 7, 20224 yr by DC1973
Edited for additional info

17 hours ago, DC1973 said:

The CIVA INS add-on is something I'm aware of, and we can actually code our own now, but it's whether our target market would want to do that with every flight, as Ray mentions, that is the issue. Frankly, most won't - that's just the way of the world. Despite the level of systems detail that I build my airplanes to, believe it or not I actually love high-fidelity stuff ( I also did my PPL in 2015, although it lapsed a while ago ). But I build for the broader market, not for my personal preferences, and I do genuinely know that most would not want to have to input LAT LONs endlessly for each flight. The best balance is a physically modelled INS, with an FMC running "invisibly" in the background and LAT LON data on the INS screens. We're working on how best to implement this method for navigation purposes to make trans-Atlantic flights accurately.

As they say, you can't please all the people all the time, and there are already a few comments here and there on the Internet about how "it'll be garbage" without an INS, the usual juvenile stuff. The fact that those are so vastly outnumbered by comments from excited prospective owners in itself displays what the larger market are looking for ( and by extension why my aircraft do so well. )

If I can provide a full INS experience in some way though, without compromising or putting the target user off, I'd do it in a heartbeat. I will keep thinking on it. 

 

 

I think this makes good sense.  If there is capability to mod the system and add the CIVA INS for those that want a more realistic option then that would be a perfect combination.

I am not sure I understand the issue. I am no programmer so bear with my crude reasoning.

Does the sim know the difference between GPS and INS  ?

It has specific « layers » reflecting the world coordinates and the aircraft moving position within. A nav equipment will direct the aircraft moves according to each aircraft features. An INS looses its precision over great distances which seems easy to simulate.

Isn’t what the simmer sees  as GPS or INS  « simply » a wrapper dressing up the display of the trajectory and the data feeder for the flightplan ?

Where is the difference of subjacent complexity ? 

I suspect that the problem is more complex than that and I’d happy to be corrected.

 

3 hours ago, DC1973 said:

 

 

ETA: Just had it confirmed that C++ and WASM gauges will be required for a CIVA INS, and WASM doesn't work yet on consoles ( hence why the DC-6 was pulled ). But at least I know it can be done now so once WASM is available for everybody, an INS will be added as an option for those that want it. Best I can do at this point.

Thats great to hear, so hopefully we can get it into the Concorde once it is possible !

I allways flown the Concorde at older times with the INS, it`s just a big fun factor and like real life flying..😎

cheers 😉

Edited February 7, 20224 yr by pmplayer

37 minutes ago, Dominique_K said:

I am not sure I understand the issue. I am no programmer so bear with my crude reasoning.

Does the sim know the difference between GPS and INS  ?

It has specific « layers » reflecting the world coordinates and the aircraft moving position within. A nav equipment will direct the aircraft moves according to each aircraft features. An INS looses its precision over great distances which seems easy to simulate.

Isn’t what the simmer sees  as GPS or INS  « simply » a wrapper dressing up the display of the trajectory and the data feeder for the flightplan ?

Where is the difference of subjacent complexity ? 

I suspect that the problem is more complex than that and I’d happy to be corrected.

 

The coding of an INS itself is not the problem. The issue is that it required the use of C++ and DLL files in FSX and Prepar3D ( via SimConnect ) in order to access the variables needed to create an INS. In MSFS, that process now involves WASM gauges which don't work on the consoles, so I'm a bit stuck until such time as that process is supported on all platforms.

It's looking like it will arrive with a future update though, so somewhere along the line Concorde will have an INS ready for use for those that wish to use one.

Edited February 7, 20224 yr by DC1973

1 hour ago, DC1973 said:

The coding of an INS itself is not the problem. The issue is that it required the use of C++ and DLL files in FSX and Prepar3D ( via SimConnect ) in order to access the variables needed to create an INS. In MSFS, that process now involves WASM gauges which don't work on the consoles, so I'm a bit stuck until such time as that process is supported on all platforms.

It's looking like it will arrive with a future update though, so somewhere along the line Concorde will have an INS ready for use for those that wish to use one.

@DC1973 - Thanks for the communication in this thread.  I honestly would not have considered this Concorde mostly because of other comments I have read, however, you explanations make this something I really am looking forward to flying.  One question, will it be possible to make the system able to accept the Simufly INS that is now compatible with MSFS ?

1 hour ago, DC1973 said:

The coding of an INS itself is not the problem. The issue is that it required the use of C++ and DLL files in FSX and Prepar3D ( via SimConnect ) in order to access the variables needed to create an INS. In MSFS, that process now involves WASM gauges which don't work on the consoles, so I'm a bit stuck until such time as that process is supported on all platforms.

 

Thank you !

The variables you need to create an INS are not the same that the ones you need to create a GPS ? or its it that you use the Asobo GNS 430  like the DC-6  ? 

PS I join Mark to thank you for your honest communication in this thread

Edited February 7, 20224 yr by Dominique_K

1 hour ago, MarkW said:

@DC1973 - Thanks for the communication in this thread.  I honestly would not have considered this Concorde mostly because of other comments I have read, however, you explanations make this something I really am looking forward to flying.  One question, will it be possible to make the system able to accept the Simufly INS that is now compatible with MSFS ?

Thanks Mark. As far as I'm aware the Simufly INS has not been updated since 2019, so it's unlikely to be compatible with MSFS. Happy to be corrected though as it would of course be a great way to circumvent the current limitations regarding WASM gauges.

@Dominique_K  The variables can only be read, not written to, unless via SimConnect and WASM gauges. I can make a display using stock MSFS code that shows the current LAT LON of an aircraft, but it is not possible to create a gauge that lets you select a specific LAT LON.

@DC1973 Thank you for the open communication and your thoughts about this product. I cannot wait to try it out.

Apologies in advance for all the abuse that we all know will come from the Keyboard Warriors upon release. No matter how well you clarify this there will be those comparing it to products 3 times the price. 

3 hours ago, espent said:

@DC1973 Thank you for the open communication and your thoughts about this product. I cannot wait to try it out.

Apologies in advance for all the abuse that we all know will come from the Keyboard Warriors upon release. No matter how well you clarify this there will be those comparing it to products 3 times the price. 

You're welcome!

Sadly, most developers like myself who build for the casual simmer suffer from that sort of thing. I think a lot of folks assume that because we don't build complex systems, we don't do anything else right either.

I can't link to any images here yet, but on Friday will include shots of the INS on my Faceache page weekly-update, with some explanations of what's being done. It's basically identical to the normal INS in appearance, but with some buttons re-purposed to allow in-flight editing of flight plans, and a small screen in place of the LAT LON digit banks.