5 баллов... но прикольно жеСообщение от ROA_McFris
5 баллов... но прикольно же
Гы!
<planes выдаёт запрос к SQL-процедуре базы статистики, которая возвращает хоть чёрта лысого.
Появление на филде игрока запрашивает результат у SQL-процедуры (на Нуле weap_rest), которая до дури всего в статистике анализирует и возвращает результат.
ДЕМОН обязан быть всего лишь обработчиком команд. ВСЁ остальное дело статистики, написанной на простом и всем понятном языке оперирования данных, а именно SQL. Конечно, разным юзерам MyDBF подобный путь заказан, вот и изощряетесь.
Демон ничто - статистика всё. А по статистике вы в жизни не договоритесь.
Гы!
А чем запрос к SQL отличается от запроса к сриптовому движку? Аж ничем. В этом плане написание логики работы на SQL абсолютно аналочино написанию логики на скриптовом языке. А процедуры хранимые есть даже на MySQL, не говоря уж про MsSQL или там Postress ...
Кстати пример был написан не для того, чтобы рассказать как надо делать, а для того чтобы показать сложности межпроцессорного общения.
А по поводу мощности языка БД, то отчего у нас вдруг появилось столько трехуровневых приложений, если все так легко и круто ложиться в БД. А генератор тоже на БД ? Или на скиптах. Ну возьмите шаблон цели и в с помощью SQL скрипта ПОВЕРНИТЕ его на произвольный угол. А потом сравним с тем как это делается в дотнете или яве с их готовой матричной математикой.
Если ты веришь, что все можно испортить, поверь и в то, что все можно исправить. Раби Нахман из Браслава.
Это был простой пример для иллюстрации того, что получается, когда пытаются объединить разные языки и разбить на модули.Гы!
<planes выдаёт запрос к SQL-процедуре базы статистики, которая возвращает хоть чёрта лысого.
Появление на филде игрока запрашивает результат у SQL-процедуры (на Нуле weap_rest), которая до дури всего в статистике анализирует и возвращает результат.
ДЕМОН обязан быть всего лишь обработчиком команд. ВСЁ остальное дело статистики, написанной на простом и всем понятном языке оперирования данных, а именно SQL. Конечно, разным юзерам MyDBF подобный путь заказан, вот и изощряетесь.
Демон ничто - статистика всё. А по статистике вы в жизни не договоритесь.
А зачем нам о ней договариваться... просто беру и пишу.
Ну и MyDBF ни чем не хуже Птиц... та же туфта, что и все остальное... Оракель - вот сила (или Птица уже научилась аналитические функции понимать?)
...И от полученных знаний скончался на месте
Жаль, что поддержка Ил-2 закончилась пару лет назад.
Можно было бы еще много чего вытянуть.
На самом деле мощность зависит от БД. Если рассматривать поделия типа MySQL или Firebird или SQLite, то да... просто хранилки данных, к тому же приложения получаются глупые с постоянным дерганьем бд.
Другое дело что-то более мощьное типа Oracle, я там обхожусь практически без DAO (только что объекты из запросов заворачивать) остальное все на PL/SQL, SLQ и немного embedded java. Жаль токо тут это неприменимо
...И от полученных знаний скончался на месте
Так для того и написано.
Когда Борада оставил генератор, размер его был ~140кб. После нормальной чистки и перекидывания некоторой чати на SQL, размер генератора сейчас ~85кб при РАСШИРИВШЕЙСЯ функциональности и несравнимо большей понятности, управляемости и безглючности. Так что вот.
Я бы и остальное перенёс, но следую старой привычке: работает - не трогай.
Это я понял, и именно так себе и представляю.
Но проблема как видим не в сложности технической реализации, а в том, что пришлось бы писать больше кода - классы, функции, методы, т.е. в большей трудоемкости. И лишь для того,чтоб сделать возможным обмен данными между какими-то модулями, а нафиг это нужно "когда я возьму и напишу без геморроя все в одной куче". И это понятно.
Но вы упускаете важный момент, который с вашей колокольни вам кажется незначительным и ненужным. У вас получается достаточно узконаправленный и зажатый в свои рамки блок. И менять или переделывать его для кого-то никто из "отцов" не будет. Да просто лениво делать, особенно то, с чем не согласен. Пример - наш разговор. Не раз сказано "каждый пишет на том, на чем лучше всего умеет писать". Готов ли каждый в одиночку написать комплект софта на своем языке и выдать его как законченный продукт? Теоретически - конечно, но практически - вряд ли. Найдется сотня причин, которые помешают это сделать.
Найдется 2-5 человек которые напишут софт на одном языке - чудесно! А кто против? Главное при этом, чтоб еще 30 человек смогли его использовать в своих целях, иначе говоря, чтоб он полностью отвечал их запросам. Шансы? Минимальные.
Пример. Мне необходимо чтоб SC выдал в чат комманду "Равняйсь, Смирна!" Возможно ? Нет. Он закрыт.
Мне надо чтоб JayDaemon это сделал? Нет. Для этого нужно выучить JAVA, разобраться с исходниками и вставить несколько строк кода. Реально, да.. но бррр, а когдаж карты рисовать? А потом вдруг на С# появится софт, который мне понравится больше, будет интереснее. Да фигня! Теперь учим С#, разбираемся с исходниками и вставляем-меняем.
Нда. Делов то.
Но меня интересует другое:
Есть техническая возможность создать софт, для которого я могу написать несколько строк на xml, например, и этот софт его проглотит и выдаст результат? Или я заполню некоторый шаблон, и на основе его сформируется скрипт или еще какая фигня, которая включится в работу не заставляя изучать новый язык программирования?
Я понимаю, что вам это не надо. Это надо НАМ, не программистам, но режисерам, картостроителям, сценаристам...
А зачем это вам? Незачем. Но может найдется один или несколько програмистов, которым будет интересно решить такую задачу. Именно поэтому я и вынес это на обсуждение, надеясь на удачу. На самом деле это гораздо интереснее и круче, чем свой маленький самодостаточный проект - работает, ну и ладно.
Крайний раз редактировалось boRada; 31.10.2006 в 07:14.
Тебе уже ответили на жтот вопрос. Конечно есть! Это и называется вставить поодержку СКРИПТОВЫХ языков. Перловку там или питон, а то и жаваскрипт. Это совсем одно.Есть техническая возможность создать софт, для которого я могу написать несколько строк на xml, например, и этот софт его проглотит и выдаст результат? Или я заполню некоторый шаблон, и на основе его сформируется скрипт или еще какая фигня, которая включится в работу не заставляя изучать новый язык программирования?
А вот женить меж собой яву и C# это совсем другое, и заниматься этим ну никто не будет
Если ты веришь, что все можно испортить, поверь и в то, что все можно исправить. Раби Нахман из Браслава.
Чей-то насквозь догфайтный нуль не ломится от количества самолетов.Вот и все. Упростить и ускорить вход - и пилоты из догфайта потянутся в проекты
А надо-то всего ничего - регистнуться и пароль ввестин а входе. Человеку, запускающему все моторы ТБ и пользующемуся огнетушителями вполне под силу.
Инструкция по стрельбе: Не льсти себе, подойди ближе! :)
Угу. За всех не скажу, кто-то готов на это, Нуль уважаем, живет и здравствует, будь ему хорошо и дальше. Но учитывая, что играть приходят не только молодежь по 18-25 лет, но и "старики" он-лайна... По десять минут ждать, простите. Это все здорово, но есть 3-4 часа на полетушки. И терять даже часть времени нет желания. Когда хочется можно и свой сервант поднять погоняться в кооп-миссиях. Где и техника движется, и прочих прелестей есть, включая планирование... Ибо и в одной кооп-миссии можно навертеть целей, с ковером и без такового, типа проект.Чей-то насквозь догфайтный нуль не ломится от количества самолетов.
А надо-то всего ничего - регистнуться и пароль ввестин а входе. Человеку, запускающему все моторы ТБ и пользующемуся огнетушителями вполне под силу.
Мля, идите на дуэльный сервер - там ваши кони, сэры рыцари
Я дрался с асами WarBirds(c)Varga
Основная проблема русского витуального сообщества - избыток лыцарелизателей и рыцаререзателей и нехватка наевропуболтоположителей... (с)CoValent
БоБ прямее руганью не станет. (с) Harh
Oculos habent non viclebunt.(c) Псалом 134
Q9650+8GbRAM+560Ti/2Gbi7-4790k+32Gb+2060/6Gb
Да и пик с ними. Мне то важен результат, а для начала мне, и не только мне, точно нужно представлять всю ситуацию. Я уж понял (да и знал) что женить их невозможно, но я предложил не женить а сожительствовать
Конкретно.
Нужен софт с возможностью изменять простыми (с точки зрения простого юзера) способами его функциональность, причем в широких пределах. На чем он будет написан - по барабану. Почему ж хотим модули? Тогда его смогут писать несколько разноязыких программистов, что одновременно и осложняет задачи и упрощает. Меньше шансов долгостроя. Год-два - это слишком много.
Меня бы устроил такой вариант. Взять готовый парсер, заготовку стата (специалистов РНР больше), коммандер с простым подключением скриптов( пусть так назовем). Заготовку генератора ( где уже есть основные алгоритмы). И более менее грамотная комманда ( сквад) может создать сервер хотяб для своих полетушек, а при удачном воплощении и выйти в мир.
Крайний раз редактировалось boRada; 31.10.2006 в 11:09.
Это все замечательно, но по личному опыту, если программистов в команде больше 3х проблемы вылазиют другого рода. Опять же приходим к ведущему-ведомым... ну да фиг с нами, с программисами... смотри другой вариант, почему это реализуемо, но слишком сложно и как следствие будет много глюков (т.к. не будет толковой тест-команды).
Вот в твоем варианте, прикинем, что все хранится в базе.
У нас есть некий показатель эффективности, который зависит от к/д и налета. Это все есть в бд. Это умеет отображать стата. Теперь представь, что нужно добавить еще один параметр: соотношение сил в момент взлета
или сбития. Допустим это не было предусмотрено. В итоге, для добавления этого параметра надо:
1. Изменить базу (SQL программист)
2. Изменить стату (Web программист)
3. Изменить запросы запросы, которые должны учитывать новый параметер. (SQL + Web)
4. Научить командер писать в базу этот параметр (плагин на чем получится).
Т.е. мы имеем довольно сложную систему, которая выглядить примерно как Access какойнибудь, т.е. необходимо сделать ее настолько универсальной, чтобы все параметры, запросы, отображение и прочее описывалось в xml/python/что угодно и система это должна видеть и перестраивать себя...
Често: за бесплатно лично я такой гимморой на себя не возьму... Не каждая коммерческая контора возьмется за столь гибкий проект. Слишком много нужно тестировать и слишком много точек, где могут быть ошибки. Мне проще потратить 2 часа в день на прикручивание фичи по просьбе людей (или допустим взяв nullwar-кий демон поколупать и подправить под себя), чем городить такой огород...
Знаешь... нет ничего хуже, чем из-за непонятного глюка пропадают килы... люди просто уходят на более простой сервер (им пофиг что и как там работает) лишь бы килы не пропадали (на опыте своего сервера).
Ну и языков кучу учить не надо... достаточно выучить Python и можно будет писать плагины (правда только на имеющихся возможностях командера, если он чего-то не знает, то тут надо уже к разработчику идти).
...И от полученных знаний скончался на месте
Позволь с тобой не согласиться. Тыж сам сказал "В базе хранится все" Т.е. в базе есть весь распарсенный лог ( что например и делает SC), зачем создавать еще ячейки?
Т.е. работа только у ВЭБ программиста. Изменить html и PHP. Прописать запрос из базы нужной информации и обсчитать ее и показать.
Мы ведь понимаем, что не получится делать проект ничего не зная или не делая. Но вопрос квалификации. Всеж это значительно проще, иначе говоря - РНР знает гораздо больше народу чем С или Java.
И зачем командеру писать в базу этот параметр? Если есть такая задача, тот же РНР при обсчете и пропишет, хотя не вижу смысла.
Без проблем никогда не получится, но надо понимать разницу между проблемами.
А килы пропадают везде. Это от софта уже не зависит, ты и сам это прекрасно знаешь. Тут проблема лога.
И вообще - "волков боятся - щепки летят"
Крайний раз редактировалось boRada; 31.10.2006 в 12:01.
Тут мы приходим к вопросу эффективности... дело в том, что например обсчитать количество пилотов в воздухе в момент вылета пилота в разы проще, чем потом SQL-ем это вытягивать (ибо некислый selfjoin). Например сейчас у меня в базе 120тыщ вылетов. Килов... блин, не помню сколько, но умножь на 0.4 для авиа + умножь на 5 для наземки. Это крайне неэффективно. Нужно все равно предрасчет делать, а некоторые вещи лучше сразу в командере считать и в базу уже в готовом виде писать.
Ну и с il2sc ты не прав... там все разложено по табличкам (в том числе сколько чего сбил (раздельно по типам), стрик, отдельная табличка на килы и т.д.). Я в стате вообще не использую лог. Но приходится добавлять таблицы, чтобы хранить нужную мне информацию.
Ну и если рассчетные параметры так сделать можно... то например как быть с такими параметрами как сквад. Или награды?
...И от полученных знаний скончался на месте
Так это потому что: "На том0же нуле можно минт 10 просидеть на филде, пока офицеры решат, что куда."Чей-то насквозь догфайтный нуль не ломится от количества самолетов.
Проект, не важно кооп или догфайт должен быть ИНТЕРЕСНЫМ для большинства пилотов.
Только тогда в нем будет много народу.
Надо знать что кому интересно.
Мне, как штурмовику/бомберу нужны наземные бои и наполненные целями ж/д станции и т.п.
Кто-то хочет бороться за превосходство в воздухе, кто-то считает, что он мастер прикрытия.
Ну и т.д.
Если в проект будет:
- легко войти, сразу иметь связь со всеми своими пилотами
- быстро получить задачу и вступить в бой
- ПОНИМАТЬ за что воюем, КАК ты можешь повлиять на положение своей стороны
то народ будет в нем летать.
Но "стоить" народ бесполезно. Останутся единицы, остальные разбегутся.
И, еще раз подчеркну - БЕСПЛАТНАЯ работа кучки энтузиастов себя исчерпала. Проект должен быть коммерческим, платным, массовым, рассчитанным на покрытие интересов максимального количества вирпилов.
Состоявшийся мужчина должен иметь не менее 4-х детей...
Как же ты ошибаешься
http://www.mono-project.com/Java
не можешь летать - не мучай метлу!
Ну это не серьезно
...И от полученных знаний скончался на месте
Я к тому что нашлись люди которые хотят "поженить"Ну это не серьезно
не можешь летать - не мучай метлу!
Это да...маньяки
...И от полученных знаний скончался на месте
Да упаси боже! Больше 30 пилотов в онлайн на сервере = бардак и полная неуправлямость, отсутствие какой либо мысли и догфайт. Именно потому у Нуля очень строгие рамки в этом плане. Сделать проект, где будет летать 100 раздолбаев крайне легко... А вот собрать и заставить хотя бы 30 человек (из разных сквадов, разных сторон, разных вообще!) действовать в строгой команде - в те же сто раз сложнее.
Так что больше проектов хороших и разных!
Если каждый игрок понимает, что его действия ведут к победе или поражению его стороны, то через какое-то время происходит самоорганизация и тот, кто быстрее организовался - побеждает.
Я ведь не из головы это все придумываю. У нас есть перед глазами World War II Online Battleground Europe, где геймплей ЗАСТАВИЛ изначально неорганизованные толпы играть командно. А там не 30 и не 100 человек играет одновременно, а гораздо больше.
ИМХО - многие принципы организации боев в WWIIOl можно реализовать в проекте по Ил-2.
Состоявшийся мужчина должен иметь не менее 4-х детей...
А как перекидывание части логики на SQL сказалось на возможность интеграции с другим ПО? То есть теперь генератор можно использовать только с такой структурой БД и никакой другой? Так зачем кому-то ещё кроме нуля нужен будет вот такой генератор который нельзя больше никуда интегрировать?Когда Борада оставил генератор, размер его был ~140кб. После нормальной чистки и перекидывания некоторой чати на SQL, размер генератора сейчас ~85кб при РАСШИРИВШЕЙСЯ функциональности и несравнимо большей понятности, управляемости и безглючности. Так что вот.
Я бы и остальное перенёс, но следую старой привычке: работает - не трогай.
не можешь летать - не мучай метлу!
Куда чего интегрировать? Я ничего никуда не интегрирую!
Ваши права
Ответить с цитированием
