Сумашедший проект

[boRada]

Тебе уже ответили на жтот вопрос. Конечно есть! Это и называется вставить поодержку СКРИПТОВЫХ языков. Перловку там или питон, а то и жаваскрипт. Это совсем одно.

А вот женить меж собой яву и C# это совсем другое, и заниматься этим ну никто не будет

Да и пик с ними. Мне то важен результат, а для начала мне, и не только мне, точно нужно представлять всю ситуацию. Я уж понял (да и знал) что женить их невозможно, но я предложил не женить а сожительствовать А это немного разные вещи. В сущности интересуют не конкретные языки (мы просто уперлись в эти два), а технологии и возможности для достижения поставленной задачи.
Конкретно.
Нужен софт с возможностью изменять простыми (с точки зрения простого юзера) способами его функциональность, причем в широких пределах. На чем он будет написан - по барабану. Почему ж хотим модули? Тогда его смогут писать несколько разноязыких программистов, что одновременно и осложняет задачи и упрощает. Меньше шансов долгостроя. Год-два - это слишком много.
Меня бы устроил такой вариант. Взять готовый парсер, заготовку стата (специалистов РНР больше), коммандер с простым подключением скриптов( пусть так назовем). Заготовку генератора ( где уже есть основные алгоритмы). И более менее грамотная комманда ( сквад) может создать сервер хотяб для своих полетушек, а при удачном воплощении и выйти в мир.

[Baks]

Меня бы устроил такой вариант. Взять готовый парсер, заготовку стата (специалистов РНР больше), коммандер с простым подключением скриптов( пусть так назовем). Заготовку генератора ( где уже есть основные алгоритмы). И более менее грамотная комманда ( сквад) может создать сервер хотяб для своих полетушек, а при удачном воплощении и выйти в мир.

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

Вот в твоем варианте, прикинем, что все хранится в базе.
У нас есть некий показатель эффективности, который зависит от к/д и налета. Это все есть в бд. Это умеет отображать стата. Теперь представь, что нужно добавить еще один параметр: соотношение сил в момент взлета
или сбития. Допустим это не было предусмотрено. В итоге, для добавления этого параметра надо:
1. Изменить базу (SQL программист)
2. Изменить стату (Web программист)
3. Изменить запросы запросы, которые должны учитывать новый параметер. (SQL + Web)
4. Научить командер писать в базу этот параметр (плагин на чем получится).

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

Често: за бесплатно лично я такой гимморой на себя не возьму... Не каждая коммерческая контора возьмется за столь гибкий проект. Слишком много нужно тестировать и слишком много точек, где могут быть ошибки. Мне проще потратить 2 часа в день на прикручивание фичи по просьбе людей (или допустим взяв nullwar-кий демон поколупать и подправить под себя), чем городить такой огород...

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

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

[boRada]

Вот в твоем варианте, прикинем, что все хранится в базе.
У нас есть некий показатель эффективности, который зависит от к/д и налета. Это все есть в бд. Это умеет отображать стата. Теперь представь, что нужно добавить еще один параметр: соотношение сил в момент взлета
или сбития. Допустим это не было предусмотрено. В итоге, для добавления этого параметра надо:
1. Изменить базу (SQL программист)
2. Изменить стату (Web программист)
3. Изменить запросы запросы, которые должны учитывать новый параметер. (SQL + Web)
4. Научить командер писать в базу этот параметр (плагин на чем получится).

Позволь с тобой не согласиться. Тыж сам сказал "В базе хранится все" Т.е. в базе есть весь распарсенный лог ( что например и делает SC), зачем создавать еще ячейки?
Т.е. работа только у ВЭБ программиста. Изменить html и PHP. Прописать запрос из базы нужной информации и обсчитать ее и показать.
Мы ведь понимаем, что не получится делать проект ничего не зная или не делая. Но вопрос квалификации. Всеж это значительно проще, иначе говоря - РНР знает гораздо больше народу чем С или Java.
И зачем командеру писать в базу этот параметр? Если есть такая задача, тот же РНР при обсчете и пропишет, хотя не вижу смысла.
Без проблем никогда не получится, но надо понимать разницу между проблемами.
А килы пропадают везде. Это от софта уже не зависит, ты и сам это прекрасно знаешь. Тут проблема лога.
И вообще - "волков боятся - щепки летят"

[Baks]

Позволь с тобой не согласиться. Тыж сам сказал "В базе хранится все" Т.е. в базе есть весь распарсенный лог ( что например и делает SC), зачем создавать еще ячейки?
Т.е. работа только у ВЭБ программиста. Изменить html и PHP. Прописать запрос из базы нужной информации и обсчитать ее и показать.
Мы ведь понимаем, что не получится делать проект ничего не зная или не делая. Но вопрос квалификации. Всеж это значительно проще, иначе говоря - РНР знает гораздо больше народу чем С или Java.
И зачем командеру писать в базу этот параметр? Если есть такая задача, тот же РНР при обсчете и пропишет, хотя не вижу смысла.
Без проблем никогда не получится, но надо понимать разницу между проблемами.
А килы пропадают везде. Это от софта уже не зависит, ты и сам это прекрасно знаешь. Тут проблема лога.
И вообще - "волков боятся - щепки летят"

Тут мы приходим к вопросу эффективности... дело в том, что например обсчитать количество пилотов в воздухе в момент вылета пилота в разы проще, чем потом SQL-ем это вытягивать (ибо некислый selfjoin). Например сейчас у меня в базе 120тыщ вылетов. Килов... блин, не помню сколько, но умножь на 0.4 для авиа + умножь на 5 для наземки. Это крайне неэффективно. Нужно все равно предрасчет делать, а некоторые вещи лучше сразу в командере считать и в базу уже в готовом виде писать.

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

Ну и если рассчетные параметры так сделать можно... то например как быть с такими параметрами как сквад. Или награды?