(NEW RELEASE) NumericHUDv3.oxp

[another_commander]

I had a very quick test run of the HUD. It is good, but I had crashes to desktop twice after being blown up and pressing space. No unusual events in the log. At this point, I do not know if it had been OXP conflict, or anything else - it was a test done in a hurry, I had plenty of OXPs running and I didn't even think to check stderr.log for possible errors or assertion failures. I tried to replicate the crash through the debugger for getting a backtrace and I couldn't get it to crash (as it usually is the case in situations like this).

I will need to give it some more thorough testing, but the time available right now is not exactly favorable for it.

[Ganelon]

I put some hours in flying with this HUD. So far as I can tell, it works well. I like a lot of it. I did end up dimming it down a bit (to .40) and setting the reticle_target_sensitive to "yes" after I'd flown it once and noted it was off.

I noted one oddity that I didn't attach to the HUD at the time, and only thought to mention because of another_commander's post. I did have some trouble with "press space" after dying, but not all the time. Sometimes it worked, sometimes it seemed to ignore the spacebar keypress and I had to ditch out. On the off-chance it might be related to the HUD, I figured I'd mention it. I do have quite a lot of OXPs installed, so I suppose it's not impossible there could be some conflict somewhere.

But other than that, the HUD seemed to work almost perfectly. Sometimes between station traffic, a furball, icesteroids, and tagged asteroids, I had a whole lot of objects on scanner and viewscreen at once, and I didn't note any slowdown or lag. I did note on one occasion that one segment of a numeral appeared to be missing. It was the top horizontal piece of a "2" in the digit to the left of the decimal in "fuel needed", but I didn't note if it was missing on more than the one occasion I saw it. Other than that, the numeric displays worked just as expected over about five hours of flying. I got into some fairly large fights, did bounty missions, planetary landings, basically putting them and the HUD through their paces.

I found the HUD quite practical. Information was easy to find, it was sensitive to status in useful ways, it's an excellent piece of work.

[JensAyton]

I had a very quick test run of the HUD. It is good, but I had crashes to desktop twice after being blown up and pressing space.

I don’t get crashes, but I do get spurious script timeouts in that situation. Possibly there’s a problem with the stack trace code. Does an infinite loop in JS cause a crash?

[another_commander]

I don’t get crashes, but I do get spurious script timeouts in that situation. Possibly there’s a problem with the stack trace code. Does an infinite loop in JS cause a crash?

Assuming that the test below qualifies, it does not look like an infinite loop causes a crash:
Both whle in the Press Space screen and with the normal flight view showing the HUD, the console command

Code: Select all

for (var i=0;;i++){}

produces the following output in the log:

Code: Select all

16:01:04.257 [script.javaScript.timeLimit]: ***** ERROR: Script "oolite-debug-console" ran for 5.05297 seconds and has been terminated.
16:01:04.257 [script.javaScript.stackTrace]:  0 (<console input>) evaluate()
16:01:04.257 [script.javaScript.stackTrace]:     this: [Script "oolite-debug-console" version 1.75]
16:01:04.257 [script.javaScript.stackTrace]:     PARAM: undefined
16:01:04.257 [script.javaScript.stackTrace]:     command: "\n for (var i=0;;i++){}\n"
16:01:04.257 [script.javaScript.stackTrace]:     result: undefined
16:01:04.257 [script.javaScript.stackTrace]:     showErrorLocations: true
16:01:04.257 [script.javaScript.stackTrace]:     i: 28213719
16:01:04.257 [script.javaScript.stackTrace]:  1 (<console input>) evaluate()
16:01:04.257 [script.javaScript.stackTrace]:     this: [Script "oolite-debug-console" version 1.75]
16:01:04.257 [script.javaScript.stackTrace]:     PARAM: undefined
16:01:04.257 [script.javaScript.stackTrace]:     command: "\n for (var i=0;;i++){}\n"
16:01:04.257 [script.javaScript.stackTrace]:     result: undefined
16:01:04.257 [script.javaScript.stackTrace]:     showErrorLocations: true
16:01:04.257 [script.javaScript.stackTrace]:     i: 28213719
16:01:04.257 [script.javaScript.stackTrace]:  2 (oolite-debug-console.js:300) consolePerformJSCommand()
16:01:04.257 [script.javaScript.stackTrace]:     this: [Script "oolite-debug-console" version 1.75]
16:01:04.257 [script.javaScript.stackTrace]:     command: "\n for (var i=0;;i++){}\n"
16:01:04.257 [script.javaScript.stackTrace]:     originalCommand: " for (var i=0;;i++){}\n"
16:01:27.570 [jstest.shipTakingDamage]: Player ship taking 104.31053924560547 damage by [Ship "Navigation Buoy" position: (-43500.3, 53387.3, 430676) scanClass: CLASS_BUOY status: STATUS_IN_FLIGHT] by means of scrape damage
16:01:27.585 [equipmentDamaged]: Equipment EQ_NUMERIC_GREEN_26_AFTSHIELD damaged.
16:02:16.132 [jstest.shipTakingDamage]: Player ship taking 1037946.4375 damage by [Station "Coriolis Station" "Coriolis Station" position: (-49515.3, 60769.4, 427622) scanClass: CLASS_STATION status: STATUS_ACTIVE] by means of scrape damage
16:02:16.132 [jstest.died]: Player has suffered an existence failure.
16:02:16.132 [jstest.died]: Killed by [Station "Coriolis Station" "Coriolis Station" position: (-49515.3, 60769.4, 427622) scanClass: CLASS_STATION status: STATUS_ACTIVE] by means of scrape damage
16:02:25.273 [script.javaScript.timeLimit]: ***** ERROR: Script "oolite-debug-console" ran for 5.14846 seconds and has been terminated.
16:02:25.273 [script.javaScript.stackTrace]:  0 (<console input>) evaluate()
16:02:25.273 [script.javaScript.stackTrace]:     this: [Script "oolite-debug-console" version 1.75]
16:02:25.273 [script.javaScript.stackTrace]:     PARAM: undefined
16:02:25.273 [script.javaScript.stackTrace]:     command: "\n  for (var i=0;;i++){}\n"
16:02:25.273 [script.javaScript.stackTrace]:     result: undefined
16:02:25.273 [script.javaScript.stackTrace]:     showErrorLocations: true
16:02:25.273 [script.javaScript.stackTrace]:     i: 28659509
16:02:25.273 [script.javaScript.stackTrace]:  1 (<console input>) evaluate()
16:02:25.273 [script.javaScript.stackTrace]:     this: [Script "oolite-debug-console" version 1.75]
16:02:25.273 [script.javaScript.stackTrace]:     PARAM: undefined
16:02:25.273 [script.javaScript.stackTrace]:     command: "\n  for (var i=0;;i++){}\n"
16:02:25.273 [script.javaScript.stackTrace]:     result: undefined
16:02:25.273 [script.javaScript.stackTrace]:     showErrorLocations: true
16:02:25.273 [script.javaScript.stackTrace]:     i: 28659509
16:02:25.273 [script.javaScript.stackTrace]:  2 (oolite-debug-console.js:300) consolePerformJSCommand()
16:02:25.273 [script.javaScript.stackTrace]:     this: [Script "oolite-debug-console" version 1.75]
16:02:25.273 [script.javaScript.stackTrace]:     command: "\n  for (var i=0;;i++){}\n"
16:02:25.273 [script.javaScript.stackTrace]:     originalCommand: "  for (var i=0;;i++){}\n"

Note there is some additonal logging by a test script I use, but in general it looks like infinite loops in JS pass.

[Staer9]

Code: Select all

16:02:16.132 [jstest.died]: Player has suffered an existence failure.

That sounds uncomfortable... suffering an existance failure

[Commander McLane]

CommonSenseOTB, I have a question: why do the fragments of script you posted earlier use mission variables? E.g.:

missionVariables.numericgaugevalue = ((player.ship.position.distanceTo(player.ship.target.position) - player.ship.target.collisionRadius) / 1000);

Why would the state of the HUD go into the saved game file; the game can only be saved when docked, so the HUD would always be in the same state? What have I misunderstood?

Wildeblood, missionVariables can store information that can then be passed on to other functions within the same script as it runs(like I'm doing) or to other scripts or saved with the save game file to be referenced later.

Any JS-variable that starts with this. can also be passed to other functions, even to other scripts. So if you don't need to store something for the next game session, it is advisable to not use mission variables.

[Mauiby de Fug]

Any JS-variable that starts with this. can also be passed to other functions, even to other scripts. So if you don't need to store something for the next game session, it is advisable to not use mission variables.

I'm familiar with passing to other functions to within the same script, but what's the syntax for passing to functions within other scripts?

[CommonSenseOTB]

Code: Select all

16:02:16.132 [jstest.died]: Player has suffered an existence failure.

That sounds uncomfortable... suffering an existance failure

Good one Staer9!

Ganelon, thanx for testing and the glowing review.
The problem with missing pieces happens when the equipment controling that piece is damaged and will eventually correct themselves when the gauge updates. The gauge updates when the gauge value or color changes only. This is due to my jury-rigged script attempting to keep the fps from falling. I will have to add a gauge update when damage occurs in the next version.

The problem with crashing at press spacebar after dieing is news to me. The above posts logs don't show anything definitive. Is it some kind of compatibility issue with other oxp's or a bug in my script or a bug in oolite? Anyone testing is advised to try my oxp by itself and try to get it to crash by dieing and pressing spacebar. If the log shows anything definitive please post it here.

I will go code diving today and check my script again. Could be something simple but why doesn't anything show up in the log? It's good to know that from preliminary reports that that hud works well as was intended. Playtesters please keep posting test reports when you are ready. Thanx!

Added just prior to posting:

Thanx Commander McLane, I was not aware of "this." for variables that work between functions in a script. What's the proper way to use them? Do you have to define them or just use them like normal local variables and do they have anything specific about them that one should know when using them? I'm assuming they also have less overhead(are faster) than missionVariables. Are local variables faster than "this." variables? I think I'm going to update my script and release a 1.1 using these variables. Still learning.

[Thargoid]

Any JS-variable that starts with this. can also be passed to other functions, even to other scripts. So if you don't need to store something for the next game session, it is advisable to not use mission variables.

I'm familiar with passing to other functions to within the same script, but what's the syntax for passing to functions within other scripts?

You want the worldScripts command, specifically worldScripts["<otherscriptname>"].<functionname> or worldScripts.<otherscriptname>.<functionname> for calling a function. Similar syntax applies to reference to variables (although don't forget to check that the script and so the variable are actually loaded first).

The two are interchangable, except the latter doesn't work if there is a space in the other script name. Basically the bit before the function name replaces the "this.", so to call shipDied in the script named "testScript" you would use worldScripts["testScript"].shipDied or worldScripts.testScript.shipDied .

The script name is defined within the script itself by the this.name variable (usually the very first line of the script), not by it's filename (although there is nothing to stop the two being set the same).

[Mauiby de Fug]

Ah, that make sense! Thanks, Thargoid!

[Thargoid]

If you want a practical example, look in either of the scripts in Repair Bots.

And just to be 100% clear, the this.name I mentioned above with reference to the target script is defined in that target script you're calling, not the one you're calling from (although that will of course have it's own name defined by its own this.name line).

[Ganelon]

I do feel I have to point out, CommonSenseOTB, that noting a missing segment for one brief instance in several hours of gameplay is "works pretty near perfect" for practical intents and purposes. I'm also not at all sure that it was this OXP that caused the "press space" to not work.

I got killed a bit more often than usual in the last couple hours of gameplay during that session because I was intentionally "playing hard" to see if I could get your displays to stutter or stall. "Playing hard" includes picking fights with large groups of Vipers (more than 15, let's say), and intentionally ramming enemy ships as a tactic. With ramming other ships, I wanted to see if the "distance to target" readout might glitch if it actually went to zero due to a collision. I also in some cases let one shield intentionally get shot down to zero before evading, which was again looking for any "at zero" programming glitches. I also intentionally let targets escape in a few cases to make sure that didn't mess up the "distance to target" display.

The point I'm making is that I don't usually play like that, and so factors like other OXPs installed might have been the problem as easily as your HUD. I haven't "pushed the system" that hard with Oolite since trying Commander McLane's Railgun or after mare's nest updated the furball oxp. I'll re-stress the point here, that it may be best not to jump to conclusions about the "press space" fail I saw intermittently actually being due to the numerical HUD. Sure, it doesn't hurt to check, but don't assume it *has* to be in your code somewhere, or you may end up chasing a red herring if it actually showed up a few OXPs ago and I just never noticed it. I did not get crashes to desktop like another_commander did, and so far as I've seen we're the only two who noticed any problem at all so far. An important thing to remember in any case, is that the possible problem only shows up sometimes and those times are when the player is already dead! So I wouldn't call it a "breaker" in any case.

I felt that the bit of feedback I gave was more of a flat "just the facts" than "glowing". However, I do feel this effort does deserve some "glow":

First off, it looks great. It is both dynamic enough in function and unusual enough to qualify as being "spectacular" in the sense of something people really should see, since pics don't do it justice. Other than the possible "press space" issue and one measly missing segment noted out of many hours of watching the display, I couldn't get it to glitch on me, and I was trying hard. LOL So it works great. On the fun side, I very much liked watching the digits "rev" up on the speed display when hitting injectors or torus. I never really had much of a sense before of how much faster injectors or torus are than regular full cruise speed, since the regular "speed bar" doesn't actually show a change beyond the usual "full bar" when hitting injectors or torus. That added a bit to being better aware of what is going on with the ship as well as looking way cool. After a little bit to get used to it, I did find the numerical data of the shields to be more important to me in gameplay than the bars had been. There's just something to seeing rear shields down to 14 that made more of an impact on me than "I still have a little bit of shield left on the rear". LOL

All that being said, I do have to mention that being able to see the speed difference between full throttle and injectors did point out to me a possible mildly annoying bit of nonsensical game behavior. Even when cutting a broad arc or flying straight across an NPC opponent's flight path on injectors, they still seem to score about as many hits as when they have an easy shot, like flying head on towards each other with little to no course deviation. Even if their ships can turn that fast, the reaction time to track a moving target doing that steep an acceleration makes it feel more like fighting a machine than living beings.

But back to the HUD. For all the good things I've had to say about it, is it perfectly to my personal tastes? Well, no. And I don't feel it would be reasonable for me to expect that it should be, either. This was the first release, and the most one can hope for is no (or very few) problems. I'd maybe lay out the items a bit differently, I wouldn't use the graphic of the edges of a monitor when in dock, the relative sizes of some of the non-numerical parts didn't all make sense to me, and labeling some of the items might be a nice notion for the comfort of newer Jamesons. I use a joystick and often toggle between regular and precision modes, but that item on the display would be superfluous for a player who doesn't use joystick. But all that is personal tastes, not too hard for me to adjust for myself, and are not things I'd say should are a reflection on the hud itself. I flew with a different HUD for many months before trying this one, and so a lot of it may just be things one gets used to. Even with that bit of "new HUD discomfort", it performed well in several hours of play.

I would say that congratulations are in order. Well done, CommonSenseOTB!

[CommonSenseOTB]

That was a nicely detailed review. Thanx Ganelon. It's good to know you couldn't break it while trying hard to for many hours. A good sign.

I tried and tried but my computer won't crash when hitting space commander after dieing. This is with no other oxp's in the AddOns folder so I'm confident my oxp is sound. Must be some other cause like another oxp or a possible conflict directly between my oxp and another one. The only thing in my script when the ship dies is removing the frame callbacks and stopping a timer. And startup just defines missionVariables. Just wondering what could confict with that and cause a crash.

I'm making a sightly revised version1.1 of this oxp to clean the script up a bit and refresh the display when damage happens. I will post it when it's done. Keep the reports coming please.(and thankyou)

[CommonSenseOTB]

NUMERIC HUDv1.1 is now available.

Features: -improved fps performance(5+)
-far fewer script ran too long errors
-refresh for gauges when damaged

Edit:Download Link Updated

http://wiki.alioth.net/index.php/Numeric_Style_HUDs

If you have version 1 you are advised to discard it in favor of version 1.1 as it is faster and improved. Enjoy!

[another_commander]

With some help from Svengali, the crash has been replicated and we have indeed an assertion failure in stderr.txt:

Code: Select all

JS API usage error: the address passed to JS_AddNamedRoot currently holds an
invalid gcthing.  This is usually caused by a missing call to JS_RemoveRoot.
The root's name is "frame callback".
Assertion failure: root_points_to_gcArenaList, at jsgc.cpp:1457

To replicate: Load save game, launch from station, turn 180, accelerate and just before colliding press F5. The game ends and upon press space it's CTD. This does not work every time for me, and I managed to replicate it only by running the game outside of the debugger.

Investigation time...