Elite Games - Свобода среди звезд!
.
ВНИМАНИЕ!
Наша конференция посвящена космической тематике и компьютерным играм.
Политические вопросы и происходящие в мире события в данный момент на нашем сайте не обсуждаются!

  » Сила торможения парашютом | страница 1
Конференция предназначена для общения пилотов. Для удобства она разделена на каналы, каждый из которых посвящен определенной игре. Пожалуйста, открывайте темы только в соответствующих каналах и после того, как убедитесь, что данный вопрос не обсуждался ранее.

Поиск | Правила конференции | Фотоальбом | Регистрация | Список пилотов | Профиль | Войти и проверить личные сообщения | Вход

   Страница 1 из 1
 
Поиск в этой теме:
Канал Orbiter: «Сила торможения парашютом»
Kulch
 105 EGP


Рейтинг канала: 2(21)
Репутация: 29
Сообщения: 604
Откуда: Россия, Санкт-Петербург
Зарегистрирован: 24.08.2004
Чему равна сила торможения парашютом? Погуглил - не нашел, по яндексил - обратно не нашел...

По логике, должна зависеть от динамического давления и площади купола.

т.е., что-то типа

F=D*S*K

где D - динамическое давление
(D=r*V^2/2, где r - плотность, V - скорость);
S - площадь купола;
K - некий коэффициент пропорциональности.

А на самом деле как?
_________________
Юрий Кульчицкий aka Kulch
    Добавлено: 16:52 28-11-2005   
Bloodest
 155 EGP


Рейтинг канала: 3(40)
Репутация: 18
Сообщения: 944
Откуда: Питерские мы
Зарегистрирован: 07.10.2004
Собственно я так и делаю (для СА)
///в определении ступени
Shild1=0.01;
CreateVariableDragElement ( &Shild1,1.0, _V(0,0.0,0.75));
//////////
.....
///в таймстепе по командам упр механизма - SubStatus
switch(SubStatus)
{
case 0:// гипер и сверхзвук
Shild1= oapiGetWaveDrag (M1,0.8,0.98,1.314,0.28)+0.01;
break;
case 1:// выпущен парашут
Shild1= 1.0;
break;
case 2:// парашут отстрелен на земле -шоб аппарат не улетел
Shild1= 0.0;
}
Ориентация (только моменты) аэрофоллом
Вобщем дешево и сердито (но посадка выглядит на ура), вообще коэффициент Shild1 я подбираю опытным путем (аппаратик маленький - 16 кг, 30 см в диаметре - единиц вполне хватило)
Для Союза это 8 и 80 - зарифленный и полностью открытый...
    Добавлено: 18:51 28-11-2005   
Kulch
 105 EGP


Рейтинг канала: 2(21)
Репутация: 29
Сообщения: 604
Откуда: Россия, Санкт-Петербург
Зарегистрирован: 24.08.2004
CreateVariableDragElement у меня не покатит. У меня довольно сложная анимация выпуска парашюта и его дальнейшего поведения. Крепление парашюта несимметричное, то есть груз под ним болтается и раскачивается. Поэтому вместо драг-элементов я использую банальный AddForce - вдоль текущего положения троса (вдоль текущего направления обдувающего потока). Выглядит очень красиво.

То есть неплохо бы знать формулу поточнее. Торможение идет в три каскада - гиперзвук, сверхзвук и дозвук. По техническим ограничениям Орбитера сделать анимацию зарифления/разрифления купола невозможно (вернее, возможно, но с существенным геморроем), так что начал делать сверхзвуковое торможение просто в два каскада.

Может, потом для сверхзвукового каскада (который второй) еще и сделаю зарифление/разрифление. А может, и для первого каскада (гиперзвук) добавлю зарифление/разрифление.

А вообще америкосам проще - у них на ускорителе шаттла просто три купола, каждый имеет трех-ступенчатое рифление.
_________________
Юрий Кульчицкий aka Kulch
    Добавлено: 13:21 29-11-2005   
Kulch
 105 EGP


Рейтинг канала: 2(21)
Репутация: 29
Сообщения: 604
Откуда: Россия, Санкт-Петербург
Зарегистрирован: 24.08.2004
Сейчас вот подумал - ничто не мешает использовать и CreateVariableDragElement. Развести анимацию и приложение сил.

Только я вот не понимаю. Первым параметром туда подается управляющий фактор, вторым - коэффициент.

У вас - наоборот. Конечно, они там все равно перемножаются...

Главный вопрос - почему то, что подается как "drag magnitude scale factor" это именно то, что возвращает oapiGetWaveDrag? Это оно и есть? Или тут просто, как враги говорят, bit of hack?

И почему не используется oapiGetInducedDrag? Этот компонент должен здорово влиять при дозвуковом полете? А oapiGetWaveDrag - это же вроде только для транс и сверхзвука, нет?
_________________
Юрий Кульчицкий aka Kulch
    Добавлено: 13:56 29-11-2005   
Kulch
 105 EGP


Рейтинг канала: 2(21)
Репутация: 29
Сообщения: 604
Откуда: Россия, Санкт-Петербург
Зарегистрирован: 24.08.2004
Все разобрался. И с управлением через Shild1 разобрался и с аэродинамикой (с коэффициентами).

В принципе, все описано в API_Guide.pdf, я мог бы и раньше догадаться, где искать.

Получается, нужно сделать сначала (в моем случае), при открытии парашюта:

CreateVariableDragElement(&param, maximum_drag_force_factor, DRAGCHUTE_POINT);

а потом param менять от 0 до 1 в зависимости от рифления, площади купола и добавляемых каскадов...

Но, по-моему, от вычисления силы вручную и применения ее по AddForce это принципиально не отличается, ведь maximum_drag_force_factor все равно нужно вычислять вручную (подбором соответствующих коэффициентов к площади купола). Правда, нужно вводить лишний колбэк (clbkPreStep).
_________________
Юрий Кульчицкий aka Kulch
    Добавлено: 19:41 29-11-2005   
Kulch
 105 EGP


Рейтинг канала: 2(21)
Репутация: 29
Сообщения: 604
Откуда: Россия, Санкт-Петербург
Зарегистрирован: 24.08.2004
М-дэээ...
Попробовал сделать анимацию рифления парашюта - ни хрена не вышло. Разрифление - это несимметричная трансформация типа scale, а трансформация типа scale может быть child'ом только в случае, если является симметричной...

А парашют у меня анимированный - вращается вокруг точки крепления по двум осям.

А подобрать вектор для неравномерного scale, если группы, к которым она прменена уже повернуты (парашют), даже зная как повернуты - невозможно.

По крайней мере добавленем одной трансформации задача не решается.

Повернуть парашют в исходную, применить scale, потом опять развернуть по потоку - чисто внешне некрасиво, это ж видно все.

Либо отказываться от красивой анимации крепления парашюта, либо отказываться от рифления. Расстроен
_________________
Юрий Кульчицкий aka Kulch
    Добавлено: 12:18 30-11-2005   
Bloodest
 155 EGP


Рейтинг канала: 3(40)
Репутация: 18
Сообщения: 944
Откуда: Питерские мы
Зарегистрирован: 07.10.2004
1. На счет oapiGetWaveDrag - там каэффициентик приплюсован 0,01 - так что ниже 0.8М - сопротивление все равно будет...
2.На счет перецепок - дык их не бесконечное число - добавить можно несколько драгов и переключаться между ними.
3.Анимация рифления, дык в NASSP ,была анимация готовыми мешами - собственно переход происходил скачками. Я слабо представляю как трансформациями можно подобрать плавность. Но обеспечить одновременное скалирование можно - нужно отделить вращение.
Ведь вращать часть (кужующуюся)корабля иногда, если не всегда) значительно проще используя аттачмент. Вращаемую часть делаем отдельным кораблем (создаем конфиг, в котором прописываем координаты и углы аттачмента, начальный меш, как вариант). В данном случае это замок крепления строп на парашуте, сам парашут отдельный КК. При выпуске парашута из блока создаем корабль парашута. Тутже прицепляемся к его программному интерфейсу из кода блока и все - с ним можно делать что угодно. Создаем в парашуте аттачмент (если не сделали это ранее в конфиге). Создаем аттачмент на блоке и стыкуем их. Теперь весь смак точку аттачмента и направляющие углы можно менять как угодно (главное обеспечить взаимную перпендикулярность направляющих - вращать вектора одновременно на одинаковый угол). Это обеспечить достаточно просто. Допустим вектор V1 (0,0,1) должен смотреть в купол V2(0,1,0) - второй перпендикулярность которого надо сохранить. Допустим получен вектор набегающего потока Vv(X,Y,Z) - обеспечить работу поворотов парашута по потоку проще простого - Нормализуем Vv=>Vvn - это новый вектор V1. Строим перпендикуляр для V2 - сначла определяем угол поворота - arccos(dotp(V1,Vvn)). Тестируем угол на 0 и 180 градусов. Если так то вектор V2 можно не менять (0,1,0). иначе вектор V2=normalize(crossp(V1,Vvn))
Функции dotp - скалярное произведение и crossp - векторное произведение есть в SDK.
Далее сохранив указатель интерфейса во внутренней переменной корабля при необходимости можно пользоватся всеми функциями VESSEL интерфейса в т.ч. и менять меши и скалировать (без помех с вращением) их.

Гыг, о птичках, более того если обозначить класс корабля как экспортабельный.
Например

class DLLEXPORT n1bisM_RN
:public VESSEL2
{
.....
конструктор
кэллбаки
прочая лабудень
....
//нужная в другом КК часть
double SetProgramm(int,int,double,VECTOR3,VECTOR3,VECTOR3);
void GetProgramm(int ,char * );
// самодельная функция
double Air;
// самодельная переменная
}

В совсем другом корабле можно декларировать всего лишь только заголовок и нужные функции
class DLLEXPORT n1bisM_RN
:public VESSEL2
{
int SetProgramm(int slot,int tip, double MJD,
VECTOR3 VAR1,VECTOR3 VAR2,VECTOR3 VAR3);
// самодельная функция - управление программным механизмом
void GetProgramm(int slot,char * buffer);
// самодельная функция - считывание состояния программного мех.
double Air;
// самодельная переменная - запасы воздуха
}

Тогда просто преобразовав указатель программного интерфейса на соответствующий указатель задекларированного нужного обрезка класса можно пользоваться чужими функциями - качать воздух - Air или заставить его выполнить сложное запрограммированное на определенное время действие (или целую последовательность) через функцию, контролировать состояние стека программного механизма через другую...

Более того можно сформировать виртуальный класс по типу VESSEL2 со всем вытекающими... (но это если надо рулить двумя и более KK последовательно)...
    Добавлено: 18:52 30-11-2005   
Kulch
 105 EGP


Рейтинг канала: 2(21)
Репутация: 29
Сообщения: 604
Откуда: Россия, Санкт-Петербург
Зарегистрирован: 24.08.2004
Bloodest :
1. На счет oapiGetWaveDrag - там каэффициентик приплюсован 0,01 - так что ниже 0.8М - сопротивление все равно будет... 2.На счет перецепок - дык их не бесконечное число - добавить можно несколько драгов и переключаться между ними.


Да, да, я уже понял, спасибо!

Bloodest :
Но обеспечить одновременное скалирование можно - нужно отделить вращение.


Можно, конечно. Только невозможно нормально сделать неравномерное скалирование. В Орбитере скалирование возможно только вдоль осей координат корабля и никак иначе. Сделать скалирование в двух направлениях, не делая в третьем можно только тогда, когда скалируемый объект (парашют) уложен вдоль одной из осей.

Можно скалинг сделать чайлдом анимации вращения, но там возможен только равномерный скалинг (то есть смысла в такой ступенчатой анимации нет - все равно скалинг только вдоль осей координат корабля).

Bloodest :
...сам парашут отдельный КК...


Вот именно этого я хочу избежать, потому и затеял такую сложную анимацию.

Bloodest :
Гыг, о птичках, более того если обозначить класс корабля как экспортабельный. ...


Ага. Я так и делаю. У меня таким образом сделана связь системы управления (она в центральном блоке "Энергии") с боковушками, переходником (блок "Я") и башней обслуживания. Очень удобный способ.

Просто очень хочется не делать вместо одного корабля - два (корабль и парашют). Боковушек - четыре. У каждой есть три каскада парашютов. Каждый каскад - отдельный корабль (ради красоты отделения - отцепил от аттачмента, он улетел). Итого - 16 кораблей. Понятно, что они появятся только на этапе списка боковушек к Земле, но все равно многовато. Удалять их потом самому? Опасная операция, думаю, знаете, к чему может привести удаление корабля из симуляции.

И еще. С аттачментами есть одна существенная проблема. Функция Detach работает далеко не так, как хочется. Она просто дает отделяемому кораблю его статус, который у него был при приаттачивании - с поправкой на новую позицию. Если корабль был на Земле перед аттачментом (статус у него был "landed"), то он так и остается висеть в воздухе с нулевой скоростью на той позиции, где произошел detach. Его статус не обновляется. Это первое.

Второе. Если на приаттаченном корабле включить движок, то он даст кораблю импульс, причем такой, какой он бы получил, если бы не был приаттачен. После отделения такой корабль мгновенно получает свой статус вместе с этим импульсом (внешне это выглядит так, как будто он улетел нахрен, как из пушки).

Резюме. Приходится все делать вручную. При отделении назначать отделяемому кораблю правильный статус, что - гемор неслабый, особенно если требуется вычисление векторов поворота (apos). Если корабль был создан и тут же приаттачен, он имеет статус такой же, как статус хозяина. Если речь о том, что у меня - стоящая на старте "Энергия", с боковушками, то все боковушки, соотв. получают статус "landed". Внимание, хинт! После отделения они по-прежнему будут иметь статус "landed"! Чтобы этого не произошло, я вручную меняю им статус (весь, вместе со скоростью, иначе улетят, ведь на них работали двигатели!). Но просто назначить статус "полет" нельзя, надо, чтобы на корабле работал хоть один двигатель!

Вот так... Поэтому, отделяя, к примеру, полезный груз, я вынужден найти на нем хотя бы один двигатель, дать на него минимальную тягу (я использую 1e-6), переждать один тайм-стэп (за него он получает правильный статус в свободном полете), потом убрать у него тягу и снова назначить ему его же статус (чтобы зря движком не работал).

Какие выводы? Правильно! Моя любимая "Энергия" способна цеплять на себя и правильно выводить ТОЛЬКО такие грузы, на которых есть хоть один движок! В противном случае, надо в сценарии для ПГ ЗАРАНЕЕ назначить его ЛЕТЯЩИМ. В целом - неслабый такой геморрой получается.

Такая вот задница. Я все это Мартину писал, он кое-что исправил, но не все. Да что говорить, до недавнего времени (до патча 050216) нельзя было сделать цепочку аттачментов длиннее 4! То есть пять последовательтных ступеней - уже не получится! К счастью, теперь уже это исправлено и лично проверял "паровозик" из 11 ступеней - работает...
_________________
Юрий Кульчицкий aka Kulch
    Добавлено: 14:45 01-12-2005   
Bloodest
 155 EGP


Рейтинг канала: 3(40)
Репутация: 18
Сообщения: 944
Откуда: Питерские мы
Зарегистрирован: 07.10.2004
Kulch :

И еще. С аттачментами есть одна существенная проблема. Функция Detach работает далеко не так, как хочется. Она просто дает отделяемому кораблю его статус, который у него был при приаттачивании - с поправкой на новую позицию. Если корабль был на Земле перед аттачментом (статус у него был "landed"), то он так и остается висеть в воздухе с нулевой скоростью на той позиции, где произошел detach. Его статус не обновляется.



У меня внутри clbkPreStep "умного" аттачмента прицепленного к "тупому" родителю.

/////////////////////////перецепка аттачмента по команде КОНТАКТ
if(Kontakt > 10)
{
ATTACHMENTHANDLE att;
if(Status ==0) att = ParentInterface->GetAttachmentHandle (false, 1);
else att = ParentInterface->GetAttachmentHandle (false, 0);
ParentInterface->DetachChild (att);
Kontakt = 3;
};
if(Kontakt>0)
{
VESSELSTATUS status,status2;
ParentInterface->GetStatus (status);
GetStatus (status2);
status2.rbody = status.rbody;
status2.status = status.status
if(status.status==1)status2.vdata[0]=status.vdata[0];
DefSetState (&status2);
Kontakt --;
}
if(Kontakt<0 && Kontakt>-5)
{
ATTACHMENTHANDLE att;
if(Status ==0) att = ParentInterface->GetAttachmentHandle (false, 1);
else att = ParentInterface->GetAttachmentHandle (false, 0);
ParentInterface->AttachChild (GetHandle(),att,attachment);
Kontakt = -10;
}

То есть аттачмент самоотделяется в 3 тайм степа и в этот момент происходит обнавление статуса по параметрам референсного тела статуса, летит/не летит и азимута если сидит. Дело в том что пока приаттачен невозможно обновить эти праметры периписыванием статуса, если отделить - то можно.
На первом отделяется, на втором периписывается статус состояния, третий запасной.
При присоединении аттачмент кушает стейты родителя как надо и все фокусы невилируются...

Kulch :

Просто очень хочется не делать вместо одного корабля - два (корабль и парашют). Боковушек - четыре. У каждой есть три каскада парашютов. Каждый каскад - отдельный корабль (ради красоты отделения - отцепил от аттачмента, он улетел). Итого - 16 кораблей. Понятно, что они появятся только на этапе списка боковушек к Земле, но все равно многовато. Удалять их потом самому? Опасная операция, думаю, знаете, к чему может привести удаление корабля из симуляции.


Гыг Гы-гы не знаю. А что? Cобственно из моей Н1 панели, обтекатли и др. сыплются как горох из дырявого мешка - красиво - при отделении головного обтекателя как комета. Правда пришлось поуменьшить пыл - ИМФД не поддерживает больше 32 кораблей. Так что живут они не долго - до следующей просыпки - отделения след ступени - сформирован стек в него записываются все кандидаты и перед след всплеском они все удаляются.
    Добавлено: 21:58 01-12-2005   
Kulch
 105 EGP


Рейтинг канала: 2(21)
Репутация: 29
Сообщения: 604
Откуда: Россия, Санкт-Петербург
Зарегистрирован: 24.08.2004
Bloodest :
ИМФД не поддерживает больше 32 кораблей.


Я бы забил с девизом - Хочешь нормально жить - не используй ИМФД. Или он для Н-1 важен?

Bloodest :
Дело в том что пока приаттачен невозможно обновить эти праметры периписыванием статуса, если отделить - то можно.


Это-то понятно. Меня другое поражает. Ракета летит. ЛЕТИТ! А то, что после Detach от нее отвалилось, почему-то имеет статус НЕ ЛЕТИТ (status.status = 1). Приходится вот так извращаться:


void EnergyC::SetStateToBlockA(OBJHANDLE block_A, int booster_index, VESSELSTATUS2 my){
if(block_A == NULL) return;
VESSEL *blockAV = oapiGetVesselInterface(block_A);

VESSELSTATUS2 bst;
bst.version = 2;
bst.flag = VS_THRUSTLIST | VS_FUELLIST;
bst.thruster = NULL;
bst.fuel = NULL;
blockAV->GetStatusEx(&bst);

Local2Rel(blockA_points[booster_index] + A_COM_POS, bst.rpos);

bst.rvel = my.rvel;
bst.arot = rots[booster_index];
bst.vrot = _V(0, 0, 0);

//вот этой строки недостаточно:
bst.status = 0;

//приходится вот так:
if(bst.thruster != NULL && bst.nthruster > 0)
bst.thruster[0].level = 1e-6;

if(bst.fuel != NULL && bst.nfuel > 0)
bst.fuel[0].level += 0.01;

blockAV->DefSetStateEx(&bst);
}
_________________
Юрий Кульчицкий aka Kulch
    Добавлено: 09:44 02-12-2005   
Bloodest
 155 EGP


Рейтинг канала: 3(40)
Репутация: 18
Сообщения: 944
Откуда: Питерские мы
Зарегистрирован: 07.10.2004
Kulch :

Я бы забил с девизом - Хочешь нормально жить - не используй ИМФД. Или он для Н-1 важен?


Про забивание не понял вовсе... Здесь скорее наоборот - ИМФД использует реально используемые в жизни алгоритмы расчетов. Весь смак именно в этом. Остальные МФД далеко позади. Но чем дольше работаешь с инструментом тем лудще он лежит в руке и тем ярче его недостатки. Мои замечания по нему носят характер предостережения от явных недостатков, чем отрицания его вцелом. 32 корабля и только 2 МФД - да явный недостаток. Но реализацию решения проблемы Ламберта (перехват небесных тел)выдвигаю как основное достоинство, также как и реализацию численных методов в функции карта. Но при детальном рассмотрении даже в этих функций обнаруживаются ограничения и недостатки.

Ведь в мануле, например, ни где не сказано какой именно метод решения проблемы Ламберта. По небольшой фразе

"If the target planet is on
the opposite side to the source planet, the inclination of
the transfer orbit may become very high." (стр 10)

и практическим результатам использования можно сказать, что это метод Гедеона (опубликован в первом номере JIAA за 65 год). Метод достаточно простой и эффективный по затратам в расчетах. Но обладает рядом недостатков. Одним из них является отсутствие разделения результатов при появлении их диапазона - просто замирает в ближайшем, кратным шагу итеративного решения, от начального приближения значении. Естественно это возлагается на "программера" использующего данный метод - при появлении диапазона сохранять уже имеющееся наклонение. А это для метода Гедеона весьма непростая задача.
Ну недостаток и ладно НО! именно эта фраза и может ввести пользователя в заблуждение, зная метод надо написать
"If the target point of interseption is near (+-5 deg)
the opposite side to the current source (planet or spaceship) , the inclination of the transfer orbit may become very high."
То бишь ошибка возникнет не только при расчете отлета но и при возможной коррекции траектории при пролете этого положения.
Именно эта потребность в коррекция фразы является явным недостатком. А вовсе не потребнось в исправлениях кода.

И вот почему.

Методы более эффективного разделения были получены позднее другими исследователями, и они базируются на разложении части уравнения Ламберта (в той или иной манере агрегации геометрических функций) в ряды Штумпфа (естественно ряды бесконечные Гы-гы ) что повышает потребные расчетные затраты примерно на 2 порядка... Естественно это не орбитеровского реалтайма. Это раз.
А два просто убийствинен для задачи Ламберта вцелом. В самой ее постановке кроется корень ее смерти - сферы влияния планет считаются грависферами нулевой протяженности - то есть отсутствуют вовсе. Естественно помехи от реальных протяженностей этих полей сводят на нет любые усовершентвования методов решения проблемы Ламберта...
То есть полученное решение можно рассматривать только как первое приближение, которое должно быть всегда подвергнуто оцененке.

Для ПНагрузок Н-1 я использую реальные запасы топлива, которые соответственно требуют реальных методов решения задач, в данном случае перехвата небесного тела. Именно по этому ИМФД и не заменим. Реальные запасы характеристической скорости, скажем для 4МН (Марс-75, доставка марсианского грунта) всего 90 м/с и надо быть виртуазом в использовании ИМФД чтобы долететь до Марса и сесть в нужной точке. Естественно мануал будет содержать подробнейшее описание всех подводных камней. Более того часть задач ИМФД переписана для упрощения жизни виртуального пилота, потому как без этого у меня получается 50/50.


Kulch :

Это-то понятно. Меня другое поражает. Ракета летит. ЛЕТИТ! А то, что после Detach от нее отвалилось, почему-то имеет статус НЕ ЛЕТИТ (status.status = 1).


За идею подачи малой тяги - большое спасибо это проще и эффективнее по реализации обновления статуса временным отделением.
Для бездвигательных ПН ни чего не машает на нее добавить двигатель и топливо а после импульса удалить. Или просто аддфорсом?

А меня с некоторых пор не поражает. Некоторое изучение кода Орбитера показало что очень часто используются буфера обмена. То есть скажем статус который считываем/периписываем пользовательской функцией лежит в одном буфере а при отделении орбитер считывает статус совсем из другого. Синхронизатор буферов естественно имеет свою логику и синхронизирует не все и не всегда.
Например есть такая функция
oapiGetVesselInterface
Аргумент OBJHANDLE == void *
А на что он указывает - конечно на буфер, доступный именно для пользователя. И несмотря на то что вышеуказанная функция содержит целю цепочку! подфункций, последняя невелирует все результаты и две! последних команды цепочки выполняют нужную функцию!
Cишный эквивалент
(VESSEL *)(((long *)((long)Argument+0x220))[0])

Исследования проводил для получения доступа к программному интерфейсу планет, чтобы ватянуть орбитеровские эфемериды.
Естественно там нули - синхронизация не проведена, а вот обратно чужую подсунуть можно! Гы-гы
    Добавлено: 14:53 02-12-2005   
Kulch
 105 EGP


Рейтинг канала: 2(21)
Репутация: 29
Сообщения: 604
Откуда: Россия, Санкт-Петербург
Зарегистрирован: 24.08.2004
Ну про IMFD погорячился... Рыдания.

А про аттачмент могу сказать следующее. Сегодня связался с Мартином на форуме, он утверждает, что исправил упомянутый баг. Исправил чуть ли не в первой бете, вышедшей после патча 050216. Только не упомянул в файле patch.txt. А я не проверил, потому что для проверки мне нужно неслабо так старый код переписать и я давно на это забил - работает и ладно. Так что он просил перепроверить на текущей бете, чем я сейчас и занят. К ночи все будет понятно. Хорошо, если исправил Подмигиваю
_________________
Юрий Кульчицкий aka Kulch
    Добавлено: 18:26 02-12-2005   
Kulch
 105 EGP


Рейтинг канала: 2(21)
Репутация: 29
Сообщения: 604
Откуда: Россия, Санкт-Петербург
Зарегистрирован: 24.08.2004
Аднака, да! Таки исправил все как надо, оба бага. Более того, теперь парент транслирует статус ребенку непрерывно, что есть круто. Теперь я могу убрать в том числе и функцию, которая на каждом степе обновляла ребенку статус (чтобы можно было сидя в гладере, прицепленном к "Энергии" видеть, как происходит выведение на орбиту).

Ускорители теперь отцепляю простым Detach - все отваливается как надо, никаких фокусов типа "выстрела из пушки" более не наблюдается.
_________________
Юрий Кульчицкий aka Kulch
    Добавлено: 21:32 02-12-2005   
Bloodest
 155 EGP


Рейтинг канала: 3(40)
Репутация: 18
Сообщения: 944
Откуда: Питерские мы
Зарегистрирован: 07.10.2004
А бета-тестирование закрытое? Если нет - адресок не дашь?
    Добавлено: 09:03 05-12-2005   
Kulch
 105 EGP


Рейтинг канала: 2(21)
Репутация: 29
Сообщения: 604
Откуда: Россия, Санкт-Петербург
Зарегистрирован: 24.08.2004
Закрытое. Есть beta-team, там около 20 человек. Ну и есть правила поведения - особенности следующей версии не раскрывать, скрин-шоты вне команды не публиковать, сырые беты на сторону не раздавать и т.п.

Проситься нужно прямо к Мартину.
_________________
Юрий Кульчицкий aka Kulch
    Добавлено: 15:54 05-12-2005   
Канал Orbiter: «Сила торможения парашютом»
 
  
Показать: 
Предыдущая тема | Следующая тема |
К списку каналов | Наверх страницы
Цитата не в тему: Помню, что было интересно, но вот что было интересно - не помню. (Star'ik)

  » Сила торможения парашютом | страница 1
Каналы: Новости | Elite | Elite: Dangerous | Freelancer | Star Citizen | X-Tension/X-BTF | X2: The Threat | X3: Reunion | X3: Terran Conflict | X Rebirth | X4: Foundations | EVE Online | Orbiter | Kerbal Space Program | Evochron | VoidExpanse | Космические Миры | Онлайновые игры | Другие игры | Цифровая дистрибуция | play.elite-games.ru | ЗВ 2: Гражданская война | Творчество | Железо | Игра Мечты | Сайт
   Дизайн Elite Games V5 beta.18