Re: [Flightgear-devel] [RFC] tacan rewrite
Csaba Halász On 4/12/07, Vivian Meazza wrote: Why do you want to offset a TACAN position? You know why: because on the carriers the tacan altitude is 100 feet. And that *is* fixed, no matter where the carrier happens to be. It should be fixed relative to the carrier. So as to hide this detail I have introduced the TACAN position which gets calculated from the model position and an offset vector. Well - if a carrier ever moves from sea level we can take the elevation add the carrier altitude. Is anything more needed? Umm, actually that is what I have done. Just in a more generic way, such as possibly accounting for lateral displacement and non-level orientation of the carrier. Admittedly does not amount to much in case of the tacan, but seems to be more logical this way. Looks like just for me. Why on earth are you hard coding TACAN idents? Why limit the MP to only one tanker ident? It is actually a limit of 9, MOBIL1-9. I could have used a *local* configuration file (or property) there, but this is just a temporary solution - I expect tacan information to come through MP protocol. Then this code will just disappear without affecting anything else. And please note that the isTanker flag *is* set from this hardcoded MOBIL callsign as well. I don't think my solution is that much worse. At least it is well localized. Yes - I know - wrote it. And I think that you might have misinterpreted the code here. The flag isTanker is set if any MP object has a callsign starting with MOBIL - it can be followed by anything. But just because it has the callsign MOBIL* doesn't imply that it fitted with TACAN - that is determined by the callsign/TACAN ID assignment in carrier_nav.dat. Any callsign can be associated with any TACAN ID - MOBIL is just a bit of a pun. Not all tankers have TACAN transmitters - the Sea Vixen in the Buddy-Buddy role is one such example. The inverse is, I think, true: I know of no airborne TACAN transmitter which isn't a tanker, but I'm a bit out of date here, and this might have changed. Of course, the association of the callsign MOBIL* with a tanker is a hack - the property isTanker ought to be passed over MP. But when this was written no properties were passed, and adding them to the MP servers is not trivial. And these changes make it possible to provide tacan parameters from MP. Like changing channels, disabling transmitter and such. All at runtime. That is a desirable goal is it not? My solution might not be the best way to do it, though. Switching on/off is indeed desirable, but not changing channels at runtime. Channels are assigned by headquarters for a mission and not changed in flight. In my day, this was only done by the ground crew, but it might well be possible in flight nowadays. Passing the appropriate property value over MP should suffice, if we had a controllable TACAN transmitter in the aircraft, which right now we don't. Right. Next step would be to send tacan channel over MP as well and then this temporary workaround would vanish. In the meantime I thought it wouldn't matter as I assumed pretty much everybody uses the default config anyway. But changing my version to support this is easy as all the pieces are in place. Carriers come from scenarios now - no need for their tacan to be in the carrier-nav.dat, might as well add them to the scenario (which essentially models the headquarters) If in the future they come from MP, the carrier-nav.dat is again not needed. Also note that runtime includes whenever a new pilot joins, similar to passing the call sign. Everybody else should see the tacan of *my* aircraft as *my* ground crew (the command line) set it - not as it is mapped in *their* carrier-nav.dat. What is wrong with the existing FLOLS and Parking Position Code? Nothing, that was just a code cleanup. Refactored duplicated code that reads a x-offset-m, y-offset-m and z-offset-m triplet into a corrected SGVec3d. It now lives in FGAIBase::readOffsetFromScenario() because I happened to need that too. Surely that is not a bad thing? It is indeed a bad thing - only properties that are common to more than one AI Object live in AIBase. The FLOLS and ParkPos offsets are peculiar to AICarriers, and so it is right that they should live there. Umm, I think you missed something here. I did not move those offsets anywhere. I just added a generic convenience function that reads a generic offset value. I have only moved the parsing code, the value is still stored wherever it was up to now. Exactly my point: AIBase only reads generic values. Offsets are not generic values, and their reading should remain where they are at present. If another AI Object comes up with a requirement, then that is a different matter.
Re: [Flightgear-devel] [RFC] tacan rewrite
On Fri 13 April 2007 10:31, Vivian Meazza wrote: SNIP Yes - this is Mathias' business, I really can't comment, except to say that I would be surprised if there were anything much wrong with his code, and certainly not his mathematics. Have I missed anything? Yup - if it ain't broke don't fix it. Now back to something which is totally broken - AIBallistic and Submodels. That is a complete mess here with _apparently_ hundreds of ballistic objects not being removed when their life expires which causes FG to slow to a crawl. I just love fixing things which used to work. And it looks as if I won't get around to it until next week at the earliest, and it might not be until the week after. Vivian Hello Vivian, Csaba I am a TACAN user, with Tankers and Carriers, (mainly developing French Navy Aircraft models) i have read with interest that long conversation. I can say, the existing TACAN system, which has been implemented and improved by Vivian suit to me, it is very simple to use and cover every requests. Many thanks to Vivian who has spend so many hours on it . I feel only one useful development which could come, it is out of TACAN development but involve AI/MP system, i mean the carriers which could be part of an external AI system (not user dependent) in order to give to every navy pilots, on line, the same carriers position, and so, to give the pleasure to land/take off all together to/from the same place. Regards -- Gérard - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] tacan rewrite
gh.robin wrote: ... Snip ... Hello Vivian, Csaba I am a TACAN user, with Tankers and Carriers, (mainly developing French Navy Aircraft models) i have read with interest that long conversation. I can say, the existing TACAN system, which has been implemented and improved by Vivian suit to me, it is very simple to use and cover every requests. Many thanks to Vivian who has spend so many hours on it . I feel only one useful development which could come, it is out of TACAN development but involve AI/MP system, i mean the carriers which could be part of an external AI system (not user dependent) in order to give to every navy pilots, on line, the same carriers position, and so, to give the pleasure to land/take off all together to/from the same place. Thank you for the kind remarks. A carrier passed over MO=P ahs long been on the wish list. Several people have been working on it (I'm not one of them), but there are no results so far. We live in hope :-) Vivian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] tacan rewrite
On 4/13/07, Vivian Meazza [EMAIL PROTECTED] wrote: Exactly my point: AIBase only reads generic values. Offsets are not generic values, and their reading should remain where they are at present. If another AI Object comes up with a requirement, then that is a different matter. They are generic in the sense that it may be an offset of anything. Yes, currently only the carrier uses it and it is not even in a function there - it is duplicated! See below. It is right that TACAN assignments should be global - that's the way it is in RL - they are not made up locally. Of course it's not really hard to change the settings if you get the urge. I was thinking that the command line arguments are essentially the ground crew. So if I start FG with a fictional future parameter --tacan=041X then this would have to be passed over MP to everyone and see me on that channel. No global xml and no hardcode. 4) the FLOLS/ParkPos issue -- that is just a code cleanup without any change in functionality whatsoever. Maybe I should have split that into a separate patch. Yes - this is Mathias' business, I really can't comment, except to say that I would be surprised if there were anything much wrong with his code, and certainly not his mathematics. Didn't say anything about mathematics. Here is what is wrong: // Transform to the right coordinate frame, configuration is done in // the usual x-back, y-right, z-up coordinates, computations // in the simulation usual body x-forward, y-right, z-down coordinates flols_off(0) = - flols-getDoubleValue(x-offset-m, 0); flols_off(1) = flols-getDoubleValue(y-offset-m, 0); flols_off(2) = - flols-getDoubleValue(z-offset-m, 0); ... and later ... // Transform to the right coordinate frame, configuration is done in // the usual x-back, y-right, z-up coordinates, computations // in the simulation usual body x-forward, y-right, z-down coordinates double offset_x = -(*it)-getDoubleValue(x-offset-m, 0); double offset_y = (*it)-getDoubleValue(y-offset-m, 0); double offset_z = -(*it)-getDoubleValue(z-offset-m, 0); See? Code duplication, even including the comment. This cries for a helper function. And since every AI object potentially reads from a scenario (there is a FGAIBase::readFromScenario after all), they could benefit from a function like this at some later time. Have I missed anything? Yup - if it ain't broke don't fix it. I was trying to improve it, not fix. Looks like we have fundamentally different views on this, but that's okay :) Greets, Csaba - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [RFC] tacan rewrite
Hello! I have looked into tacan code when investigating a bug found by Nick. From the one-liner fix it grew to this massive patch. Here is what I did: Moved tacan parameters from carrier_nav.dat to the appropriate model node in the property tree (eg. /ai/models/carrier/navaids/tacan). Implementation added to AIBase (could even make a different class, say AIBaseWithTacan). Ideally, the values should come from 3 places: i) the scenario, ii) the model and iii) the network. Until iii) works I automatically set up a tacan channel for mp aircraft with callsign MOBIL (the isTanker flag was set based on this anyway.) While normally a configuration file is preferable to hardcoding things, in this case I think it is a bad choice to pollute the globals with information needed by a hack. And nobody ever tweaked these settings. Added support for tacan position offset from the model position. For now I just put in a temporary solution that should work OK for carriers (the only place where this is used currently). I don't know how to properly add a body-relative vector to the lat,lon,alt coordinates. I have changed the channel-ID to lower case in the scenario xml and the property tree. A quick search didn't show anything that used it, so hopefully nothing is broken. Just a matter of personal preference, feel free to ignore. Also, code cleanups here and there. At least I think they are cleanups :) The TACAN::update function could use some optimization so that it does not update unchanged nodes. There is an indicated-ground-speed-kt property which seems to hold the closing speed. Should it be the ground speed of the selected target, or do we need a rename? In the second case, we should also add a little integration or something to make the values more stable. (Given that ETA is also calculated from this, I think it is a misnomer.) With these changes theoretically it should be possible to operate the tacan from the source aircraft in MP for example. Grab the patch from: http://w3.enternet.hu/jester/fgfs/tacan-20070412.diff Now you can start telling me why this doesn't make any sense :) Greets, Csaba PS: Note to people with cvs write access: please do *not* commit this (yet). - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] tacan rewrite
Csaba Halász Hello! I have looked into tacan code when investigating a bug found by Nick. From the one-liner fix it grew to this massive patch. Here is what I did: Moved tacan parameters from carrier_nav.dat to the appropriate model node in the property tree (eg. /ai/models/carrier/navaids/tacan). Implementation added to AIBase (could even make a different class, say AIBaseWithTacan). Ideally, the values should come from 3 places: i) the scenario, ii) the model and iii) the network. Until iii) works I automatically set up a tacan channel for mp aircraft with callsign MOBIL (the isTanker flag was set based on this anyway.) While normally a configuration file is preferable to hardcoding things, in this case I think it is a bad choice to pollute the globals with information needed by a hack. And nobody ever tweaked these settings. Added support for tacan position offset from the model position. For now I just put in a temporary solution that should work OK for carriers (the only place where this is used currently). I don't know how to properly add a body-relative vector to the lat,lon,alt coordinates. I have changed the channel-ID to lower case in the scenario xml and the property tree. A quick search didn't show anything that used it, so hopefully nothing is broken. Just a matter of personal preference, feel free to ignore. Also, code cleanups here and there. At least I think they are cleanups :) The TACAN::update function could use some optimization so that it does not update unchanged nodes. There is an indicated-ground-speed-kt property which seems to hold the closing speed. Should it be the ground speed of the selected target, or do we need a rename? In the second case, we should also add a little integration or something to make the values more stable. (Given that ETA is also calculated from this, I think it is a misnomer.) With these changes theoretically it should be possible to operate the tacan from the source aircraft in MP for example. Grab the patch from: http://w3.enternet.hu/jester/fgfs/tacan-20070412.diff Now you can start telling me why this doesn't make any sense :) Doesn't make any sense to me - what bug are you trying to fix? TACAN works as is for AI and MP aircraft, and at the moment allows up to 3 of each, but it is trivial to increase that to any number you like, without recourse to hard coding. Why do you want to offset a TACAN position? Why on earth are you hard coding TACAN idents? Why limit the MP to only one tanker ident? What is wrong with the existing FLOLS and Parking Position Code? If you don't know how to properly add a body-relative vector to the lat,lon,alt coordinates don't muck with Mathias' code - he does know. I'm not persuaded by this - try to convince me that something is wrong with the existing code and its method, and while you are trying to do that, I will not accept hard coding TACAN channels for mobile transmitters, any more than I would for fixed sites. Vivian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] tacan rewrite
On 4/12/07, Vivian Meazza [EMAIL PROTECTED] wrote: Doesn't make any sense to me - what bug are you trying to fix? None, it is already fixed. This is just a follow-up. Why do you want to offset a TACAN position? You know why: because on the carriers the tacan altitude is 100 feet. And that *is* fixed, no matter where the carrier happens to be. It should be fixed relative to the carrier. So as to hide this detail I have introduced the TACAN position which gets calculated from the model position and an offset vector. Why on earth are you hard coding TACAN idents? Why limit the MP to only one tanker ident? It is actually a limit of 9, MOBIL1-9. I could have used a *local* configuration file (or property) there, but this is just a temporary solution - I expect tacan information to come through MP protocol. Then this code will just disappear without affecting anything else. And please note that the isTanker flag *is* set from this hardcoded MOBIL callsign as well. I don't think my solution is that much worse. At least it is well localized. And these changes make it possible to provide tacan parameters from MP. Like changing channels, disabling transmitter and such. All at runtime. That is a desirable goal is it not? My solution might not be the best way to do it, though. What is wrong with the existing FLOLS and Parking Position Code? Nothing, that was just a code cleanup. Refactored duplicated code that reads a x-offset-m, y-offset-m and z-offset-m triplet into a corrected SGVec3d. It now lives in FGAIBase::readOffsetFromScenario() because I happened to need that too. Surely that is not a bad thing? If you don't know how to properly add a body-relative vector to the lat,lon,alt coordinates don't muck with Mathias' code - he does know. I pointed out what I don't know so that somebody who does can help me out (and it does not slip in unnoticed). In the meantime that code works for the 2 cases currently in use. (My guess is that I would need to convert to cartesian, rotate by the yaw,pitch,roll add the offset and convert back.) Do you think I should have done nothing because I am not sure about that little detail? Personally I also disliked the old TACAN::search from a coding point of view. Lots of code duplication, variable names like str1,str2, ... str6 etc. I won't mind if this does not get into cvs. I am having much fun with FG - both flying and coding. So I thought why not try something other than bug fixes (even though this started out as that as well). Hope Mathias doesn't mind that I mucked with his code. Looks like JSB is next :) Greets, Csaba - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] tacan rewrite
Csaba Halász On 4/12/07, Vivian Meazza [EMAIL PROTECTED] wrote: Doesn't make any sense to me - what bug are you trying to fix? None, it is already fixed. This is just a follow-up. Why do you want to offset a TACAN position? You know why: because on the carriers the tacan altitude is 100 feet. And that *is* fixed, no matter where the carrier happens to be. It should be fixed relative to the carrier. So as to hide this detail I have introduced the TACAN position which gets calculated from the model position and an offset vector. Well - if a carrier ever moves from sea level we can take the elevation add the carrier altitude. Is anything more needed? Why on earth are you hard coding TACAN idents? Why limit the MP to only one tanker ident? It is actually a limit of 9, MOBIL1-9. I could have used a *local* configuration file (or property) there, but this is just a temporary solution - I expect tacan information to come through MP protocol. Then this code will just disappear without affecting anything else. And please note that the isTanker flag *is* set from this hardcoded MOBIL callsign as well. I don't think my solution is that much worse. At least it is well localized. Yes - I know - wrote it. And I think that you might have misinterpreted the code here. The flag isTanker is set if any MP object has a callsign starting with MOBIL - it can be followed by anything. But just because it has the callsign MOBIL* doesn't imply that it fitted with TACAN - that is determined by the callsign/TACAN ID assignment in carrier_nav.dat. Any callsign can be associated with any TACAN ID - MOBIL is just a bit of a pun. Not all tankers have TACAN transmitters - the Sea Vixen in the Buddy-Buddy role is one such example. The inverse is, I think, true: I know of no airborne TACAN transmitter which isn't a tanker, but I'm a bit out of date here, and this might have changed. Of course, the association of the callsign MOBIL* with a tanker is a hack - the property isTanker ought to be passed over MP. But when this was written no properties were passed, and adding them to the MP servers is not trivial. And these changes make it possible to provide tacan parameters from MP. Like changing channels, disabling transmitter and such. All at runtime. That is a desirable goal is it not? My solution might not be the best way to do it, though. Switching on/off is indeed desirable, but not changing channels at runtime. Channels are assigned by headquarters for a mission and not changed in flight. In my day, this was only done by the ground crew, but it might well be possible in flight nowadays. Passing the appropriate property value over MP should suffice, if we had a controllable TACAN transmitter in the aircraft, which right now we don't. What is wrong with the existing FLOLS and Parking Position Code? Nothing, that was just a code cleanup. Refactored duplicated code that reads a x-offset-m, y-offset-m and z-offset-m triplet into a corrected SGVec3d. It now lives in FGAIBase::readOffsetFromScenario() because I happened to need that too. Surely that is not a bad thing? It is indeed a bad thing - only properties that are common to more than one AI Object live in AIBase. The FLOLS and ParkPos offsets are peculiar to AICarriers, and so it is right that they should live there. If you don't know how to properly add a body-relative vector to the lat,lon,alt coordinates don't muck with Mathias' code - he does know. I pointed out what I don't know so that somebody who does can help me out (and it does not slip in unnoticed). In the meantime that code works for the 2 cases currently in use. (My guess is that I would need to convert to cartesian, rotate by the yaw,pitch,roll add the offset and convert back.) Do you think I should have done nothing because I am not sure about that little detail? Well, I think it's better if patches don't have built in problems - the trouble is no one is likely to pick up on little details for you. Personally I also disliked the old TACAN::search from a coding point of view. Lots of code duplication, variable names like str1,str2, ... str6 etc. Fair comment. It grew out of the old dme code, and I would have probably done it differently with a clean sheet of paper approach I won't mind if this does not get into cvs. I am having much fun with FG - both flying and coding. So I thought why not try something other than bug fixes (even though this started out as that as well). Well, you haven't convinced me that this is a valid change, in fact I think it flawed in several important respects. Sorry, especially if you have spent any great time on this. But thank you very much indeed for finding and correcting the original bug. Hmm - no one noticed for 6 months! Oh well ... particularly as it had been fixed once. Hope Mathias doesn't mind that I mucked with his code. Looks like JSB is next :) I sure he
Re: [Flightgear-devel] [RFC] tacan rewrite
On 4/13/07, Vivian Meazza [EMAIL PROTECTED] wrote: Csaba Halász On 4/12/07, Vivian Meazza [EMAIL PROTECTED] wrote: Why do you want to offset a TACAN position? You know why: because on the carriers the tacan altitude is 100 feet. And that *is* fixed, no matter where the carrier happens to be. It should be fixed relative to the carrier. So as to hide this detail I have introduced the TACAN position which gets calculated from the model position and an offset vector. Well - if a carrier ever moves from sea level we can take the elevation add the carrier altitude. Is anything more needed? Umm, actually that is what I have done. Just in a more generic way, such as possibly accounting for lateral displacement and non-level orientation of the carrier. Admittedly does not amount to much in case of the tacan, but seems to be more logical this way. Looks like just for me. Why on earth are you hard coding TACAN idents? Why limit the MP to only one tanker ident? It is actually a limit of 9, MOBIL1-9. I could have used a *local* configuration file (or property) there, but this is just a temporary solution - I expect tacan information to come through MP protocol. Then this code will just disappear without affecting anything else. And please note that the isTanker flag *is* set from this hardcoded MOBIL callsign as well. I don't think my solution is that much worse. At least it is well localized. Yes - I know - wrote it. And I think that you might have misinterpreted the code here. The flag isTanker is set if any MP object has a callsign starting with MOBIL - it can be followed by anything. But just because it has the callsign MOBIL* doesn't imply that it fitted with TACAN - that is determined by the callsign/TACAN ID assignment in carrier_nav.dat. Any callsign can be associated with any TACAN ID - MOBIL is just a bit of a pun. Not all tankers have TACAN transmitters - the Sea Vixen in the Buddy-Buddy role is one such example. The inverse is, I think, true: I know of no airborne TACAN transmitter which isn't a tanker, but I'm a bit out of date here, and this might have changed. Of course, the association of the callsign MOBIL* with a tanker is a hack - the property isTanker ought to be passed over MP. But when this was written no properties were passed, and adding them to the MP servers is not trivial. And these changes make it possible to provide tacan parameters from MP. Like changing channels, disabling transmitter and such. All at runtime. That is a desirable goal is it not? My solution might not be the best way to do it, though. Switching on/off is indeed desirable, but not changing channels at runtime. Channels are assigned by headquarters for a mission and not changed in flight. In my day, this was only done by the ground crew, but it might well be possible in flight nowadays. Passing the appropriate property value over MP should suffice, if we had a controllable TACAN transmitter in the aircraft, which right now we don't. Right. Next step would be to send tacan channel over MP as well and then this temporary workaround would vanish. In the meantime I thought it wouldn't matter as I assumed pretty much everybody uses the default config anyway. But changing my version to support this is easy as all the pieces are in place. Carriers come from scenarios now - no need for their tacan to be in the carrier-nav.dat, might as well add them to the scenario (which essentially models the headquarters) If in the future they come from MP, the carrier-nav.dat is again not needed. Also note that runtime includes whenever a new pilot joins, similar to passing the call sign. Everybody else should see the tacan of *my* aircraft as *my* ground crew (the command line) set it - not as it is mapped in *their* carrier-nav.dat. What is wrong with the existing FLOLS and Parking Position Code? Nothing, that was just a code cleanup. Refactored duplicated code that reads a x-offset-m, y-offset-m and z-offset-m triplet into a corrected SGVec3d. It now lives in FGAIBase::readOffsetFromScenario() because I happened to need that too. Surely that is not a bad thing? It is indeed a bad thing - only properties that are common to more than one AI Object live in AIBase. The FLOLS and ParkPos offsets are peculiar to AICarriers, and so it is right that they should live there. Umm, I think you missed something here. I did not move those offsets anywhere. I just added a generic convenience function that reads a generic offset value. I have only moved the parsing code, the value is still stored wherever it was up to now. Your point would be valid about the whole tacan equipment not belonging in AIBase, but I allowed for that in my original mail by saying maybe there should be a separate FGAIBaseWithTacan. Well, I think it's better if patches don't have built in problems - the trouble is no one is likely to pick up on little details for you.
