Объявляю эту тему своей. Тем не менее, я буду использовать её с некоторым уважением к правилам форума.
Я буду публиковать здесь то, что посчитаю нужным, в какой захочу форме, и в желаемых количествах.
(Предупреждаю, что если кто-либо необоснованно и без моего согласия прикоснётся к самой теме или сообщениям здесь – то я для начала стану рандомно удалять чужие комментарии в соседних темах до тех пор, пока не лишусь формальных прав, позволяющих это.)
Безусловно, ничего не имею против чьих-либо ответов.
(прошлое содержимое этой темы отправлено туда; а вот и заархивированная копия прошлого содержания)
ЦитатаVirki ()
(это из чата, если что)
*UPD*
ЛИЦЕНЗИЯ НА ВЕСЬ КОНТЕНТ ЗДЕСЬ И НЕ ТОЛЬКО:
Я, Клименко Алексей, также известный как Aleksusklim/aleksuslim и Kly_Men_COmpany, сим объявляю, что все мои авторские тексты, такие как личные сообщения, комментарии, описания или документации, и художественные произведения любого характера – все написанные ранее и все последующие – должны рассматриваться как лицензированные под «CC0» (общественное достояние), если в них не указано иное; а все мои авторские программные продукты, которые я распространяю с открытым исходным кодом – все написанные ранее и все последующие, если не указано иное и отличное от «лицензия – свободная» или «free» – должны рассматриваться как лицензированные под WTFPL (отказ от авторских прав); однако, данное моё заявление должно применятся только к тем материалам, в отношении которых моё единоличное авторство объективно не вызывает сомнений, а также к таким материалам, для которых очевидно отсутствие ещё чьих-либо претензий на лицензию и авторские права. but nobody came
Сообщение отредактировал aleksusklim - Воскресенье, 05.11.2017, 15:26
Вот закидали просто текстами. Закидали. (Это не хорошо и не плохо, просто закидали!..)
Так. Раз уж я в эту минуту на работе (а как вернусь домой – уйду ж в глубокую отладку), отвечу на текст. Но без переключения на что либо, кроме этой ветки.
Цитатаaleksusklim
Обновлю пост, когда выложу программу для ХА.
Чёртов пад отвлёк даже от неё.
ЦитатаАрчик
Иными словами можно подвести четру под всем этим и выразиться словами филатова -
На самом деле, да. Кстати, люблю Филатова…
И я снова прошу меня простить. Не, я как бы да, рассчитывал вот так просто взять и вернуться к тексту, ведь мне есть много чего сказать по поводу много чего, но сейчас я, блин, всё равно не свободен! Даже выкинув всё то, на что я забил, текущий стек такой: – Offline Spyro Pad – Его кастомизация (ниже) – Программа универсальной обработки ХА – Интерфейс к ней для сборки ХА, метод вставки наших озвучек в игру (думаю, отменю это пока из приоритетов) – Прокачка SWV v1.4 до поддержки Spyro1/2 (учитывая вышестоящее, тоже лучше сбросить) – Норм инструкиця по записи озвучек
Цитатаalteya
Выкладываю сценки 1-13 на форум.
Здесь и далее я пока игнорирую все фразы, которые не были никем прокомментированы. (Иначе этого поста бы не было)
Цитатаalteya
Если честно, во фразе «нам нужен небольшой тихий мирок» я этой игры, и второго значения слова «мир»=антивойна не ощущаю.
(О, и я могу ошибаться в своих комментариях, я же сейчас ничего не проверяю. Говорю по памяти и по имеющемуся тут).
Насколько я понимаю, тут я, возможно, сделал игру слов на некотором «недопонимании» значения слова. Спайро употребляет мир как локацию, а Бёрд воспринимает как отсутствие войны. Наверное, мне это казалось логичным (он же военный; ну то есть, драконы-то ясно не из-за такой войны исчезли, какая сейчас на базе сержанта).
Цитатаalteya
У меня эти таблицы - моя и Серлутинские - вообще по-разному отражаются.
Там по-моему, последний элемент адреса нужно делать /edit чтобы на редактирование открыть. Но вообще да, зайдя с другой машины – открылось редактирование. Уф, но там всё равно как-то неудобно, особенно – вести обсуждения.
Когда-то aleksusklim что-то решил, и когда-то alteya с чем-то была согласна.
А ведь и правда… (Вы в обиде на меня за то, что за всё это время я не перевёл Спайро, да?..)
Цитатаalteya
а рифм там вообще нет - алексусклиму померещилось.
ЦитатаDragonFlight
Вы прямо мои мысли читаете! Слово в слово (два последних).
Эй!! Если не хотите рифмы – не будут вам рифмы. Но фразы «обычными» сделать не позволю!..
ЦитатаSerlutin
Предлагаю название: Злой Плот Разворачивается. М, ну как вам? Гениально же!
Это ваще!
Цитатаalteya
[/УРЛ]? Откуда?? Самое интересное, что при редактировании этого сообщения его в тексте нет.
Ага, я пока там стишок Филатова поправлял, тоже раз шесть перередактировал. У меня выскакивала закрывающаяся [/в]
Вообще говоря, можно Серлутина попросить скрипт на наши страницы добаивть скрипт, либо убивающий его, либо превращающий в старый (ну я подредактирую, наверняка он уже поломался). Мы же пишем здоровенные посты с кучами цитат, и нам он мешает.
А в других темах форму, где люди привыкли быстро строчить короткие ответы – там останется их любимый визуальный…
ЦитатаDragonFlight
Настолько ли необходимо во всём сохранять верность оригинальным названиям, вплоть до оставления синтаксической конструкции?
Нужна как бы свобода. Свобода настолько, чтобы брать вариант – какой хочешь. Но при этом он и оригиналу противоречить не должен.
Ведь очень часто, адаптивные локализации, так ненавситные труъ-фанами, на самом деле вольны, свободны и ближе – делают продукт лучше. Возможно, большой ценой каких-то там оригинальных хитросплетений. А нам, видимо, нужно что-то среднее. Русский вариант не должен страдать только потому, что оригинал, видите ли, ТАКОЙ ( – такой перекрученный, такой страдательно-пассивный, такой непонятно-что-имеется-в-виду…)
ЦитатаDragonFlight
У меня на примете игра, пестрящая шедевральными названиями, в которых игра слов в самом явном виде.
Оу, а ведь нам повезло. Ведь в пони такие же круто ассемблированные названия серий. И для переводчика – как бы …ЧО-О!? Что, что можно предпринять? Когда отсылки идут на альбомы каких-нить композиторов, которые не особо и с сюжетом вяжутся, а просто подходящее название для игры слов; на устойчивые сочетания, на названия фильмов (хотя это ещё лёгкий случай)… «Ice To See You // "nice to see you"» – я даже представляю, что там будет, и почему название такое. Шедевр! Ну да, в конкретно этом случае – можно сыграть на «лёд» уже не важно как. Как будет лучше стыковаться с содержанием, не противоречить ему. Пример от фонаря: «Внезапный за лёд» («залёт»)
Кстати, вспомнил. На этот (да и многие другие спорные моменты в обычных фразах) случай же у меня в запасе есть одна формула (я её косвенно озвучивал, когда делал PPT). Эта формула даёт ровно столько свободы, сколько позволено взять. Однако её должны «принять» те, кто будут оценивать/выбирать варианты. То есть итоговый спор нужно вести именно по поводу того, верно ли применена формула к данному тексту, а не о том, имеет ли она место в принципе. Суть такова:
Если в переводе то, чего нет в оригинале: нужно честно ответить на вопрос: «Могло ли оно там быть?».
– и если все согласны, что могло – тогда МОЖНО.
ЦитатаDragonFlight
Факт в том, что сейчас игра сама по себе для них не сильно важна; они не застревают в прошлом, как мы: это пройденный этап. Потому Тед Прайс и не помнит ни одного названия драконьих семейств...
Да-да-да, всем пофиг как назывался такой-то уровень. Так и есть. Но нужно хотя бы не опускаться ниже уровня, когда начинают задавать вопрос «а с какого перепугу он назван именно так».
Будут оценивать качество поверхностно, то есть через озвучку: для этого не надо много думать.
Упс. А ведь это так..
ЦитатаDragonFlight
Сколько раз можно так распоряжаться актёрами? И если в конце концов будет решено, что актёр не справился с задачей - как сказать об этом так, чтобы не обидеть?
Ну, я надаюсь на то, что с нами будут во-первых не полные нубы, и которые во-вторых понимают смысл всего проекта. И которые не будут производить плохой материал, либо же – соглашаться с нашими замечаниями. Или что ещё вероятнее – исправлять наш текст по объективным причинам.
ЦитатаDragonFlight
К примеру, недавно я пробовал повторить коронный монолог Бианки
Поддерживаю.
Когда я делал пробные реплики – почти каждая из них по сути являлась правкой текста. Потому что что-то невозможно произнести, что-то другое напрашивается сразу же, а что-то третье – получается само собой наперекор попытке идти строго по тексту.
ЦитатаDragonFlight
Но, объективно, я не уверен, что такая переделка будет уместной (не всю же игру стихами переводить, в конце концов).
Ну может быть. На глаз – действительно словно фраза ради одного этого выкручена. Такого ощущения возникать не должно…
ЦитатаDragonFlight
О-о, здесь конкретное непопадание в тон персонажа.
В «Рапунцель: Запутання История» там даже нарочно с «вы» на «ты» перешли. Ой, то есть наоборот. Наверное, у нас не тот случай. Хотя это зависит от количества явных личных местоимений всего ранее.
ЦитатаDragonFlight
А я, например, не знаю, какого рожна слово "дух" подобрано к punk
Знаю точно, что там же дальше у меня было «или-ка, я знаю, где ты прячешься», а ранее, мол – «не носорог ли там за кустами?» «дух» вроде как, применяется к тому, кто чего-то боится, скрывается в тени, не идёт на прямой конфликт (ну типа, «Пошли выйдем! Чё, дух?»)
Вроде подходит…
Цитатаalteya
Сценка с Элорой, Агентом 9 и Профессором. И я тоже против «дух».
Эй!..
Цитатаalteya
Если хотелось сделать один слог, может тогда «гад»?
На удивление, я не против.
Цитатаalteya
Можно ведь как-то принудительно оставить двух последних светлячков? Заодно и пропавшую фразу Гомера вернем. А то там так уныло и грустно становится, когда вокруг одни носороги и крокодилы…
По-моему, мне это даже предлагали, не то Yams, не то Serlutin.
Цитатаalteya
Взять, проговорить и записать (да хоть на телефон!) наши реплики в сценках – с примерной интонацией но без претензий на Оскар (можно и с ними – это завсегда пожалуйста).
На самом деле это именно то, чего я желал in the first place. Озвучивать – это же так весело! Даже если это не будет использоваться далее. Озвучить и выложить – мне это очень нравится. Да, тему озвучки уже пора оживлять…
А вообще да, грубо говоря, если я сам всё озвучу – то к всем (ну, ко многим) у нас появятся актёрские правки, пусть даже мои. Возможно, так и стоило делать изначально.
Процесс, конечно, забавный, но и времени требует не мало. То есть ВСЕ фразы вот прямо сейчас – я по-любому не осилю. Но в перспективе – можно.
Цитата DragonFlight
Да не коробит, бесполезное замечание, в сущности. Надо мне такие фильтровать.
Цитатаalteya
Не, почему же? И так тут не то, чтобы бурные дебаты и обсуждения.
(я тоже сначала воспринял цитату имено в таком ключе, но по-меому, он другое имел в виду)
ЦитатаDragonFlight
"СМО-ТРИ!" явно лишняя, не будем успевать.
Не знаю, что у вас там лишнее, но я это и писал, и озвучивал. Было норм, хотя на вид и не норм. Но текста-то на экране не будет.
Хотя елси будет вариант лучше – пожалуйста.
ЦитатаDragonFlight
"Зайдёшь"?
Цитатаalteya
Эти две принимаю.
WTF!? Я точно знаю, что мой вариант был – «навестишь меня в Аваларе», и я не понимаю, чем он так хуже этих. Но если вы реально его уже где-то обсудили и когда-то отвергли – ладно, чего уж…
ЦитатаDragonFlight
Но... одиночные предложения приветствуются, да ведь?
Гоу в пад. (не ну как бы пока некуда, да, но вообще – гоу в пад!)
ЦитатаDragonFlight
Вообще в Мортале было "FINISH HIM!", а finish him off вполне распространено.
Оу. Я думал это обсуждение Бартоломея (или как там его у нас уже величают) и его «this is the last round, finish him off!»
Цитатаalteya
Клименко когда-то предлагал вариант «И только Зло не дремлет» или вроде того. Ну типа пока добро дрыхнет, зло не спит и тырит яйца.
ЦитатаDragonFlight
Мне нравится, особенно второе.
Ой, а ведь и точно!
Цитатаalteya
Только вот что-то я тут ничего такого не заметила. Ни когда сама играла, ни когда смотрела видео на ютубе.
ЦитатаDragonFlight
Я тоже не припомню.
Это эксклюзивная фишка Greatest Hits.
Я подумывал насчёт «зад» в озвучке и «ЖОПУ» в тексте, который не появится.
Цитатаalteya
И я понятия не имею, как финализировать текст.
Я агитирую за пад не потому что мы там в нём переводили пони. Не потмоу что я уже неделю на него угрохал. И не потмоу что у меня гугль-доки не открываются.
Вариант оффлайн-пада я вижу отличным решением проблемы, сочетающим в себя одновремнно и достоинства Ворда (форматирование) и форума (в смысле, лёгкий перенос текста туда-сюда), и системы контроля версий (конечно диффа и мержда как таковых не будет, а даже если кто-то удалит весь текст – это всего лишь запись в истории самого пада, легко исправимая выкопированием прошлого текста; ревизии самого гита тут нужны на случай, если кто-то попытается в обход пада грохнуть/испортить само хранилище – вот тогда будет реверт в гите, да).
Но если я – единственный, кому кажется, что использование пада как я сказал – избавит нас от кучи неудобств – то окей. Попытаюсь с гугль-доками подружиться…
Цитатаalteya
Да звучат по-дурацки... почти как «аналогового» (который мы, к счастью, нафиг убрали)
Но к сожалению – лишь при попытке непосредственно озвучить. but nobody came
Сообщение отредактировал aleksusklim - Вторник, 04.10.2016, 19:06
Так, из восьми байт: – первые два: координаты сдвига по горизонтали и вертикали, для отсечения слева и сверху (начать с 00 и добавлять); отрицательные – что-то выворачивают наизнанку. – следующие два: координаты палитры. Пока не понял, как именно задаются, но сокорее всего, очень просто. – ещё два: высота и ширина. Моё FF-FF на скриншоте – максимум, что можно выжать. – предпоследний байт: номер текстурной страницы. Старший бит – использовать ли 256 цветов палитры (иначе – 16). Самая верхняя-правая текстураня страница, вроде бы, «8Eh». Попытка сослаться на левую половину рисуемого экрана допустима, хотя и глупа. – последний байт: младший бит – использовать ли полноцветный 15-битный режим – будут игнорироваться палитра и режим 4/8 бит.
Пора заполнить правый угол через PGG хоть чем-то, и глянуть. Кстати, на место оригинального логотипа можно будет положить наш шрифт…
I never imagined myself out on my own Trying to find out what's next for me The Cutie Mark Crusaders have always been my home Maybe now there is more that I could be
I guess as time goes by Every pony has to go out on their own And maybe someday I'll have to try Something new that's just for me A little something that could be Just my own and I won't feel so left behind
We used to say that we'd be always side by side Maybe things are changin' and this could mean goodbye I always thought our friendship was all I'd ever need We've always been crusadin' – what else is there for me?
I guess as time goes by Every pony has to go out on their own And maybe someday I'll have to try Something new that's just for me A little something that could be Just my own and I won't feel so left behind
__________
Мой опубликованный перевод:
Я и не думала, что буду одна В поисках: что же ждёт меня? Искателей команда – вы были мне родня, На что же ещё способна я?
Когда придёт ваш час, То все пони по своим тропам пойдут… Так может и я сумею раз Сделать что-то, что моё, Найти призвание своё И смогу не потеряться, как сейчас.
Клялись, что вечно будем мы плечом к плечу, Времена сменились – я вам «прощай» шепчу. Всегда казалось: дружба – вот всё, что нужно мне. Мы свой талант искали, заняться чем теперь?
Когда пробьёт мой час, Я, как все, своей дорогою пойду. Попробую всё, но может раз Что-то я найду своё, Что идеально и моё, Да смогу не огорчаться, как сейчас.
Take a look at everything around you All the smells that surely will astound you Open up your heart, it will surround you In the magic of Hearth's Warming Eve
The little things that make it better Little ponies spreading cheer Give a toy, a hug, a sweater Memories that last all year
The present's always filled with presents Large, medium, and small Sometimes the most important things Aren't very big at all
What a party, there's so much to see here Can't believe you didn't want to be here You'd have a blast, I guarantee here This is the spirit of Hearth's Warming Eve
Cider's flowing, this is living Come on and feel the beat Life is better when you're giving Each time you do it feels so sweet
The present's always filled with presents So come on, open your eyes Spend time with ponies just like you And watch your spirits rise
The present's always filled with presents Take a look around The reason for the holiday Is quite easily found
Yes, the reason for the holiday Is quite easily found And the reason is to be with your friends!
__________
Наш исходный перевод (с Princess_of_Uranus):
Посмотри-ка ты вокруг, приятель: Запахи попробуй-ка, впитать ты, Сердце поскорей открой, окружит Нас с тобою магия очага.
Вот всё, что нам дарует счастье: Малышей веселие: Дай игрушку и обьятье – На весь год волнение.
Подарочки полны подарков: Мал, в меру, и большой – Бывает, самый важный дар Он меньше нас с тобой.
Что за вечеринка тут, смотри же: Здесь ты не хотела быть, но вижу, Оторваться можно тут по полной, И вот что значит наш дух очага.
Сидр льётся, жизнь несётся – Давай, почувствуй бит. Ведь приятнее живётся, Когда всё делаешь для других!
Подарочки хранят подарки, Открой же пошире глаза, Тусуйся с пони прям как ты – И вот твой дух воспрял!
В подарочках всегда подарки, Посмотри кругом – Празднику причину мы Легко с тобой найдем.
Да, для праздника причину мы Легко с тобой найдем, И причина – лишь быть вместе друзьям!
Everypony has times in their lives When their hearts are filled with doubt Frustration builds up inside And it makes you want to shout
But if you just take that first step The next one will appear And you find you can walk, then run Then fly…! Into the stratosphere
You've got to give it your best So you can pass the test Give it everything that you've got
And we know you can win You just have to begin Have to give it your very best shot
There are times that you want to give up When you think that you can't go on But if you fight through with all of your might You will find that you can't go wrong That you could do it all along
Everypony has times in their lives When their hearts are filled with doubt But if you just give it your all You'll start to work it out
And I know I can't give up too soon Get myself in the zone And I find I can walk, then run Then fly…!
I can do it on my own You can do it on your own I can do it on my own I can do it on my own
__________
Наш опубликованный перевод (с Princess_of_Uranus):
Каждый пони миг в жизни видал – Что в сомненьях сердца часть, Тревогу не обуздал И уже готов кричать!
Но стоит лишь сделать шажок – Как следующий грядёт, Ты идёшь и бежишь, прыжок, Полёт!.. В небо тебя несёт!
Напомнить гордо хочу: Всё тебе по плечу, Лучше всех мастерство покажи!
Знаем – ты победишь, Ты пройдёшь, лишь начни, Просто приложи больше ты сил!
Может сдаться совсем и пора: Трудно встать да идти вперёд Но стоит только чуть-чуть поднажать, Превзойти сил своих порог – Дела закончить сам бы смог!
В каждой жизни пусть есть времена И колеблется душа, Но посвяти в целом себя – Всё сдюжишь не спеша.
Отступать я уж нет, не хочу – А войду весь во вкус. И уже я хожу, бегу, Лечу!
Я сделать всё и сам смогу! Всё по силам впредь ему! Делать всё я сам могу, Всё сумею, всё смогу.
Would you say I'm a hero Glorious and brave If I told something You wouldn't believe?
That sometimes I'm scared And I can make mistakes And I'm not so heroic, it seems
But if day can turn to night And the darkness turn to light Then why can't we imagine a changeling can change?
No two ponies are exactly the same No two snowflakes ever match their design
And I thought I was strong But I was nothing but wrong When I forgot to be friendly and kind
But if day can turn to night And the darkness turn to light Then why can't we imagine a changeling can change?
Would you say I'm a hero Glorious and brave If I told something You wouldn't believe?
This changeling, it seems Knows the real me And would stay by my side 'til the end
So if day can turn to night And the darkness turn to light Then why can't we imagine Just, why can't we imagine Then why can't we imagine A changeling can change?
__________
Наш опубликованный перевод (с Princess_of_Uranus и grimnir11):
Я герой, говорите, Доблестный храбрец… Образ лишь – поймите, Притворству конец:
Порою боюсь, С ошибками учусь – Не таким уж героем кажусь…
Даже день сменяет ночь, Но и мрак свет гонит прочь – Так что ж нельзя нам образ, Проверить, хоть раз.
Ведь не могут пони в точь совпадать, И снежинок форму не угадать.
Думал, силы нашёл, Только друга подвёл… И позабыл доброту сберегать.
Даже ночь сменяет день, Или свет прогонит тень… Пора бы всем увидеть Соседа ясней.
Я герой, говорите, Доблестный храбрец… Образ лишь – поймите, Притворству конец:
И друг мой сполна Понял, кто же я, Но остался со мной до конца!
Если день сменяет ночь, Отгоняя тени прочь – Луч дружбы нам укажет, И правды путь покажет, И перевертыш сможет Мир перевернуть?
__________
~Даже снежинки не получается такими, какие задуманы.
Иф дэдей кен тёрн ту на-а-айт, Эн дэдаркнэс торн ту ла-а-айт, Бат айвсты-ы-ыл Гят дэблю-ю-юс Фо-о ю-ю-ю.
Эх. Мне кажется, нужно что-то поменять в самом устройстве работы с текстами, хотя даже я это сделать неоднократно пытался. Проблема в том, что меня-то и устраивает вот так вот «переводить на форуме», когда основные посты содержат правки текста, а последующие – правки к ним, и так далее. В итоге эти сорок страниц и набежали. И тут ничего сделать нельзя.
Вот явно же, инструмент должен быть походим, но другим. Вот чисто например: посты (вернее, их абзацы), на которые был дан кем-то ответ – должны выделяться цветом, становиться ссылкой… Чтобы время жизни одного кусочка текста можно было легко проследить, чтобы сразу было видно, что висит, что требует внимания, и что уже рассмотрено. Но я понимаю, что это нереализуемо. Тем более, создавать новый инструмент работы – вообще не вариант ну никак. Точно так же наше Хранилище не показало себя как удобный помощник процесса перевода – да, мы там хранили тексты. Но собирали мы их руками, заливали руками, создавали ТУТ. Идея обсуждений вКонтакте тоже провалилась. Вместо новых идей, мы кажется, получили только новое поле битвы, где за свои варианты фраз бороться надо уже не друг с другом, а с мало что понимающим левым народом, чьё мнение нам как бы формально и важно, но как мне помнится, не устроило.
Ха, ещё можно попробовать перенести что-нибудь в «пад». Уж в этом опыт у меня есть… Но нет, основные наши тексты туда как-то не особо полезно скидывать. Хотя из этого и может что-то получиться. Опять же, это просто инструмент. И им нужно уметь пользоваться по назначению. Есть разница между чатом стиля «двач», комментариями вКонтакте или конференциями в Телеграмме, нашим форумом, системой Issue гугль-кода, форк-бранч-пулл того же Гитхаба, голосовыми чатами Скайпа или Тимспика, и падом. – Каждое из этого создавалось для решения определённых задач, и НИЧЕГО нам нормально не подходит для нашей. Вести переписки на 20 000 символов где-нибудь вКонтакте или паде – ещё менее эффективно, чем здесь (скажем, отсутствием адекватного цитирования), но пад имеет преимущество в виде возможности редактирования общего документа своим цветом, Телеграмм/вКонтакте – доступностью, Гихаб – слиянием, но лишь если «продукт» не требует обсуждений, Тимспик – способностью быстро придти к решению конкретной задачи, прямо за несколько минут, а не днями и неделями при общении на форуме.
Да я и сам не понимаю, что за философию я тут развожу! Я лишь вижу, что что-то не так. Допустим, я заглянул в новенькую соседнюю тему по переводу субтитров к видео. ПИПЕЦ!
Там ж дохрена текста. И если переводить его на форуме – к новому году у нас будет либо овер-10 страниц и никакой надежды на приближающийся конец, либо просто какие-то наработки, которые все уже бросили, но которые в принципе можно релизнуть и будет не то чтобы совсем плохо. Мёртвый путь, даже я не могу представить, ЧТО мне придётся сделать. Нет, ну допустим, я захочу ответить (со мной такой бывает иногда). Для этого я потрачу один-три дня, чтобы последовательно собирать все цитаты, разметить документ, вписать все мои правки и пояснить их. Допустим, я отвечу. Далее, через пару кто-нибудь создаёт ответный пост, с цитатами моих правок (а для прослеживания цепочки придётся уже делать поиск по странице – это ещё если они на одной окажутся), а я должен в следующий раз и на его сообщение ответить, и продолжить ковырять первоначальный текст, полноценный ответ на который явно в предыдущее сообщение поместиться не мог. Ага, а далее появляется какая-нибудь Томас, которая расфигачит за денёк-другой ВСЕ тексты в десяти постах – и как бы всё, я умер. Не потому что не хочу, а потому что не могу. Это как тащить пианино на двенадцатый этаж – сколько бы я его не любил, и как бы мне не стало потом приятно на нём играть – я просто ЗАМАНАЛСЯ.
Конкретно эту тему, в смысле, задумку, с переводами видео – надо тащить в пад. Потому что больше некуда. Если она должна выжить – ей придётся покинуть форум, состоящий из зыбучего песка.
Пример, конечно, дерзкий. И у нас такого хаоса не будет никогда. Но суть ясна – исходный текст представляет себя блокнот белого цвета, а все авторы-переводчики – имеют свои цвета, которыми дописывают к нему всё, что пожелают. Основной принцип перевода для субтитров – одна строка это одна реплика. Переводы записываются напротив неё (длинные строки переносятся, но номер строки остаётся одним). Комментарии – туда же, праве. Ответы на них – туда. И так сколько угодно. Первый же плюс в том, что обсуждения одной строки находятся физически на ней, всё сразу видно. Всякие условности вроде оформления комментарием курсовом, итогового жирным или выбеленным, ошибок подчёркиванием и так далее – второстепенны.
Каждый может делать что угодно (но во-первых, на пад можно поставить пароль против левых людей, и плюс защиту на «зарегистрированный e-mail аккаунт» – против наших, но не своих), например – удалить весь текст. Но как видно, сохраняется таймслайдер – временная шкала, кто, что и когда делал, с возможностью выкопировать оттуда текст. Впрочем, если вся работа сведётся к ковырянию в истории – то это ничем не лучше листания наших форумных страниц.
Пад, когда является единственным инструментом – используется и как форум ( http://ponypad.etherpad.svimik.com/guidelines ), но это костыль. Почти такой же, как форумные вики страницы ( http://mlp.wikia.com/wiki/Forum:Speculation/Animation/Season_three ), чей ужас заключается в том, что новое сообщение – это новое изменение, а это – новая ревизия, требующая и краткое описание, и сохраняющаяся в лог с возможностью отката, не говоря уже о куче правил наподобие «не редактируйте чужие комментарии» (за нарушение которого этой ревизии дают откат, создавая новую с пометкой о нарушении) или «всегда подписывайте свои сообщения» (что часто плодит ревизии, потому что забыть очень легко, а исправить – значит отредактировать ещё раз; и уж тем более это получасовая задача – найти автора какого-нибудь старого поста, который забыл подписаться, чтобы по правилам хорошего тона, восстановить его же подпись – задача, потому что адекватного поиска «в какой ревизии появился этот текст» там нет, остаётся лишь тыкать наугад. Пока не осознаешь, что страница была получена после слияния или разделения другой…)
Как я уже сказал, переходить в пад для перевода основных реплик Spyro – идея не очень. Там в текстах – связи, там обсуждения, там важна последовательность диалога в цитировании, а не просто один комментарий к одной строчке. Насчёт атласа, яиц или ещё чего-нибудь – не знаю.
Но переводы видео обзоров и интервью лучше делать в паде. На форум можно либо копировать завершённые куски, либо обсуждать что-то, не повязанное на каждом конкретном кусочке текста.
Хотя, Piratenpad – не лучший вариант. На самом деле, владелец сервера svimik.com вполне себе не против, что его пады использовались и другими. Я тут даже аккаунтик нам создал: http://spyro3-rus.etherpad.svimik.com/ (вон в тот тестовый пад тоже можете тыкать без ограничений)
Тут просто чуть побольше фишек, чем в Пиратенпаде, но и есть небольшой риск того, что сервер не вечен.
ЦитатаSerlutin
aleksusklim, люди даже вон в гугл таблицах работать не хотят, а они легче, чем любой пад. Зашёл и пиши себе.
Цитата
а они легче, чем любой пад.
Я бы так не сказал.
Цитатаalteya
Что касается организации переводов. Как мне кажется, было бы неплохо если бы это в конечном счете выглядело примерно как мои сборки обсуждений: реплика - все коменты и варианты к реплике строго под этой репликой. Далее следующая реплика и коменты к ней (где каждый автор своего цвета, к примеру). Возможно, это как-кто в табличном виде, где например будут идти отдельной колонкой новые версии (только то что будет в тексте), и параллельно - всевозможные пояснения, ссылки, рассуждения. И возможность автоматически свернуть все промежуточные варианты, получив текущую версию всего текста.
Цитатаalteya
И чтобы все было просто как детская лопатка. Без всяких зубодробительных выстраиваний и вывешиваний тегов и прочей мути (иначе ноги моей там не будет).
Но что касается Spyro 3 - то думаю, поздновато изобретать велосипед, поезд уже ушел. Осталось не так уж много, и проще добить это как есть. Сосредоточившись на самой работе, а не на умозрительных изысканиях способа ее организации.
реплика - все коменты и варианты к реплике строго под этой репликой. Далее следующая реплика и коменты к ней (где каждый автор своего цвета, к примеру).
Вроде как, мой набросок оффлайн-пада подойдёт.
Цитатаalteya
И возможность автоматически свернуть все промежуточные варианты, получив текущую версию всего текста.
Ну некая поддержка этого у меня есть. Это как бы стиль «скрытый текст», сворачивающийся в «▉». Правда глобального раскрытия нет (но можно сделать), есть построчное, то есть визуально раскрывает всё скрытое на строке с курсором. Но если обсуждения построчные – тут нужен блок типа спойлера. Надо подумать.
Цитатаalteya
Без всяких зубодробительных выстраиваний и вывешиваний тегов и прочей мути.
Более того, если я адекватно привяжу экспорт в ВВ-коды, то из пада можно будет в любой момент вставить часть текста на форум без потери форматирования. И обратно тоже, надеюсь.
Цитатаalteya
Но что касается Spyro 3 - то думаю, поздновато изобретать велосипед, поезд уже ушел.
Вот сейчас у нас опять обсуждения паравозом поехали. Уже ваще не понятно, даже тут – на что НИЖЕ были даны ответы, а на что нет. И я именно про фразы. Да, основное обсуждение, разумеется, нужно вести тут. Но сами правки – да блин…
Причём, если будет прямое выкопирование (потенциально опционально прямо в этот визуальный редактор) – то без проблем можно будет вставлять свои правки в пад, а комментировать их (цитируя из пада) – тут. Тогда: – мы не потеряем привычный ход обсуждения фраз (то есть пад не заберёт нисколько от форума) – все реплики и все комментарии к фразам будут собираться в паде (как бы как копии, да…) – по идее, на это не будет уходить ТАК много времени, как например попытка скопировать кусок гугль-таблицы на форум, или внести разноцветные обсуждения на вики-страницу гугль-кода или в сам репозиторий.
Я представляю это так: 1) Синхронизировал свой пад с мастером-репозиторием (гитхаб, всё сведётся к одной кнопке; но сам транспорт на данный момент ещё пока не настроен) 2) Внёс в пад ЛЮБЫЕ изменения, комментарии, выбор финальных вариантов (думаю, условимся так, что тот, кто вносит правку – либо сам же и меняет ИТОГОВЫЙ вариант непосредственно, либо же, если исходная фраза явно чья-то личная – как у нас сейчас, по сути – оставляет правку, и её внесёт уже автор, если согласен). Варианты будут накапливаться не только тем, кто сейчас «держит» все данные об уровне (как steeldragon на гугль-коде, или как alteya сейчас: «внесла» – куда внесла? Понятно, что «себе», но это опять же нудная и неблагодарная работа – копипастить правки других, следить за ними и комментировать успевать. Я бы не смог. Вернее, я и не смог). 3) Синхронизировал пад ещё раз. Он преобразится: будут объединены текущие вносимые изменения, и изменения, сделанные другими за всё это время (которое, разумеется, может быть сколь угодно долгим). 4) Выкопировал куски из пада в свой пост на форуме, чтобы НЕ ТУТ предлагать правку, а просто констатировать факт её внесения. Тогда не придётся собирать вручную, потому что всё уже будет собрано там. 5) Ну и история. Собственная история изменений технически сохраняется подробнее, а глобальная – по непосредственным коммитам-синхронизациям; просмотр истории тоже оффлайновый. Автосохранение также имеет место: думаю, сделаю при потере фокуса у пада, может быть по таймауту (минута или полминуты) тоже можно. (Для справки: в онлайн паде автосохранение происходит каждые 500 миллисекунд!)
То есть ещё раз. При написании очередного поста в Ворде (и я, вообще говоря, не завидую тем, кто делает это не в нём) параллельно должен быть открыть мой оффлайн-пад. По сути это почти такой же Word, на вид. Правки – туда, копии – сюда. Обсуждения – сюда. Итоговые на данный момнет варианты – туда. Время и программы ни к чему не обязывают. Интернет не нужен, быстрый процессор тоже: пад, после превращения его в оффлайн, стал значительно меньше тормозить.
Однако, работать можно будет толкьо под Windows (любой версии), ну или с очень болшой натяжкой – под Linux. На планшетах или андроидах эта вещь не пойдёт (да, в отличие от гугль-доков, которые онлайн).
Так, чего я такой голословный. У меня же есть рабочая версия «онлайн-пада», прямо из которой я делаю оффлайн: http://klimaleksus.narod.ru/Files/D/TDTPad.rar (28 Мб; эта база всё равно понадобится для оффлайн-сборки) – он чуть плоховато настроен, но должен работать. Если я не ошибаюсь, достаточно запустить START.BAT, а потом зайти браузером на http://127.0.0.1:9001/ (или какой там порт в settings.json прописан…) Разумеется, сейчас я призываю оценить не его оффайновость или коллаборейт рантайм эдитинг, а чисто сам интерфейс (дизайн, особенно панель инструментов – параша, это да. Но такой был!..) и юзабилити. Это пока ещё тормозная версия (низкая отзывчивость на быстрое редактирование), и малое количество видов форматирования (скрытие текста «Н» – кстати, есть: нажатие без выделения – раскрытие всего на текущей строке)
Цитатаalteya
Сосредоточившись на самой работе, а не на умозрительных изысканиях способа ее организации.
Может быть… Но я уже впарился, и не остановлюсь. Жаль, что каждый раз, когда я исправляю очередную строчку с мыслью «всё, релиз!» – она опять и опять не работает. Уже несколько дней.
Эй, steeldragon! Короче, Git. У меня есть три файла: checkout.bat %name% commit.bat %name% %file% done.bat %error%
, где параметры %name% – имя папки текущего документа (у меня каждый «документ» = директория), %file% – имя файла для внесения в репозиторий, %error% – код ошибки 0/1/2. Короче, чё надо.
«checkout.bat» запускается первым, и нужно, чтобы Git выкачал свежую версию нужной папки репозитория, и положил её в каталог .\%name%\ рядом с этим батником. По сути, ему нужно просто дописать сюда новые файлы, ибо старые никогда не будут ни обновляться, ни удаляться (ну кроме форс-мажора, когда всё летит в трубу, и нужно фиксить руками). Когда Гит закончит обновлять (успехом или неудачей, не важно; хотя если можно, то насчёт этого тоже чё-нить придумаем, хотя бы окошко пользователю), выполнение .bat файла должно прекратиться (пад лочится и ждёт завершения cmd.exe).
Теперь, если пад желает внести новый файл в репозиторий, он практически сразу запускает «commit.bat» (ну если ему пока нечего коммитить, то выполнится «done.bat» и всё). Однако, он создаёт файлик «failed.tmp», но ложит своё целевое обновление (всегда едиснтвенный файл) в папку .\%name%\%file% (которую только что чекаутил). Гит обязуется попытаться внести этот файл под контроль как ревизию в репозиторий. Причём очень важно, чтобы хоть при малейшей ошибке (скажем, если за каким-то фигом этот файл уже есть в хранилище, хотя мы только что чекаутили) скрипт завершился. Но когда всё прошло успешно, и новый файл ТОЧНО сохранился в мастер-репозитории – скрипт удаляет «failed.tmp» перед завершением. Тогда пад поймёт, что коммит прошёл, и не будет удалять свой %file%, а оставит его и произведёт локальное слияние.
По идее, «done.bat» и не нужен как таковой, но он гарантированно выполняется всегда (если пад, конечно, тупо не грохнется по дороге), и там например, можно сделать «разблокировку» репозитория (если такое вообще возможно), а блокировку ставить в «checkout.bat». Код ошибки – 0 если всё хорошо, 1 – если что-то не сошлось в самом паде (напрмиер при попытке синхронизировать _разные_ документы), и 2 – если «commit.bat» не стёр «failed.tmp».
Ну и всё. Мне нужны параметры Git, которые будут выполнять эти операции автоматически. То есть все передаваемые пароли, настройки, пути – всё это нужно прописывать в батниках, чтобы синхронизация и коммиты были неинтерактивными (но при ошибках лог лишним не будет).
Сейчас я тестил просто на локальной сети – в батниках у меня тупо команда replace (в данной ситуации лучше, чем copy), читающая и копирующая в/из общей сетевой папки. Работает. Теперь надо гит… (все запросы – синхронные, скрипт должен ждать завершения операций, а пад на это время блокируется на редактирование).
Копипащу сюда мысли о моей идее насчёт специальной версии пада, часть из недавней переписки с администратором сервера svimik.com:
И в этой связи у меня вопрос начёт пада, вернее, его ace-редактора и changeset алгоритма слияния.
Можно ли сделать «оффлайн-пад»? Допустим, берём Git. Хочу, чтобы каждый участник мог коммитить изменения.
Но при этом хочу, чтобы они работали в паде, оффлайн. Все изменения, сделанные локально – сохраняются как один такой нефиговый ченджсет. Потом приложение качает текущую общую ревизию, и само же применяет к нему свой чейнджсет, зная при этом во-первых, старую версию, от которой шло редактирование; и новые чейнджсеты, которые другие люди успели запушить в репозиторий, их можно хранить хоть как новые файлы, а старые даже не менять – ещё и от конфликтов избавимся; а наличие всей истории локально у всех (это же система контроля версий, у всех на руках все данные) сделает даже таймслайдер локальным!
Получается, каждый и клиент и сервер одновременно, а Git – транспорт. Я представляю это себе так, что человек пишет-пишет что-то в оффлайн-пад, а потом нажимает «синхронизировать». И тут в документе появляются правки всех остальных, а его собственные – уходят туда, откуда их получат другие.
Итого, если синхронизировать до и после активной работы (учитывая низкую вероятность того, что кто-либо другой вообще этот документ тронет), и при этом условиться не менять построчную структуру документа – то новые правки будут появляться только как добавки к строкам, или их изменения. И по идее, написанный на определённой строке текст – никуда не скакнёт. Равно как и если многие допишут что-то в одну строку – их текст появится там цельным куском.
Как думаете, сильно код пада придётся перекраивать?
Есть ещё вариант, перекроить только сервер, сделав из него локальный, который правит файлы так, как я описал. А клиентская часть как обычно. Просто при синхронизации сервер передаст клиенту сразу много всего.
ЦитатаSviMik
А в чём смысл? Фича пада в групповой работе.
Так нет, это будет уже не пад. Приложение для другой цели.
Ну, я предполагал нечто вроде плагина к браузерам, имеющее доступ к файловой системе.
Всегда можно делать несколько синхронизаций подряд, чтобы что-то поправить, что криво легло. Нужно просто оставлять документ «неиспорченным». Тогда, если кто-то внесёт свои оффлайновые правки в документ, и они лягут чуть-криво – он тут же поправит их. И тогда мердж от другого участника (относительно исходной версии) должен лечь не более криво, чем первый коммит предыдущего участника.
Так вот!
Первый способ – суррогат, конечно, но по идее должен сработать. Ломаем etherpad-lite, найдя в нём значение таймаута для постинга своих изменений на сервер. Там же как работает: клиент пишет в документ, а скрипт через каждые полсекунды (вроде как) – пытается постануть его изменения на сервер. Сервер в ответ пришлёт ему «окей, бро», а всем остальным – новые перевычесленные для каждого чейнждсеты, чтобы те увидели его изменения. Если постинг не удался – скрипт всё ещё пытается какое-то время сделать это.
Я предполагаю, что если сломать таймер, то клиенты будут (потенциально) нормально принимать чужие правки в реальном времени, а постить свои – нет. Кстати, у изменений сохраняется ревизия, от которой сделаны эти правки.
Теперь добавляем кнопку «sync», заставляющую таймер постинга обнулиться, и коммитнуть изменения на сервер. Их сразу все увидят, потому что приём от сервера идёт в реальном времени.
Это не то, что я хочу, но по ощущениям – именно оно.
Вот это всё описывает, как работает чейнджсет. Математика такова, что:
1) если есть документ Д, и изменение И, то мы получим некий новый документ Д1: Д → (И) → Д1.
2) Если есть Д1 и Д2, а нам нужен результирующий документ Р, то алгоритм найдёт нам такие изменения И1 и И2, что: Д1 → (И1) → Р Д2 → (И2) → Р
3) Если есть общий документ Д (сам являющийся набором чейнджсетов от контрольной точки – например, пустого документа), и у двух людей есть свои изменения И1 и И2, приводящие к Д1 и Д2 соответственно, то обменявщись информацией о них, можно получить такие изменения-мерджи М12 и М21, что они приведут обоих людей к результирующему документу Р: Д → (И1) → Д1 → (М12) → Р Д → (И2) → Д2 → (М21) → Р
Так вот. Представим, что пользователь 1 – это репозиторий, а 2 – коммитер. Коммтер изначально скачивает последнюю версию репозитория (всю цепочку) и считает её точкой отсчёта (Д на последней схеме). Теперь он редактирует свой документ как хочет и сколько хочет, локально.
В момент синхронизации, его «браузер» выкачивает новые изменения с репозитория, и сравнивает данные. Если там вообще нет новых ревизий – идеально, просто сохраняем туда свой чейнджсет (суммарный всего того, что мы меняли). Но теперь, некий второй юзер, тоже внёсший свои правки в свою локальную копию репозитория, решил синхронизировать.
Его клиент-браузер (потому что «сервер» с мозгом в этой схеме вообще отсутствует, есть только глупое хранилище) выкачивает репозиторий и сравнивает. Видит, что начиная с какой-то ревизии пошло расхождение. Алгоритм рассчитывает М12 – это как превратить репозиторий в новую версию с его изменениями; и М21 – это как отобразить на собственном экране всё то, что писали другие в репозиторий ранее. Теперь М12 добавляется в хранилище и фиксируется, а М21 нужен просто для локального бесшовного обновления экрана (иначе пришлось бы перезаписать свои изменения тем, что было рассчитано для репозитория, и перезагрузить пад). Но клиент по факту отвергает собственные чейнджесеты чтобы содержимое локального хранилища совпало с репозиторием – получается сначала чекаут в новую папку (или не нужно, если своё состояние запомнить отдельно) и реверт своих, потом чекаут своих, коммит туда слитых чейнджсетов, и пуш в репозиторий.
Также, схема вполне позволяет в гитовском стиле синхронизироваться не с центорм, а между собой. Тогда инициатор синха пушит в репозиторий коллеги мердж своих чейнджсетов, для себя юзает обратный мердж, и обе рабочие копии становятся синхронными. Если кто-то захочет синхронизироваться с мастером – там отсчёт будет идти от номера той ревизии, которая у их общая. То есть эти слитые изменения двух чуваков как собственное единое изменение уходят одной ревизией на сервер.
Ага, вижу проблему. Когда второй из них тоже синхронётся с мастером – будет конфликт, ведь «общая» ревизия-то у них старая, но при этом новые изменения по факту уже давно на сервере. Видимо, тут нужна система хеширования, чтобы брать максимальную из ревизий, хеш контента которой соответствует лучшему хешу на клиенте. В данном случае на сервере будет старая версия, и новая версия со слитыми изменениями двух участников (которые пушнул один из них без ведома второго). А второй (он тоже их имеет, ведь они с первым синхронизировались ранее) при попытке синхронизировать какие-то ещё сверх-новые изменения – должен делать это не от старой ревизии (несмотря на то, что они отлично совпадают), а новой. Но никак, крове сверки хэша содержимого, он этого понять не может. (Ну может можно как-то там сохранить, чтобы было видно, что его авторство указано в ревизиях, но на первый взгляд с хешем проще).
Короче, что это даст. Можно редактировать пад в любой момент, и сохранять изменения на сервере в любой момент. Копаться в истории без сервера. Возможность работать вообще без центра с мастером.
Чат не предполагается. Цвета авторов – может быть, не знаю. Там наворотить уже не такая проблема.
Технически, я вижу каждый документ-пад как ПАПКУ, в которой лежит куча пронумерованных файлов – это чейнджсеты ревизий. Однажды добавленный в «мастер» (любой, в кого мы пушим) файл больше НИКОГДА не изменяется. Все редактирования пада превращаются в новые файлы ревизий. Однако, когда мы пушим в мастер – НАШ репозиторий теряет сколько-то верхних ревизий, и получает их новые варианты с мастера (включая созданным им новый файл), удаляя свои. Тем не менее, алгоритм гарантирует, что по факту его логические изменения текста сохраняются (это типо как уже стало умножение «A*В», но мы из состояния «А» сделали «А*С», а при слиянии для нашего экрана получаем «А*С*В», но в оба репозитория мы положим «А*В*С», по факту откатывая своё «А*С» до «А», а потом обновляя уже сделанное «*С» с сервера как «*В*С»).
Тогда, Git будет норм вариантом, и конфликты решать не потребуется. Допустим, у клиента две копии репозитория – одна для работы, другая для слияния.
Он меняет рабочую. При синхронизации – checkout на вторую. Потом программа («браузер») анализирует эти два своих репозитория, высчитывая объединённые изменния. Коммитит новую ревизию в репозиторий слияния, затем пушит его на сервер. Ревертит свою собственную рабочую копию, и производит чекаут с сервера. И всё снова синхронизировано.
Ну как, норм идея? По алгоритму вроде окей. Непонятно, с какой стороны подходить к реализации: начать вырезать куски из имеющегося пада, или проще собирать по кускам собственный…
*UPD*
С одной стороны, хочется работать с библиотекой Changeset напрямую и сразу правильно, а с другой – сам пад как есть уже ахрененен, и на первый взгляд проще всего – как-нибудь обойти стороной непосредственное изменение его рабочего кода, а сменить интерфейс и протокол общения с сервером…
чем дольше народ будет править одно и то же место без синхронизации - тем хуже потом будет.
Так нет же!
Редактирование = новая ревизия. Каждая ревизия = новый файл. Старые файлы никогда не редактируются. Тот, КУДА пушают – не меняет содержимое имеющихся файлов. Тот, КТО пушает – удаляет у себя часть файлов и заменяет их новыми.
Поскольку, мастер-репозиторий САМ не вносит правки, не пушит никому по своей воле, а лишь принимает изменения других – то на нём конфликты не возникнут никогда. Потому что каждый клиент будет перестраивать свою рабочую копию так, чтобы менялось «задним числом» только у него, а на мастере – всё линейно.
Гипотетический конфликт может возникнуть в сам момент двухэтапной синхронизации, если два клиента физически одновременно попытаются сделать коммит и обратный чекаут, но скорее всего, Гит на этот счёт должен иметь какой-то иной механизм наподобие кратковременной блокировки целевого репозитория, пока один клиент не закончит свой синх (а там ж просто файлы туда-сюда перекопировать).
Однако точности ради, я тут прикинул, и кажется – нельзя будет сливать ревизии разных людей в объединённый файл различий. Их придётся всё равно хранить отдельными файликами (что не проблема, в принципе). Потому что например есть три участника. Изначально у них всех документ условно равен 0. Теперь каждый их них делает свой документ соответственно 01, 02, 03, Первый синхронизируется со вторым. У них становится 021. Второй синхронизируется с третьим: 0321 (потому что идёт «0(21)» с «0(3)», и «21» дописывается третьему в конец). Теперь первый хочет синхронизироваться с третьим. Имеем «021» к уже «0321». Изначальный алгоритм, вычисляющий позицию слияния по номеру ревизии, выдал бы «0(21)» к «0(321)» равно «032121», что неверно. Вместо этого, видя всю цепочку изменений «0321» и свою «021» он должен по хешам каждого файла понять, что единственные изменения, которые нужны – получить эту «3» себе, а на целевом ничего не менять, там всё есть. По идее, алгоритм changeset это позволяет (там можно даже отменить любую ревизию в цепочке изменений, путём правильного пересчёта «будущего» от неё и вперёд). Неочевидно только, как это запрограммировать, чтобы универсально было. Для полноты примера покажу, что будет, если это третий (или второй) хочет синхронизироваться с первым: Имеем «0321» к «021». Мы вычисляем такой чейнджсет «4», чтобы он при добавлении к «021» дал то же, что даёт «0321». Каким образом реализуется вызов этой операции, пока не знаю. Знаю, что есть понятие «инверсный чейнджсет»…
Так, стоп. Ерунду говрю. Соединение «01» и «02» даёт не «021», а «021'» (это «1'» – «один-штрих»). Это не тот же самый чейнджсет. Это я больше подразумевал эффективные _правки_ участников. Да, тут надо ещё подумать над децентрализованным синхом, но он реализуем.
Надо пока отсечь эту головную боль, и хотя бы добиться только централизованных операций с мастер-репозиторием. Там я уж точно всё продумал.
Конец копипасты.
Мои вопросы адресованы не нам, разумеется. Я привёл этот текст только ради того, чтобы все просто оценили саму идею – как на ваш взгляд, это хорошо? Это удобно? Или это нафиг не нужно?
ЦитатаSerlutin
Так, ребят, Алексей натолкнул меня на одну мысль. Переводить сразу все видео в одной теме будет явно сложно. Но с падом мне пока разбираться лень. Поэтому вот одна идея. Гугл Таблицы. Всё просто переходите по ссылке. И переводите. Даже регистрироваться не надо. Единственная проблема, что они слегка тормозят.
ЦитатаТампли
aleksusklim, признаться честно, не совсем до конца поняла тонкости, но уловила общую суть. Как по мне, идея действительно замечательная! Да и позволила бы наконец полноценно организовать все наработки участников форума. Да, я считаю, что это - вполне удобный вариант для переводчиков. Было бы интересно посмотреть, каково оно на практике.
Ну слава богу. Если что, я пару раз прочитал и даже попытался вникнуть.
Цитатаaleksusklim
…в очень глубокой отладке… (Offline pad is actually working!..)
ЦитатаDragonFlight
Не-е-ет!..
Цитатаaleksusklim
Чёртов пад отвлёк даже от неё.
ЦитатаDragonFlight
Не-е-ет!!..
Цитатаaleksusklim
Я привёл этот текст только ради того, чтобы все просто оценили саму идею – как на ваш взгляд, это хорошо? Это удобно? Или это нафиг не нужно?
ЦитатаDragonFlight
Меня удивляет одно: вы ради приличия спросили? Всё равно же сделаете, если захотите. На вашем месте я бы направил энергию в более рациональное русло. Но у вас в голове работает другая система приоритетов, и вы работаете на идею, а не на результат, это давно известно. Дело ваше. Чем вы проаргументируете, что пад удобнее Google таблиц? Создание такой программы именно для нашего перевода вообще обосновано? Потому что я не вижу смысла заставлять всех участников разбираться в длинных инструкциях и тем более с техническими заморочками, если есть вариант быстрее и проще. Поэтому лично я (за других не говорю) не притронусь к вашей программе, если вы не гарантируете, что мне не придётся взрывать над ней мозг как это обычно бывает.
ЦитатаDragonFlight
Чем вы проаргументируете, что пад удобнее Google таблиц?
Он оффлайновый.
Следующий вопрос?
ЦитатаDragonFlight
Создание такой программы именно для нашего перевода вообще обосновано?
Что вы понимаете под «созданием» в данном контексте?
ЦитатаDragonFlight
разбираться в длинных инструкциях
Как я понимаю, выложенный мной основной движок в архиве TDTPad.rar вы даже не попытались запустить.
ЦитатаDragonFlight
если есть вариант быстрее и проще
translate.google.com
ЦитатаDragonFlight
Меня удивляет одно: вы ради приличия спросили?
На тот момент я ещё не был уверен, что сумею реализовать основную часть алгоритма так, чтобы она работала как я описал.
ЦитатаDragonFlight
aleksusklim, воу. Я уловил в вашем посте агрессивные интонации. И если вы в моём – тоже, то прошу прощения: это не нарочно. Я не собираюсь раздувать здесь конфликты (поверьте, меня просто писанина на форум изматывает). А потому постараюсь сейчас объяснить, что имел в виду.
ЦитатаDragonFlight
ЦитатаDragonFlight
Не-е-ет!.. Не-е-ет!!..
В то время я относился к паду как к задумке исключительно для и из-за темы для субтитров, так как вы отписались именно здесь и дали мне основание это предполагать. И я чувствовал в какой-то степени свою вину за то, что отвлёк вас созданием этого обсуждения второстепенной важности, нагрузил и до того переполненный "стек" ваших заданий.
Но, судя по всему, я был не прав, и вы используете пад универсально. В других темах я вообще не вякаю: решите перейти в пад, куда я-то денусь?
Цитатаaleksusklim
Что вы понимаете под «созданием» в данном контексте?
ЦитатаDragonFlight
1) Вложенные время и усилия, которые можно было потратить на давно намеченные цели, 2) новое рабочее пространство, которое может быть даже и не нужно, учитывая объём и глубину текста (это не игра) и количество вовлечённых участников (я не думаю, что их будет слишком много). Всё же понадобится некоторое время, чтобы привыкнуть к паду, в то время как в Гугл таблицах осваиваться не надо (кто ещё со мной не согласен?). Вообще, Альтея сказала как нельзя лучше:
Цитата
Сосредоточившись на самой работе, а не на умозрительных изысканиях способа ее организации.
Цитатаaleksusklim
Как я понимаю, выложенный мной основной движок в архиве TDTPad.rar вы даже не попытались запустить.
ЦитатаDragonFlight
На тот момент – нет. Уже давно в моих планах после ответа в теме Spyro 3 была эта ветвь, и на пару дней я здесь застрял. Не, я пролистал глазами новые ответы в той теме, но ваши посты с описанием своих разработок – это не то, во что можно вникнуть на расслабоне! Даже порой кажется, что высшую математику вкурить легче! Как студент факультета прикладной математики говорю (аж стыдно произносить). Поэтому кусок про пад я пропустил.
Но сейчас – да, попытался. START.BAT там, да? Ну, как бы вот. I'm done. (про "гарантировать", это именно про это было)
Цитатаaleksusklim
Следующий вопрос?
ЦитатаDragonFlight
По сути, чтобы поагитировать за преимущества пада, достаточно было привести свою же цитату:
Цитатаaleksusklim
Причём, если будет прямое выкопирование (потенциально опционально прямо в этот визуальный редактор) – то без проблем можно будет вставлять свои правки в пад, а комментировать их (цитируя из пада) – тут. Тогда: – мы не потеряем привычный ход обсуждения фраз (то есть пад не заберёт нисколько от форума) – все реплики и все комментарии к фразам будут собираться в паде (как бы как копии, да…) – по идее, на это не будет уходить ТАК много времени, как например попытка скопировать кусок гугль-таблицы на форум, или внести разноцветные обсуждения на вики-страницу гугль-кода или в сам репозиторий.
Цитатаaleksusklim
Время и программы ни к чему не обязывают. Интернет не нужен, быстрый процессор тоже: пад, после превращения его в оффлайн, стал значительно меньше тормозить.
Вариант оффлайн-пада я вижу отличным решением проблемы, сочетающим в себя одновремнно и достоинства Ворда (форматирование) и форума (в смысле, лёгкий перенос текста туда-сюда), и системы контроля версий
ЦитатаDragonFlight
Чем-то убедили, но не могу сказать, что совсем. Он-/оффлайн для меня не играет особой роли, но может быть кому-то это будет впрок.
Цитатаaleksusklim
translate.google.com
Способ обсуждения и правки текстов не влияет на качество переводов. Может, если только очень косвенно.
ЦитатаDragonFlight
---- Пожалуйста, не заставляйте меня больше так изгаляться. Давайте лучше работой заниматься.
– продолжение этого обсуждения из четырёх постов выше. Опять же, вопросы не нам. Просто текущий результат:
У-у, я завершил свой оффлайн-алгоритм! Осталось только интерфейс немного поправить, например – сделать выбор текущего репозитория.
О, а ещё я знаете что придумал – не «clear authorship colors», а «toggle»! Пусть будет кнопочка как «Bold», но другая, а её накладываемый CSS будет давать {background:transparent!important;} И там не нужно автоматические покрытие атрибутом нового вводимого текста – тогда экспириенс будет классический: свой текст всегда цветной, а такое «выбеливание» – делает выделенный кусок белым глобально. Но бонус в том, что сделав повторное выбеливание уже белого текста – в нём вернутся исходные авторские цвета! Почему я раньше до этого не додумался… (Кнопку очистки цветов вообще удалить можно, но если опять же рассматривать кастомизитрованного клиента – ну нет, там на этот счёт куча куда больше серьёзных дыр в безопасности. К тому же, для оффлайн пада единственным клиентом будет 127.0.0.1, а ему дозволяется всё.)
Ладно, вот что с оффлайн. Я хотел было собрать это именно как плагин, но там такая инвалидская система хуков (раз уж плагинная архитектура – так ВСЁ должно было реализоваться легко заменяемыми плагинами), и множество констант просто захардкожены, а переменные – сокрыты в замыканиях. Грёбаная инкапсуляция, публичные функции ущербны! Пришлось нагло менять ядро. Хоть я и старался ставить метки на изменённых строках, но по-моему там уже как бы всё, официальные обновления движка будут невозможны. И фиг с ними.
Итак, предполагаем, что в моём Паде одновременно может быть открыто несколько разных падов, но в каждом из них – не более одного клиента. Клиент-серверная часть считается единым целым (вплоть до того, что клиент может послать строку, а сервер сделает её eval). Кстати, как-то можно ли гарантированно закрыть Пад от внешних не локальных подключений? «Bind to localhost» будет достаточно?
Далее, клиент не шлёт на сервер все совершаемые в паде действия (я там флаг блокировки поставил). Также, не совершает дисконнект по свое воле, если ему кажется, что связь с сервером потеряна по таймауту.
Название (=идентификатор) каждого пада – не привязывается к имени документа в репозитории. Один и тот же документ может быть загружен в разные пады, и вот как это устроено (каждый раз под «сервер» я подразумеваю «локальный etherpad-сервер», а не целевой репозиторий; если я где-то говорю о «двух клиентах» – то это имеются в виду два разных клиента репозитория за разными локальными серверами)
На клиенте есть две основные операции, а на сервере – одна. Ну ещё, сервер обладает громадной функцией обработки «новых изменений» от клиента, которую в основном я и менял. Итак, первое что клиент может сделать – послать свои изменения на сервер, как он обычно это делает. Но не каждые полсекунды, а лишь когда окно фрейма редактора потеряем фокус.
Причём исходный алгоритм там шикарен!
Он сливаёт всё – ещё до отправки на сервер. Например, если написать «123», а потом стереть «2», то чейнджсет будет – «13». Тем более, что уж говорить о возможности отмены. Атрибуты тоже. Вообще, любые действия взаимообъединяются в минимальную и адекватную последовательность вставок и удалений. Не важно, насколько дико пользователь работает с текстом до синхронизации – все локальные изменения схлопываются ровно в то, что останется под конец. Удаление и отмена, вставка барахла и очистка его от мусора – всё это ни в истории, ни тем более в репозитории не сохранится.
Теперь, когда клиент посылает изменения на сервер – он блокирует пад на редактирование (но так, чтобы потом суметь разблокировать после получения ответа). Сервер делает всё как обычно (вносит чейнджсет в базу), но при этом сохраняет копию сообщения от клиента в очередной файл в папку, имя которой такое же, как у пада.
То есть ещё раз. Есть, скажем, папка .\PADS\. Там будут паки .\PADS\mypad1\ , .\PADS\test\ – где «mypad1» и «test» – пады, открытые в браузере. В этих папках – файлы с именами «00000000», «00000001»… (десятичные – оказывается, числа в base36 неправильно сортируются Проводником). Каждый файл – сообщение от клиента, отталкивающееся от ревизии с этим номером. То есть начинается всё с пустого пада (именно с пустого, никаких default text!), это – нулевая ревизия, папка пуста. Следующее изменение, приходящее с клиента – сохраняется в файл по номеру количества ревизий. И так далее. То есть, скажем, в файле «00000034» будет «"baseRev":34» – и это чейнджсет, применяемый к 34-ой ревизии, и создавший 35-ю. Таким образом, «лишних» файлов в папке вообще быть не должно, чтобы их общее количество всегда показывало текущую ревизию.
Итак, все приходящие от клиента данные, сервер сливает в эти файлы в папке соответствующей данному паду. Тогда, база данных (только dirtyDB, никакого нафиг MySQL!) пада и эта папка – будут синхронными. Для сброса – придётся либо грохать dirty.db и все папки всех созданных падов, либо – просто создать новый пад с любым ещё неиспользованным именем.
Теперь, вторая операция на клиенте – синхронизация с мастер-репозиторием. Во-первых, она вызывает немедленный постинг всех текущих изменений на сервер (кстати, если посылать нечего – то клиент и не пошлёт ничего), а потом отправляет ему сообщение с именем документа (папки), с которой нужно синхронизировать пад.
Структура тут следующая: у сервера есть ещё одна папка, которая является локальной копией репозитория. Подпапки – «документы», в каждом из них – опять же «00000002», к примеру, – ревизии. Того же типа, что в папке пада, но логически по-другому создающиеся. Теперь задача – считать из нужной папки новые изменения, внести их себе; а свои новые изменения – опубликовать в эту папку следующей ревизией.
Вначале я пытался сообразить что-то из-под запоминания номера ревизии, но к успеху это не привело. Я остановился на варианте с хешем, вернее даже – идентификатором ревизии. Каждый файл, как «00000005», – должен иметь уникальный идентификатор. Я взял строку «автор+время+рандом», чтобы точно гарантировать уникальность. Когда новое сообщение от клиента ещё не имеет его – он создаётся. Так что в папке пада, все файлы ревизий уже с хешами.
Ещё, нужно отдельно сказать, что крутого в библиотеке чейнджетов – операции протаскивания и мерджа, называющиеся follow и compose. Допустим, у нас есть цепочка изменений 1-2-3-4, и вторая – 1-2-5. Операция «follow» применяется от «5» к «3» так, чтобы получить некий «5'», который уже применился бы к «4», и дал бы объединение изменений 3+4+5. Цепочка будет 1-2-3-4-5'. Последняя ревизия как бы протащилась через другие, и встала последней. Именно так пад обрабатывает изменения участников, применяемые к разным ревизиям – протаскивает их до последней, а сами изменения в тексте остаются именно на тех местах, где сделаны.
Вторая операция – объединение – позволяет, скажем, свернуть цепочку 1-2-3-4 в 1-4', где «4'» – это «2-3-4», объединённые в единый чейнджсет. Именно так клиент схлопывает все подряд идущие изменения – поскольку операция применяется к двум соседним – он просто делает «compose» имеющегося чейнджсета с новым.
Ну, для полной картины, можно рассказать про AttributePool. Каждый чейнджсет может не только вставлять текст или удалять его, но и менять атрибуты (например, жирность). Атрибуты нумеруются числами, и каждый – это пара «настройка=значение» (например «bold=true»). В самом чейнджсете физически прописаны только числа, а сами названия атрибутов – прикладываются отдельно. Например, если в одном чейнджсете какой-то текст (условно говоря) выделяется синим, а другой – зелёным, то там будет *0 и *1, а в пуле атрибутов – «0:color=blue,1:color=green». Возникает вопрос, как оперировать над чейнджсетами, если за одним номером могут быть разные атрибуты? Для этого есть функция, преобразующая атрибуты из чейнджсета в новый пул, путём слияния с имеющимися в нём. Причём сам чейнджсет тоже меняется, ведь числа в нём должны обновится. Моя обёртка вокруг функции объединения чейнджсетов именно так и поступает – добавляет атрибуты в общий на двоих пул.
Ещё есть понятие AText – текст с атрибутами. По сути – это один чейнджсет, создающий весь текст с паде. Но внутренне собран он чуть по-другому, хотя и ему также требуется пул (со всеми атрибутами пада). Для применения чейнджсета к а-тексту пада – сначала нужно слить его пул с пулом пада. Это как общий знаменатель: у всего пада он самый большой, потому что там складывается всё подряд.
А вот как ещё можно протаскивать чейнджсеты через цепочку: инверсно. Например, если цепочка одного будет «0-1-2», а второго – «0-1-3», то протащив «2» через «3» получится «0-1-2-3'», а если, с точки зрения второго, протаскивать «3» через «2», то будет «0-1-3-2'». И текст физически не будет одинаков, если в одном из случаев не указать инверсию при follow. Но, как потом я выяснил, эта инверсия не всесильна! И на некоторых цепочках, где были удаления, потом объединённые со вставками – follow не даст идентичные результаты, и будет зависеть от порядка применения, чего быть не должно.
Но пока, вернёмся к тому, что пад решил синхронизироваться. Теперь у нас есть две папки: одна своя, для текущего пада; и чужая, из репозитория. Первое, что сервер делает – смотрит на количество файлов в них. Если обе пустые – ничего не делаем, потому что на клиенте изменений нет, а репозиторий ещё не инициализирован вовсе.
Хорошо, пусть клиент сделает несколько файлов ревизий у себя. Тогда синхронизация с репозиторием должна просто скопировать их туда, а ещё лучше – объединить, чтобы публиковать лишь один чейнджсет в одном файле. Этот файл должен иметь новый хеш (который просто уникальный идентификатор).
Если же наоборот, в репозитории были файлы, а в рабочей копии – нет, то это значит, это производится попытка первый раз получить данные из репозитория. Серверу достаточно честно открыть по порядку каждый файл, и обработать их содержимое так, словно эти изменения идут от локального клиента (все проверки на токен сессии, на авторство и подобное – я отключил). Тогда локальное содержимое базы данных пада, и его папки – станет абсолютно таким же, как в репозитории! Включая и хеши ревизий (поскольку хеш в «приходящих» изменениях уж был, то он и остаётся) и даже историю таймслайдера – серьёзно, сервер обманывает сам себя, словно это клиент только что понасоздавал столько ревизий, и все они запомнились в базе – теперь и откатиться к любой точке можно!
Самый сложный, и основной случай: когда файлы есть в обеих папках – распадается ещё на три вариации, и вот тут уже самую важную роль играют хеши. Для начала предположим, что в рабочую копию не были внесены изменения, а в репозитории – есть обновление от других участников. Тогда новые ревизии нужно «протащить» через локальные, но начиная с правильного места (хотя в данном предположении протаскивать и не понадобиться – кладём в конец). В этом помогут хеши: поскольку синхронизированные версии обладают в точности одинаковыми хешами, достаточно будет идти по целевым ревизиям в обратном порядке, найдя первую (с конца), хеш которой совпадает хоть с каким-нибудь (в предположении – последним) нашим хешем – для этого я ещё отдельно храню ассоциативный массив «хеш=ревизия», привязанный к паду и даже сохраняющийся в его базу данных. Если таковой не найдет – это значит, что документы не могут быть синхронизированы, потому что разные; отсчёт от «нулевой» изначальной ревизии (когда документ пуст) – пришлось логично запретить, чтобы не сливались по ошибке разные документы. То есть первоначально нужно хоть что-то написать в новый пад, и чтобы другие сперва это выкачали себе, а не изменяли пустой документ.
Теперь, есть номер локальной ревизии, и ревизии в репозитории – которые находятся в синхронизации. По предположению, локальная ревизия – последняя (новых изменений нет), значит нужно лишь добавить файлы репозитория сюда, с оригинальными хешами. Но на самом деле не всё так просто, но пока идём дальше…
Второй случай: в репозитории не было обновлений, а у нас – были! Значит, нужно собрать ОДИН чейнджсет, и дописать его как новую ревизию. Но перед тем, нужно опять же вычислить, от какой ревизии отталкиваться. Для этого я формально создаю временный пад, а потом вгружаю в него все файлы репозитория с первого по последний, поступая при этом так, как будто изменения приходят от клиента (но не от конкретно текущего, а просто от некоторого), разве что не сохраняю их ещё в какие-то файлы. Тогда и массив пад-ревизия для нового пада будет заполнен корректно. Обратное действие – беру свои локальные ревизии, и перечитываю их с конца в начало, чтобы найти первый совпавший хеш. Причем по ходу считывания – объединяю их в одну, чтобы публикуемый чейнджсет был единственным. Хеш объединения – это хеш последней локальной ревизии, чтобы в итоге после коммита – хеши последних файлов совпали. Когда ревизия найдена – протаскиваем свои объединённые изменения через неё до конца целевой цепочки.
Как оказалось, объединять изменения перед протаскиванием – единственная возможность протащить больше одно чейнджсета. Потому что нет функции типа «multifollow» – чтобы я передал ей массив чейнджсетов, первый из которых был бы для протаскивания, а прочие – его цепочка. Проблема в том, что каждый конкретный чейнджсет предполагает применения к конкретному тексту. И больше ни к какому другому. Рассмотрим две цепочки: «0-1-2-3» и «0-1-4-5». Начала «0-1» у них одинаковые, а дальше было разветвление. К чейнджсету 2 подходит только 3, к 4 – только 5. А к 1 – одновременно и 2 и 4. Допустим, мы протаскиваем чейнджсет 4 через чейнджсет 2 и 3: «0-1-2-3-4'», где «4'» несёт те же изменения, что и 4, но при этом применим не к 1, а к 3. Возникает вопрос: как протащить «5»? Он подходит только к «4», которого уже в чистом виде нет. Нужно было изменять его как-то параллельно с 4, чтобы он стал неким 5', но готовой функции я не нашёл, а свою писать не знаю как (на самом деле я так и не понял, КАК они так протаскиваются в принципе).
Моё решение – сначала объединить один из хвостов. Пусть станет «0-1-(45)», где 45 – это мердж «4-5». Тогда, поскольку он применяется к 1, его можно успешно протащить: «0-1-2-3-(45)'», где штрих формально берётся от «1-». Если рассмотреть зеркальную цепочку, то будет «0-1-4-5-(23)'». В одной из них нужно протаскивать с инверсным флагом, и как я выяснил – в собственной. Когда локальные изменения вносятся в репозиторий – там follow прямой, он, в реальности, допишет текст того, кто постил позже – СПРАВА от уже имеющегося текста. Пример: первый пишет «0», второй обновляет. Теперь первый пишет «1», у него «01», обновляет. Второй пишет «2», у него – «02», обновляет. У него получится «012» (единичка первого встанет СЛЕВА от его двойки, потому что протаскивание «себе» – инверсное). Первый обновляет – у него тоже «012», но двойка просто появится справа, потому что здесь протаскивание прямое, сделанное вторым.
Ладно, случай третий, самый главный: и в локальном, и в целевом репозитории были созданы новые чейнджсеты. Две операции запускаются по очереди: сначала я ищу с конца целевых ревизий такую, которая бы совпала с каким-нибудь локальным хешем, и объединяю их между собой по дороге. Потом создаю временный пад, прогружаю в него все целевые ревизии по порядку, а затем – иду по своим снова с конца, находя такую, которая совпадёт с хешем из них, тоже объединяя. Казалось бы, теперь достаточно лишь запостить в репозиторий наши изменения, протащив по правильной ревизии, а к нам – его изменения, тоже с верного номера, но уже инверсно. Правда, оба этих новых файла должны иметь одинаковый хеш, причём уникальный, не совпадающий ни с тем и не с другим. К тому же, если коммит одного файла по каким-то причинном не может быть выполнен – себе брать собранные и протащенные изменения тоже ни в коем случае нельзя (это и отличает данный вариант от просто применения двух прошлых по очереди), иначе потом при следующей синхронизации на сервер ушли бы уже имеющиеся там изменения (ошибочно ставшие частью локальной цепочки), либо же – не дошли бы собственные.
Но как я уже сказал, оказалось, что функция протаскивания с инверсией – багнутая. Если первый сделал «0» и синхронизировал, второй тоже синхронизировал; первый дописал слева от нуля «1» и синхронизировал, затем удалил свой «0» и снова синхронизировал; второй дописал «2» слева от нуля, и синхронизировал. Теперь у второго «21», а у первого после синхронизации – будет «12».
…как я долго искал проблему!! При обычных редактированиях, всё нормально. Если делать всё аккуратно и по шагам – ничего не ломается. Но когда я уже был уверен, что всё работает идеально, просто делал беспорядочные правки текста и синхронизации – пад вылетал на попытке применить очередной чейнджсет к тексту, потому что там где-то не сошлись переносы строк (ага, а потом никак «аккуртно» всё повторить и не мог).
На самом деле, операции в чейнджсетах бывают однострочные и многострочные. Причём многострочная операция – это такая, которая затрагивает кусок текста, в котором строго определённое количество переносов строк, причём последний символ (будь то удаление, атрибуты или вставка) – обязан быть переносом строки! Однострочные операции – переносов строк не затрагивают. Поэтому, когда происходила рассинхронизация – клиент вносил такой чейнджсет, который был уже невалиден для второго клиента, если переносы строк оказывались на разных позициях.
Это поставило под угрозу всю задумку, пока я не вернулся к своему изначальному плану, «отвергнуть все локальные изменения» при синхронизации. А ведь даже не обязательно все! Синхронизируяюсь, и рабочая копия, и репозиторий – должны придти к одинаковому состоянию, но разными путями. Поскольку в репозиторий коммит изменений и протаскивание происходит прямым способом, и верен; а вот обратный – глючит, то: что мешает в этот момент полностью почистить текст своего пада, и внести туда ровно то, что должно получиться – текст временного пада, представляющего собой весь репозиторий? Причём это даже не повлияет на таймлайн и историю: какая разница, будет ли чейнджсет таким крутым, что, будучи применённым к имеющемуся тексту каким-то чудом сделает его именно таким, каким пожелает пад репозитория; или же мы просто скажем «удали свой и замени вот этим» – да, возможно тут придётся поплатиться тем, что в таком случае чейнджсет будет размером с весь текущий текст в паде, но какая разница – это всё равно локально, а в репозитории-то всё нормально. Более того, если сбросить свой пад, или создать другой – то при первой синхронизации будет выкачана именно нормальная цепочка с нормальными чейнджсетами. Правда я не стал убирать из алгоритма подготовку к инверсному протаскиванию (чтобы ветвление ещё на случаи не разбивать), просто её результат под конец затирается прямой заменой, вместо этого самого протаскивания.
Замена, кстати, оказалась не такой простой. Там была функция «вставить в новый чейнджсет готовый а-текст», но не было «добавить удаление всего текущего». Вернее было, но лишь в одном клиентском файле, который зависел от каких-то слайсеров, нужных только клиенту и Ace-движку; а у сервера этого не было. Пришлось писать… Функция вышла низкоуровневая: удаляет многострочным изменением весь текст от начала до предпоследнего переноса строки включительно, и потом – однострочным всё на последней строке до самого последнего переноса не включительно (который вообще трогать ни в коем случае нельзя!). И производит вставку а-текста из нового пада; ну там ещё за пулом атрибутов постоянно следить надо.
Теперь, общая функция синхронизации выглядит так: 1) Выкачиваем свежую копию репозитория, и считаем файлы у себя и у цели. Если по нулям – выход. 2) Если у цели пусто – то объединяем все свои файлы, и коммитим результат с хешем последнего. Выход, но если коммит не удался – удаляем внесённый файл. 3) Если пусто у нас– то проходимся по всем файлам цели, и выполняем каждый из них в свой пад, как будто это всё изменения, пришедшие от текущего клиента; файлы у себя появятся автоматически, как обычные изменения настоящего клиента. Выход. 4) Проверяем хеш последнего файла цели: если такой у нас есть – к пункту 7. 5) Объединяем все файлы цели в обратном порядке, до тех пор, пока не найдём хеш, совпавший с одним из наших. Если такого нет – ошибка, это пад другого документа. 6) Собранные изменения запоминаем, а хеш для них будет – из последнего целевого файла. 7) Создаём временный пад, и загружаем в него последовательно все целевые файлы, как изменения, приходящие от фиктивного клиента, но без дополнительного сохранения ещё куда-то, хотя и со слежением за хешами. 8) Проверяем хеш последнего нашего файла: если он есть во временном паде, и при этом пункт 6 не выполнялся – выход, потому что на данный момент, отказывается, ещё ни у кого нет никаких новых изменений. 9) Если хеш есть во временном паде, но пункт 6 выполнялся – то эти самые запомненные изменения просто вносим в свой пад. Выход – мы успешно обновили свой неизменённый пад с репозитория. 10) Объединяем все свои файлы в обратном порядке, до тех пор, пока не найдём хеш, совпавший с одним из целевых во временном паде. Если такого нет – выход с ошибкой, это тоже пад другого документа. 11) Если пункт 6 выполнялся – то создаём новый хеш, который присваиваем и этому объединению, и тому, что мы запомнили тогда. 12) Вносим объединение во временный пад, с протаскиваем через ту ревизию, пред которой совпал хеш в пункте 10; сохранение автоматически в очередной файл в целевой папке. 13) Пытаемся коммитить этот созданный файл, но если не вышло – удаляем его и выходим с ошибкой (по факту, никакие изменения в свой пад ещё не были внесены, раз выполнение дошло до сюда); например, если в целевом репозитории уже появился файл с этим именем последней ревизии – то есть гит-конфликт – то весь алгоритм нужно перезапустить с пункта 1. 14) Если пункт 6 не выполнялся – то выход, ведь наши изменения уже в репозитории, который за это время никто не менял. 15) Берём результат пункта 6 с хешем из пункта 11, и меняем его содержимое на текущий текст из временного пада. Вносим это изменение в свой пад как последнюю очередную ревизию – и синхронизация, наконец, полностью завершена.
Временный пад должен быть удалён сразу, как не нужен. Все файловые операции у меня – вопреки духу джаваскрипта – синхронные. Обращения к репозиторию – тоже. Их, собственно, два: чекаут в самом начале, и коммит на пунктах 2 и 13. Причём успешность или неуспешность коммита критически важна! Клиент блокирует пад на изменения до тех пор, пока эта функция синхронизации не завершится. Каждый чекаут – допись файлов, которых ещё нет; каждый коммит – сохранение одного файла в репозитороии.
Вопрос, что же делать с авторскими цветами? Это именно то, чем я намерен заниматься далее, но идея такая: кроме хеша, я же могу любые метаданные в своих файлах хранить! Буду посылать от клиента целиком его userinfo. Да и вообще, позволю выбирать не только «имя», а сделаю его по факту эквивалентным «id». Тогда, вместе с изменениями серверу будет приходить цвет текущего клиента, и сохранятся в репозитории. Обновляя, разные клиенты смогут и получать цвета друг друга, и менять их.
А что с чатом? Ну так же: приходящие от клиента сообщения чата, буферизуются на сервере. Причём до тех пор, пока не выполнена синхронизация – должна быть возможность удалить любое из них. При первом же постинге в репозиторий – все накопившиеся сообщения чата уходят вместе с изменениями, а новые – вносятся в пад. Ну да, тут и порядок, и даты – будут в рассинхроне: пришедшие с репозитория сообщения чата в любом случае будут добавлены в конец текущего пада, после отправленных собственных; хотя если потом обновить с чистого пада – то сообщения окажутся на самом деле в другом порядке. Хотя всё логично – все новые для данного пользователя – всегда снизу.
Однажды созданный файл ревизии – не удаляется и не изменяется, то есть конфликтов не будет никогда. Если же по каким-то причинам очередной коммит как-то нарушит работу всей системы – то его можно быстро ревертнуть (уже через Git), ведь предшествующая цепочка всегда верна и никуда не делась. Локально можно создавать столько угодно падов, и вгружать в них содержимое репозитория, если по каким-то причинам, текущий локальный пад вышел из строя (например, создан чистый пад в базе, но в папке с его именем уже что-то есть), и не хочет нормально синхронизироваться.
Когда я говорил «хеш» – я имел в виду «идентификатор», просо случайно создающийся, и прямо не связанный с непосредствнным содержимым: два разных файла с одинаковым хешом обозначают, что полная цепочка от начала и до каждого – приводит пад к одному и тому же состоянию (но скорее всего, разными путями).
Возможность синхронизироваться клиентам между собой без центрального репозитория – я пока не рассматривал. Ведь если у одного «0-1-2-3», а у другого – «0-1-4-2'-6» – как это слить, я в своём алгоритме в принципе не представляю («2'» – это чейнджсет 2, протащенный через 4); да, тут постинг не взаимный, но случай рассмотрения различных беспорядочных взаимных синхронизаций сведётся именно к такому.
А в моём случае с мастер-репозиторием – процесс синхронизации сведён к нажатию одной кнопки, и я уже проверял продакшн в локальной сети – шикарно! Изменения сливаются идеально, например если кто-то пишет в строке 4, а я ставлю перед ней два переноса – то после обновления его текст окажется на строке 6 и ничего не нарушится. Если кто-то удалит весь текст в паде, а другой что-то напишет в исходный вариант – то после синхронизации у всех окажется лишь его текст на пустом паде.
Изменения сплетаются между собой неочевидными зависимостями: первый что-то изменил и синхронизировал, второй тоже изменил и синхронизировал, третий изменил (всё ещё исходную версию) и тоже синхронизировал; потом снова первый, опять что-то поменяв, синхронизировал – а ведь перед ним пад уже трогали двое – и НИ У КОГО не будет на экране одно и то же. Но тем не менее, если они перестанут редактировать, а просто несколько раз синхронизируются – то все придёт в норму: изменения каждого достигнут каждого, и пока никаких слияний нет – пады у вех одинаковы, несмотря на то, что в их папках разные файлы, разное количество, разные хеши, и даже разные истории – своя всегда запоминается подробно, а чужие – ревизии встают в те моменты, когда происходило локальное обновление; чтобы получить чистую историю всех настоящих ревизий репозитория – нужно выгрузить в новый пад.
Так во-от… Всё шоколадно.
За одним исключением – теперь пад, он как бы… оффлайн. Да, кэп. Я вот думаю, нельзя ли его обратно – онлайн сделать? Чтобы можно было работать и онлайн, и оффлайн…
Потому что если рассмотреть пользователей мобильных браузеров – так туда ни сервер пада не поставить, ни даже расширение, имитирующее его. Но с другой стороны, есть GitHub. А на нём можно создать проект pages – в нём содержимое репозитория будет отдаваться по http как статичный сайт. Включая все мои файлики ревизий всех документов!
Остаётся лишь кастрировать etherpad до такого состояния, в котором ему вообще не нужен будет «умный» сервер: браузер просто заходит на нужную страничку, и всё ядро и все плагины – скачиваются как обычные .js файлики. И браузер работает сам по себе. Чекаут – просто выкачка новых файлов из нужной папки. Коммит – ну… пусть браузер просто даст скопировать правильный текст, и откроет для клиента страничку Гитхаба, куда нужно будет просто вставить его и подтвердить коммит. Или ещё лучше – пусть сам прокоммитит, может у сайта есть POST-api?
Что же делать с базой-то. DirtyDB… она же хранит простой JSON? Ну видимо, его можно сохранять в localStorage. Ещё даже deflate-ужимать можно, чтобы больше поместилось.
Может у вас есть какие-нибудь идеи насчёт этого? А именно, с чего начать превращение пада с умным локальным сервером – в пад, скачивающийся со статического хостинга, и сохраняющий всю работу в паде локально? Пока у меня идея, перехватить все места отправки оставшихся (я же всякие там «второй юзер зашёл в пад» и тому подобные – вообще не рассматриваю) сообщений, и превратить их в вызовы серверный функций. Движок базы переделать под localStorage.
Ну и функцию синхронизации тоже полностью переписать, заменив файловые операции удалённым скачиванием и опять же localStorage. Хотя, эту функцию всё равно придётся переписывать… http://klimaleksus.narod.ru/Files/4/offline.png – щедро рассредоточить, дать понятные названия и комментарии, и в кой-то веке все вложенные вызовы под anync.series расписать, а не вглубь. (она одной строчкой, потому что я тестировал, отправляя её серверу через консоль браузера как строку)
О, а ещё каждый коммит должен пересоздавать некий общий файл html-экспорта в репозитории. Чтобы всегда можно было легко посмотреть, что там сейчас в паде – даже без включённого javascript.
*UPD* Продолжаем:
ЦитатаSviMik
сама идея править текст в оффлайне для меня выглядит странно.
Из того, что я успел натестировать – пад мерджит ШИКАРНО. То есть, если у нас (а у нас так) будет список строчек такого формата:
Оригинал. Текущий итоговые перевод. Вариант. Обсуждения, Оппонирования, Ещё вариант. Дополнения…
Следующая строка, и так далее.
– тогда, основной текст представляет из себя диалог. Старые строки не правятся, просто добавляются новые. Раздвинуть строки – да пожалуйста, это ничего не сломает. Двое пишут в одну строку? Ну ничего, варианты встанут друг за другом.
Менять будем только финальный вариант, и только с учётом сделанных обсуждений ниже его. Текста (да и вообще, документов) у нас будет МНОГО, и вероятность, что два человека предложат правку к одной строке одновременно (скажем, в течении недели) – низка. Другое же дело, когда кто-то отредактировал, а второй – потом прочитает и напишет ответ. Вот он и примет решение, брать ли предложенные правки (или удалит уже внесённые), и допишет свой ответ.
В этом и оффлайновость! У нас специфика работы другая, и особенно – темп. Что мне не нравится в вашей специфике – необходимость писать обсуждения на той же самой строке. У нас заморочек с нумерацией нет – всегда можно раздвинуть строки и хоть диалог с форума туда добавить.
Оу, а я не говорил, что нам нужны «спойлеры»? Что-то большее, чем скрыть/показать кусок текста на одной строке. Хочу – скрывать несколько строк (хотя, это даже никаким тегом не реализуешь – там в body строго вложен список div, в которых – непересекающиеся span). Чтобы можно было и всё свернуть, и всё развернуть, и поштучно. Да так, чтобы нумерация не сбивалась… Видимо, кастомная функция нумерации, которая не только номера меняет, но и по содержимому смотрит, может даже высоту меняет. Сейчас как есть, даже если как-то сделать многострочный спойлер – он сломает нумерацию строк. Не то чтобы нумерация была мне так нужна… но не отдавать же её без боя? )) А делать многострочный спойлер формально в одну строку (то есть использовать какой-то символ, делающий <;;br>) – ну нет, по моим расчётам для моей задачи – 90% всего пада будет под тем или иным спойлером, и из-за messing with newlines – мердж чейнджсетов сломаться не должен – я как раз про то, что стандартные переносы строк хорошо обрабатываются при слияниях.
Возможно, в сложных ситуациях пад тоже мог бы показывать пользователю диалог с просьбой выбрать вариант решения той или иной ситуации?
Насколько я могу сказать сейчас – изменения затрагивают по факту только тот текст, к которому прикасался редактировавший. А ещё: если после синхронизации произошёл фак-ап – человек может сразу же всё поправить, и синхронизировать ещё раз.
Алгоритм чейнджсетов может протаскивать либо прямо, либо инверсно – всё. Других вариантов «решения проблемы» в нём нет. И я отказался от одного из протаскиваний. В принципе, можно попробовать переключить на инверсное – тогда текст последнего синхронизировавшегося будет, вообще говоря, добавляться СЛЕВА на совместно изменённых строках (больше ни на что не влияет – если он писал на отдельной строке, то в любом случае будет на отдельной), но мне кажется это не совсем ожидаемым, ведь новые изменения логично должны оказаться на конце.
Мне больше импонирует возможность, например, подгружать из хранилища не единым изменением, а частями. Или чтобы всё новое – получало как-то особый атрибут, чтобы сразу было видно, что же было изменено. Это вроде неплохо. И должны быть кнопка, грубо говоря, «прочитал» – очищающая это форматирование. А все приходящие вставки – пусть выделяются. Хотя, с удалениями всё равно ничего не сделаешь – не вставлять же туда какой-то символ?..
Цитатаalteya
aleksusklim, слушьте, а может... это самое... все эти рассуждения перенести в какую-нибудь другую ветку? Есть же у нас темы "общего" назначения. К субтитрам видео они имеют крааайне опосредованное отношение. Ну правда. Вот захочет вдруг кто попереводить видео. Зайдет в тему. И тут же сломает себе мозг! И убежит без оглядки.
Цитатаalteya
Одна из наших форумных проблем. Да что там... Самая ГЛАВНАЯ форумная проблема как раз в том, что среди продуктивных обсуждений самого материала (тексты, правки) есть нефильтрованные ТОННЫ вот таких вот сторонних рассуждений. И потом в этих тоннах откопать крупинки правок весьма затруднительно. Это я вам как копательница со стажем говорю. Сломавшая не один десяток титановых лопат, и стершая себе руки до кровавых мозолей в этих раскопках.
Цитатаalteya
Куда эффективнее было бы сперва установить фильтр на все неотносящееся непосредственно к теме. Например, волшебной кнопкой spoiler.
UPD
Цитатаaleksusklim
Продолжаем:
Цитатаalteya
Тему "Перевод видео "The Making of..." пора переименовать в "The Making of pad". А видео... Какое еще видео? Тут было что-то про видео?
А если серьезно. Это гораздо лучше смотрелось бы в теме "Переезд платформы".
ЦитатаDragonFlight
http://s1.uploadpics.ru/images/Wy-LI7daK-.png
КТО Ж ТАКОЕ В PROGRAM FILES РАСПАКОВЫВАЕТ!!
Только в корень, без пробелов в именах и с КОРОТКИМИ названиями (спорю, что тут проблема лишь в том, что максимальный пусть оказался слишком длинным – в просто не захотите знать максимальную глубину каталогов в архиве…).
Плюс, если при первом запуске вылелит с «заблокирован файл базы данных» (как-то так на английском) – просто перезапустить.
Даже если это очки – зачем притворяться мартышкой?..
ЦитатаDragonFlight
Как студент факультета прикладной математики говорю (аж стыдно произносить).
Земляк, что ли?..
Цитатаalteya
все эти рассуждения перенести в какую-нибудь другую ветку?
(всё, даже сова прилетела и дала подзатыльник…) Да вроде эта ветка пока хорошо подходит – свеженькая, ещё не испорченная…
Цитатаalteya
К субтитрам видео они имеют крааайне опосредованное отношение. Ну правда.
Ну я надеюсь, что всё о субтитрах – уйдёт в пад. Тут останутся лишь итоговые варианты, и какие-нибудь общие обсуждения. Копипасты из пада…
Цитатаalteya
И убежит без оглядки.
Мне хочется убежать просто от громадного числа субтитров, которые тут УЖЕ есть.
Цитатаalteya
И потом в этих тоннах откопать крупинки правок весьма затруднительно.
Ну я же не вечно буду этот пад делать (тьфу-тьфу…), и на следующих страницах – будет только по теме. А для навигации новичкам – нужно шапку нормальную собрать, с хорошими инструкциями. Только прежде нужно чётко понять, ЧТО делать, и какой инструмент для работы выбрать. И решать лучше здесь. Я именно и хочу сделать так, чтобы на форуме больше не приходилось копаться – а его нужно было лишь читать, чтобы понимать, что вообще происходит. Переводить сами субтитры нужно не тут…
Нижеследующее (и часть выше, а то не поместилось…) собрано из различных источников, следуя в логичной хронологии. Вот сохранённая копия последнего состояния изменённой темы: http://klimaleksus.narod.ru/Files/48/12828.zip
ЦитатаSviMik
Представь ситуацию, есть исходный текст: "Lorem ipsum dolor sit amet / Sed do eiusmod tempor incididunt"
– Один пользователь удаляет первый фрагмент, у него остаётся: "Sed do eiusmod tempor incididunt" – Второй пользователь дописывает свой вариант слова: "Lorem ipsum/laborum dolor sit amet / Sed do eiusmod tempor incididunt" – Третий пользователь решает, что ipsum не нужен впринципе, у него в паде остаётся: "Lorem dolor sit amet / Sed do eiusmod tempor incididunt" – Четвёртый решает поменять местами Lorem и ipsum (учитываем также смену регистра L и i): "Ipsum lorem dolor sit amet / Sed do eiusmod tempor incididunt"
ЦитатаSviMik
Вопросы: 1) Что будет, когда все четверо нажмут на синхронизацию? 2) Будет ли результат отличаться в зависимости от того, в каком порядке они будут синхронизироваться? 3) Останется ли вариант второго пользователя "/laborum", и если да - останется ли он приклеен к слову "Ipsum", или уедет в другое место? 4) Если пользователь 1 окажется последним на синхронизацию, его удаление: а) проигнорируется? б) снесёт первую половину вместе с новыми вариантами? в) снесёт частично, оставив ошмётки текста?
Цитата
"Lorem ipsum dolor sit amet / Sed do eiusmod tempor incididunt"
Первый пишет это, все синхронизировались. Старт есть.
Цитата
Один пользователь удаляет первый фрагмент, у него остаётся: "Sed do eiusmod tempor incididunt"
Допустим, синхронизировался первым.
Цитата
Второй пользователь дописывает свой вариант слова: "Lorem ipsum/laborum dolor sit amet / Sed do eiusmod tempor incididunt"
Пока пусть синхронизироваться в этой же очерёдности. У него: «/laborumSed do eiusmod tempor incididunt»
Цитата
Третий пользователь решает, что ipsum не нужен впринципе, у него в паде остаётся: "Lorem dolor sit amet / Sed do eiusmod tempor incididunt"
Поскольку, ипсума уже там всё равно нет, у него тоже: «/laborumSed do eiusmod tempor incididunt» (кстати, это сгенерировало identity-чейнджсет «Z:15>0$»)
Цитата
Четвёртый решает поменять местами Lorem и ipsum (учитываем также смену регистра L и i): "Ipsum lorem dolor sit amet / Sed do eiusmod tempor incididunt"
А вот тут зависит от того, КАК он сделал эту правку.
Если вырезать «Lorem », изменить первую букву «ipsum» на «I», и вставить «Lorem » после «Ipsum» и исправить «L» на «l» то: «/laborumIpsum lorem Sed do eiusmod tempor incididunt»
Если вырезать «ipsum », вставить перед «Lorem», исправить «L» на «l» и «i» на «I», то: «/laborumIpsum lSed do eiusmod tempor incididunt»
Тут, видимо, зависит от границ вмешательства. Например, если забить на регистр и тупо менять местами слова через вырезать-вставить, то – Лорем направо: «/laborumLorem Sed do eiusmod tempor incididunt» Ипсум нелево: «/laborumipsum Sed do eiusmod tempor incididunt» – значит, когда прикасаются к удалённым словам по буквам – иногда может остаться только изменённая часть, а иногда и всё слово (потому что трогали и справа и слева от него)
Если же удалить «Lorem ipsum», и написать «Ipsum lorem» вручную, то: «/laborumIpsum loremSed do eiusmod tempor incididunt»
Цитата
1) Что будет, когда все четверо нажмут на синхронизацию?
Допустим, четвёртый всё же написал «Ipsum lorem» вручную, тогда:
Цитата
2) Будет ли результат отличаться в зависимости от того, в каком порядке они будут синхронизироваться?
Ну попробуем ещё раз!
Четвёртый меняет на ипсум лорем: «Ipsum lorem dolor sit amet / Sed do eiusmod tempor incididunt» Третий удаляет ипсум, которого опять уже нету: «Ipsum lorem dolor sit amet / Sed do eiusmod tempor incididunt» Второй приписывает лаборум: «Ipsum lorem /laborum dolor sit amet / Sed do eiusmod tempor incididunt» Первый удаляет начало, эффективно – долор сит амет: «Ipsum lorem /laborum Sed do eiusmod tempor incididunt»
Пусть тогда сначала третий удалит ипсум, второй допишет лаборум, первый удалит начало, а четвёртый пусть только региcтр поменяет, не трогая сами слова:
У третьего: «Lorem dolor sit amet / Sed do eiusmod tempor incididunt» У второго: «Lorem /laborumdolor sit amet / Sed do eiusmod tempor incididunt» У первого: «/laborumSed do eiusmod tempor incididunt» У четвёртого: «l/laborumISed do eiusmod tempor incididunt» (лаборум встал между «И(псум)» и «л(орем)»)
Цитата
3) Останется ли вариант второго пользователя "/laborum", и если да - останется ли он приклеен к слову "Ipsum", или уедет в другое место?
Как видно, останется в любом случае, потому что его конкретно никто не удалял, но при этом откажется он там, где повезёт…
Цитата
4) Если пользователь 1 окажется последним на синхронизацию, его удаление:
– в) снесёт частично, оставив ошмётки текста. Значит, удаление привязывается к конкретному тексту.
Но как я сказал, в моей задаче – будет так, что:
Первый переносит строку и пишет: «Начало нафиг не нужно, оставим только "Sed do eiusmod tempor incididunt"», сам ничего не трогает. Второй тоже переносит строку, и пишет: «давайте "laborum" вместо "ipsum"», ну да и пусть допишет «/laborum» в строку, нормально. Третий говорит на следующей строке, «"ipsum" убрать нафиг!» и делает это. Четвёртый пишет после переноса, «Ipsum lorem» будет лучше звучать, выделяя эти два слова жирным и не меняя их (потому что, допустим, он не уверен, что так действительно лучше).
Кстати говоря, порядок, в котором появляются новые строки после переноса – такой же, в каком они нажимали на синхронизацию: последний писавший окажется снизу, и после синхронизации – сможет непосредственно увидеть, что написали перед ним.
И что бы там не произошло с текстом в исходной строке – последний всегда сможет разобраться, что каждый пытался отредактировать, соберёт на своё усмотрение верный вариант (даже добавит его копию отдельной строкой далее), и потом ещё и к нам на форум обсуждения фразы прямо из пада и скопирует (кстати, мне нужен экспорт в BB-коды…)
Так что норм!
Цитатаalteya
Цитатазагрязнитель тем
свеженькая, ещё не испорченная…
Вооот. Ага. Непорядок! Как это так - люди обсуждают только переводы, и нет ни одного громадного невтемного сообщения!? Срочно исправить!! Ну серьезно. Вы так стараетесь решить все наши проблемы, попутно создавая другие. Вам доставляет неимоверные физические и моральные муки вид чистой темы?
Так… Мне что ли перетащить всё обсуждение туда, вырезав отсюда, да?
ЦитатаSerlutin
aleksusklim, оффтоп не по теме перевода выделен в отдельную тему
ПРОКЛЯТЬЕ!!
Вы только что уничтожили прямые ссылки на посты, спасибо.
Оффтоп, значит? Ну, посмотрим…
Вообще-то, я и сам мог перенести, _аккуратно_.
Цитата
Вообще-то, я и сам мог перенести, _аккуратно_
Цитатаalteya
Ну дык и надо было. После тоооненьких аки двойной бигмак намеков с моей стороны.
Цитата
Оффтоп, значит? Ну, посмотрим…
Цитатаalteya
Звучит как объявление войны... Ради пресвятых кексиков! Не надо "назло всем" постить ЕЩЕ БОЛЬШИЙ оффтоп или делать другую нехорошую каку.
Насчет пропавших ссылок - честно, сочувствую, если они правда имели большое значение.
Цитатаalteya
Ну и напоследок. Только не подумайте, что все кругом (и я в частности) вражины, которые категорически против pad'а и всего с ним связанного. Нет. Если, это и впрямь окажется крутой штукой - я первая скажу вам СПАСИБО. Но единственное чего я не понимаю, так это зачем все расписывать в теме перевода субтитров или других текстовых темах. В отдельной теме это и выглядит куда красивее.
Цитата
Ну дык и надо было.
Видимо, не я один предпочитаю месть шантажу.
Serlutin, не вышло уговорами – возьмём силой? Way to go.
Перекрёстные. Ссылки.
Это же так просто…
+ адекватная шапка.
Цитата
если есть документ Д, и изменение И, то мы получим некий новый документ Д1: Д → (И) → Д1.
ЦитатаSerlutin
Мне кажется, или кто-то придумал децентрализованную распределённую систему управления версиями? Ну точно, всё сходится. Оффлайн. У каждого своя версия. Синхронизация в начале работы и в конце. Хеш для каждой версии и для каждой правки. Ну точно. Это же Git.
ЦитатаSerlutin
И по описанию, чувство, что просто в Git запихнули обычную таблицу, со строками: Оригинал, Перевод, Обсуждение. Проблема лишь в том, что все системы версий и svn, и Git, и Mercurial, и куча других рассчитаны на программистов, а не на переводчиков. Следовательно, либо учить консольные команды, либо устанавливать дополнительные программы. А переводчик — человек творческий. Он не хочет устанавливать и разбираться, он хочет переводить.
ЦитатаSerlutin
Ну вот просто пример оторванный от реальности. Это если бы, допустим, начать переводить фильм, мультфильм или игру. Но попросить, чтобы актёры не просто записывали свой голос и выкладывали, а еще и конвертировали полученный файл в картинку и выкладывали на хостинг изображений. Да если так сделать, то все актеры сразу бы разбежались. Сложно, неудобно, непонятно, долго и, что главное, отвлекает от озвучивания.
ЦитатаSerlutin
Так дальше, я пытался вникнуть в Ипсум лорем и... ничего не понял. В Git как происходит. Если есть конфликт правок, то при слиянии открывается программка (не помню название, гит давно уже не запускал): бла-бла-бла, какой из вариантов выбрать. Если брать GitHub, то при Pull request просто нужную версию выбирает автор репозитория.
Цитата
Теперь каждый их них делает свой документ соответственно 01, 02, 03, Первый синхронизируется со вторым. У них становится 021. Второй синхронизируется с третьим: 0321 (потому что идёт «0(21)» с «0(3)», и «21» дописывается третьему в конец). Теперь первый хочет синхронизироваться с третьим. Имеем «021» к уже «0321». Изначальный алгоритм, вычисляющий позицию слияния по номеру ревизии, выдал бы «0(21)» к «0(321)» равно «032121», что неверно.
ЦитатаSerlutin
Чёт ересь какая-то. Зачем так? Ну допустим есть файл ПИРИВОД.ТХТ Он хранится на гитхабе. Первый пользователь добавляет первую строку, второй пользователь вторую, третий третью. Потом они нажимают git push (ну или как там называется это в чудо-паде) и в итоге получается ПИРИВОД.ТХТ с тремя строками. Если вдруг четвертый пользователь перевел все три строки, не зная, что их перевели другие, то при пуше он получит конфликт правок. Причем даже при одновременной отправке. Git сравнивает под timestamp, где учитываются даже доли секунды (вроде бы). Так что одновременно в любом случае не получится.
Цитата
У третьего: «Lorem dolor sit amet / Sed do eiusmod tempor incididunt» У второго: «Lorem /laborumdolor sit amet / Sed do eiusmod tempor incididunt» У первого: «/laborumSed do eiusmod tempor incididunt» У четвёртого: «l/laborumISed do eiusmod tempor incididunt» (лаборум встал между «И(псум)» и «л(орем)»)
ЦитатаSerlutin
Эм, то есть вместо того, чтобы сказать: «Чувак, с этой строкой что-то не так, какая-то хрень выходит», получается нечитаемая фигня без пробелов? О да, сверх продуктивно. Но в принципе, я даже в это лезть не хочу. Что-то запускающееся на батниках, которое надо хранить в корне диска? Да ни за что.
ЦитатаSerlutin
ЦитатаDragonFlight
Чем вы проаргументируете, что пад удобнее Google таблиц?
Цитатаaleksusklim
Он оффлайновый.
И? Что дальше? Звучит так, как будто все такие. АААА, ну он же оффлайновый. Это всё меняет. Вроде бы из гугл таблиц тоже можно сделать оффлайновую версию. Есть и googledocs offline. Или можно хранить в виде .xslx и править Excel или Calc.
ЦитатаSerlutin
Нет, Гугл Таблицы, конечно, для перевода подходят довольно плохо. Но они позволяют редактировать, где угодно и с чего угодно. Компьютер, планшет, телефон, холодильник. Проблемы с инетом? Ну скачай на комп, переведи, а потом вручную закинь, ничего страшного.
ЦитатаSerlutin
А вот обсуждения? Тут как раз форум удобнее, как мне кажется. По крайней мере для тех, кто переводит у нас субтитры. В любом случае, даже если есть несколько вариантов, выбирать правильный перевод будет кто-то один. У нас переводчиков можно по пальцам пересчитать. Даже одной руки. Да там хоть по телефону переводи, а результат карандашом на туалетной бумаге пиши, а потом отсылай почтой. Всё равно получится.
Цитата
И? Что дальше? Звучит так, как будто все такие. АААА, ну он же оффлайновый.
Это была инсинуация, ибо его достоинства уже были описаны в другом месте.
Цитата
Что-то запускающееся на батниках, которое надо хранить в корне диска? Да ни за что.
Серьёзно? Вы не запустите и не запускали НИ ОДНУ мою программу?
Цитата
Мне кажется, или кто-то придумал децентрализованную распределённую систему управления версиями?
Гитхаб/изерпад/лайт/мастер.зип
Цитата
Чёт ересь какая-то. Зачем так?
Что, совсем никто не понимает различий между _использованием_ программы, и её внутренним устройством.
Цитата
Хеш для каждой версии и для каждой правки.
А это даже смешно.
Цитата
Чёт ересь какая-то. Зачем так?
Поражаюсь, почему мы до сих пор просто не вставили в игру пофикшенный вариант от Вектора, как DrWho завещал?..
Цитата
Ну точно. Это же Git.
Зачем нужен Windows, если есть Linux? Зачем нужен Delphi, если есть C++? Зачем нужен VK, если есть Facebook? Зачем нужен Telegram, если есть WhatsApp? Зачем нужен Mp3, если есть Ogg? Зачем нужен Ожегов, если есть Даль? Зачем нужен Paint.Net, если есть Photoshop? Зачем нужен SourceForge, если есть GitHub? Зачем нужен KMplayer, если есть VLC? Зачем нужен Game Maker, если есть Construct? Зачем нужен Yandex, если есть Google? Зачем нужен Akelpad, если есть Notepad++? Зачем нужен FarManager, если есть TotalCommander? Зачем нужен TeamSpeak, если есть RaidCall? Зачем нужен Nginx, если есть Apache? Зачем нужен NOD32, если есть Kaspersky? Зачем нужен TheBat, если есть Outlook? Зачем нужен Georgia, если есть Times? Зачем нужен Siemens, если есть Nokia? Зачем нужен aleksusklim, если есть steeldragon?
Цитата
все такие. АААА, ну он
Сорян, IPv6 не юзаю.
Цитата
Ну допустим есть файл ПИРИВОД.ТХТ Он хранится на гитхабе.
Вот есть файл «/levels/original-english/01. Sunrise Spring Home.txt», он хранился на GoogleCode. Что, много диффоф и мерджев, коммитов и пулов было эффективно в него совершено?
Цитата
вместо того, чтобы сказать: «Чувак, с этой строкой что-то не так, какая-то хрень выходит», получается нечитаемая фигня без пробелов?
То есть вы прочитали тот абзац – ПРОТИВ которого я выступал, предложив ниже ровно такой, как вы сейчас сказали – и вы используете это как аргумент против меня же?
Цитата
Так дальше, я пытался вникнуть в Ипсум лорем и... ничего не понял.
А потому что это не для вас и ни для кого здесь. Я опубликовал это для того, чтобы иметь ПРЯМУЮ ССЫЛКУ на данный текст.
Цитата
чтобы актёры не просто записывали свой голос и выкладывали, а еще и конвертировали полученный файл в картинку и выкладывали на хостинг изображений
I wanna be the very best, Like no-one ever was. To catch them is my real test, To train them is my cause. I will travel across the land, Searching far and wide. These pokemon to understand, The power that's in side.
Pokemon! Gotta catch 'em all. It's you and me. I know it's my destiny. Pokemon! Oh, you're my best friend, In a world we must defend. Pokemon! Gotta catch 'em all. A heart so true, Our courage will pull us through. You teach me, And i'll teach you. Pokemon! Gotta catch 'em all. Gotta catch 'em all. Yeah-eh-eh.
Every challenge along the way, With courage i will face. I will battle every day, To claim my rightful place. Come with me, The time is right. There's no better team. Arm in arm, we're in the fight. It's always been our dream.
__________
Мой перевод:
А я хочу великим стать, Всех лучше, без прикрас! Мне не легко их поймать, А тренером быть – класс. Путешествий – тьма с меня, Поиск ждёт в пути: Вот покемон – как их понять, И силу, что внутри?
Покемон! (Всех ловить готов!) Лишь ты и я: Такая моя судьба. Покемон! Он – навек мне друг, Мы миры спасём вокруг! Покемон! (Всех ловить готов!) Душой горжусь, Всё мужеству по плечу, Вас учу И сам учусь, Покемон! (Всех ловить готов,) Всех ловить готов!
Я!
Испытанья волной грядут, Чтоб смелость я постиг: Битвы каждым днём пройдут – Не зря высот достиг! Цель близка, Давай ко мне: Лучших не сыскать. Мы в бою – спина к спине, О чём ещё мечтать?
Покемон! (Их поймать бы смог!) Всегда я и ты, Верны нашей доле мы. Покемон! Он – товарищ мой, Защитим земной покой! Покемон! (Их поймать бы смог!) Дух честен твой, Отвага решает бой: Ты со мной, А я с тобой, Покемон! (Их поймать бы смог,) Их поймать бы смог!
Их поймать бы смог! Их поймать бы смог! Их поймать бы смог! Я!
Покемон! (Их искать – улёт!) Вот мы с тобой, Покорны судьбе одной, Покемон! Он – мой друг навек: Избавлять свет наш от бед. Покемон! (Их искать – улёт!) Тьмы в сердце нет, И храбрость у нас вдвойне: Ты ко мне, Да я к тебе – Покемон! (Их искать – улёт,) Их искать – улёт!
Вот когда однажды понадобилось мне собрать ОДИН список своих игр – я его собрал. Но это было сделано слишком поздно, а чтобы дополнить его всеми описаниями, которые я когда-либо к ним писал – вышло бы значительно дольше и скучнее.
Это у нас-то всегда раскопки хоть и долгие – но конечные. А мне, чтобы на самом деле найти что-то, что я когда либо кому-то писал – это перебирать все документы, все письма электронной почты, все мессенджеры и диалоги в социальных сетях. Я же никогда не собираю ничего в формате, удобном для поиска или экспорта (и кстати, предыдущие два поста к приведению в такой формат дались мне далеко не без труда).
В общем, дальнейшее содержимое не полное как по количеству (тут не всё), так и качеству (описаний могло быть больше), и ещё и собрано из различных мест, но тем не менее, я публикую его.
{{{ В этой игре нужно выискивать цели мышкой, основываясь на расстоянии до ближайшей из них от текущего положения мыши. Управление – только перемещением указателя, кликать нужно только для паузы и старта игры.
В каждом уровне цели расставляются случайно, и они не видны. Пеленгация происходит автоматически, примерно раз в две секунды. Чем ближе цвет волны к красному, и чем меньше общий радиус – тем ближе цель.
По мере распространения волны в кругу шариков на миг возникает цельная полоса, и она наиболее яркая в тот момент, когда радиус как раз равен расстоянию до ближайшей цели (относительно центра испускания).
Если волна выпущена в достаточно маленьком радиусе от цели – это считается попаданием, и закрашивается кружком. После поражения всех целей на уровне, игра переходит на следующий, в котором на одну цель больше.
Количество снарядов (=время) ограничивается в зависимости от числа целей (=уровень), если патроны закончатся – игру придётся начинать с самого начала. В качестве рекордов ведётся статистика максимального достигнутого уровня и минимального количества использованных снарядов на каждом из них.
Игра вполне проходима, если понимать стратегию. Вообще говоря, математически возможно ловить одиночную цель всего за четыре хода, ведь расстояния от трёх различных точек даёт однозначное её расположение. Но со схожими яркостями цветов и многими целями – задача становится не такой тривиальной! }}}
Это программа-помощник для создания японских кроссвордов. В нее встроен решатель, позволяющий убедиться, что кроссворд точно решается без «предположений»: http://klimaleksus.narod.ru/Files/3/JapMaker.rar
Обрывки описания: {{{ Короче, ты – красный, вправо-влево-вверх-вниз. Ушёл за экран = проигрыш. Синие – враги, коснулся = проигрыш. Всё поле – клавиши на клавиатуре, 123,… WER… ASD… ZXC. Розовые кружки по бокам – это два шифта и два контрола. Зажал ОДНУ кнопку и контрол/шифт – стрельнул ТУДА заряд из соответствующей пушки (заряд осколочный). Зажал ДВЕ кнопки и нажал пробел или энтер (что сработает) – пустил два снаряда между ними (если пересекутся, будет осколочный). Зажал ТРИ кнопки – запустил генерацию взрывной волны, которая если скастуется, то почти полполя зачистит. Снаряды могут убить себя и убивают всех врагов. НО! использованные пушки надо перезарядить, иначе из них более нельзя пальнуть. Двойные и тройные также требуют перезарядки – для этого нужно КОСНУТЬСЯ их своим красным шаром. Цель – выжить как можно дольше и завалить всех синих! Каждый выживший и убежавший синий снимает один восклицательный знак из заголовка окна, а их количество отображает время до следующего появления нового синего, так что… (кстати, во многих играх в качестве паузы можно использовать F1). Из «key» надо попробовать мультиплеер кооператив сделать. > "ко-оп режим: пушки дамажат по синим и себе, но не бьют союзника" – Я думал только управление рапараллелить, но не персонажа. Хотя… ИДЕЯ!! )) }}}
О, а вот моё пианино на GML: http://klimaleksus.narod.ru/Files/4/rp.rar Правда, я туда подключил перехват windows-messages через Delphi, чтобы получить абсолютную отзывчивость на события ввода. Высокой ценой, правда. Да и программа получилась какая-то бесперспективная из-за этого.
А вот ещё одна незаконченная 3D-игра: http://klimaleksus.narod.ru/Files/4/ih.rar Уровень – болванка. Один враг, цели нет. Можно бежать и прыгать, приседать. Кстати, если выбросить «свет» и присесть, то враг отвлечётся на него, если не «видел» куда пошёл игрок. Там вообще у врага два режима (их переключение можно увидеть, нажав Z для дебаг-вида) – поиска и погони. В первом он стандартными средствами GML вычисляет пусть к игроку по секте лабиринта, а во втором, когда игрок окажется его поле зрения – движется к нему в лоб, огибая препятствия тоже стандартными средствами. Насчёт этой игры у меня было даже больше идей, но я её что-то забросил…
О, вот математическая игра: http://klimaleksus.narod.ru/Files/4/la.rar Нужно визуально подбирать значения переменных в систему линейных уравнений без видимых коэффициентов.
Вот игра-тренировка, где нужно запоминать последовательность чисел: http://klimaleksus.narod.ru/Files/C/External_12.rar Говорят, нужно исправить режим проверки ответов, чтобы был вариант «пропустить», а не перебирать забытый, чтобы не забыть в это время оставшиеся далее.
Вот украденная идея игры, где мышью нужно щёлкать по правильным кружкам: http://klimaleksus.narod.ru/Files/P/scull_1.rar Нужно тыкать в те, цвет которых совпадает с цветом фона в данный момент. Можно прочерчивать без отрыва. При первом касании остальные меняют цвета. Но инверсный цвет рамки остаётся, по нему всё ещё можно отличить нужные. А на самом деле, игра сетевая! Для запуска сервера достаточно передать любой аргумент при старте, или перетащить на бинарник любой файл, да хоть её же исходник. Подключение по IP к серверу – кнопка S. Старт игры на сервере (только отдельным процессом) – пробел в его окне. Определение победителя довольно чёткое, с учётом пинга до клиентов, однако с полным доверием к ним (т.е подаётся взлому). Жаль, нет адекватного управления пирами, как и таблицы рекордов.
Вот редактор картинок для использования в играх на ZX Spectrum: http://klimaleksus.narod.ru/Files/S/sinc2.rar (своей цели – MLP2048 – я так и не достиг, но и не отверг её) Особенность в том, что поле делится на квадраты 8*8, каждый пиксель которых может иметь либо цвет фона, либо цвет тона. Но эти цвета (коих всего восемь) задаются для каждого квадрата, а не пикселя, из-за чего придётся умело располагать рисунок по четким границам между квадратами.
А ещё я некоторое время в институте преподавал уроки разработки игр на Game Maker, и поэтому у меня появилось несколько концептов, не все из которых стали полноценными играми (но фонтанчики, туннель-драйвер и даже моя охота на лис – именно из этой серии), а так и остались концептами.
Я тут пособирал всё (и не только) отдельно без бинарников в архивчик: http://klimaleksus.narod.ru/Files/4/concepts.rar Имена двухбуквенные (они недостойны большего), везде ниже, где вместо ссылки написано [xx] в квадратных скобках – это одна из папок этого архива. Хотя иногда что-то выложено и по ссылкам отдельно. Для открытия – вот сама среда без ресурсов: http://klimaleksus.narod.ru/Files/S/GML.rar
[de] – воссоздание механики игры «Dark Echo». В оригинале персонаж создаёт звуки во тьме, которые визуально вырисовываются и отражаются от стен. Можно идти, удерживая мышь в стороне, красться путём быстрого нажатия, бросать камень правой кнопкой, а ещё совершать хлопок, удерживая мышь на самом персонаже.
[ml] – это типа битва на двоих. Управление почти как в моём chopduel, но упор был сделан на векторное отталкивание от краёв экрана, соперника и от этой хреновины в центре. Основного игрового процесса нет.
[ff] – концепт основной механики камер первых Five Nights at Freddy’s. Зелёное – игрок. Голубое – текущий вид из камеры. Ну жёлтое – подсветка. Синий – игрок, красные – враги; время, конечно, ускорено. Левый клик – включить нужную камеру. Клик по игроку или правый щелчок в любом месте – закрыть камеру и перейти на игрока. Мышкой можно закрывать двери вокруг себя, но только одну одновременно. Враги движутся тупо по рандому. Персонаж игрока передвигается нажатием стрелок, но только если камера закрыта. А фишка в том, что если враг попадает на камеру – то он должен на неё остаться до тех пор, пока камера с него не уёдет. Если игрок входит в комнату с врагом – проигрыш сходу. Но если камера закрыта, то враг не может войти к игроку, и будет бесконечно ждать в следующей комнате, если выбрал целью хода текущую. А если же камера открыта, и не на этом враге – то он прыгает в комнату к игроку, но игра не закончился до тех пор, пока камера не будет закрыта. Всё это типа для того, чтобы скриммер вылетал только на отклик от действия пользователя…
[ab] – демонстрация того, как например можно сделать быстрое отталкивание шарика от поверхности произвольной формы: считаем по кругу, есть ли пересечения некоторых точек, и выбираем противолежащий вектор. И складываем их… Правда я с коэффициентом прибавки к скорости не разобрался, но управление на стрелках, а добавление стены – правый щелчок.
[gw] – какая-то битва с боссом, мы собирали разные варианты его снарядов, чуть ли не Touhou вышло. One-hit-death, почти непроходимо. А ещё можно через Ctrl оставить бомбочку, которая может убить врага, если её заденет его снаряд. Вторая версия – чья-то модификация в стиле андертейла, там атака уже на Shift.
[gn] – псевдо 3D, тут надо мышкой сбивать летающие тарелки и уклоняться от астероидов…
[pt] – PianoTiles? Управление на F-G-H, жизни в заголовке. Абсолютно непроходимо.
[rn] – вот это чёткая штука. Простой бегунок, с замедлением и ускорением, а также регулируемой высотой прыжка. Не то что мой SpyroRunner, это играть можно бесконечно, и не проигрывать. Перезапуск на пробел.
http://klimaleksus.narod.ru/Files/4/robot.rar – Вот учебный исполнитель «робот», по аналогии с паскальским из PascalABC ( http://klimaleksus.narod.ru/Files/PABCDistr.zip ). Несколько заданий приложены, одно с решением. Можно либо всё прописывать в самом исходнике в среде, либо же перетаскивать решения в текстовых документах на бинарник. Само задание тоже можно перетащить, чтобы посмотреть его. Enter – перезагрузка текущего задания (некоторые слегка рандомные). Хорошо бы сделать новую версию, более багоустойчивую (но нет, я не собираюсь опять gml вручную парсить!..) и с нормальным описанием функционала.
А ведь у меня тоже полно и своих концептов! Вот например какая-то одна хромая реализация квадродерева: [qu] Мышкой можно рисовать и убирать дырки. А ещё в архив я положил какую-то флеш-презентацию про квадродеревья (если я не ошибаюсь, она уже удалена со странички разработчика).
К слову о параспрайтах: [ft] Цели нет, но можно полетать. Хотелось сделать игру, в которой игрок летает в конце игры лучше чем в самом начале отнюдь не потому, что его персонажу чего-то там прокачали, а лишь из-за прокачки собственного скила тыканья по кнопкам. Управление на стрелочках. Спорю, что без подсказки не взлетите)) Нужно удерживать кнопку вверх, быстро отпускать её и нажимать ещё раз. В полёте нужно временно нажать вниз, чтобы немного повысить обтекаемость. И продолжать нажимать вверх с правильным переменным ритмом, который показывает сила взмахов. А для доказательства того, что чётко лететь можно всегда, предлагаю зажать Ctrl. Скорость понизится до 10 fps, а на отладочных шкалах будут выделены те, которые отвечают за силу взмаха. Нужно удерживать вверх до тех пор, пока они не сравняются – отпустить и тут же нажать снова. О, сюжет бы придумать…
Случайные шахматы: [rc] Что будет, если белые будут выбирать любой из доступных ходов, а чёрные – сначала выбирают любую случайную фигуру, которая может ходить, а потом – делают ей возможный случайный ход? Взятие имеет приоритет, правила насчёт короля стандартные. Shift – ускорить время.
Ещё одна проверка физики летящего объекта: [wd] Тут притяжение, ускорение, скорость, подъёмная сила и сопротивление воздуха, конечно же, неправильно подсчитанные. Суть в том, что можно менять свой угол наклона, если он направлен вверх, то ещё и ускорение добавляется (набор высоты, планирование, пикирование). Сверху притяжение сильнее. Управлять всего двумя стрелочками вверх и вниз. Стрелять – удержание Ctrl или вправо, снаряды как бы разгоняются траекторией угла атаки, поэтому их можно закидывать по дуге назад. Пробел – сброс уровня. Ну вообще цели нет, но я поместил бесполезный сверкающий шарик в самый верхний-правый угол, и его можно попробовать достать…
Буквенные кроссворды! http://klimaleksus.narod.ru/Files/4/cross.rar В них нужно собирать слово в таблице букв, рисованием ломаных линий. Эта программа поможет составить такой кроссворд, имея форму поля (не обязательно прямоугольное) и список слов. Картинка считывается из файла, как и слова; сама же программа в полуавтоматическом режиме расставляет эти слова по тычку. Клик по клетке – выпустить оттуда слово случайным образом. Если плохо легло – можно кликнуть по началу правой, и перестроить; каждый раз выбирается максимальное из слов, которые могут поместиться в данное пространство. В принципе, программа не гарантирует, что все слова займут все клетки, но вместо этого даёт статистику, и позволяет выровнять (Pageup/down и стрелочки, в том числе автоматически по Enter) накладываемую сетку по контурам фона. А через Ctrl можно увидеть реальные слова, а не их цветные тени.
Самолётик… [tg] Хотелось сделать игру, в которой у самолёта был бы угол, под которым он летит, влиял бы на его вектор направления; и с учётом силы тяги (на самом деле, это ж предшественник «wd»), потребляющей топливо. А при повреждениях у него могли бы выходить из строя различные системы, и их нужно было бы ремонтировать. Реализация получилась отвратительной… Пробел – стрелять, Enter – чиниться, стрелочки – наклон и тяга. В игру впихано больше, чем отлажено и доведено до ума.
Как-то меня зачем-то попросили сделать имитатор казино для проверки чего-то в теории вероятности: [cs] Там много всего подсчитывается (показываются при наведении), но всё было реализовано неудобно и кучей.
Мощная игра задумывалась: [cd] Я видел такой концепт где-то на Spectrum, смысл в том что корабль плавает по карте, а если встречает подлодку, самолёт или другой корабль – экран переключается на мини-игру, в которой нужно победить врага особенным способом. А я ещё попробовал сделать так, чтобы заезжая на сушу, корабль мог превратиться в танк, а на взлётную полосу – в самолёт. У всего этого разное оружие и управление. Но реализация меня опять не удовлетворила, и я не стал заниматься пустым левел-дизайном, просто бросив игру неоконченной. Оружие меняется на Shift, на пробеле можно уйти в атаку подлодок (там бомбы падают глубину, куда показывает стрелка) или самолётов (там нужно стрелять на Ctrl по самолётам, а прицел показывают конусы четырёх пушек, направляется стрелочками; а уклоняться от атак нужно с удерживанием Shift).
Однажды для чего-то меня просили сделать имитатор ватсаппа, где на экране был бы неинтерактивный интерфейс открытого мессенджера, в котором можно было бы заранее задать текст входящих и исходящих сообщений: http://klimaleksus.narod.ru/Files/4/wa.rar Это для какой-то сценки а-ля КВН и выводом на проэктор. На самом деле, по назначению программу так и не использовали, хотя функционал у меня получился большой, и даже справка есть.
А вот реализация лотереи, чтобы случайным образом выбрать один шарик: http://klimaleksus.narod.ru/Files/4/rb.rar (с секретной возможностью наоборот сделать так, чтобы выпала нужная последовательность)
Вот думаю, это тоже что ли выложить: http://klimaleksus.narod.ru/Files/4/mc.rar – заменил оригинальный текст на лорем. Программа принимает шаблон картинки и большой текст, чтобы расположить его на ней и расширить промежутки между буквами так, чтобы пробелы образовали исходный рисунок. Делал, можно сказать, в качестве своеобразного подарка (вернее, не саму прогу, а конкретную картинку: http://klimaleksus.narod.ru/Files/4/mc.png )
А вот мои старые-старые игры, и некоторые можно даже сказать, хоть сколько-то удавшиеся: (хотя нет, в мусорку всех!) [tm] – тут нужно собирать созревшие помидоры (украл чей-то пак ресурсов), в игре нужная поуровневая справка.
[bk] Банка – сверху падают камни, нужно прыгать залезать на них. Кривая игра с бесполезными понтами, а ещё можно прыгать сверху до касания с летящими, и прошибать стоящий камень кнопкой вниз под собой. Очки несбалансированны, как и недокументированные эффекты от призов…
[rf] Отражения – нужно гонять шарик в правильном направлении, чтобы собирать призы и не попадаться на бомбы. Жёстко сделано, возможно если замутить нормальный физический движок, то пересоздать идею можно будет.
[rr] Рельсы – а тут нужно проехать по железной дороге, запоминая её форму, чтобы собрать максимальное (и минимальное) количество призов. Внутренний расчет реализован был как-то рекурсивно, и ещё есть меню, позволяющее задать параметры генерации уровня.
[tp] А тут исходник даже не мой, я его где-то украл. Блин, будь моя реализация чуть получше, годная бы штука вышла! Простой платформер, с разными типами стенок. Головоломка! Нужно пропрыгать до конца и не проиграть.
[md] Это кончено не Пэкмен, но просто стилизация такая. Идея в том, что нужно собрать по лабиринту боезапас, потом расставить динамиты, а затем – рвануть всё по цепочке, чтобы уничтожить всех врагов! А ещё брать и прятать яйца, из которых потом можно ожить при проигрыше. Тут меня левел-дизайн скорее подвёл, даже имеющиеся карты настолько сложны, что по-моему даже я их не проходил. И сама игра опять же жестковата.
[zd] Зимний дрифт! Реалистичность физики конечно так себе, но тут нужно проехаться вперёд, огибая препятствия (а линии покажут направление к ним). Разные шкалы на экрана отображают какие-то разны параметры, а при ударе об стенку или препятствие управление машиной меняется и переходит в решим скольжения, где нажатие кнопок действует не сразу, и можно лишь чуть-чуть подруливать. В режиме на двух игроков есть оружие (кнопка вниз), которое меняет тип в зависимости от взаимного расположения игроков (а бонус в скорости получает отстающий). И есть режим автопилота, когда компьютер сам рулит (и вот как раз эту идею ИИ я и использовал в TunnelFlyer), и даже есть битва с компом отдельным режимом; кнопка вверх – быстрое ускорение с низкой скорости ценой дрифта.
[ms] Сапёр. Хотел сделать так, чтобы первым ходом не открылась не только бомба, но и просто всегда была пустая клетка. Хотя нет, с тех пор как я узнал, что на стандартный сапёр в XP есть крутой чит-код, моя реализация стала априори хуже.
[fs] Просто быстрая штука, чтобы «растрясти» стереограмму. Такую, как с сайта http://hidden-3d.com/
[db] О-о, а рпг-задумка была-то большой. Биться на Ctrl при пересечении с врагами, магия – на пробел, сменить магию – на Pageup/down (сбалансировано плохо).
[lv] Тугая неинтерактивная реализация игры «жизнь».
[bl] Какая-то неудачная реализация игры наподобие «три в ряд», перетаскивать мышью.
[pl] Украденная идея игры про диспетчера, где нужно перетаскивать самолётики на посадочные полосы, и не давать им врезаться. При зажатом Shift их поведение становится очевиднее. Правый щелчок – посадить готовящийся к посадке самолёт.
[dm] Какая-то очень старая моя демонстрационная игра, но вышла она уж с очень жёстким управлением. Стрелять на пробел.
[hc] Какой-то хоккей, где нужно запихивать мячик в ворота во время пересечений с ним. Там есть даже не только режим для двух игроков, но и мультиплеер, через встроенную в игру мою же обёртку для мультиплеера в Game Maker. Обёртка фиговатая и нелогичная, но на удивление как-то работает.
[sn] Плоходокументированная змейка с тем же модулем мультиплеера, но тоже какая-то грубоватая и не очень.
[pg] Погоня… первоначально – как модификация исходного же образца самого Game Maker. Управление стрелочками. Глупая и нудная игра. Вторая версия – уже на мыши, нужно просто удерживать шарик под курсором, а потом и кликать по нему.
[sw] Очень неудачная реализация махания световыми мечами: управление стрелочками; двойное нажатие в сторону – полный оборот; удерживание пробела – щит; Ctrl – убрать меч – без него пробел выбрасывает магию, дающую контроль над врагом или стеной, которую она коснётся.
[gr] – это головоломка, когда дано разноцветное поле, нужно пройти по цветам из одной точки в другую, сохраняя всегда одну и ту же последовательность цветом Для старта, слева нужно нажать последовательно при кнопки, а потом перетаскивать персонажа мышкой по полю справа (вернее, он сам за мышью следует). Странно, но мне хватило самого факта того, что я смог реализовать этот концепт, и такие вещи как улучшение управляемость или адекватность меню меня резко перестали интересовать… Любая кнопка на клавиатуре – перезапуск.
Во многих вышевыложенный играх, даже если и написано, что справка есть – на самом деле её нет. Если я где-то забыл указать управление – то обычно это стрелочки, Ctrl/Shift/Enter/пробел. А ещё я раньше делал такие щедрые начальные экраны, и указывал на них своё авторство. Потом, когда стало чуть-чуть стыдно за такие дурацкие реализации, мои копирайты стали более скромненькие и краткие.. Ну и теперь вот я вообще стараюсь ничего такого не указывать в самих играх, разве что может быть в справке либо даже просто в названии версии в самом ресурсе для .exe
Вдогонку – уже довольно старая моя копипаста:
Я манал это MIDI.
Целую неделю убил на то, чтобы закончить клёвую программу, которая, видимо, призвана стать программным синтезатором, умеющим считывать .mid и воспроизводить через колонки (буду называть динамики так, чтобы не путать со спикером) или pc-speaker. Если построить пересечение и разбитие шкалы времени на такие участки, где играет равное количество нот – то их и надо будет выводить на спикер быстрым перебором; иначе – ровной нотой. Для вывода в колонки можно либо так же порезать, либо играть как в оригинале, с любыми объединениями нот.
Потом я упарился с «инструментами» – прямоугольным, пилообразным, треугольным и синусоидальным сигналами. Оказалось, что громкость каждого на слух может сильно отличаться от других, а загуглив конкретно ВО СКОЛЬКО РАЗ, мне выходило разве что «ой-ой, это всё субъективно, ибо даже звуки разной частоты ощущаются с разной громкостью». Но я всё же выбрал примерно некоторые цифры …
А затем выяснилось, что происхождение миди-файлов может быть насколько угодно корявым, и в них может меняться темп воспроизведения, уф! Дело в том, что я не писал свой миди-парсер (несмотря на то, что я хотел просто вытащить массив всех нот с их временами, длительностями, номером инструмента и канала – все остальные события, все-все – меня не интересуют..), потому что понял, что без парсинга ВСЕХ событий там не обойтись; а нашёл готовую реализацию на Delphi. Но оказалось, что в ней игнорируются события изменения темпа и масштаба времени, из-за чего многие файлы воспроизводились неправильно. И когда я попытался сам разобраться со временем, я вконец запарился со структурой формата, где куча формул и условностей, зависящих от кучи всяких параметров.
Нашёл ещё одну реализацию полноценного синтезатора, но она оказалась наоборот же такая большая и сложная, что я не смог вытащить из неё нужную мне часть, а всё вместе у меня компилироваться не хочет.
Короче, я пока ставлю крест на своей идее, потому что от неё меня уже тошнит. Исходник: http://klimaleksus.narod.ru/Files/4/midi2something.rar – там полный бардак, куча неиспользуемых функций и закомментированных кусочков. Я это вообще из трёх других программ собрал. По умолчанию он сейчас запущен как софт-синтезатор с несколькими инструментами (там файлик, на котором более-менее нормально воспроизводится). Если изменить константу на строке 806, то включается режим деления на участки с равным количеством нот; хотя у меня такое чувство, что там уже что-то сломалось (этот режим я делал первым, а потом ж значительно менял всё вокруг). Теперь если изменить 720, то воспроизведение переходит к спикеру, но играется только первая соло-нота. Изменив 348 можно получить многоголосый перебор, но добавил я его только что и весьма грубовато (а ведь это чуть ли не основное, что должно работать идеальнее прочего!..)
Может когда-нибудь перепишу эту программу заново (там ещё столько всего планировалось: много опций запуска, затухания и громкости, фильтр и мап каналов и инструментов, поддержка других трекерных форматов, вывод на миди или разные wave-устройства, сохранение в звуковой файл…), если найду как нормально миди распарсить.
Ха, а вот pcstream – другой франкенштейн, к которому я пришёл, когда захотел выяснить, можно ли заставить Windows воспроизводить стандартные звуки через спикер. Всё же элементарно – либо найти заводскую функцию, которой нет; либо указать на миди-файл (и сделать свой виртуальный драйвер миди-устройства…), что тоже невозможно. Тогда я подумал, что это ж можно программой наподобие виртуального аудио-кабеля, перенаправляющей выходное wave устройство (если поставить его по умолчанию – системные звуки тоже пойдёт через него) на другое входное, которое можно считывать (как на запись с микрофона) другой программой, которая уже будет перенаправлять найденные в wave частоты (не-а, таки БЕЗ разложения Фурье) на спикер.
Что, собственно она и делает. Ну анализ там слабенький, со многими предположениями о входном сигнале (нужная громкость, нужная форма, нужный диапазон частот и выравнивание по нулю, равное распределение в положительную и отрицательную амплитуду), то есть «всё подряд» один фиг играть не сможет. Но если заранее формировать wave файлы с синусоидальным сигналом, то по идее она идеально должна переваривать и выдавать чистую ноту (там я ещё привязку к нотнам midi-диапазона сделал, чтобы небольшие отклонения частоты не сразу меняли тональность).
Эту прогу я придумал только что, после вашего письма. Ага, а теперь угадайте, зачем я сейчас стал париться с предыдущей программой. Именно для конвертирования миди в СИНУС для этой.
Ну а к этой нужно ещё добавить выбор входного устройства, и чтение звука из файла (оно там было, но я его уже успел поломать). Но вообще говоря, поиграться с микрофоном можно хоть сейчас ^^ Там, конечно, задержка (как-то я не очень пряморуко с буферами работаю, и таймлаг у меня ещё и копиться в ту или иную сторону – поставил явные условия на пропуск или добавление семплов при отклонении, это же явно как-то неправильно) ощутимая, но это очень прикольно наблюдать, как спикер пытается «повторить» тот звук, который слышит микрофон. У него можно даже ртом ноту издавать. А можно и на колонки чистый синус по нотам пустить, прижав к ним микрофон – вообще чётко играть будет. В прочем, можно замкнуть микрофон на себя, прислонив к спикеру же – и получить самогенерацию. О, чувствительность регулируется в строке 290, это шестнадцатибитное число (порог регистрируемой амплитуды). but nobody came
Редактор
