Если вы работаете с регистрами с каким-то своим устройством у которого несколько кб памяти возможно и и затратно, но не проверял. А так не понятно о каком языке вообще идет речь
Ну первая мысль, алгоритм начинает свою работу сверху вниз слева направо, тоесть с левой верхней точки.
Изначально у нас есть список всех точек, убираем из списка левую верхнюю точку. Далее условно от это точки проводим так скажем угол обзора (на картинке оранжевые линии), находим все точки из списка которые попадают в этот угол обзора и берем ближайшую, исключаем эту точку из списка и опять от нее повторяем такой же алгоритм. Если точек в углу обзора не найдено или они слишком далеко опять ищем крайнюю левую верхнюю и списка и продолжаем строить такие цепочки( цепочки обозначены черными линиями), по итогу думаю не составит труда уже определить сколько строк (это количество цепочек), а кол-во столбов (это максимальное количество точек во всех цепочках). Ну тут стоит поиграться с углом и возможно еще с расстоянием, чтобы исключить варианты как на второй картинке. Для это стоит найти для каждой точки расстояние к ее ближайшей точке и взять среднее из всего этого и если расстояние при построении цепочки сильно отличается от этого среднего расстояния, то не учитывать такие точки...
Ну это так первая мысль, если посидеть я думаю можно что нибудь получше придумать.
Зачем удалять меш, а камеру оставлять , если его просто нужно полностью удалить у живых, ну и оставлять у мертвых чтобы они друг друга видели я так понимаю.
Мне кажется пока вы научите нейросеть определять все эти параметры, за это время уже 100 раз можно это руками будет заполнить.
Нужно найти группу китайцев которые по быстрому все просмотрят и все заполнят :D
Шахмаев Анвар, причем тут лок, если клиент делает запрос к серверу, на чем лок будет висеть? Сервер один, а клиентов много и у каждая отдельная машина.
Ну Race Condition чаще всего подразумевают когда несколько потоков используют один ресурс приложения, например переменную, а тут всетаки внешний ресурс который предоставляет свой функционал в виде транзакций, который позволяет решать такие проблемы
Шахмаев Анвар, да ситация как раз довольно тривиальная, ну и я бы не сказал что это даже многопоточное программирование, вот если бы вы один конекшн или контекст делили, а так все вопросы разделения решает движок бд.
И вы говорите про какой-то сервер, и что запрос к серверу сделать синхронным?
Если от клиентов, то запросы невозможно сделать синхронными. Если под сервером вы подразумаете бд, то запросы к ней и так синхронно выполяются, просто движок бд может их выстраивать в очередь, и если у вас бд падает от 1000 одновременных запросов, то у вас какая-то странная бд.
Vitsliputsli, Ну во первые на мало-мальски нагруженной системе это не вполне реальная ситуация, а ситация на один миллиард. Тут должны совпасть такие факторы как должен заканчиваться какой-то товар, и кнопку оформления должны нажать прям с разницей в несколько миллисекунд максимум и даже если все это сложится, то еще должно очень повезти чтобы это в коде не правильно отработало.
Во вторых люди которые делают прям сильнонагруженные системы, знают что такое транзакции и не спрашивают такие глупые вопросы на тостере.
Ну и в третьих это не связано никаким образом с обработкой денежных операций, в любом случае каждый заказ потом обрабатывает менеджер, который продвигает его дальше и если уже вы такой счасливчик и на вас сошлись звезды, вы заплатили, а товар уже зарезервирован на другого, то менеджер вам перезвонит и решит такую ситуацию сделает возврат денег или предложить выбрать другой товар, они такие вопросы решают постоянно, потому-что скорее вы не заметите что клацнули на красный цвет товара и оплатили, а потом оказалось что вы думали что выбрали зеленый, чем ситуация описанная выше.
Ну и четвертых я не сказал что нужно забивать на это и делать как попало, я сказал что просто чаще всего такими вопросами не замарачиваются фрилансеры, разрабатывая какой-нибудь мини интернет магазин. Пишите код правильно и не будет никаких проблем! (шучу, проблемы всегда будут...)
Kotovasofa, нет на бекенд вы можете передать данные, чтобы там делать свои секретные расчеты по секретным алгоритмам, которые должны быть скрыты от глаз желающих их украсить.. А вообще, чесно говоря, ваш конструктор ***** никому не нужен, потому-что это примитивная вещь, которую проще разработать с нуля чем разбираться в чьём-то коде после обфускации. Я понимаю у вас бы там был супер навороченный конструктор в 3д, с функционалом что кнопку нажал и тут тебе симуляция воды риалтайме в басейне ....
