Стандартный Email — прекрасное приложение, тем более, что по сравнению с более старыми версиями, туда завезли unified inbox и поддержку imap push. Тем не менее для моих сценариев использования мне нужно ещё поддержка OAUTH-аутентификации (gmail, янжекс почта), html signature и возможность иметь несколько identity для одного аккаунта. Кроме этого есть ещё ряд мелочей, в которых стандартный email, увы, проигрывает
Сейчас у меня установлен обычный LineageOS 17 (который базируется на Android 10) + microG, так что это не какая-то особая версия андроида. Вставлять текст в поле с паролем конечно же можно.
Что касается копирования пароля чтоб потом увидеть его обычным текстом, то мне такое никогда раньше не надо было, но сейчас проверил — скопировать из «парольного» поля нельзя. Но мне кажеся, что есть какой-нибудь XPosed-модуль для этой цели.
Сам по себе Google Pay без родных GSF работать не будет скорее всего, а если ставить GSF, то для меня теряется вся суть кастомной прошивки. Если вам такое не критично, то ставите OpenGApps, через Magisk накручиваете чтоб проходился SafetyNet (инструкций в интернете много, но потребуется доля везения), и тогда Pay должен работать (наверное :))
А в чём вообще его суть (я никогда не пользовался)? Оплана телефоном через NFC?
Два байта это неспортивно. Вот мы тут поджались, и зарелизили аж целый язык программирования размером в 1 байт для ZX-Spectrum — www.pouet.net/prod.php?which=85125
Смысл ограничения более чем понятен, но трактовка очень размытая.
Давайте рассмотрим на таком гипотетическом примере — допустим, прислали вам игру Dancing Box, смысл которой заключается в том, что нажимая на пробел, нужно в такт музыке прыгать квадратиком избегая препятствий. Невооруженным взглядом видно что это «закос» под geometry dash, тем не менее закос исключительно на уровне геймплея и использования простых геометрических фигур вместо прорисованной графики.
Допускается ли такая гипотетическая игра «по мотивам», или это too much?
1) «Игра должна запускаться на оригинальном ZX Spectrum 48K или 128K» (изначально было «и 128K») — т.е. по сути 128K only можно, так?
2) «Она не может быть создана по мотивам игр, обременённых авторскими правами, или их продолжением» — насколько широко следует это трактовать? т.е. если, допустим, игра будет использовать механику, похожую на уже существующую, но совершенно другое название, уровни и т.д.? а если при этом графика состоит из геометрических примитивов, как в уже существующих играх? например, игра по мотивам geometry dash или, там, thomas was alone?
Если это планируется использовать где-то кроме как в качестве обучения, то почти все ОС предоставляют специальные механизмы для отслеживания изменений файлов, чтобы не делать while (true) { ... }. Гугл подсказывает, что есть кросс-платформенные библиотеки, например — github.com/emcrisostomo/fswatch
Да, это сработает. Но на мой вкус будет меньше гибкости — в текущей реализации комната может быть 3x3, 4x4, 5x5 и т.д., а в реализации где тайл генерации — 3x3 в карте комнаты будут 3x3, 6x6, 9x9 и другие кратные 3м.
Но если вы будете использовать подобный метод генерации для вашей игры, и вас это будет устраивать — why not?
Генератор писался под конкретный движок, в котором стену нельзя поставить между двумя рядом стоящими тайлами (т.к. сама стена размером минимум 1x1 тайл)
Размер уровня зависит от изначального размера поля, оно конфигурируемо (и не обязательно квадратное).
> Сценарий получается линейным?
В этом генераторе сценарий всегда линеен (т.е. не может быть такого, что, например, игроку сразу доступно два ключа, которые нужны будут потом).
Но это не означает что не придётся походить, например, итоговый путь может быть такой: A -> B -> A -> C -> A -> D -> E (при этом сценарий линеен — A открывает B, B открывает C, С открывает D, D открывает E)
Не исследовал этот вопрос. Вероятно, когда уровень уже будет в реальной игре, то сложность будет определятся не сколько хитроумностью лабиринта (в игре есть карта), а скорее количеством врагов, их «крутостью», количеством аптечек, патронов и т.д.
> Также сказано, что время неважно. Но сколько уходит на генерацию уровня, несколько секунд, минут?
На глазок — пару секунд. Думаю, если убрать всё что связано с логгированием и записью промежуточных картинок, то должно отрабатывать примерно мгновенно.
Если про неквадратное поле, то с этим всё ок — изначально поле может быть прямоугольным.
Если про стены не под 90 градусов — то я в эту сторону не копал, т.к. для моих целей это не нужно (скорее наоборот, мне очень нужно чтоб все стены были под 90 градусов). Вероятно, можно вместо «полибоксов» делать обычные полигоны, и сглаживать углы.
Мне кажется, что часть вопросов к статье отпадёт, если сказать что пин — это не обязательно 4х-значное число, а вполне себе может быть неким очень непростым мастер-паролем.
Я как раз использую похожий метод хренения паролей, вместо пина — мастер пароль (сам по себе хороший и рандомный — это единственное что надо запомнить). Только в результирующем пароле использую шестнадцатеричные цифры — при достаточном количестве символов секурность не уменьшается, а набирать пароль на разного рода мобилках становится в разы проще.
Использую такой подход — sha1(«осмысленная для меня фраза»), первые 12 — 16 символов (для почты, банка и т.д. — больше). Ресурсы делю на группы, для левых каких-нибудь — одна и та же фраза, для более важных — разные для каждого.
Плюсы:
— пароль достаточно криптостойкий, причём его можно ввести, наверное, на любом устройстве;
— даже если пароль узнают, можно легко сделать новый путём добавление к фразе номера (1, 2, etc), причём хэш получится абсолютно другим;
— если забыл пароль, но помнишь фразу, достаточно любого ЯП с нужной хэш-функцией чтоб его восстановить, причём не нужен доступ к интернету.
Минусы:
— сложно запомнить (хотя через некоторое время начинаешь привыкать).
Стандартный Email — прекрасное приложение, тем более, что по сравнению с более старыми версиями, туда завезли unified inbox и поддержку imap push. Тем не менее для моих сценариев использования мне нужно ещё поддержка OAUTH-аутентификации (gmail, янжекс почта), html signature и возможность иметь несколько identity для одного аккаунта. Кроме этого есть ещё ряд мелочей, в которых стандартный email, увы, проигрывает
Что касается копирования пароля чтоб потом увидеть его обычным текстом, то мне такое никогда раньше не надо было, но сейчас проверил — скопировать из «парольного» поля нельзя. Но мне кажеся, что есть какой-нибудь XPosed-модуль для этой цели.
А в чём вообще его суть (я никогда не пользовался)? Оплана телефоном через NFC?
Давайте рассмотрим на таком гипотетическом примере — допустим, прислали вам игру Dancing Box, смысл которой заключается в том, что нажимая на пробел, нужно в такт музыке прыгать квадратиком избегая препятствий. Невооруженным взглядом видно что это «закос» под geometry dash, тем не менее закос исключительно на уровне геймплея и использования простых геометрических фигур вместо прорисованной графики.
Допускается ли такая гипотетическая игра «по мотивам», или это too much?
1) «Игра должна запускаться на оригинальном ZX Spectrum 48K или 128K» (изначально было «и 128K») — т.е. по сути 128K only можно, так?
2) «Она не может быть создана по мотивам игр, обременённых авторскими правами, или их продолжением» — насколько широко следует это трактовать? т.е. если, допустим, игра будет использовать механику, похожую на уже существующую, но совершенно другое название, уровни и т.д.? а если при этом графика состоит из геометрических примитивов, как в уже существующих играх? например, игра по мотивам geometry dash или, там, thomas was alone?
while (true) { ... }. Гугл подсказывает, что есть кросс-платформенные библиотеки, например — github.com/emcrisostomo/fswatchНо если вы будете использовать подобный метод генерации для вашей игры, и вас это будет устраивать — why not?
Размер уровня зависит от изначального размера поля, оно конфигурируемо (и не обязательно квадратное).
> Сценарий получается линейным?
В этом генераторе сценарий всегда линеен (т.е. не может быть такого, что, например, игроку сразу доступно два ключа, которые нужны будут потом).
Но это не означает что не придётся походить, например, итоговый путь может быть такой: A -> B -> A -> C -> A -> D -> E (при этом сценарий линеен — A открывает B, B открывает C, С открывает D, D открывает E)
Не исследовал этот вопрос. Вероятно, когда уровень уже будет в реальной игре, то сложность будет определятся не сколько хитроумностью лабиринта (в игре есть карта), а скорее количеством врагов, их «крутостью», количеством аптечек, патронов и т.д.
> Также сказано, что время неважно. Но сколько уходит на генерацию уровня, несколько секунд, минут?
На глазок — пару секунд. Думаю, если убрать всё что связано с логгированием и записью промежуточных картинок, то должно отрабатывать примерно мгновенно.
Haxe (https://haxe.org/), не?
Я как раз использую похожий метод хренения паролей, вместо пина — мастер пароль (сам по себе хороший и рандомный — это единственное что надо запомнить). Только в результирующем пароле использую шестнадцатеричные цифры — при достаточном количестве символов секурность не уменьшается, а набирать пароль на разного рода мобилках становится в разы проще.
Плюсы:
— пароль достаточно криптостойкий, причём его можно ввести, наверное, на любом устройстве;
— даже если пароль узнают, можно легко сделать новый путём добавление к фразе номера (1, 2, etc), причём хэш получится абсолютно другим;
— если забыл пароль, но помнишь фразу, достаточно любого ЯП с нужной хэш-функцией чтоб его восстановить, причём не нужен доступ к интернету.
Минусы:
— сложно запомнить (хотя через некоторое время начинаешь привыкать).