[-] HaF - 767 Production Slot Allocation

[DanDan]

Hello Sami,

the 767 production slot allocation is weird again: i have a big hole in the deliveries... production of the 762ER starts in 85, i get planes only in 88 - please check.

[gazzz0x2z]

it just went after your 767-300s, which sounds logical.

What seems not logical to me is that the 300 orders were allocated before the 200s, yet the start date is later. If the order was OK, htere would not be that problem.

[DanDan]

its not logical, since there is over a year between 200s and 300s, where the 200ERs are already on the market. and there is even now still empty slots.
and also the 200ER and 300 i purchased with the same one order!

i am a major customer for boeing, the game should reflect that.

[Sami]

Not a bug. Your first -300 delivery is 20-Feb-1987 and the model gets certified in Feb-1987.

[Mort]

i am a major customer for boeing, the game should reflect that.

Surely that belongs in a feature request, not a bug fix? 

[DanDan]

its not about the 300: its about the 200ER. I ordered them in one order, with the ordering menu showing me the sequence of delivery: first incoming 200ER and then alternating 200ER and 300s. Now all the 200ERs are coming only after the 300. Thats not what i was shown by the purchasing menu. There is no logical reason why I dont get any 200ER between January 86 and Feburary 87. In my opinion, this is a bug.

[Zombie Slayer]

I agree completely. This is not a case of Inordered planes and then early production slots opened up, this is a model that goes into production a full year plus before current orders. The 1986-87 slots prior to 763 EIS should be available for 762ER orders.

[Sami]

Misread it as -300.

Can't comment what is the scenario here without taking a closer look.

[DanDan]

now with the assignment of the new variants of the fleet type, it got even worse. the production numbers i was promised before are reduced, i even have a gap of almost 3 months in deliveries. sami, please fix the slot issue, people need to either be able to rely on the manufacturers promises or get compensated. thank you

[Sami]

When a new subtype is introduced it will ALWAYS affect also the other slots and changes are possible. Final delivery date is locked 6 months prior delivery and prior to that the dates may change - so this change in that last picture is not a bug.

[schro]

When a new subtype is introduced it will ALWAYS affect also the other slots and changes are possible. Final delivery date is locked 6 months prior delivery and prior to that the dates may change - so this change in that last picture is not a bug.

So you're saying it's realistic and fair for a manufacturer to be delivering 2 planes per month to an airline that has placed a large order and has tentatively agreed to deliver them at a constant rate but when it launches a new and more popular type that the manufacturer decides to pause deliveries to the existing customer to squeeze out the new variant to customers that ordered later?

[Sami]

Checked the data from backup with the following status:
 - last B767-200 delivery on 21-Feb-1986
 - first B767-300 delivery on 08-Mar-1987
 - unallocated preorders for B767-200ER

Later, when B767-200ER orders are allocated they will be assigned after ANY existing orders you have on that production line. = Orders which have a date (have been allocated). In this case the B767 line is available for you after 08-Mar-1987 for any preorders to be allocated.

This is by design and making it smarter for such a rare case (a smallish gap in the middle) is not feasible. => Not a bug.

[DanDan]

Checked the data from backup with the following status:
 - last B767-200 delivery on 21-Feb-1986
 - first B767-300 delivery on 08-Mar-1987
 - unallocated preorders for B767-200ER

Later, when B767-200ER orders are allocated they will be assigned after ANY existing orders you have on that production line. = Orders which have a date (have been allocated). In this case the B767 line is available for you after 08-Mar-1987 for any preorders to be allocated.

This is by design and making it smarter for such a rare case (a smallish gap in the middle) is not feasible. => Not a bug.

ok, thanks for clarifying the logic on slot allocation!