Community A-4E

[shagrat]

Thus far, we have done our best to push the limits, and we've gotten a lot of positive feedback that we appreciate. Our ability to do an EFM is probably there from a skill perspective, but to be honest, it doesn't seem that important to us right now since we don't also have SDK access for the advanced systems modeling. Maybe that's something that can be worked out with ED in the future, but for now, we're sticking to our original goal of "free release of SFM + as much systems modeling as we can do without the SDK." The SFM isn't perfect, but for most of the flight envelope it's pretty darn good.

 

I also would like to point out however that most of the FC3 planes (except for the MiG-29 and Su-33) use PFM, which is a very advanced flight model. FC3 systems modeling is simplified, and they're not clickable, but they fly very accurately.

 

--gos

Yeah, the PFM upgrades make the FC3 jets darn good, from a flight perspective.

Personally I miss the switchology, most of the time.

Whenever flying the F-15 for example, I see myself grabbing the mouse and trying to click clearly visible controls, only to "remember" it is not "clickable" :sad:

 

If ED would make another "upgrade" to implement the "clickable" cockpit... That would be fantastic.

You guys already show what is possible in that regard. : thumbsup:

[legitscoper]

So when this aircraft will be released, which plane/pack I will need?

 

Wysłane z mojego SM-A500FU przy użyciu Tapatalka

[gospadin]

So when this aircraft will be released, which plane/pack I will need?

 

Wysłane z mojego SM-A500FU przy użyciu Tapatalka

 

Nothing. We created it from scratch and it is fully self-contained (except for weapons available in CoreMods, which everyone has access to.)

[LevelPulse]

Thus far, we have done our best to push the limits, and we've gotten a lot of positive feedback that we appreciate. Our ability to do an EFM is probably there from a skill perspective, but to be honest, it doesn't seem that important to us right now since we don't also have SDK access for the advanced systems modeling. Maybe that's something that can be worked out with ED in the future, but for now, we're sticking to our original goal of "free release of SFM + as much systems modeling as we can do without the SDK." The SFM isn't perfect, but for most of the flight envelope it's pretty darn good.

 

I also would like to point out however that most of the FC3 planes (except for the MiG-29 and Su-33) use PFM, which is a very advanced flight model. FC3 systems modeling is simplified, and they're not clickable, but they fly very accurately.

 

--gos

 

If you do an EFM, do the systems have to be done as ASM? I thought you could keep the lua systems but have an EFM.

[CHDT]

I don't know if jato's were used on the variant you are developing, but as it's the first time I see a pic of a A-4 starting with Jato's :-)

 

http://www.use.com/showoriginal.pl?set=f673d53e6f905e78bc3d&p=1

[gospadin]

I don't know if jato's were used on the variant you are developing, but as it's the first time I see a pic of a A-4 starting with Jato's :-)

 

http://www.use.com/showoriginal.pl?set=f673d53e6f905e78bc3d&p=1

 

They were used extensively by the USMC at Chu Lai.

 

About 9 months ago I added Leatherneck's MiG-21 JATO bottles to our A-4, and they shot a lot of flame, but didn't provide thrust. I don't think we can actually implement them without the SDK.

 

--gos

[gospadin]

If you do an EFM, do the systems have to be done as ASM? I thought you could keep the lua systems but have an EFM.

 

My understanding (possibly wrong) is that we can keep basic LUA systems if we wanted to, but we would lose the ability to have systems influence flight behavior or vice-versa because we cannot share data between LUA systems and an EFM without knowing what the API calls are.

 

Basically, the LUA systems calls are limited to the 25 or so primary functions, but if we were to have, say, asymmetric fuel drain due to a pump failure, there's no way to detect that from the Lua (and thus show it on the fuel level indicators) because the API is limited to C++/ASM.

 

--gos

[legitscoper]

My understanding (possibly wrong) is that we can keep basic LUA systems if we wanted to, but we would lose the ability to have systems influence flight behavior or vice-versa because we cannot share data between LUA systems and an EFM without knowing what the API calls are.

 

Basically, the LUA systems calls are limited to the 25 or so primary functions, but if we were to have, say, asymmetric fuel drain due to a pump failure, there's no way to detect that from the Lua (and thus show it on the fuel level indicators) because the API is limited to C++/ASM.

 

--gos

So you want do disassemble API library?

 

 

 

just joking

[NineLine]

My understanding (possibly wrong) is that we can keep basic LUA systems if we wanted to, but we would lose the ability to have systems influence flight behavior or vice-versa because we cannot share data between LUA systems and an EFM without knowing what the API calls are.

 

Basically, the LUA systems calls are limited to the 25 or so primary functions, but if we were to have, say, asymmetric fuel drain due to a pump failure, there's no way to detect that from the Lua (and thus show it on the fuel level indicators) because the API is limited to C++/ASM.

 

--gos

 

I think that sounds about right, and your EFM probably wouldn't be rated as high as a PFM. But then look at ED has done with the FC3 aircraft, so it must be possible, but maybe you need to be a actual 3rd Party to get that kinda access?

[gospadin]

So you want do disassemble API library?

 

 

 

just joking

 

We're not above walking through ED's Lua code in the base installation to see how certain things were implemented, which has helped us figure out how to define new weapons and certain other capabilities.

 

We see reverse-engineering the C/C++ APIs as something that wouldn't be "right" and would likely jeopardize any potential future licensing from ED.

 

If (no, this isn't confirmation) we decided to do EFM/ASM in the future, we'll apply for the license. If we get it, great, if not, we'll just stop work and move onto other things. No matter what happens, this has been a great educational experience for everyone on the team.

 

--gos

[gospadin]

I think that sounds about right, and your EFM probably wouldn't be rated as high as a PFM. But then look at ED has done with the FC3 aircraft, so it must be possible, but maybe you need to be a actual 3rd Party to get that kinda access?

 

FC3 is really a unique set of capabilities. They have simplified engine and systems management, but I believe that's a choice not a limitation. Weapon employment in FC3 (among other things) uses functions that don't exist in the SSM Lua API.

 

As an example, I can change radio channels with Lua, but without the C++ API I cannot turn the radio itself on, thus preventing us from talking to ATC.

 

--gos

[CHDT]

They were used extensively by the USMC at Chu Lai.

 

About 9 months ago I added Leatherneck's MiG-21 JATO bottles to our A-4, and they shot a lot of flame, but didn't provide thrust. I don't think we can actually implement them without the SDK.

 

--gos

 

Thanks for the info.

It would be great to have them.

[SilentEagle]

My understanding (possibly wrong) is that we can keep basic LUA systems if we wanted to, but we would lose the ability to have systems influence flight behavior or vice-versa because we cannot share data between LUA systems and an EFM without knowing what the API calls are.

 

Basically, the LUA systems calls are limited to the 25 or so primary functions, but if we were to have, say, asymmetric fuel drain due to a pump failure, there's no way to detect that from the Lua (and thus show it on the fuel level indicators) because the API is limited to C++/ASM.

 

--gos

 

You can pass information back and forth between lua and the EFM by using the get/set parameter API functions. It is a major pain however and creates an iteration of lag into the system if that is important. That's why I do almost all logic with systems that run in the EFM simulation loop. I still need some lua systems to interface with the sim for several things, but it makes life simpler to run it on the dll. The downside to that is no possibility for active pause, that is, running systems simulation while the EFM is frozen, since the EFM is not called while the sim is paused. Another downside is that all your systems must run at a multiple of the EFM rate (0.006 s) only. I created a subsystem manager to run my systems automatically at rates of 0.006 s (fastest), 0.012 s, 0.024 s, etc. depending on the system.

Edited March 21, 2017 by SilentEagle

[Sport]

This whole thread has been a fascinating insight into the process and intricacies of creating a module. Gives a whole lot more perspective to how and why things take the time they do, especially if you're creating things from scratch. I think many on this forum could benefit from reading the whole thread.

 

I don't possess the skills to follow in your footsteps, but the nerd in me can appreciate the hell out of it!

[gospadin]

You can pass information back and forth between lua and the EFM by using the get/set parameter API functions. It is a major pain however and creates an iteration of lag into the system if that is important. That's why I do almost all logic with systems that run in the EFM simulation loop. I still need some lua systems to interface with the sim for several things, but it makes life simpler to run it on the dll. The downside to that is no possibility for active pause, that is, running systems simulation while the EFM is frozen, since the EFM is not called while the sim is paused. Another downside is that all your systems must run at a multiple of the EFM rate (0.006 s) only. I created a subsystem manager to run my systems automatically at rates of 0.006 s (fastest), 0.012 s, 0.024 s, etc. depending on the system.

 

Yea, there's also an embedded PID controller or something on the parameter API that gives values "momentum" which is really annoying too. Makes for some VERY funky behaviors if you don't code stuff correctly.

 

It was obviously intended for mechanical gauges, but we've extended it to all our inter-system communication. I had forgotten about using it to talk to the EFM, thx.

 

--gos

[SilentEagle]

Yea, there's also an embedded PID controller or something on the parameter API that gives values "momentum" which is really annoying too. Makes for some VERY funky behaviors if you don't code stuff correctly.

 

It was obviously intended for mechanical gauges, but we've extended it to all our inter-system communication. I had forgotten about using it to talk to the EFM, thx.

 

--gos

 

I think I remember you telling me that before, but I have just never seen that behavior. I have used set/get functions from lua systems and the C++ API for discrete and floating values and never had a problem with the value not being what I expect. Now, if you are talking about using the gauge controllers in the mainpanel_init to grab parameter data, maybe that is having an effect, but pure parameters should just store the value you set.

[LevelPulse]

My understanding (possibly wrong) is that we can keep basic LUA systems if we wanted to, but we would lose the ability to have systems influence flight behavior or vice-versa because we cannot share data between LUA systems and an EFM without knowing what the API calls are.

 

Basically, the LUA systems calls are limited to the 25 or so primary functions, but if we were to have, say, asymmetric fuel drain due to a pump failure, there's no way to detect that from the Lua (and thus show it on the fuel level indicators) because the API is limited to C++/ASM.

 

--gos

 

That makes sense, thanks.

[gospadin]

Just a quick comment, a mini March update if you will...

 

We're still here, still working in the background, but at this time the team is not ready to show any of the work in progress from the last month. Hopefully some things come together by the end of April, for another big update.

 

--gos

[AG-51_Razor]

Thanks Gospadin. This is just about all I look forward to on this forum. :thumbup:

[Tirak]

Just a quick comment, a mini March update if you will...

 

We're still here, still working in the background, but at this time the team is not ready to show any of the work in progress from the last month. Hopefully some things come together by the end of April, for another big update.

 

--gos

 

We'd take just a vid of you guys screwing around in the plane too you know :music_whistling:

 

I look forward to the April Update.

[Robert31178]

I'd take a vid of you guys on the company picnic since you've been working so hard lol...... Very excited about this mod!!!

 

~S and keep up the excellent work!!!

[gospadin]

We'd take just a vid of you guys screwing around in the plane too you know :music_whistling:

 

I look forward to the April Update.

 

I have vids of me screwing around in planes from the last few weeks, just not the A-4. =P

[AG-51_Razor]

I have vids of me screwing around in planes from the last few weeks, just not the A-4. =P

 

Any chance one of them was an AD Skyraider?? :music_whistling:

[gospadin]

Any chance one of them was an AD Skyraider?? :music_whistling:

 

Sorry, not nearly as cool: 182RG and 172P. Working on my instrument rating IRL. :pilotfly:

[n8d0g]

Sorry, not nearly as cool: 182RG and 172P. Working on my instrument rating IRL. :pilotfly:

 

Good luck with that. To this day with ATPLs from 2 seperate juristictions, the IREX exam and flight was the hardest thing Ive had to do relative to the experience I had.