Yoko

flush log нужна только для того, что бы буфер скинулся на диск.
как правело краш происходит после 100-ой ошибки
а суть самой ошибки происходит в 1-ой из за большого объема инфы буфер успевает скинутся. flush log просто как рекомендация... во всяком из всех логов что уменя были все привели к ошибке в STL

Грин, твои возвышенные речи трудно понять )

их и не надо понимать, эти речи обращены к человеку который владеет исходным кодом. Только ему удатся исправить ошибку STL библиотеки.

чертовски интеерсно было б узнать что это такое

так в перед, это не секретная информация, дефакто это стандартная бибилиотека.

в перед не поулчается .не знаю с чего начать когда не знаешь вообще ничего

ну могу только придать вектор ускорения;))

дык действуйте

посколько это вид физического взаимодействия, то нужно что бы ты был на растоянии 50см от меня;) тогда без проблем;)

А потеме уже полностью готово lastcontainer и lastcorpse без потери lasttarget через set

Вообще гоовря ускорение может возникать не только вследствие физ воздействия ,но так же благодаря гравитации, электромагнитному взаимодействию, ну и есть там еще какие то силы, связывающие частицы в атомах

не ну если ты хочешь центростремительное ускорение это одно а если прямо линейное это другое;)
на а магнитные атомные... это уже попахивает извращением;)

то есть вы хотите сказать, что физ. воздействием невозможно создать центростремительное ускорение, а гравитация и электоромагнетизм не способны придать прямолинейного ускорения?

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

давайте не будем отвлекать ув. Грина от столь важной темы которую он нам решил осветить
хотел спросить следующее - одновременная работа uo.findtype в нескольких функциях увеличивает шанс краша или ошибки?

Ошибка возникает как минимум при работе insert в хешьмасивы.
не долго думая можно придумать ситуацию когда происходит доступ на чтение и на запись когда может возникнуть ошибка. Хешь масивы реализованы по понятию СПИСОК со всеми вытекающими последствиями. На сайте разработчиков STL есть целая статья о тредсефти.
Собственно раз трабла возникает при инсерте (изменяется параметры СПИСКА) то ошибка может возникнуть при любом раскладе при одновременном чтении и записи в это список, зависет от обстаятельств.

хм..а если safe insert делать с проверкой идет ли доступ к списку ?;)

то как минимум 70% ошибок пропадет...

я так понимаю осталось выцепить исходники и ковырять код до бетонного основания из описания переменных

интересно а чем ему так много поточность не нра

купил ты себе машину, а утебя сын есть...
Ты встаешь утром на работу, радуешься своей покупке, выходишь... а машины нет... сын взял ключи и поехал кататся... не синхронизировались...

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

Особо исходники ковырять и не надо даже... просто переписать функцию и добавить в класс объект синхронизации... на производительности скажется не значительно.

ну да.. ты подтвердил мои догадки ...

хотя с другой стороны как показывает опыт синхронизацию безопасную делать тоже не особо простая задача.... потому как баги как ни крути останутся и где нить выползут

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

итог : НУЖЕН КОД !