Star E пишу.

Снимок экрана

на снимке редактор аватарок для ЛОР ? тема поней не раскрыта :-)

ps. так держать! а то Develop окончательно превратится в коллективный решатель лабораторок, справочник по git и филиал гугл-search :-)

Посмотрел гамбас исходники и мне стало плохо.

Добавь readme.md с кратким описанием.

А что вообще это за редактор? Для чего? Игра(какая)?

Вообще то это жуки. Хотя если охото, то можете добавить по поней.

begin unit
speed=0
type-unit=
tactics=0
formation=0
group=0
x=0
y=0
z=0
writ=0
writ-target=0
writ-x=0
writ-y=0
writ-z=0
begin other-values
begin universal-values
name=
id=0
next value

'= Описание юнита для 2D редактора морфид
name=
id=10002
value-godc=
begin game-object-data

'= Название юнита
add-string=Тестовый юнит

add-string=
add-string=
add-string=

'= Имя файла с картинкой для редактора
add-string=pictures/test/test-model-1/body-test-model-1.png

'= Описание юнита
add-string= Обычное описание юнита


add-integer=0

'= Крепление конечности координаты XYZ (0 голова)
add-integer=25
add-integer=193
add-integer=0

'= Крепление конечности координаты XYZ (1 лапа)
add-integer=59
add-integer=207
add-integer=0

'= Крепление конечности координаты XYZ (2 лапа)
add-integer=59
add-integer=207
add-integer=0

'= Крепление конечности координаты XYZ (3 лапа)
add-integer=99
add-integer=211
add-integer=0

'= Крепление конечности координаты XYZ (4 лапа)
add-integer=99
add-integer=211
add-integer=0

'= Крепление конечности координаты XYZ (5 лапа)
add-integer=157
add-integer=211
add-integer=0

'= Крепление конечности координаты XYZ (6 лапа)
add-integer=157
add-integer=211
add-integer=0

'= Крепление конечности координаты XYZ (7 лапа)
add-integer=178
add-integer=210
add-integer=0

'= Крепление конечности координаты XYZ (8 лапа)
add-integer=178
add-integer=210
add-integer=0

'= Крепление конечности координаты XYZ (9 хвост)
add-integer=230
add-integer=193
add-integer=0

end game-object-data

next value

end universal-values
end other-values
unit no-parts
end unit

'= Это комментарий
'= Данный формат файлов описывает часть юнита
begin part-unit
hp=0
armor=0
hp-armor=0
armorK=0
minimal-demage-armor=0
chance-demage=0
max-hp=0
weight=0
power=0
begin other-values-part
begin universal-values
name=Балластное свойство
id=0
next value
name=
id=10001
value-godc=
begin game-object-data

'= Здесь название юнита для 2D редактора морфид
add-string=Тестовая лапа

'= Поля зарезервированны
add-string=
add-string=

'= Имя файла с картинкой для чётной конечности
add-string=pictures/test/test-model-1/fut-test-model-1e.png

'= Имя файла с картинкой
add-string=pictures/test/test-model-1/fut-test-model-1.png

'= Описание юнита
add-string= Обычное описание

'= Строка проверки дублирования
add-string=fut-test-1

'= Тип необходимой симетрии (0-нет, 1- с нечётного, 2 - с чётного)
add-integer=0

'= Координата X в 2D редакторе
add-integer=11

'= Координата Y в 2D редакторе
add-integer=7

'= Координата Z в 2D редакторе, на всякий случай, вдруг станет 3D редактором
add-integer=0

'= Это лапа, значение 1 (0 голова, 1 лапа, 9 хвост)
add-integer=1

'=Маска дублирования
add-integer=0

'=Маска блокирования
add-integer=0


end game-object-data
next value
end universal-values
end part-unit

Посмотрел гамбас исходники и мне стало плохо.

Что именно тебе не понравилось жутко?

Добавь readme.md с кратким описанием.

А что писать то и в каком виде?

что вообще это за редактор? Для чего? Игра(какая)?

this. Напиши для чего проект предназначен.

А что вообще это за редактор? Для чего? Игра(какая)?

Я делаю движок для стратегической игры реального времени. В нам будет кастомизация и персонализация юнитов. А так же автоматический микро-контроль (с пользовательскими скриптами).

Пока из мыслей, играть можно будет за:

1) Морфидов. Стая или рой.

2) Дельфинчиков (название временное). Торговый флот или планетарные силы.

3) Людей. Корпорация или государство.

Естественно понадобится сложная экономическая модель присущая стратегиям «германской школы».

this. Напиши для чего проект предназначен.

Просто содержимое моего прошлого сообщения?

Почему бы и нет?)

формат файла ЖЕЗТЬ ;-)

текстовый вид с позиционно-зависимыми строками - переделывайте срочно прям бегом

Уродский синтаксис.

текстовый вид с позиционно-зависимыми строками - переделывайте срочно прям бегом

Вообще то это следствие того что GameObjectDataClass это всего лишь контейнер содержащий 3 динамических массива: целочисленный, строковый, дробный. Собственно это такой тип данных который нужен для тех объектов, которые не описать одним значением. Поэтому для ориентации в этих 3 массивах используются константы. Не нашёл лучшего решения. Потому что даже если их сделать позиционно независимыми, то будет не лучше (строка 1, строка 2, строка 3 ...).

Уродский синтаксис.

Кому как. По мне так лучше фигурных скобок в которых легко потеряться.

Как тебе уже выше написали, синтаксис сомнительный. Будет очень тяжело расширять. Осиль либо xml, либо хотя бы ini-файлы (сделав вместо всех этих add-string и add-integer нормальные имена полей и именованные секции). Но xml всё же лучше.

И чем обусловлен выбор языка? Любовь к бейсику? Я не то, чтобы имел что-то против, просто хочу понять.

Честно говоря, нормальные разработчики не форматы присосабливают под язык, а наоборот, начинают с однозначных читаемых форматов. Если Гамбас не прозволяет сделать более наглядный конфиг (в чём я сильно сомневаюсь, вероятно, ты просто что-то не осилил), то это минус в его карму.

Вообще то это следствие того что GameObjectDataClass

это отговорка. Вам очевидно было лень освоить, а фан приносило рисование форм :( надо себя бороть, благо что wikipedia обещает наличие sql и xml модулей gambas - признайся, наверное всё-таки не осилил чё-нить?

совершенно не знаю бейсик, но не поверю что в живых диалектах всё настолько по уродски. Сам по себе «редактор» в приведённом виде делается на qt/gtk максимум за день, на tk(tkinter) за полдня. Причём на всех знакомых технологиях, надо ещё значительно извернуться чтобы поддержать формат конфига приведённый вами. И наверняка в бейсике который вы выбрали это тоже делается проще и за то-же время, может просто компонент взят неудачно и не все маны прочитаны ;-)

справедливости ради конечно замечу что автор языка подзабил на проект - сайт не то чтобы мёртв, но издаёт запахи :-)

Будет очень тяжело расширять.

Как раз таки я так и сделал что бы было расширять легче. http://star-engineers.blogspot.ru/2013/09/blog-post_30.html

сделав вместо всех этих add-string и add-integer нормальные имена полей и именованные секции

Вообще то add-string и add-integer это одно поле, которое имеет свой Name и ID.

И чем обусловлен выбор языка? Любовь к бейсику? Я не то, чтобы имел что-то против, просто хочу понять.

Просто на нём я умею писать и не напрягаться сильно. С другими языками всё несколько сложнее. К тому же я программист-любитель, а не профессионал.

В gambas есть классы для управления конфигами. Но описания пользовательских структур которые ты видел, не являются конфигами. Назначение каждого элемента трёх массивов, должен «знать» лишь конкретный обработчик событий данного ID или диапазона ID. Таким образом назначение каждого элемента пользовательской структуры разрешается локальными константами обработчика ID. Планирую для этих обработчиков сделать Mod-API и класс-шаблон.

признайся, наверное всё-таки не осилил чё-нить?

Мне на первых порах нужно иметь способ лёгкого редактирования файлов. Поэтому я просто не стал осиливать.

Сам по себе «редактор» в приведённом виде делается на qt/gtk максимум за день, на tk(tkinter) за полдня.

Редактор не является конечной целью иначе бы я всё сделал на одном наборе. Я делаю максимально расширяемый и дополняемый новыми свойствами и методами их обработки движок.

Честно говоря, нормальные разработчики не форматы присосабливают под язык, а наоборот, начинают с однозначных читаемых форматов.

Скорее формат под моё восприятие. Мне его удобно редактировать в блокноте.

Скорее формат под моё восприятие. Мне его удобно редактировать в блокноте.

Уж очень какое-то сильно специфическое восприятие.

Твой вариант:

'= Крепление конечности координаты XYZ (2 лапа)
add-integer=59
add-integer=207
add-integer=0

Вариант с ini-файлом:

; Крепление конечности (2 лапа)
[paw2]
x=59
y=207
z=0

Второй вариант с ini-файлом (на любителя, парсить сложнее, да и вообще не по фэншую, но компактнее):

paw2 = (59;207;0)
paw3 = (99;211;0)
...

Вариант XML:

<paw num=2 x=59 y=207 z=0 />

Ты продолжаешь утверждать, что первый вариант самый удобный?

Да, и что ты используешь в качестве блокнота? Если это, как я надеюсь, не notepad.exe, а хотя бы gedit или kwrite (и даже под виндой есть продвинутые блокноты) - то для синтаксисов ini и xml там есть вменяемая подсветка.

Боже, что за !@#$ ?

Ты продолжаешь утверждать, что первый вариант самый удобный?

В game-object-data может оказаться что угодно, а не только визуальное описание конечности. Что именно там находиться, определяет исключительно ID и Name.

Вот картинка http://4.bp.blogspot.com/-4VL8b6xv8Qw/Ukl5XPVFnlI/AAAAAAAAADA/FLJO_h1n2sg/s16...

Да, и что ты используешь в качестве блокнота?

Leafpad

Боже, что за !@#$ ?

Ты про что?

Про эталонное говноедство.

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

Про эталонное говноедство.

Поясни про что ты. Я не понимаю.

за vb

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

В game-object-data может оказаться что угодно, а не только визуальное описание конечности

Если «что угодно», то тем более надо делать человеческие имена переменных. Как тогда ориентироваться в этих твоих add-string? Одна неверно набранная строка - и всё, что после неё, псу под хвост.

Как я понимаю, для конечностей, например, у тебя сейчас программа считает, что x для первой лапы - это 11-я значащая строка (не считая пустых строк и комментариев) внутри game-object-data. Ну или 5-й add-integer. Офигенно наглядно и надёжно. Расширение программы автоматически означает переделывание всех ранее сохранённых файлов.

На все эти грабли программистская мысль уже давным-давно наступала, и ей на них надоело наступать как минимум в середине 80-х годов прошлого века. Появились ini-файлы. Но они подходили только для линейных структур (в крайнем случае - для двухуровневых), поэтому в более поздние годы для сложных форматов предпочтение стало отдаваться XML. А сейчас ещё и JSON.

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

сейчас программа считает, что x для первой лапы - это 11-я значащая строка (не считая пустых строк и комментариев) внутри game-object-data

 
name=
id=10001
value-godc=
begin game-object-data

Переделывание кода, это добавление новых ID или добавление новых элементов в массивы game-object-data

Как тогда ориентироваться в этих твоих add-string?

Есть одна мысль, при сохранении автоматически создавать строки с ремарками.

например, у тебя сейчас программа считает, что x для первой лапы - это 11-я значащая строка

Пятитое целочисленное значение. И не программа в целом считает, а только модуль 2D редактора данного класса юнитов (10000). Нигде более в программе эти данные естественно не будут использоваться.

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

Иерархия примерно такая:

Юнит

• Базовые фиксированные в коде свойства присущие всем юнитам
• Набор с дополнительными свойствами индивидуальный для каждого юнита []
  • GODC integer[], string[], single[]
• Части юнита []
  • Базовые фиксированные в коде свойства присущие всем частям юнитов
  • Набор с дополнительными свойствами индивидуальный для каждого юнита []
    • GODC integer[], string[], single[]

Элемент набора с дополнительными свойствами

• name
• ID
• value (as Variant)

При этом значение может быть нескольких типов, одним из них может быть GODC.

Пятитое целочисленное значение

Ну я и говорю

Ну или 5-й add-integer

В общем, как я понял, ID - это замена типа, причём в кодированном виде.

Но я так и не услышал, чем все эти add-string и add-integer лучше нормальных имён переменных. А чем хуже - тебе уже объясняли выше, и не только я.

Есть одна мысль, при сохранении автоматически создавать строки с ремарками.

Костыль вместо имён переменных. Человеку он ещё как-то поможет, программе при обратном чтении - нет. Хотя если бы он был не «вместо», а «в дополнение к» - то вполне разумно.

В game-object-data может оказаться что угодно, а не только визуальное описание конечности.

Зло именно в этом. Что ты создаёшь «универсальный язык для определения всего», который никак не обеспечивает проверку корректности. Сравни с подходом XML/XSD. В XML можно вводить _любые_ теги, но они должны подчиняться определённым правилам. Всё это не идиоты создавали, поверь мне. INI менее строг (и более привычен человеческому глазу), но и в нём ориентироваться легче, чем в add-string.

Вот к примеру

И не программа в целом считает, а только модуль 2D редактора данного класса юнитов (10000). Нигде более в программе эти данные естественно не будут использоваться.

Тогда тем более резонно определить теги/переменные для «данного класса юнитов» или хотя бы для юнитов вообще (зависит от того, что ты понимаешь под этим словом). То есть надо продумать структуру данных. Писать «универсальную хреновину для всего», которая всё делает (в твоём случае - описывает) одинаково хреново - это очень распространённая болезнь молодых программистов. Я сам таким был когда-то, поверь.

Что именно там находиться, определяет исключительно ID и Name.

Ага, это уже ближе к телу. ID определяет тип. Но определяет он его максимально ненаглядным способом - через абстрактное число. Такие ID хороши для потрохов базы данных, но никак не для языка описания игровых объектов, которые, как ты пишешь, редактирует и человек.

Займись описанием структуры. В твоём словосочетании «модуль 2D редактора данного класса юнитов» первичны последние два слова. Прикинь, какие будут классы юнитов, что у них будет общего, что различного. Тогда набор переменных для будущего языка вылезет сам собой. А код модуля редактора - вторичен.

Не в этом суть, суть в синтаксисе.

чем все эти add-string и add-integer лучше нормальных имён переменных.

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

Но определяет он его максимально ненаглядным способом - через абстрактное число.

Это число указанно как константа в editor2d . Диапазоны ID ещё предстоит распределить, но я же рашил зарезервировать от 10000 до 100000 для графических описаний. Кроме того ID нужен лишь для ускорения доступа, планирую сделать функцию которая будет возвращать ID по Name.

Прикинь, какие будут классы юнитов

Это то как раз и не определенно.

хм..

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

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

Правильно!

А теперь подумай, относится ли к этим случаям, например, тот же набор координат для ног, причём x, y и z россыпью. Вот ноги - это да, кандидат в массивы. Причём массив не простых типов, а структур (в терминологии Си) или записей (в терминологии Паскаля), есть ли аналогичное понятие в Гамбасе, я не знаю, но по идее, должно быть. Структур с полями x, y и z. В файле, в отличие от программы, имеет ещё смысл застолбить место для номера ноги. И если это ini, а не xml - ещё и общее их количество.

Вот те три варианта, которые я приводил выше, эту идею и реализуют. А файл, который у тебя... он как раз мне почему-то напоминает старые Бейсики, где под имя переменной отводилось 1-2 символа, и приходилось путаться в именах типа P0 и W5. А структур не было вообще.

Диапазоны ID ещё предстоит распределить, но я же рашил зарезервировать от 10000 до 100000 для графических описаний.

Тогда в файл как раз лучше писать имена строковые типов. Нечего при чтении файла ускорять, здесь важнее наглядность и переносимость. Вот при работе в памяти, да, можно смастырить какие-нибудь индексы для ускорения. И то ещё надо посмотреть, насколько это существенно.

И ещё раз напоминаю: структуры и форматы первичны. Код вторичен.

А теперь подумай, относится ли к этим случаям, например, тот же набор координат для ног, причём x, y и z россыпью.

Относиться. Потому что эти классы будут иметь значение только во время создания проекта юнита. А игровому серверу без разницы как юнит выглядет в 2D редакторе, он просто при событии будет последовательно передавать все элементы из нужных диапазонов в классы обработчики.

А файл, который у тебя... он как раз мне почему-то напоминает старые Бейсики

Файл нужен что бы сохранять проекты и игру.

Тогда в файл как раз лучше писать имена строковые типов. Нечего при чтении файла ускорять, здесь важнее наглядность и переносимость. Вот при работе в памяти, да, можно смастырить какие-нибудь индексы для ускорения. И то ещё надо посмотреть, насколько это существенно.

Если ты смотрел исходный код, то должен знать что вообще то практически так и сделано. Я не ставил перед собой делемму «Что же выбрать, ID или Name?», я выбрал и то и другое, если ты обратил внимание на то что в файле данных эти два поля рядом. Эти два поля дублируют друг друга, когда нужно быстрое обращение, то используется ID (из константы нужного класса), а в пользовательских сриптах и в подключаемых плагинах будет использоваться Name.

Предположим, я решу добавить в игру моделирование броне-листов, значит я выделю диапазон под различные типы брони, допустим от 500000 до 510000. Это значит что при наступлении события _demage по диапазону ID будет найден класс и в него будет передана ссылка на объект и константа обозначающая тип события. Допустим броня описывается комбинацией цифр, таких как толщина, плотность, вязкость, керамический коэффициент комбинированной брони и угол наклона в 3х проекциях. Значит это массив цифр. Задача игрового процесса, просто передать ссылку на этот массив тому обработчику, который точно знает что делать с этим ID. Никаким другим частям программы нет дела до его внутренней структуры и того какое число что обозначает им важен только ID который указывает кем это свойство (состоящее из 3х массивов) может быть обработано. Вообще, мне хотелось бы, что бы добавлять новые свойства юнитов можно было лишь добавлением в проект их файла-класса и написанием одной строки в модуле инициализации типа:

ArrayGameValuesTypes.Add(New MyGameClass1488)

Представь ситуацию,что у тебя завёлся бета тестер. Вот он лепит своего монстра, лепит. А у тебя новая версия, где ты добавил параметр. Например, число веснушек на... в общем неважно какой.

Что ему делать? Откроет новая версия старый формат? Или пользователь с удобством, в простом текстовом редакторе, всё поправит?

Откроет новая версия старый формат?

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

Так же добавить функцию

UpdateDataVersion (GODC As GameObjectDataClass, Optional ID As Integer = 0, Optional Name As String = "") As GameObjectDataClass 

Которую использовать после загрузки такого объекта в редакторе.

Ты из нескольких костылей собираешь грабли.

Несколько тестеров. Все с разными версиями. В один день решили обновиться. А у тебя даже версии формата нет.

В один день решили обновиться. А у тебя даже версии формата нет.

Назначения полей не меняются. Максимум если нельзя вынести функционал в дополнительный ID, то добавляются новые.

Ты из нескольких костылей собираешь грабли.

Возможно. Но я думаю что уже к первой beta-версии стабилизирую это. А до стабильной версии буду писать процедуры проверки размеров массивов. Чем больше размер массива, тем соответственно больше версия.

Ты из нескольких костылей собираешь грабли.

Хорошая метафора, возьму на вооружение.

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

А если бы у тебя был xml, то сервер точно так же передал бы в класс-обработчик ссылку на DOM-объект, соответствующий тегу <unit>, вместе со всеми дочерними объектами - не вникая в их суть, как ты и хотел. При этом разбор файла вместе с синтаксическим контролем выполняется одной строкой программы. Википедия подсказывает, что XML-парсер в Гамбасе есть (я правда, не знаю, что он поддерживает - DOM, SAX или обе модели).

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

Судя по первой фразе - как раз не массив, а структура (запись). Применительно к XML - набор разноимённых (что принципиально) атрибутов внутри тега <armor>. Применительно к INI - набор разноимённых переменных внутри секции. А у тебя да, получается массив никак не контролируемого формата.

комбинированной брони

Несколько секунд думал, при чём тут пони. ЛОР действует на мышление :)

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

Количество ты так проконтролируешь, состав - нет. А если один параметр добавился, а другой (устаревший) выкинут? Нет, ну можно старые оставлять для совместимости? Далее, при твоём подходе новые элементы можно добавлять только в конец, даже если их группировка подсказывает обратное.

P.S. Честно говоря, если б я начинал новый проект и хотел его написать не на C или C++, я бы выбрал FreePascal. Хороший язык, пронизан структурным подходом, строгая типизация (в отличие от всех известных бейсиков). Но это дело вкуса...