Yoko

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

Вопрос в основном к экспертам.

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

К сожалению, "абы кто" меня не устраивает. Я бы предпочёл чтобы я уже знал такую персону, если она найдётся, и чтобы она обладала как минимум следующими тремя достоинствами:
1) достаточным знанием C++ (учиться языку, экспериментируя на игроках я считаю политнекорректным)
2) достаточным количеством свободного времени (дать исходники, чтобы с ними только ознакомились или внесли одно изменение и забили, мне не хочется)
3) разделяла некоторые мои взгляды на багеров и на жизнь (а именно не вносила явно багерские коррективы и не раздавала последнюю версию иходников)

Будучи найдутся такие кандидатуры, просьба стучать на аську 139629504 или почту zombie@i.com.ua с готовностью к достаточно серьёзному тесту на профпригодность к программированию на С++.

Обана
Неожиданно

а мож не надо?

может ещё рановато говорить "Я устал. Я ухожу" (с) ЕБН, но комуто спихнуть часть ответственность за разработку тоже надо.

один человек сейчас проходит тест на профпригодность, некий VeNdOr, итальянец, немного работавший с IRW.

Я в претенденты на этот пост и близко идти не собираюсь, но мне кажеться что теста на знание языка С++ не хватит. Намного лучше сделать тест на понимание кода Инжекта.
Я так считаю, потому-что для примера я, можно сказать достаточно знаю С++, но делая свой инклудер, я 95% времени потратил не на кодинг, а на изучения пути передачи информации в инжекте и вообще как он сделан.
А идеальный тест был-бы просто задачка добавить какую-то фичу к инжекту (например новую функцию). Заодно и инжект добровольцы улучшили бы =).

Есть еще предложение - сделать опен сорс.

Он и так опен сорс.

Beyonder wrote:Я в претенденты на этот пост и близко идти не собираюсь, но мне кажеться что теста на знание языка С++ не хватит. Намного лучше сделать тест на понимание кода Инжекта.
Я так считаю, потому-что для примера я, можно сказать достаточно знаю С++, но делая свой инклудер, я 95% времени потратил не на кодинг, а на изучения пути передачи информации в инжекте и вообще как он сделан.
А идеальный тест был-бы просто задачка добавить какую-то фичу к инжекту (например новую функцию). Заодно и инжект добровольцы улучшили бы =).

так как это вещь достаточно очевидная, то с постом ты немного уже опоздал. Vendor прошёл тест на профпригодность, закончив недоделаную процедуру ongump. Не то что там было очень много работы, но там именно на "понимание материала"

В общем любите и жалуйте, если хотите, нового (возможно) разработчика YokoInjection - зарегистрировавшегося на этом форуме как Vendor_Er_Pirata.

Он тут особо не живёт по причине перенасыщенности форума русским, которого он не понимает.

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

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

Может он также одним махом и с Step warning failure разберется?

* Step buffer failure

А не собирается ли новый девелопер заняться поиском и устранением причин, приводящим к 'Unhandled exception in parser' и других сбоев и падений инжекта?

Вообще-то Unhandled Exception это не проблема парсера, а проблема скриптов. Конечно иногда бывает заслуга и парсера в этом, но очень редко.

Нифига. Очень часто (читай, постоянно) при долгой работе большого скрипта появляется Unhandled exception. После этого любая (!) инжектовская функция, даже print "Hello world" приводит к этому же эксцепшну. А если быть настойчивым и продолжать вызывать разные функции, то клиент "выполняет недопустимую операцию и будет закрыт". И иногда бывает, что при частом вызове некоторых функций появляется сообщение "warning: error in command". Если это сообщение появилось при выполнении какой-нибудь функции инжекта, то оно будет появляться всегда на этой функции, пока не перезапустишь клиент.

J17 wrote:Очень часто (читай, постоянно) при долгой работе большого скрипта появляется Unhandled exception.

угум...

Beyonder wrote:Вообще-то Unhandled Exception это не проблема парсера, а проблема скриптов. Конечно иногда бывает заслуга и парсера в этом, но очень редко.

В том то и фишка. 100% правильные и стабильные скрипты начинают внезапно (или при переносе на другой комп) выдавать такую х**ню. ((

Два компа. Один дома, другой на работе. На работе коннект похуже (помедленней). Компы примерно равные по мощности. Софт одинаков. На работе добывающие скрипты работают сутками, сбои и анхандлед еррор ин парсер - раз в месяц, дома - максимальный срок жизни чара на этом же скрипте - полчаса-час. А быстрее всего "вожделенное" сообщение я получу минут так через 5-10.

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

На сегодняшний день существует у меня достаточно стойкое убеждение - есть какая-то "кривизна" в работе с прицелами. И "кривизна" эта не в разовом применении прицелов, а в большом кол-ве при достаточно быстром коннекте. Если же коннект к шарду лагает - эти проблемы рассасываются. Как и почему - хз.

Edred wrote:Два компа. Один дома, другой на работе. На работе коннект похуже (помедленней). Компы примерно равные по мощности. Софт одинаков. На работе добывающие скрипты работают сутками, сбои и анхандлед еррор ин парсер - раз в месяц, дома - максимальный срок жизни чара на этом же скрипте - полчаса-час. А быстрее всего "вожделенное" сообщение я получу минут так через 5-10.

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

На сегодняшний день существует у меня достаточно стойкое убеждение - есть какая-то "кривизна" в работе с прицелами. И "кривизна" эта не в разовом применении прицелов, а в большом кол-ве при достаточно быстром коннекте. Если же коннект к шарду лагает - эти проблемы рассасываются. Как и почему - хз.

А я думаю, что на работе комп хорошо настроен, а дома тяп-ляп, лишь бы уо конетило

Destruction wrote:А я думаю, что на работе комп хорошо настроен, а дома тяп-ляп, лишь бы уо конетило

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

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