Hi,
I'm thinking that if you can find the performance graphs for a given
alternator for an aircraft, especially those with rpm vs output
(whether voltage or current) and then put the values into an XML file,
it might do the trick for you. You could then use Kirchoff's laws to
sum the input from
Ampere K. Hardraade wrote:
I have been experimenting with Nasal lately. The focus of my experiment is to
have one Nasal script communicate with another using the property tree. In
an attempt of communication, a Nasal script of mine placed the following
stream of characters to the property
Andy Ross wrote:
Property names should be ASCII strings, by convention at least if not
by force. ASCII strings don't contain nuls.
Oh wait, Ampere is actually trying to put \0 etc into a string (or
default) property? That can't be done. You could however define the
properties to be of type
I don';t think the property tree cares much, I expect this is a string
handling problem in Nasal because it is written in C(++).
Actually, it is the otherway around: Nasal doesn't care, while the property
tree does. I hope Nasal stays that way.
Oh wait, Ampere is actually trying to put \0
Ampere K. Hardraade wrote:
Well, last evening I experimented with putting information one byte at a time
to the property tree as opposed to putting a string, but I don't see this as
a way out because it is not scalable. The running time can reach thousands,
if not tens of thousands easily.
* Ampere K. Hardraade -- Tuesday 31 May 2005 21:12:
I have been experimenting with Nasal lately. The focus of my experiment is
to
have one Nasal script communicate with another using the property tree.
Why don't you exchange data between Nasal-modules directly?
foo.nas:
After a couple hours of flying around the Sembach/Ramstein area I've twice
gotten ground cache errors, with this console output:
prepare_ground_cache(): trying to build cache without any scenery below the
aircraft
FGInterface is being called without scenery below the aircraft!
altitude
* Melchior FRANZ -- Wednesday 01 June 2005 16:49:
Why don't you exchange data between Nasal-modules directly?
foo.nas:
string_full_with_zeroes = \x00\x00\x00...;
bar.nas:
do_something_weird(foo.string_full_with_zeroes);
That was just meant as a code fragment. It should be noted
* Dave Culp -- Wednesday 01 June 2005 16:59:
After a couple hours of flying around the Sembach/Ramstein area I've twice
gotten ground cache errors, with this console output:
prepare_ground_cache(): trying to build cache without any scenery below the
aircraft
FGInterface is being called
Dave Culp wrote
After a couple hours of flying around the Sembach/Ramstein area I've twice
gotten ground cache errors, with this console output:
prepare_ground_cache(): trying to build cache without any scenery below
the
aircraft
FGInterface is being called without scenery below the
Erik Hofman wrote:
I don';t think the property tree cares much, I expect this is a
string handling problem in Nasal because it is written in C(++).
No, Nasal strings are arbitrary byte streams. You can have embedded
zeros. I understood the question to be about the property *name*, not
the
I've automatically (pkg-get) installed FlightGear on my Solaris 10 : all
is here (plib, simgear, fgfs and base), a good scenery ; the simulator
starts normally, with a perfect sound, but... very too slow.
On Fedora or Redhat, i never got this problem after i puted AGPMode =
4 in my XF86.conf.
Sergio wrote:
I've automatically (pkg-get) installed FlightGear on my Solaris 10 :
all is here (plib, simgear, fgfs and base), a good scenery ; the
simulator starts normally, with a perfect sound, but... very too
slow.
What kind of 3D hardware/drivers do you have? FlightGear does not
work in
after fighting with my new graphics card:
I do confirm , the actual CVS release + Mathias Patch is OK.
I just Wonder about the Carrier Landing Fonction with FDM JSBSim.
Up to the release before it it was possible to patch JSBSim ( patch from
Andy Ross a crit:
Sergio wrote:
I've automatically (pkg-get) installed FlightGear on my Solaris 10 :
all is here (plib, simgear, fgfs and base), a good scenery ; the
simulator starts normally, with a perfect sound, but... very too
slow.
What kind of 3D hardware/drivers
On Tuesday 31 May 2005 18:24, Lee Elliott wrote:
On Tuesday 31 May 2005 00:44, Curtis L. Olson wrote:
Lee Elliott wrote:
Can anyone confirm that terrasynch is currently working?
Hmmm, the master scenery server looks like it may have gone
down ... I can't ping it or log into it right
On June 1, 2005 04:23 pm, Andy Ross wrote:
My guess is that the property tree doesn't care either, and it's
simply the output routine that is truncating the string due to the
embedded null. Is there some sample code to exhibit the problem?
Andy
Do you mean something like this?
# **
Ampere K. Hardraade wrote:
Andy Ross wrote:
Is there some sample code to exhibit the problem?
Do you mean something like this?
Yup, that will do it. :)
You're right. The property system does not support arbitrary byte
arrays in the string value. The SGPropertyNode::setStringValue()
Just some general info that may or may not be useful.
General aviation batteries : Typically lead acid
Commercial and military : Typically Ni-Cad (nickel cadmium)
Alternators are far more efficient at *low* RPM than generators but are still
terrible energy converters (unless you really need
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Surgeon schrieb:
Just some general info that may or may not be useful.
General aviation batteries : Typically lead acid
Commercial and military : Typically Ni-Cad (nickel cadmium)
[...]
On the battery side of things the discharge and
20 matches
Mail list logo
