Николай Алексеев

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

->where('Comments', '>', 8)

Дополняю ответ для большей достоверности

Мой ответ дан ровно так, как задан вопрос. Однако же, в реальности комменты, и их число не будут храниться в той же таблице. Скорее всего, есть какая-то таблица с внешним ключом на таблицу компаний, вам нужно сделать JOIN этой таблицы и в условии опираться уже на количество записей в ней, а не в основной таблице.

По делу: для того, чтобы понимать, что в вашем коде не так, научитесь пожалуйста читать текст ошибки. Там написано 100% нужной для решения проблемы информации.

В вашем случае: Non-invocable member 'Transform.rotation' cannot be used like a method.
Вы не можете использовать член класса как метод, как функцию, если вам так удобнее.

Вы пытаетесь задать поворот, вызывая ротейшн и отдавая ему координаты.

Вторая ошибка, в принципе, имеет те же корни. Просто почитайте документацию по работе с позицией и поворотом.

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

Если вы пользуетесь Visual Studio, то просто кликните мышкой на проблемном интерфейсе (IBeginDrug... и IEndDrug...) и нажмите alt+enter, VS предложит вам реализовать интерфейс явно или нет.

Если же не VS, то... переходите на VS.
А по совести достаточно просто прочитать документацию по указанным вами интерфейсам, что они делают и зачем.

Можно попытаться сделать сокетами, как посоветовал adam_carraway , но в данном конкретном случае - это выглядит перегруженным решением.

Мне кажется самый простой и правильный способ в данном случае - ajax запросы по таймеру раз в 1-2 секунды это более чем достаточно для описанной задачи.

Если же нужно чтоб прям ну моментально, то действительно гуглите comet технологии и используйте то, что подойдёт.

Небольшой некропостинг, но всё же.
Авось кому-то пригодится
Я решил проблему так

$message = mb_convert_encoding($message, 'UTF-8', 'UTF-8');

Готовых библиотек нет 100%, а если и можно найти что-то (в чём я лично сомневаюсь), то оно скорее всего будет платным.
Здесь нужно решить несколько задач:
1) Придумать как воспроизводить звук.
Средствами чистого JS и HTML5 это делается в одну строчку кода. Другой вопрос, какой звук нужно воспроизводить
Тут я виду два варианта:

1. Использовать предзаписанные звуки нот - звучать будет скорее всего красиво, но тяжело и много подготовительной работы
   
2. Воспроизводить звук средствами MIDI - легче и продуктивнее, можно посмотреть в сторону (midi.js)
   

2) Необходимо решить что именно воспроизводить. Так как табулатуры можно писать в разных программах, а не только гитарпро, то, скорее всего правильнее будет идти по пути универсализации. Так или иначе, gtp - это проприетарный формат и читать его на стороне JS будет дюже затратно. Как мне кажется необходимо на стороне сервера парсить загружаемый туда файл таб и преобразовывать в midi или какой-то собственный формат и уже его отдавать на воспроизведение.

Исключительно отдельно. При необходимости, можно одним fbx, но при этом объекты должны быть обязательно самостоятельными мешами.
Идея в том, что с точки зрения производительности Юнити с большей любовью и трепетом воспринимает отдельные объекты. Движку не нужно держать в памяти всю модель уровня, а значит не придётся есть ресурсы целевого компа. Плюс, при самостоятельных объектах локацию проще будет редактировать прямо в движке, это позволить использовать повторяемость предметов, чтобы каждая условная "кружка" или "бочка" на карте были не самостоятельными мешами, а просто дубликатами одного и того же. Что также значительно сократит потребление ресурсов. Ну и никто не отменял запекание окружения.

Мой ответ вам скорее всего не понравится, но, как человек, занимающийся геймдевом уже больше 5-ти лет могу сказать наверняка: пока никак.
Уроков вы не найдёте 100%, так как задача уникальная. И, если и найдёте, то это будет просто кто-то кто так же бился и чего-то да добился - это не уроки, это просто один побитый жизнью делится опытом с другим.

Подход должен быть следующим:
1. Учимся работать с инструментом (в вашем случае это движок)
2. Учимся программировать (хотя бы базовые знания шарпа нужны обязательно)
3. Очень долго сидим над бумажкой и разбиваем вашу будущую игровую механику на составляющие, такие как тот же драг н дроп, а то и мельче.
4. Пробуем реализовать каждую отдельную задачу. Под них уже вполне реально найти уроки. Можно делать это даже не в основном проекте, а заводить новый ради каждой фичи. Так как это обучение, так будет даже логичне.
5. И вот только потом собираем всё в кучу, но уже не бездумно, а с пониманием, что вообще происходит

Код функции, которую я использую в своих проектах.
Подразумевается загрузка с помощью AJAX, то сути дела это не меняет

public function uploadGallery(Request $req) {
	try {
		$files = $req->file('photo');
		foreach ($files as $file) {
			$tmp1 = md5(microtime());
			$tmp2 = md5(uniqid());
			$newName = strtolower(substr(base64_encode($tmp1 . $tmp2), 0, 7)).'.'.$file->getClientOriginalExtension();
//здесь важная поправка куда перемещать - это абсолютный путь
//так что к слову media в моём случае нужно ещё применить функцию base_path или конкотинировать результат функции public_path
			$file->move('media', $newName);
			//Storage::putFileAs('/public/ //строчка закомментирована, но можно использовать её
		}
	} catch (\Exception $err) {
		//$errorcode = $err->getMessage();
	}
}