[The E]

I guess that as long as it doesn't distract him from more important stuff (like performance improvements) for too long, it'd be nice to see that.

That's it. Dragon, I recommend you stop commenting on SCP topics in this way. Coders will work on what they consider to be a priority to them, not whatever you think they should work on.

[jr2]

I think he meant to speak in a larger scope of things, like what would (probably) be best for the community (in his opinion, if the coder / member in question wanted to listen to it)... but yeah, it does come off like he is telling people where they should put their efforts.

[Dragon]

I think he meant to speak in a larger scope of things, like what would (probably) be best for the community (in his opinion, if the coder / member in question wanted to listen to it)...

That's what I meant, maybe I should have said it differently. Last time I heard, he was working on optimizing collision detection system, which is a very big deal regarding performance and something that a lot of people (especially those with weaker machines) would like to see.

[The E]

I'm sorry, just like I don't buy Mobius' "language issues" as an excuse, I am unwilling to accept this one. You have been conversing here long enough to be fully aware of how to phrase such things, or, in this case, to not say anything in the first place.

[Goober5000]

I really don't think offense is warranted here.  The E seems to be reading that sentence as "I think it would be more worthwhile if Swifty spent his time on X", whereas I read it as "I would like to see Swifty work on this, but I don't want my humble request to take priority over more important things [such as X] he may be working on".

[m!m]

I have a patch that adds the requested feature to the DRADIS HUD gauge and another feature which adds customizable sounds ("beeps") for the case that an object arrives or departs as torc requested (patch is attached).

Added options:
These go into the "Radar BSG" section after the last entry ("Cockpit Target") and have to appear in the specified sequence:

• Loop Sound: Integer or string identifying the looping sound to be played. This sound will not be played when the view is not in the cockpit or when the HUD is disabled
• Arrival Beep Sound: Same syntax as Loop Sound; specifies the sound that should be played when a ship arrives
• Minimum Beep Delay: float specifying the minimum delay in seconds between two sounds (default 0.25s) for the arrival beeps
• Departure Beep Sound: Same syntax as Loop Sound; specifies the sound that should be played when a ship departs
• Minimum Beep Delay: float specifying the minimum delay in seconds between two sounds (default 0.25s) for the departure beeps

Please take a look at it dear codes

[attachment deleted by ninja]

[Swifty]

Is there a specific reason why you created a new base virtual function for the HudGauge class? It seems like you could just put those sound calls for the Dradis gauge into the Dradis gauge's preprocess() method instead of the onFrame() method.

In fact, if the sounds are only supposed to be played when the gauge is rendering, you might as well throw them into the render() function since that depends on the canRender() condtional so at least the sound playback is dependant on Viewer_mode instead of having to check redundantly in doBeeps() and doLoopSound().

Are the sound entries optional btw? I haven't ever used parse_sound so I'm just wondering.

[m!m]

That method only gets called when cockpit_display_num is less than zero, see

Code: (hud.cpp:1725) [Select]

if ( cockpit_display_num < 0 ) {
    sip->hud_gauges[j]->preprocess();
}and I didn't want to change that as I don't know for which reason that method doesn't get called when there is no cockpit target.

[Swifty]

It really might be better to put those sound calls in the render() method. Are there any objections to that?

[m!m]

The only problem might be that there might be cases where render() doesn't get called for example when setupRenderCanvas() or canRender() fails although an update for the HUD gauge is needed. Thats why I created that method as it's more generic and can also be used for other gauges.

[Swifty]

Well, if the gauge doesn't get rendered, the sound shouldn't be played, no? Is there a reason the sound needs to be played if the gauge isn't rendered?

[Dragon]

Player looking to the side, for instance?

[Swifty]

Player looking to the side, for instance?

The HUD doesn't get switched off for that.

[Dragon]

Not entirely, but certain gauges are not rendered in that mode.

[Swifty]

Not entirely, but certain gauges are not rendered in that mode.

From looking at the code, none of them get shut off.

[Dragon]

Then it shouldn't be a problem (though it means they are somehow rendered, but I can't see them. Perhaps they could be seen if I had more monitors).

[m!m]

I think that for this specific case the location in the render() method is just fine, I used that new method because I thought that a method that gets called once per frame would be good if a HUD gauge needs to update some information regardless if it is rendered or not but if you think that this is not neccessary then I have no objections against the render() method .

[Swifty]

Yeah for sure, that's definitely something that needs to be addressed. I think I need to think about it for a while and try to figure out what roles all these virtual functions have in relation with each other.

In the meantime, provide an implementation using the render method and I think we're good to go.

[Dragon]

BTW, are you going to add these beeps to other radar types?
Arrival and departure beeps sound really interesting.

[torc]

i suppose since they are in the code,you can use them for whatever you want