В.: "что делать если грузятся два экземпляра одного прибора и дерутся между собой, вызывая ошибки в работе панели? И что делать если логика прибора не стартует, пока прибор не будет показан на экране"
О.: Отвязать логику (работы прибора/системы) от представления (от того, что в симе называется gauge). Как это сделать? Сначала экскурс в основы.
Многие начинающие прибористы воспроизводят шаблон, предложенный разработчиками сима в SDK. т.е.

Итак, что же надо сделать? конкретно - прекратить использовать шаблон, предложенный SDK, и использовать ту внутреннюю машинерию, которую скрывает этот шаблон. Выполнив это, вы способны внедрить в функции, вызываемые симом при загрузке приборного модуля (не отдельного прибора, события откладываемого до непосредственного отображения прибора, а всего модуля!) и при выгрузке, необходимый вам код инициализации и запуска логики, независимой от представления.

Кстати помнится я с подобным сталкивался, уж не помню на каком проекте - так вот, MAKE_NEEDLE имеет какие-то проблемы, а вот спрайт работал плавненько.

У меня два вопроса.

1. В любой гау баблиотеке должен быть хотя бы один прибор с именем, которое, в свою очередь, нужно прописать в Panel.cfg, для того, чтобы сим мог подцепить библиотеку. Сам же прибор требует наличия макроса GAUGE_HEADER_FS700, который в свою очередь, требует обязательного списка элементов. Вот и приходится в прибор логики добавлять такой список, хотя бы с одним элементом, к примеру, MAKE_STATIC, содержащий в качестве параметров нули. В принципе, ничего особо страшного в этом нет, но может есть способ обойтись без таких заглушек?

2. Необходимо написать программный модуль обработки ввода пользователя. Ввод пользователя осуществляется через клавиатуру, джойстик, мышь. С джойстиком понятно - пишем с использованием DirectInput, отключаем в симе джойстик и получаем нечто похожее на ПТ. Мышь. Мышиные события и так обрабатываются в пользовательском коде. Остается клавиатура. И тут мне известны два возможных варианта: DirectInput и SetWindowsHookEx. Собственно клавиатурный хук пока вполне справляется с задачей, то есть клавиатурное событие прехватывается перед симулятором, и в коде определяется что с ним делать: а) обработать самостоятельно и "погасить"; б) обработать самостоятельно и передать симу; в) просто передать симу без обработки.

Собственно вопрос: нужно ли смотреть в сторону DirectInput (с которым я никогда не работал применительно к клавиатуре)?

Можно. Способ для FS9 называется "модуль". Собственно гау есть частный случай обычного модуля, несколько более специфицированный. Для FSX нужно работать через SimConnect.

Как сделать модуль FS9? да точно так же как и gau. С одним отличием - в Linkage первый параметр ("магическое число 0x00000013) заменяется либо на 0, либо на любое не занятое симовскими модулями (ага, они имеют такую же структуру, те же ImportTable и Linkage символы) число. Впрочем, отличное от нуля число необходимо только тогда, когда предполагается загрузка вашего модуля другими компонентами сима (ну например - вашими приборами) посредством штатных механизмов ФС. Ну и дальше в Linkage, где у вас идут списки приборов, будет стоять простой сакраментальный 0, обозначающий пустой список функций. Такой модуль надобно будет положить в папочку modules, сим при запуске его загрузит. Что с этим делать дальше и как взаимодействовать с симом? нууу, это большой и сложный вопрос, который уходит в сторону "грязных" хаков и использования штатных, но немножко недокументированных функций

В том то и проблема, что не создается никаких папок и файлов вообще, а компилер ошибок не выдает.
Без /I пишет "fatal error U1077".
А с указанным параметром "link..." и т.д. - т. е. вроде все Ок.
??? Не понятно.

можно make файл в студию.
и ещё один вопрос - а почему собсно из консоли компиляем? чем живая студия плоха?

и ещё, если работаешь из консоли, vcvars32 запускал?

vcvars32 запускал - все по-прежнему..