20,741
edits
Emesary: Difference between revisions
Jump to navigation
Jump to search
→Work in progress
| Line 78: | Line 78: | ||
|date = Jun 14th, 2017 | |date = Jun 14th, 2017 | ||
|added = Jun 14th, 2017 | |added = Jun 14th, 2017 | ||
|script_version = 0.40 | |||
}}</ref> | |||
ALS landing lights visible on the runway from outside views are with FG since 2016.3 or so - same with the technology of lights external to the aircraft specified via relative geometry (used e.g. to illuminate the Shuttle from the ground floodlights during night landings or SRB separation at night). The latter can also be used for scenery to player or MP to MP illumination, and Richard is toying with the idea of using the emesary MP bridge for the job.<ref>{{cite web | |||
|url = https://forum.flightgear.org/viewtopic.php?p=306389#p306389 | |||
|title = <nowiki> Re: The BK117-B2 </nowiki> | |||
|author = <nowiki> Thorsten </nowiki> | |||
|date = Mar 5th, 2017 | |||
|added = Mar 5th, 2017 | |||
|script_version = 0.40 | |||
}}</ref> | |||
any lighting ''always'' requires some form communication between light source and effect assigned to the surface. In Rembrandt, lots of performance is burned to set this up fairly generally via additional passes and buffers. The ALS technique requires you to set this up specifically - so there has to be an information exchange between light and effect - which is what the light manager does for the Shuttle, and which is what emesary can do more generally between scenery object Nasal snippets and an aircraft.<ref>{{cite web | |||
|url = https://forum.flightgear.org/viewtopic.php?p=306418#p306418 | |||
|title = <nowiki> Re: The BK117-B2 </nowiki> | |||
|author = <nowiki> Thorsten </nowiki> | |||
|date = Mar 6th, 2017 | |||
|added = Mar 6th, 2017 | |||
|script_version = 0.40 | |||
}}</ref> | |||
There are certain things that work better as addons, and with the work Richard has been doing on Emesary FlightGear is in a better position to have integration of addons than it was previously - simply because Emesary removes inter-dependencies.<ref>{{cite web | |||
|url = https://forum.flightgear.org/viewtopic.php?p=318878#p318878 | |||
|title = <nowiki> Re: [Serious Request] Making flightgear combat capable. </nowiki> | |||
|author = <nowiki> Richard </nowiki> | |||
|date = Sep 15th, 2017 | |||
|added = Sep 15th, 2017 | |||
|script_version = 0.40 | |||
}}</ref> | |||
Most of the work that Richard did to the MP protocol - extending the number of properties available and improving the efficiency of transfer came out of the need for the OPRF aircraft to transmit more properties - but is something that has much wider applications. Equally Emesary developments are coming along nicely - we should soon (next few months) see Emesary used on the OPRF fleet to allow models to communicate with each other in a more structured way to provide chaff, flares, radar, missiles, bombs, link16, damage etc. | |||
<ref>{{cite web | |||
|url = https://forum.flightgear.org/viewtopic.php?p=318872#p318872 | |||
|title = <nowiki> Re: [Serious Request] Making flightgear combat capable. </nowiki> | |||
|author = <nowiki> Richard </nowiki> | |||
|date = Sep 15th, 2017 | |||
|added = Sep 15th, 2017 | |||
|script_version = 0.40 | |||
}}</ref> | |||
To work over MP properly the model needs to use the existing property transfer over MP (e.g. in sim/multiplay/generic/). | |||
The best and possibly easiest way to do this is using Emesary with a multiplayer bridge to transmit this (transparently) using a GeoEventNotification. <ref>{{cite web | |||
|url = https://forum.flightgear.org/viewtopic.php?p=312137#p312137 | |||
|title = <nowiki> Re: Synchronization between 2 pc is not reliable </nowiki> | |||
|author = <nowiki> Richard </nowiki> | |||
|date = Jun 9th, 2017 | |||
|added = Jun 9th, 2017 | |||
|script_version = 0.40 | |script_version = 0.40 | ||
}}</ref> | }}</ref> | ||