Open flyteaceo opened 1 year ago
Those fields are not designed to hold decimals, they are technically integers. Also SimBrief API wants them as integers, specially the passenger and baggage weights should be integers, also they must be in pounds as units (lbs).
From SimBrief API Docs;
All weights except the paxwgt value must be in thousands of pounds, but can be specified with up to 3 decimal places (in order to set precise values).
So in my opinion this is not a bug, probably you are mis-interpreting SimBrief API docs and confused about structural weights vs passenger / baggage weight definitions.
Technically even if you try to enter 185.01 here or 185.99, they will be treated as 185 as you described as a bug (but it is not) :)
Thank you, I stand corrected.
Regarding the input fields, if as you say, they are not designed to hold decimals, wouldn't it be better to lock the field's input to integers then?
What will be the benefit of that change? Those fields follow documents and backend works fine (according to documentation)...
My personal opinion; No, it will make no difference. Either with or without that limitation same goal is achieved and it is not possible to fully avoid human errors/mistakes :(
I think this would avoid confusion. I spent some time trying to figure out why I was having weights discrepancies in all my flights until I got here. If the fields "are not designed to hold decimals", maybe they shouldn't be allowed by design... Anyway, not a big issue, I'll find a workaround on my end to compensate, not a problem. Thank you very much for your explanation and opinion, Fatih.
From SimBrief API Docs;
All weights except the paxwgt value must be in thousands of pounds, but can be specified with up to 3 decimal places (in order to set precise values).
This sounds like decimals are valid, if you enter decimals, does it just get multiplied out? So 123.45 becomes 12345lbs? And 123 to 12300?
If I understood FatihKoz correctly, my interpretation is that decimals are valid in all weights, except paxwgt.
Got it, changing the input to int makes sense
pax weight and (per pax) baggage weight needs to be integers rest can be floats (for precise conversions).
And we do not have problems regarding weights and sending proper data to SimBrief ;) As per API requirements, we are sending pax and bagg weights as integers and the rest (when needed) as thousands of pounds.
I think this would avoid confusion. I spent some time trying to figure out why I was having weights discrepancies in all my flights until I got here. If the fields "are not designed to hold decimals", maybe they shouldn't be allowed by design... Anyway, not a big issue, I'll find a workaround on my end to compensate, not a problem. Thank you very much for your explanation and opinion, Fatih.
Honestly, I think your confusion is not generated by phpvms or those fields. You either did not read the docs or guides, or mis-interpreted it :( Both can lead you to "the software is doing something wrong" point and then here or discord :) Anyway, the outcome is ok for everyone and the result is nice, this is what matters.
Safe flights :)
This should be closed.
Describe the bug Defining the weights of pax and baggage in settings admin page of phpvms is not possible using decimals (I believe 66.01 or 66.99 is being calculated the same way as 66). This compromises final flight calculations with simbrief, because simbrief recognizes decimals.
Version 7.0.0-dev+230420.930ceb
To Reproduce Steps to reproduce the behavior:
Expected behavior Calculated weights should take into consideraton decimals.