General Category > Unofficial F/A-18 Acceleration Pack board
Increasing the MFD/HUD refresh rate on the F/A-18
virtuali:
--- Quote from: JamesChams on March 12, 2013, 01:11:44 am ---a). ...saved in a "state file" for future use/reloads somewhere (.xml/.txt file)?
--- End quote ---
No, they aren't
--- Quote ---b). ...just on the fly & need to be modified each time; therefore, can you grant permission to alter this for the former ability?
--- End quote ---
Well, I can't grant any permission about anything on the F/A-18, because it never was our own IP property, it's always been MS property, that's why we couldn't release any "patches" or other fixes as FSDT, it would always go through MS. It's likely (but we don't have any knowledge about this) the F/A-18 rights hasn't even been sold to LM, since it's not included in P3D. Not that I find likely that LM would want to include a Boeing airplane in their own product...
--- Quote ---a). ...what might those be? Do you have a map/list, perhaps somewhere in the SDK, which list those labels, tags, etc. from the .mdl's functions?
--- End quote ---
That's actually fairly easy: we used custom events, if you look in the modeldef.xml file that comes with the Acceleration SDK, many events have an hex code rather than a name, such as this one for example:
<PartInfo>
<Name>switch_guard_fire_r</Name>
<AnimLength>100</AnimLength>
<Animation>
<Parameter>
<Code>
(L:switch_guard_fire_r,number) 100 *
</Code>
<Lag>400</Lag>
</Parameter>
</Animation>
<MouseRect>
<Cursor>Hand</Cursor>
<MouseFlags>LeftSingle</MouseFlags>
<EventID>0x00011004</EventID>
</MouseRect>
</PartInfo>
This means, when you press the button of the left fire prevention guard switch in the F/A-18 model, an 0x00011004 event code will be generated. It will then be your own Gauge task to INTERCEPT that code, and do something.
--- Quote ---b). ...I guess what I'm asking for is the ability to intercept the push buttons of the DDI's in order to implement added functionality?
--- End quote ---
You surely can do that, but you'll have to replace the whole DDI code with a new gauge you write, you can just add new features or pages to the exiting one. If you are prepared to rewrite the DDI code from scratch, then yes, creating new features it's surely feasible, same as others have replaced the HUD.
--- Quote ---Since MS no longer supports FSX will this still be intellectual prosperity at all, without upsetting EULA? Not a GMAX modeler (at least not right now during this post) but attempting something and could use some FREE advise.
--- End quote ---
If you replace the Gauges with your own, there's are IP issues whatsoever, and the information about custom events and their codes is already disclosed in the clear in the modeldef.xml file that comes with the SDK, which means products based on THAT information are explicitly allowed by the SDK EULA, as long as you don't distribute code from MS, but only use the information provided in the SDK to create your own work.
Orion:
I posted a thread about this before but didn't get a response: is it possible to release updates that use delta encoding, which only includes the changed parts of the file?
virtuali:
--- Quote from: Orion on March 12, 2013, 02:08:06 am ---I posted a thread about this before but didn't get a response: is it possible to release updates that use delta encoding, which only includes the changed parts of the file?
--- End quote ---
The whole underlying issue has been already answered long ago, we don't have a complete F/A-18 model source ourselves: MS made some changes in the end, like adding the internal wing views and other small things, and they also changed something in the gauge code, probably to match such modifications they did to the .MDL.
Since we were never given back the source code for the released version (we never had any right to ask for it), what would come out as a "delta", would be something that would "downgrade" the model to an earlier version compared to the released one, a mix-up between what we gave to MS, with some eventual modifications added, and I don't even want to *begin* to think about possible legal ramifications of such distribution, because it would be a new binary obtained by delta patching of a binary compiled from pre-released source code covered by nda, any IP lawyer will go crazy about this, assuming he'll UNDERSTAND what really means...and that's not something we have the slightest intention to discover.
JamesChams:
--- Quote from: virtuali on March 12, 2013, 01:39:08 am ---
--- Quote from: JamesChams on March 12, 2013, 01:11:44 am ---a). ...what might those be? Do you have a map/list, perhaps somewhere in the SDK, which list those labels, tags, etc. from the .mdl's functions?
--- End quote ---
That's actually fairly easy: we used custom events, if you look in the modeldef.xml file that comes with the Acceleration SDK, many events have an hex code rather than a name, such as this one for example:
<PartInfo>
<Name>switch_guard_fire_r</Name>
<AnimLength>100</AnimLength>
<Animation>
<Parameter>
<Code>
(L:switch_guard_fire_r,number) 100 *
</Code>
<Lag>400</Lag>
</Parameter>
</Animation>
<MouseRect>
<Cursor>Hand</Cursor>
<MouseFlags>LeftSingle</MouseFlags>
<EventID>0x00011004</EventID>
</MouseRect>
</PartInfo>
This means, when you press the button of the left fire prevention guard switch in the F/A-18 model, an 0x00011004 event code will be generated. It will then be your own Gauge task to INTERCEPT that code, and do something.
--- End quote ---
Yes, this is what I was looking for... Thank you!
--- Quote ---
--- Quote ---b). ...I guess what I'm asking for is the ability to intercept the push buttons of the DDI's in order to implement added functionality?
--- End quote ---
You surely can do that, but you'll have to replace the whole DDI code with a new gauge you write, you can just add new features or pages to the exiting one. If you are prepared to rewrite the DDI code from scratch, then yes, creating new features it's surely feasible, same as others have replaced the HUD.
--- End quote ---
I was able to locate the (e.g. DDI_x_btn00x) and see the implementations. Of course, many of their internal functionality in C/C++ is hidden within your .gau files but that doesn't necessarily matter if a complete re-write is necessary.
However, I do have other questions regarding your specific implementation of the AI traffic within the function of the DDI's. As I recall (correct me if I not, cause its been quite a while since I looked at this capability specifically), the gauges are able to see AI in both AWAKE, SLEEP and In_Air, On_Ground or On_Sea modes, Correct? I've been studying the ITraffic implementation within the SDK and I want to verify/clarify what the XML and C implementations permit, certain features that allow for correct segregation of AI types and states/mode that they are in. Any clarification of your implementation are/are-not within the .gau files (without breaking trade secrets) would be helpful and appreciated.
--- Quote ---
--- Quote ---Since MS no longer supports FSX will this still be intellectual prosperity at all, without upsetting EULA? Not a GMAX modeler (at least not right now during this post) but attempting something and could use some FREE advise.
--- End quote ---
If you replace the Gauges with your own, there's are IP issues whatsoever, and the information about custom events and their codes is already disclosed in the clear in the modeldef.xml file that comes with the SDK, which means products based on THAT information are explicitly allowed by the SDK EULA, as long as you don't distribute code from MS, but only use the information provided in the SDK to create your own work.
--- End quote ---
OK, just to clarify (in case I'm seeing a typo), there are NO IP issues, right? Also, this begs another question, if I use both the existing gauge in-place while intercepting the OSB's event ID while having another gauge (invisible) do something with it and then pass that along to your DDI gauge instead of what the .gau currently operates, does that also break the IP? This is more to know about boundary/capability limitations for FSX as well as legally defined with in the EULA. I see some developers user your gauges within their models but I'm not sure to what end it is yours and what is theirs.
Grazie! :)
virtuali:
--- Quote from: JamesChams on March 20, 2013, 11:05:21 am ---However, I do have other questions regarding your specific implementation of the AI traffic within the function of the DDI's. As I recall (correct me if I not, cause its been quite a while since I looked at this capability specifically), the gauges are able to see AI in both AWAKE, SLEEP and In_Air, On_Ground or On_Sea modes, Correct? I've been studying the ITraffic implementation within the SDK and I want to verify/clarify what the XML and C implementations permit, certain features that allow for correct segregation of AI types and states/mode that they are in. Any clarification of your implementation are/are-not within the .gau files (without breaking trade secrets) would be helpful and appreciated.
--- End quote ---
There's nothing "specific" we did when reading AI states. Everything it's done 100% according to Simconnect specifications, so there's no need to repeat here what you can surely find in the FSX SDK.
--- Quote ---OK, just to clarify (in case I'm seeing a typo), there are NO IP issues, right?
--- End quote ---
Yes, of course it was a typo.
--- Quote ---Also, this begs another question, if I use both the existing gauge in-place while intercepting the OSB's event ID while having another gauge (invisible) do something with it and then pass that along to your DDI gauge instead of what the .gau currently operates, does that also break the IP?
--- End quote ---
Apart for the absurdity of doing it that way (I don't think it will really work, since you'll have to "fight" against the original gauge code to set the variables), I think my first reply was clear enough: you can do whatever you want, provided you DO NOT DISTRIBUTE ANY MS CODE IN ANOTHER PRODUCT.
But of course, anything I write here doesn't have any legal base whatsoever, since (as I've said, quite clearly) I do not own ANY of the F-A/18 IP anymore, if a Microsoft lawyer comes knocking to your door, don't expect to justify yourself with "Virtuali, the developer, told me it's ok", because even if I was the developer, I don't own such IP anymore because it has been bought by Microsoft long ago, so I don't have any power to allow/disallow anything about it, that's just my personal interpretation of the SDK EULA.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version