freeExec

Веса принято держать в районе нуля - что-то типа +/-1. В итоге, если мы будет просто в лоб брать порядковый номер, то нейронке надо и порядковый номер 2 и порядковый номер 20 как-то приводить в свою нутрянку к маленьким числам (нормировать), иначе слово в позиции 100 будет иметь в 100 раз больше значимость, чем первое.
Поэтому тут нужно какое-то векторное кодирование из небольших чисел. Сразу напрашивается двоичный код, он в принципе подходит, но его минус в том, что получается тоже большой разлёт, то 0 то 1. Синус же дает несколько промежуточных значений. В принципе кодировку можно было бы и захардкодить, но зачем, когда синус сделает это за нас.

Использовать MemoryProfiler: сделать снапшот до смены сцены и после. Там же в режиме сравнения будет видно разницу, какие объекты добавились (и убавились, но нас они не интересуют). Вот дальше и начинаете расследование, что за объекты, почему остались, а не удалились.

Какой-то волшебной галочки в настройках, исправляющая увеличение памяти не существует.

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

Ну вообще это странно, просто передавать тип. Можно как и в твоём примере Func1("hello".GetType())

Но вообще мода давно перешла не генерики.

string text = Func1<string>();

T Func1<T>()
{
    return (T)myPrivateObject;
}

Но ведь это не одно и тоже, обращаться к одному и тому же экземпляру или каждый раз создавать новый. Хотя может быть такая реализация (например через playerprefs), что будет казаться, что нет разницы. Но в общем случае ты стреляешь себе в ногу, потому что в любом другом варианте у тебя получается такая логика:
1) выполнил квест -> создал пустой инвентарь и положил туда 100 монет. (теперь в этом экземпляре 100 монет)
2) выполнил другой квест -> создал пустой инвентарь и положил туда 100 монет. (теперь в другом экземпляре 100 монет)
3) отобразить монеты -> создал пустой инвентарь, показал 0 монет.

Вся суть из твоей портянки тут

> com.android.ide.common.signing.KeytoolException: Failed to read key release from store "D:\bikemap\bikemap\user.keystore": Cannot recover key

Не знаю, что ты с ключом сделал, но он похоже запорот.

Давно это было могу наврать.
Есть сеть, которой на вход приходит несколько последних состояния среды и она предсказывает действие.
Потом можем каждый шаг обучать: заработали очки - положительная обратная связь; не чего в общем не произошло - немного штрафуем; умерли - большой штраф. Ну и дальше тут большое поле для экспериментов, за что ругать, а за что хватить и как сильно сеть.

Есть setCentre и setZoom, что тут ещё надо

Извлеки из tokenizer.json vocab и сохрани в vocab.txt

Сложно, особенно если возникает такой вопрос, то можно сказать невозможно.

Решения есть, 2ГИС

Удел без программирования это geojson на github-е, где каждый зарегистрированный может предложить модификацию файла с добавлением новых мест с атрибутами.

У метки есть событие клика. Вот по нему и начинай перемещение куда нужно.

Нет таких домашних ПК где у тебя 512ГБ оперативки. Можешь конечно взять SSD и повесить на него своп, но тогда о каком комфорте может идти речь при скорости токен в пару минут.

Зачем тут платный яндекс, бери ФИАС/ГАР

Если физика висит, то значит Time.timeScale = 0

Чтобы узнать в какое место смотрит пользователь, нужно на каждое перемещение карты отправлять запрос геокодеру, чтобы он сказал, что по этим координатам расположено, ну и там уже принимать решение.