Hi Oliver,
the HLA specifications (IEEE 1516) are not free, that's a disadvantage. However
there are open-source HLA run-time environments (e.g.
http://www.cert.fr/CERTI), so it's not necessary to implement whole new HLA
run-time environment.
Regarding the multiplayer in FlightGear I see two
Hi Petr.
Am Donnerstag 06 März 2008 14:50 schrieb Petr Gotthard:
Hi Oliver,
the HLA specifications (IEEE 1516) are not free, that's a disadvantage.
However there are open-source HLA run-time environments (e.g.
http://www.cert.fr/CERTI), so it's not necessary to implement whole new HLA
run
On March 7, 2008 02:53:32 pm Ampere K. wrote:
On March 6, 2008 08:50:46 am Petr Gotthard wrote:
Hi Oliver,
the HLA specifications (IEEE 1516) are not free, that's a disadvantage.
However there are open-source HLA run-time environments (e.g.
http://www.cert.fr/CERTI), so it's not necessary
On March 6, 2008 08:50:46 am Petr Gotthard wrote:
Hi Oliver,
the HLA specifications (IEEE 1516) are not free, that's a disadvantage.
However there are open-source HLA run-time environments (e.g.
http://www.cert.fr/CERTI), so it's not necessary to implement whole new HLA
run-time environment
?
libHLA is part of simgear (see simgear/hla). To build flightgear with
-D ENABLE_RTI=ON, you'll first need to build simgear with -D
ENABLE_RTI=ON.
cheers,
Thorsten
Hi Thorsten,
Thanks for the reply, but if you look a little
closer, I AM building simgear, SIMGEAR!, when I get
this error
Hi,
I'm also interested about RTI/HLA informations.
Actually I 've compiled FGFS and SG with -D ENABLE_RTI=ON and I run FGFS with
--hla=bi,10,FOM,ASN,mp-aircraft.xml
If I use av-aircraft.xml in replacement of mp-aircraft.xml I have an FGFS crash
with this error during splashscreen:
Cannot get
Hi Petr.
I (as the author of fgms) would be pretty much interrested to implement fgms
as part of a HLA infrastructur.
What detained me from going that way is, that I found no free (as is free
beer) documentation on HLA specifications and the quite complex structure
(too complex for a one-man
Dear FlightGear developers,(a short introduction first: I'm a newcomer to
FlightGear, my professional profile can be found at
http://www.linkedin.com/in/gotthard) May I ask whether you would be interested
on striving to make FlightGear compliant with the US DoD High Level
Architecture (HLA
Hello,
-Original Message-
Sent: Tuesday, March 04, 2008 11:23 PM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Suggestion to make FlightGear
multiplayer compliant with HLA
I (as the author of fgms) would be pretty much interrested to
implement fgms
exclusive.
I'm building a FlightGear interface for MS HLA simulations
(http://virtualair.sourceforge.net/flightgear.html). There is a single
standartized C++ API, but many HLA infrastructure (RTI) implementations. To use
a particular HLA RTI it's necessary to re-compile and re-link FlightGear
FlightGear multiplayer
compliant with HLA
Dear FlightGear developers,
(a short introduction first: I'm a newcomer to FlightGear, my professional
profile can be found at http://www.linkedin.com/in/gotthard
http://www.linkedin.com/in/gotthard)
May I ask whether you would be interested on striving
Hi,
On Thursday, April 14, 2011 06:07:18 cas...@mminternet.com wrote:
Agree with the first part about hacking, but disagree with the second idea
of cost
HLA is a follow-on to DIS and SimNet developed by DARPA and would require
either an extensive rewrite of FG to be HLA (Stanag 4603
HLA is a follow-on to DIS and SimNet developed by DARPA and would require
either an extensive rewrite of FG to be HLA (Stanag 4603)
compliant or a wrapper function, In addition, there is a thing called
Run-Time Infrastructure (RTI) that handles the federates interfaces
Matthias Fröhlich added
Petr Gotthard wrote:
To follow the do things right rule I think it would be great to implement a
generic interface for standalone I/O modules. Both Micro$oft FSX and X-Plane
have such interface. The MS HLA users would just need to build a shared
module (.dll or .so) for a particular HLA
it in some
way. Moreover, it's not always possible to include all functions in a
single binary. Some functions may be mutually exclusive.
I'm building a FlightGear interface for MS HLA simulations
(http://virtualair.sourceforge.net/flightgear.html). There is a single
standartized C++ API
Mathias Fröhlich wrote:
long promised and now checked in:
First attempt of HLA/RTI support in flightgear.
Cool !!!
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends
Hi all, Hi Mathias,
1 )
I'm really interested by your work about OpenRTI / HLA. I've added the RTI
support in the download_and_compile.sh brisa script's in order to make it more
user-friendly to use and participate to the development.
I compile SG and FG with -DENABLE_RTI=ON since some weeks
Thanks for the links Torsten,
I need to upgrade from git 2.2 release to current to play with this, I have
spend the last few hours since your post digging into HLA.
As there is so much on the move here I was unaware of, best for now i
confine myself to a routine to parse ads-b data.
Harry
Hi Stuart,
On Friday, January 18, 2013 00:04:35 Stuart Buchanan wrote:
1) Are there any significant features/enhancements that have been
missed? (Matthias: what HLA enhancements have been made, and can you
provide a couple of suitable sentences describing them? I'm happy to
wordsmith any
Hi Mathias,
Thank you very much for your comments.
So, as far as I knor HLA/RTI, your problem is divided in two parts:
1. The problem with different RTI implementation libraries.
2. The problem with different fom's
Regarding the RTI libs:
As far as I can see the RTI c++ interface is defined
Hi,
So sorry for the long delay.
On Wednesday 01 July 2009 16:29:23 Petr Gotthard wrote:
The basic HLA standard (both DoD and IEEE variant) provides only a C++
API compatibility at a compile-level. There is a SISO standard that should
assure dynamic link compatibility (DLC). However, some
Hi,
On Thursday, December 20, 2012 22:22:19 Clement de l'Hamaide wrote:
1 )
I'm really interested by your work about OpenRTI / HLA. I've added the RTI
support in the download_and_compile.sh brisa script's in order to make it
more user-friendly to use and participate to the development. I
Hi all,
long promised and now checked in:
First attempt of HLA/RTI support in flightgear.
For the ones that do not know about that, HLA/RTI is message distribution api
used for distributed and paralell real time simulation systems. There are
a few api variants out there where the newest two
or Mac would
handle that.
Oh, and just hitting the send button a little too early, I had wanted to add
that Martin Spott pointed me that the possibilities of using the new HLA layer
for this purpose. I'm currently not familiar with HLA myself to comment on that
though, so I'm just passing
Marcel Fernandez wrote:
Thanks for your help martin, I??m going to get a copy.
BTW, I just reminded that I'm having a copy of a source code package
implementing OpenRadar-on-HLA (as an additional data feed for
OpenRadar, like FG multiplayer and ADEXP). Everything pure Java, like
the rest
is listed by my Synaptic Package
Manager...
And even a general web search does not provide many
hits, and certainly NO clear download sites for
libHLA...
What should I be searching for? What do I need
to install?
libHLA is part of simgear (see simgear/hla). To build flightgear with
-D
I ran a clean build of master/next using download_and_compile.sh -ei and
everything under fgfs/flightgear built including fgviewer.
Smoke test: Run with C172P at KSFO, takeoff for a run to half moon bay.
Multiplayer working.
So what needs testing with HLA?
-Pat
On Sun, 17 Mar 2013 15:30:47
it looks like - I was being told so - that some
people already started jumping onto this idea.
Readers of this list will remember a proposal about implementing an
interface to the so-called HLA ('High Level Architecture') for
FlightGear, using the CERTI RunTime Infrastructure. I've been
monitoring
Hi,
On Wednesday, April 13, 2011 11:52:30 Durk Talsma wrote:
Oh, and just hitting the send button a little too early, I had wanted to
add that Martin Spott pointed me that the possibilities of using the new
HLA layer for this purpose. I'm currently not familiar with HLA myself to
comment
In thinking about it a bit and being reminded of the existing HLA
interface that FlightGear has, I'm leaning toward proposing something
built with Python and the PyQT4 GUI library. Both components are
cross-platform and there is a Python binding for the CERTI HLA library
(PyHLA).
The idea
in
the long run) if clear abstraction layers are not being considered and
it also won't facilitate the task of interfacing FlightGear to other sim
networks in the future.
I've been mentioning HLA because it's the tool precisely made for this
sort of interfacing complex simulation setups together
Hi,
On Thursday, March 07, 2013 18:26:46 Clement de l'Hamaide wrote:
Mathias, some weeks ago I told you about a compilation problem for FG on
Linux when RTI is enabled. You asked me to remind you of this problem
later, this day is came :)
Thanks, I have moved the rti libs below the simgear
Petr Gotthard wrote:
To follow the do things right rule I think it would be great to implement
a generic interface for standalone I/O modules. Both Micro$oft FSX and
X-Plane have such interface. The MS HLA users would just need to build a
shared module (.dll or .so) for a particular HLA RTI
...@mgras.net
Marcel Fernandez wrote:
Thanks for your help martin, I??m going to get a copy.
BTW, I just reminded that I'm having a copy of a source code package
implementing OpenRadar-on-HLA (as an additional data feed for
OpenRadar, like FG multiplayer and ADEXP). Everything pure Java, like
On Sat, 2011-06-25 at 05:48 -0700, Gene Buckle wrote:
On Sat, 25 Jun 2011, Mathias Fröhlich wrote:
Hi Gene,
On Wednesday, June 15, 2011 21:43:36 Gene Buckle wrote:
In thinking about it a bit and being reminded of the existing HLA
interface that FlightGear has, I'm leaning toward
reading older threads and try to understand how the MP
protocol works and where the sharing of random seeds could be really
practicable too actually- I fear I should really take HLA/RTI into
account. A weather engine creates a weather federation which could be
shared by other participants.
Since I'm
Hi,
Mathias, some weeks ago I told you about a compilation problem for FG on Linux
when RTI is enabled.
You asked me to remind you of this problem later, this day is came :)
For remembering :
Clement wrote :
I'm really interested by your work about OpenRTI / HLA. I've added the RTI
Hi,
Rob Ratcliff wrote:
You could use an event distribution (Pub/Sub) paradigm based on
something like the CORBA Notification Service (Event Service), the CORBA
property service, the newer Data Distribution Service (DDS) or something
like the High Level Architecture (HLA). A CORBA ORB TAO
(HLA). A CORBA ORB TAO supports
communication across shared memory or sockets depending on where the
clients and services are running. I know that TAO is used quite a bit
for real time control systems communication for the military.
Do you know the order of magnitude of the real time
(HLA). A CORBA ORB TAO
supports communication across shared memory or sockets depending on
where the clients and services are running. I know that TAO is used
quite a bit for real time control systems communication for
the military.
Do you know the order of magnitude of the real time
Melchior FRANZ wrote:
It's well known that Nasal has an io module with wrappers around
fopen(), fclose(), etc. An aircraft that you install, or even
scenery objects with embedded Nasal could in the past use this
to delete the contents of your whole home directory, or to append
commands to
.
Instead, I'd lobby for familiarization with VirtualAir, an effort
which aims at integrating FlightGear with HLA-compilant simulation
frameworks via the CERTI RunTime Infrastructure:
http://virtualair.sourceforge.net/
As far as I can tell, VirtualAir is not yet ready for general
consumption
Hi,
On Thursday 08 October 2009 22:09:40 Martin Spott wrote:
If bandwidth is not a matter, then you'd probably want to jump on the
HLA train and join the CERTI/VirtualAir effort. They're offering
everything like subscribing to attributes and the such yet I have
to state that reduced
a little bit free time I will build a prototyp.
There is some work going on to make use of an existing standard for realtime
simulations HLA/IEEE1516 for that purpose.
I expect the code landing just past the upcomming release.
So, overall targeting at the topics you wrote on the wiki as well
cas...@mminternet.com wrote:
However, a quick search indicates there is an open source HLA on sourceforge
License is Apache License V2.0, no idea how that compare to GPL or LGPL,
but might be worth a look-see. Whatever, it is going to take time and
effort (cost) to make FG compliant
On Thu, 14 Apr 2011 18:50:18 +0700, Harry wrote in message
BANLkTikwQVYG2zrmu+yE2sbiaCq=CT=z...@mail.gmail.com:
Thanks for the links Torsten,
I need to upgrade from git 2.2 release to current to play with this,
I have spend the last few hours since your post digging into HLA.
..another 3
Thanks for the reply, but if you look a little
closer, I AM building simgear, SIMGEAR!, when I get
this error ;=((
Maybe it would have been better, clearer, if I had
said
Having just successfully compiled the latest
SimGear git, in Ubuntu 10.04, using the default,
which is -D
On 25 October 2011 01:47, Torsten Dreyer tors...@t3r.de wrote:
Hi Geoff,
you need a RTI implementation. I can recommend the OpenRTI implentation
from our fellow FlightGear developer Mathias:
http://developer.berlios.de/projects/openrti/
which you can clone from
git://git.berlios.de/openrti
George Patterson wrote:
Btw, Berlios is closing on 31/12/2011 so grab what you need now. I am
not sure if Mathias has moved the above project to another host.
I'm sure Mathias will speak about the details himself, but aside from
that I can confirm he's aware of the implications. In case of
On Monday, October 24, 2011 22:12:15 Martin Spott wrote:
George Patterson wrote:
Btw, Berlios is closing on 31/12/2011 so grab what you need now. I am
not sure if Mathias has moved the above project to another host.
I'm sure Mathias will speak about the details himself, but aside from
Mathias,
Thanks, I have moved the rti libs below the simgear ones.
Does this help?
Yes it works fine now ! Thanks you.
But a new mistake appers now, FG is not able to found libRTI-NG.so.1 because
the file is in install/openrti/lib/x86_64-linux-gnu/libRTI-NG.so.1 I've fixed
the problem by
Mathias,
I'm not sure if this will help but there is an open source project that is
currently making use of the HLA/IEEE1516 standard.
Check out - www.delta3d.org
Christian
FreedomWorks Inc.
US: 609-858-2290
Canada: 905-228-0285
Fax: 347-296-3666
Email: christ...@freedomworks.ca
likely
sockets. Shared memory would be ideal, but not sure how MS or Mac would
handle that.
Oh, and just hitting the send button a little too early, I had wanted to
add that Martin Spott pointed me that the possibilities of using the new HLA
layer for this purpose. I'm currently
and whatever else
from various sources will render the system unmaintainable (at least in
the long run) if clear abstraction layers are not being considered and
it also won't facilitate the task of interfacing FlightGear to other
sim networks in the future.
I've been mentioning HLA because it's the tool
Suse 11.1 machine but not the new Ubuntu 10.4 installations. A picky new
complier i think but I don't understand it well enough to sort it out.
Now I am not a programmer of any kind and thus really cant assist those who
are, I cant offer comment on HLA and how to implement things, I would only
put
of the existing HLA
interface that FlightGear has, I'm leaning toward proposing something
built with Python and the PyQT4 GUI library. Both components are
cross-platform and there is a Python binding for the CERTI HLA library
(PyHLA).
Well you can use PyHLA - That should just work
loader does this currently. but the lower level of details still
lacks altitude information. And the basic texture is just the croase whole
world texture even in the mid lod case.
That's what I currently use for developing a seperate hla viewer that can be
attached to any hla object. I can
Hi Gene,
On Wednesday, June 15, 2011 21:43:36 Gene Buckle wrote:
In thinking about it a bit and being reminded of the existing HLA
interface that FlightGear has, I'm leaning toward proposing something
built with Python and the PyQT4 GUI library. Both components are
cross-platform
On Sat, 25 Jun 2011, Mathias Fröhlich wrote:
Hi Gene,
On Wednesday, June 15, 2011 21:43:36 Gene Buckle wrote:
In thinking about it a bit and being reminded of the existing HLA
interface that FlightGear has, I'm leaning toward proposing something
built with Python and the PyQT4 GUI library
. :-)
You could use an event distribution (Pub/Sub) paradigm based on
something like the CORBA Notification Service (Event Service), the CORBA
property service, the newer Data Distribution Service (DDS) or something
like the High Level Architecture (HLA). A CORBA ORB TAO supports
communication
at satisfactory performance.
If bandwidth is not a matter, then you'd probably want to jump on the
HLA train and join the CERTI/VirtualAir effort. They're offering
everything like subscribing to attributes and the such yet I have
to state that reduced bandwidth footprint, compared to the current
/asterix/public/subsite_homepage/homepage.html)
Well, OpenRADAR is going the opposite direction: It already provides
FlightGear MP (plus HLA RTI via a side project), ASTERIX could be done
as well by changing swapping another interface in ;-)
I'm surprised to realize that a lot of people don't
2011/4/15 ThorstenB bre...@gmail.com:
Ok, not sure what has changed there, but is it important enough to be
migrated to 2.2? I know it's tempting to make all the new features
available right now (I'd like to see my new TCAS in the release, we've
had 2 JSBSim updates, new HLA support, tank
a configurable
HLA interface, and removing the current one from FlightGear is
extremely cheap compared to making local weather multi-viewer
compatible. Just a random example, think about it
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends
, partly because I'm sick of all the compiler warnings from the
UIUC / larcsim code, but also because at some point in the future we want the
FDMs to be more 'modular' to the rest of FG - eg in their own thread or
HLA-process, potentially. Knowing that the code builds cleanly with, for
example
the compiler
warnings from the UIUC / larcsim code, but also because at some point in the
future we want the FDMs to be more 'modular' to the rest of FG - eg in their
own thread or HLA-process, potentially. Knowing that the code builds cleanly
with, for example, *just* the Null/UFO FDM selected
take a look after the release is
complete. I'll also check
with Matthias to see if there's any HLA issue I should be considering.
Thank you Stuart!
signature.asc
Description: This is a digitally signed message part
be found here:
http://wiki.flightgear.org/Changelog_2.10.0
I have two asks:
1) Are there any significant features/enhancements that have been
missed? (Matthias: what HLA enhancements have been made, and can you
provide a couple of suitable sentences describing them? I'm happy to
wordsmith any text
that have been
missed? (Matthias: what HLA enhancements have been made, and can you
provide a couple of suitable sentences describing them? I'm happy to
wordsmith any text)
- flight-path history on the map is nice, that's one of mine.
- ThorstenB added the capability to save replay tapes to disk
by
adding the apropriate hla objects and attaching the viewer to them.
In the long term this is probably the viewer to use as it is designed to be
used in an environment like this.
Greetings
Mathias
--
Master Visual Studio
with / after 2.12 is to work with Mathias' HLA code to make
this separation possible, unless of course he beats me to it :)
James
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps
if you put the library files outside of x86_64-linux-gnu
and x86_32-linux-gnu you would not be able to tell if the files are for
32 or 64 bit. That directory is part of the multi-arch specification.
I don't think we want to take it out.
Can this be fixed in the CMakeLists.txt?
Is that the right
) or something
like the High Level Architecture (HLA). A CORBA ORB TAO supports
communication across shared memory or sockets depending on where the
clients and services are running. I know that TAO is used quite a bit
for real time control systems communication for the military.
Do you know
, we plan an integration of HLA and web services, one the side
of the CCM implementation.
Another possible approach is the multiplayer mode. We did not use it, because
one of the goals of our work was a performance test of the CCM implementation
used.
Drop me a mail if you have more questions
: It already provides
FlightGear MP (plus HLA RTI via a side project), ASTERIX could be done
as well by changing swapping another interface in ;-)
I'm surprised to realize that a lot of people don't spare effort for
discussing new ATC clients while a slightly rudimentary but rather
functional system
(and also doesn't invalidate any
arguments).
Adding another 'wrapper' around libsgtsync, let's say a configurable
HLA interface, and removing the current one from FlightGear is
extremely cheap compared to making local weather multi-viewer
compatible. Just a random example, think about
with a seperate AI component in a HLA
federation.
Greetings
Mathias
--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating
produced an
executable However this would not run and usually involved using the
depends tool to work out why FG had been made with the wrong set of
libraries.
The final straw came with the incorporation of HLA, which I never sorted
out.
VC100 is to be avoided like the plague. It even seems
a look after the release is
complete. I'll also check
with Matthias to see if there's any HLA issue I should be considering.
-Stuart
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8
that will probably arrive too late for you
if you need that about now. The hla components will enable correct time
slicing over more participants and components.
May be for your particular case: If your simulink models live in the same
matlab, it could help if the data for both aircraft is sent
split out from the simulation backend, via HLA, which is
exactly what Mathias (and soon, myself) are working towards, but slowly.
Regards,
James--
Try New Relic Now We'll Send You this Cool Shirt
New Relic is the only SaaS
messages and runs as a stand-alone utility. I
actually tested the new library using the (remains) of terrasync(.exe)
stand-alone utility - but decided not to push any changes to terrasync
itself. Not now at least.
And I'm pretty aware of the HLA approaches - we've discussed that for
long
Hi,
On Monday, June 18, 2012 13:20:17 castle...@comcast.net wrote:
The HLA/RTI architecture is far more sophisticated than what might be
needed. The idea is not to split FlightGear into a distributed, federated
application across a multi-platform machine or network although
level
stuff with building of 3d models that do not need anything application level
code to animate the models ...
I think of some kind of separation that will also be good if we would do HLA
between a viewer and an application computing physical models or controlling
an additional view hooking
of testing recent, development-features
in 'production' environment at LinuxTag (mostly related to scenegraph
in the past), I'm glad to mention that we were now able to check wether
FlightGear/HLA is robust enough and suitable to serve as a substitute
for multiplayer in local environments. I does
and usually involved using the
depends tool to work out why FG had been made with the wrong set of
libraries.
The final straw came with the incorporation of HLA, which I never sorted
out.
VC100 is to be avoided like the plague. It even seems to have problems
linking with libraries produced
abstraction layer
for switching data source interfaces. Somone built a pure Java HLA
compilant interface for OpenRadar, but that's never been integrated
into the main source tree.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends
, Mathias did the same for
HLA and OSG support, Torsten for the NAV radio and environment code etc.
Then we create some central website listing all available patches, so
people can choose (according to their hardware/performance/interests).
And to make it easier for users: we create a large
from my summer vacation (sometime around early
August). In the mean time, I'm thinking about wether I want to continue with
the current system, or move towards a more modular (multiplayer / network /
HLA) based approach.
4). I will monitor development, handle the occasional bugfix, git commit
further. In
the mean time, the floor is open to anyone who would like to comment or
pursue this idea on their own.
Well, that's about what I am about to do with the HLA stuff.
The nice thing is that the ipc is hidden behind something that is also able to
distribute this across multiple machines
, some weeks ago I told you about a compilation problem for FG
on Linux when RTI is enabled. You asked me to remind you of this
problem later, this day is came :)
For remembering :
Clement wrote :
I'm really interested by your work about OpenRTI / HLA. I've added
the RTI
support
it into a Gitorious project
alongside simgear and all the other stuff, hoping that people drop a
patch every now and then.
One of the various nice features in OpenRadar is its abstraction layer
for switching data source interfaces. Somone built a pure Java HLA
compilant interface
The HLA/RTI architecture is far more sophisticated than what might be needed.
The idea is not to split FlightGear into a distributed, federated application
across a multi-platform machine or network although that is an intriquing
prospect for stimulating the brain cells. ;-)
By way
required to create their visual
scene.
Hopefully, I'll have some time in the fall to pursue this idea further. In
the mean time, the floor is open to anyone who would like to comment or
pursue this idea on their own.
Well, that's about what I am about to do with the HLA stuff.
The nice thing
the efforts.
Regards,
Tom
I don’t know what is it worth to think about a GUI inside fgfs at all
sometimes. When I look to what can be done i.e. with the FGx launcher,
properties and now HLA/RTI I’m thinking about trying to skip the
built-in GUI at all ;-)
Cheers, Yves
architectures (and use multiple CPUs) better. That's
Mathias Fröhlich's HLA/RTI work, and indeed he has done the recent work on
extending fgviewer to test changes to the current terrain system.
Oh, and if you can do IRC, I'm sure the guys in #fg_scenery would be delighted
to discuss what you've done
several times in redoing the property implementation in a
more 'orthogonal' way. That would allow for such extensions in a natural way.
Also from what I currently work on the HLA component seperation, a more
flexible property system might allow me to greatly reduce the communication
load
to be driven by HLA or something similar than most other
parts). No, we're very likely to not get any of this since we're
absolutely unable to motivate - or at least keep people motivated on
working on our project. That's a major issue we have. Everyone who
spends time is welcomed by negative
ground types for traditional scene
queries. Sure, this is much more work to set this up.
In the future, I hope to have a completely independent weather module using
the HLA stuff that runs in an own process/thread. So, at that time you might be
able to do more sophisticated stuff. May
99 matches
Mail list logo
