Thanks for the praise!
As you can see, there has been a little more improvement (hopefully in time for U.S. Independence Day+weekend), although I'm running out of ideas. For those interested in the details, read on.
My proudest achievement with this release is the separate ns04events.vbs and its filtering. Truly reduced overhead. It doesn't get much better than this. Some might argue it got worse, since the module event calls can (and often do) have fewer arguments than the primary event calls, but the looped code is somewhat faster.
The multiple variables allocated to Lat/Lon/Alt (many modules had one or two sets) had been bugging me for some time. Making them global is a nice code reduction/optimization.
Mappoint went through a lot of reordering, but there hasn't actually been that much change in functionality. Mainly, the huge Initialize call has been in-lined, so instead of literally thousands of checks (or more) in every OnGPSPosition and OnPositionChange, it's only checked once. I still don't have the software, so I haven't tested it. If something is broken, you can go back to a previous ns04mappoint.vbs, but since I changed the calls, you'll also need to copy the calls (i.e., in ns04events.vbs, OnGPSPositionMappoint would take three parameters instead of none, OnScanCompleteMappoint would take four parameters instead of one - basically copy all the old
If UseMappoint statements from the old ns04master.vbs into the new ns04events.vbs, replacing the shorter
If UseMappoint statements).
If you can think of a compelling reason to delay initialization of Mappoint until the first OnGPSPosition, please post it here (not PM) for peer review.
UseGPX was (to some degree) requested by Dutch for
OpenStreetMap. While one can convert the Database (if UseDatabase and IndividualReadings are enabled) or the NS1 file or derivatives, writing directly to a GPX file has benefits (e.g. tracks/segments stopped and started as properly as possible).
A couple of warnings on the GPX support:
- VBScript seems to lack an ability to open a file for both reading and writing. The three constants are ForReading, ForWriting, and ForAppending. If one tries to add two constants together, the Open fails. Therefore, to remove the </gpx> ending, I ended up needing to rename the existing file and copy all of its content (except lines with "</gpx>" on them, of which There Can Be Only One) to a new file. Grr... So this can make things slow if you continually grow your GPX file.
- If you abort out of the script, the GPX file won't have the proper ending, in which case you should manually append the following three lines:
- Code: Select all
</trkseg>
</trk>
</gpx>
Of course, feel free to remove any <trkseg></trkseg> pairs that are empty - they're harmless.
I haven't actually validated the GPX file(s) it produces, because I couldn't get Xerces working well, but if there is a bug it should be easy to fix. Oh, and I don't know if an umlaut'ed U is supported in the gpxCreator setting.
(It's limited to whatever XML supports.)
The most difficult part of the GPX code was trying to determine the timezone (GPX, which uses xsd:datetime, requires knowledge of each timestamp's timezone). If it fails to detect it, you'll need to hardcode it, or suggest another way to detect it. One other side-effect of GPX is that, while sub-second resolution could easily be determined, GPX (per xsd:datetime) won't support it.
UseGPS was requested by cp99, and I'm guessing Xarth might find it useful as well. I haven't actually tested NetStumbler to see how much overhead it cuts out (if any), but every little bit of code removed from loops is arguably worthwhile.
The SAPI.SpFileStream support is somewhat experimental due to lack of easily found examples/documentation. I'll admit, it really doesn't sound great with WAVs I've generated from the
AT&T Natural Voices site (they sound like 16-bit converted to 8-bit, or something like that). If this bothers you, and you'd rather not install SCBLIB, change the SpFileStream constant to something else (e.g. "SAPI.SpScrewyStream") to disable it and use sndrec32 instead. Patches welcomed.
Of course, any feedback is invited. If you're reporting a bug,
please see if you can reproduce it in both the latest version and the
penultimate version (so I'll know whether it's something I broke or something that might've always been broken). If you want something added to the GPX code (e.g. waypoints), PM or post an example and I'll try to code it up (if your example is GPX-compliant). If you can derive a proper KML file from a GPX file that this produces, post both (generated GPX and corresponding KML) and I'll try to write some native KML output code. Fake data is fine (preferable!), as long as it's compliant.
Sadly, I hit the forum's 5 attachments limit, so I've removed 2004-10-30 from the first posting after exactly 500 "views". If anyone wants it (e.g. for comparing), I've attached it to this message.