В такой форме можно будет бороться и с «блуждающими» отложенными приказами. Далеко не всегда есть смысл делать #LASTORDER, да и заблудшие приказы могут прийти как раз в момент между получением отчёта и отправкой последнего приказа с #LASTORDER, как это разруливать?

А для веб-формы просто добавить дополнительное поле.

деда, а не проще ли тогда вернуться к классической гэлакси (к примеру формат Лаки)? где каждый последующий ордер отменяет ордер предыдущий? ведь это именно то, о чем вы говорите. но тогда пропадет прелесть того, что можно изменить апгрейд, который "неправильно" был сделан, можно будет обратно вернуть "исправленное не так производство" и т.д. вот только, имхо, это помощь тем, кто не может и не хочет думать ДО того, как отправит приказ. да и клиенты тогда придется переделывать, т.к. и Гком и ГВНГ отправляют повторно изменения приказа, а не весь приказ заново. нет, ну можно конечно стирать строчку с сообщением об отправке, но если уж возвращаться к классической гэлакси, то и клиенты надо будет доделывать.

Это совсем другой вопрос. Вернуться к модели обработки приказов как в классике можно, и это и будет сделано (как опция партии). Заплатить придётся невозможностью использовать переданную группу на этом же ходу, негарантированностью колонизации (если несколько колонайзеров на пустой планете разгружаются, то до самого ходопроизводства будет неясно, чья же станет планета) и ещё несколькими мелочами. При этом можно даже аккумулировать приказы для текущего хода а отменять специальной командой, так что и клиенты менять не придётся. В плюсе мы получим полную скрытость действий от противника — не только смена производства, но и апгрейд, загрузка/выгрузка и разделение групп станут скрытыми.

Но проблемы заблудившихся приказов это не решит. Мы посылаем один приказ, следом второй, отменяющий первый, но к серверу второй может дойти раньше первого. Значит нужно пометить, что это приказ «первый», а это «второй» и игнорировать «первый» если он придёт после «второго».

деда, прости меня, но это, имхо, бред. абсолютно никому ненужное усложнение игры. "интересности" абсолютно не добавляющее. но это всего лишь мое мнение

CKOPnuOH, эта фича нужна не для «интересности». И никому игру не усложняет.

gegMOPO3 said:
Есть идея. Можно завести "номер приказа".
1) Приказ с номером имеет приоритет перед приказом без номера.
2) Приказ с большим номером имеет приоритет перед приказом с меньшим номером (за тот же ход).
3) При получении приказа сервер игнорирует его, если был получен приказ с большим приоритетом.
4) Также игнорируются не исполняясь отложенные приказы с меньшим приоритетом, чем максимальный за этот ход.
Эта фича опциональна в том смысле, что можно ею не пользоваться и играть даже не подозревая о её существовании. Полезна она будет только в таких экстремальных ситуациях, когда всё равно приказы отправляются руками, так что и поддержка клиентов не очень нужна.
Есть какие-то уточнениея-возражения?

Если сделаете, будет замечательно. Я как раз из-за последней остановки GL подергался изрядно, посылая приказы в большом количестве... к счастью, обошлось.

Есть какие-то уточнениея-возражения?

А вот что у вас неправильно, так это

2) Приказ с большим номером имеет приоритет перед приказом с меньшим номером (за тот же ход).

Должно быть наоборот!

Потому что интерес ведь как раз в том, чтобы РАНЕЕ ОТПРАВЛЕННЫЙ приказ имел приоритет, а позднее отправленный - не испортил такие вещи, как разделение групп и т.п.

Sorcerer-swineherd said:
Есть такая команда

O PASS

Через веб

У меня была ситуация: с работы почта уходила в десятикратных количествах

Не поможет. Утомительно ведь вставлять эту фразу в каждый приказ. А значит, будет так - отправил приказ - не получил трансляцию - понял, что что-то неладно - отправил снова.

Вот должно быть средство как раз в этом, втором приказе сделать какую-то пометку, что он является "ненастоящим" в том случае, если раньше какой-то приказ уже пришел.

Именно поэтому

gegMOPO3 said:
Есть идея. Можно завести "номер приказа".
...
2) Приказ с большим номером имеет приоритет перед приказом с меньшим номером (за тот же ход).
3) При получении приказа сервер игнорирует его, если был получен приказ с большим приоритетом.
...

должно быть наоборот. Ранее посланный приказ должен иметь приоритет, а наивысший приоритет - у приказа без номера!