SmokiMo

https://yadi.sk/i/ez49-RYR3DrTx9

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

Я пользуюсь Uinstall Tool скачай любую крякнутую версию, и выбери "Принудительное удаление" в списке программ, под чистую снесет все.

В описании к сборке есть фикс лист

На форуме 365 версия вместе с diff есть=)

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

http://forummaxi.ru/tutorials/article/287-мануал-компиляция-исходников-lineage-2-antом/

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

Тут посоны бесплатно рипы делают =)

Тут, например http://forummaxi.ru/files/category/15-исходники-серверов/

Для выгрузки накопившихся данных и сброса возможных утечек =)

Мультиселл ТП? Вы в курсе, что мультиселл является перечнем продаваемых/покупаемых товаров?

Где вы видели хук у танка и раши у других профессий на хрониках С+? О каком запиле С3-Т0 идет речь, если это был просто перезапуск с нуля =)

Напиши в скайп

А почему модераторы должны закрывать тему?

Я вам могу подсказать почитать правила форума

Предлагаю Вам свои услуги, а именно создание скриптов/сервисов/систем на заказ, с уникальными концепциями и качественной поддержкой и обновлениями. Так же внесение изменений в исходный код, поиск и исправление проблем. Что Вам предлагается: 1. Качественные скрипты/сервисы/системы под ваши сервера. 2. Внесение изменений и доработка уже существующих скриптов. 3. Перенос скриптов с одной сборки на другую. 4. Поиск и исправление проблем в скриптах и исходном коде сборки. 5. Поддержка на все услуги. Цена на заказ формируется исходя из сложности проекта и сроков на его выполнение, пишите в телеграмм. Пользовательское соглашение: 1. При заказе какого-либо скрипта, заказчик обязан предоставить четкое ТЗ. В случае проблемных моментов по ТЗ, заказчик корректирует его после обсуждения конкретных моментов. 2. После анализа финального ТЗ, ему присваивается категория: возможно ли это реализовать, невозможно, либо же возможно в теории. Если я не уверен, что это возможно реализовать (третий вариант), то я не беру с Вас предоплату, но и не называю никаких сроков и не гарантирую выполнение заказа. 3. Для работы Вам необходимо предоставить мне ядро Вашей сборки и папку libs или же исходный код. В случае необходимости Вы предоставляете мне сборку для тестов/работы. Искать сборки самостоятельно я не обязан. 4. После принятия ТЗ, Вы вносите предоплату в размере 50% от суммы заказа. Предоплата вносится за время на выполнение работы и является залогом за мою работу. В случае отказа от заказа, предоплата не возвращается. Остальные 50% от суммы оплачиваются после выполнения работы. 5. Сумма и сроки заказа оговариваются сразу. Названные сроки могут сдвигаться до 5 рабочих дней. В случае сдвига сроков сдачи более чем на 5 дней по моей вине, за каждый простроченный день от суммы заказа отнимается по 500 рублей в день. В случае, если заказчик игнорирует принятия заказа, данное правило не работает. 6. После демонстрации полноценной работы заказа, вы обязаны подтвердить принятие заказа словами "Я принимаю вашу работу" (необходимо для фиксации одобрения работы и исключения возникновения дальнейших разбирательств). В противном случае я могу отказать в выдаче заказа. 7. В случае если Вы пропали и не принимаете работу, Ваша работа остается у меня на протяжении 30 календарных дней. После этого срока, заказ выставляется в магазин. Предоплата не возвращается. 8. После принятия заказа на него распространяется гарантия сроком 14 дней, с момента получения. 9. В случае возникновения проблем или пожеланий с работоспособностью заказа, Вы обязаны обратится только по моим контактам. В случае постороннего вмешательства гарантия пропадает. 10. Я гарантирую решение возникших по моей вине проблем с работоспособностью заказа в течении 48 часов с момента получения информации от Вас. 11. Я не несу ответственность за возможный ущерб, который может быть нанесен моими скриптами. 12. Я не даю никаких гарантий по поводу того, принесет ли мой скрипт Вам прибыль, будет ли он популярен и успешен. 13. Запрещена передача моих работ третьим лицам. В случае обнаружения данного факта, я в праве отказать Вам в любых услугах. 14. Запрещено любое вмешательство в код скриптов. 15. Запрещена продажа скриптов. Если даже вы его отредактировали, и предположим, доработали, то смотрите пункт 13 и 14. Небольшой список с примерами работ: Скачать видео Скачать видео Скачать видео Скачать видео Скачать видео Скачать видео Видеоописание сборки и скриптов, может кому нужно. Описан далеко не весь функционал, часть функционала не попала на видео, постараемся записать и другие функции. Для удобства под описанием видео есть таймкоды.

Сегодня от ключевых людей из команды Java появились сразу две новости: Марк Рейнхольд сообщил об открытии репозиториев JDK 10, в которые коммиттеры уже могут размещать багфиксы и мелкие улучшения. Можете прочитать официальное письмо Марка об этом, а можете — хабрапост Тагира Валеева. В общем, стоило окончательно устаканиться фичам «девятки», как можно уже начинать переживать о том, что попадёт в десятку. Брайан Гетц выставил на голосование новое предложение: создать Project Amber для внесения туда JEP с «маленькими, ориентированными на продуктивность языковыми фичами» (вроде недавних Enhanced Enums и Lambda Leftovers). То есть предложение не в том, чтобы затеять какое-то гигантское нововведение, а в том, чтобы сгруппировать и так появляющиеся маленькие — дав им отдельный общий репозиторий, списки рассылки и так далее. https://twitter.com/RichardWarburto/status/824305443975626752?ref_src=twsrc%5Etfw Непонятно только, почему назвать проект решили «янтарь». Это звучит как что-то, навсегда застывшее и активно не развивающееся!

Пока Java-сообщество продолжает вечные споры «Scala-Groovy-Kotlin», у этих языков появляются новые конкуренты (пусть им пока и далеко до того, чтобы конкурировать всерьёз). За последнюю неделю сразу три молодых проекта привлекли к себе внимание: Eta — диалект Haskell на JVM. Зачем нам при живых Scala и Clojure ещё один функциональный язык? По заявлению его создателя, Eta ощутимо отличается от них обоих. Подчёркивают чистоту («вызов функции с одними и теми же аргументами всегда будет приводить к одинаковому результату»), неизменяемость по умолчанию и «мощную систему типов». Сейчас язык в версии 0.0.5 — ну, все с чего-то начинали. Если приживётся, небось в рунете будет много шуток о названии: когда на официальном сайте видишь заголовки «What is Eta» и «Why Eta», сразу хочется перевести их как «што эта» и «зачем эта». Lux — тоже функциональный язык. В его случае JVM рассматривают только как одну из платформ, но за неё взялись в первую очередь. На GitHub-странице проекта создатели заявляют, что вдохновлялись подходом к функциональному программированию в Haskell, синтаксисом и «look and feel» Clojure, а также системой модулей в ML. Номер текущей версии Lux выглядит на порядок мажорнее, чем у Eta: 0.5.0 https://twitter.com/ChrisGSeaton/status/820237536501100545?ref_src=twsrc%5Etfw Тем временем у проекта JRuby+Truffle, начавшегося как форк JRuby, по итогам 2016-го большой прогресс: в частности, он теперь соответствует спецификации Ruby лучше всех остальных альтернативных имплементаций (включая тот же JRuby). Из-за этого проект почувствовал себя достаточно взрослым и самостоятельным, чтобы «съехать от родителя», переименовавшись в TruffleRuby. Судя по твиттер-боту Github Trending, эта новость привлекла внимание и к самому TruffleRuby, и к «родителю». При этом TruffleRuby — только один из примеров целой языковой экосистемы, возникающей благодаря связке Graal+Truffle от Oracle Labs. Похоже, в наступившем году мы все услышим об этой связке ещё не раз, и если раньше можно было не обращать на неё внимания, теперь настало время разбираться, «што эта». И вот сейчас удобный момент: на Хабрахабре как раз перевели текст об этом.

Молодой учёный Росс Тейт опубликовал текст о проблеме в системе типов Java (а также Scala), делающей эту систему «unsound». Как поясняет тот же текст, слово «unsound» (буквально — «ненадёжный», «необоснованный») в данном контексте говорит, что система типов предоставляет разработчикам не все те гарантии поведения программ, которые должна была предоставить по задумке создателей. Система типов Java призвана, например, гарантировать, что метод, требующий Integer, не примет String. Тейт и Нада Амин (исследователь, участница команды Scala) обнаружили хитрый случай, в котором гарантия не соблюдается — так что компилятор, вполне соответствующий спецификации, скомпилирует код, присваивающий переменной значение другого типа (впрочем, это не означает возможности исполнять его на JVM, и вряд ли вы столкнётесь с таким кодом в рабочем проекте). Впервые Амин и Тейт сообщили о своей находке в ноябре на конференции OOPSLA (update: как заметил наш читатель, в Фейсбуке сообщали и того раньше), представив там соответствующую научную публикацию. Но после конференции на это обратили внимание только в академических кругах, а вот теперь заговорили в индустрии, что и побудило Тейта написать его новый текст, предназначенный для разработчиков. Внимание многих привлёк недавний твит Джошуа Блоха с примером «ломающего систему» кода: https://twitter.com/joshbloch/status/822948565433466881/photo/1?ref_src=twsrc%5Etfw Как написал Блох в следующем твите, «Другими словами, Нада Амин и Росс Тейт обнаружили такую дыру в 12-летней системе типов в Java-дженериках, что сквозь неё можно на грузовике проехать». Не все согласны с такой оценкой. Нашлось много заявлений вроде «но ведь такой код в реальной жизни никто никогда не пишет» и «но ведь он выбрасывает исключение ClassCastException». Тейт в своём тексте отвечает на первое, что это не вопрос юзабилити, а вопрос безопасности — то есть мы должны думать не о том, пишем ли мы такой код сами, а о том, может ли в принципе написать такой код злонамеренный разработчик. А на второе — что с исключением нам просто повезло. Мол, так случайно получилось из-за того, что при добавлении дженериков заботились об обратной совместимости, а если бы что-то пошло иначе (например, дженерики в Java были изначально), его бы не было, что открывало бы большой простор для злоупотреблений. Так что, хотя в итоге всё обошлось без ужасных последствий, подход всё равно неправильный, и разработчикам других языков надо мотать на ус. Помимо текста Тейта и видеоинтервью с ним и Амин, доступна страница, на которой можно лично побаловаться с примерами кода. А чем же изначально была вызвана проблема? Тейт пишет, что в конечном счёте всё сводится к null-pointer bug — «но в отличие от большинства таких багов, на обнаружение этого ушло 12 лет». В общем, связанные с null проблемы бывают не только у рядовых разработчиков!

Видимо кому-то не тому =)

Напиши в скайп, глянем

В описании же написано что он под ловели

А, ну и вот еще https://yadi.sk/i/p7GbeM-k3Am6CN https://yadi.sk/i/FEXArgnq3Am6Ph