man_cubus

благо есть волшебный MCEdit, а в 1.12.2 - еще и всякие инструменты для создания кастомных генерируемых структур. а убежища можно генерировать с помощью компьютера, как раньше должен был работать Улей.

Флаг в руки, дерзай, запиливай свой рандомно генерируемый еще один вариант на тему фоллаута.

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

и даже если убрать еду, то откуда ее игроки будут добывать? в убежище нормальную ферму не построишь...

Калька с фоллаута например: подземные убежища/склады/военные базы.

Именно для того чтобы не связывать себя этим сюжетом я думал о варианте с крушением в безвоздушном пространстве. Потому что все эти фоллаутоподобные прелести - это кастомная карта. С отстроенными вручную базами, автоматизированной защитой, минными полями и прочими армейскими приколами, которые просто так автоматически не сгенерируешь.

@@Kartze Серьёзное радиоактивное заражение исключает полезность предметов из деревень на поверхности

Насколько я помню, кислород же генерируется какими-то механизмами. Или они тоже будут отключены? Тогда чем этот вариант отличается от бункера, из которого нет возможности выбраться?

Тем, что вот прям на старте будет скафандр и один полный средний баллон.

Механизмы будут в сундуке и да, на старте придётся повозиться чтобы достаточно быстро их установить и не задохнуться.

У меня есть похожий, но несколько отличающийся вариант этой идеи. Скорее всего на основе галактикрафта или advanced rocketry. Без сидения в ангаре и "отрезания рук".

 

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

Эту локацию смогут уничтожить другие игроки, но не криперы.

 

При необходимости раз в пару суток должна быть возможность начать заново, с уничтожением старой стартовой локации и генерацией новой. И никаких телепортов вообще впринципе.

 

В идеале - никаких планет с кислородом вообще.

Когда-то ... В давние времена ... Моей креативности, хватило только на - чтобы немного "растянуть" свои инициалы ...

Позже понял, что звучание этого ника - похоже на что-то на латыни.    Что-то из DOOM-а 

Да, знакомая история.

Скорее согласен с мнением ораторов выше чем не согласен. Не вижу смысла в еще одной такой броне и вот почему: эта броня не использует ничего принципиально нового. Ну то есть концепция защиты игрока айтемом - старая. Концепция улучшенной защиты - старая. Нового в ней только модульность (хотя есть вообще то ModularArmor) а та же продвинутая защита достигается в ванильном майнкрафте зачарками.

Нет нововведений, нет ни одной действительно новой механики (какими в тауме, например, являются алхимия и ритуалы).

 

У меня самого также есть идея (нет, не про самодвижущуюся броню, которую лучше заменить транспортом типа поезда из РК), но я еще нескоро до неё всерьёз доберусь; так чтоб прямо код писать и в сборке тестировать. А пока не добрался - пару раз обсудил с опытными людьми для лучшего понимания что и как и взгляда со стороны, который бы мне сходу указал на ляпы и принципиальные недочеты в идее. И этого достаточно на самом деле.

 

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

Недавно видел в какой-то теме про сворачивание блоков кода, которые завернуты в do ... end

Попробовал то же в своем sublime и увидел как оно работает. Захотелось бОльшего

 

Немого поковырявшись в гугле разобрался как в sublime 3 добавить подобную свертку для любого синтаксиса. Включая Lua

 

С помощью PackageControl устанавливаем SyntaxFold

Идём в Preferences -> Package Settings -> SyntaxFold -> Settings - User

Добавляем такую запись для сворачивания функций и таблиц:

{
    "scope": "source.lua",
    "startMarker": "local function, function, {",
    "endMarker":"end, end, }"
},

По аналогии можно добавить более специфичные маркеры после чего перезапустить редактор

 

Теперь по Control+Shift+[ , Control+Shift+] , Control+K, Control+Цифра а также командами в меню Edit -> Code Folding можно сворачивать и разворачивать блоки внутри назначенных маркеров.

 

Если тут есть еще любители саблайма кроме меня, новые полезности и удобности для луа - приветствуются

 

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

Можно даже еще короче и быстрее если цвета пронумеровать с нуля. Закоммитил. Пока не тестировал, но сегодня вечером погоняю на своих роботах.

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

На серверах по полтора человека играет, поэтому никакого смысла в таких ставках нет.

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

 

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

Твой друг ставит ставку, на то что ты перестанешь заходить на пару недель. Не заходишь. Профит делите пополам.

Ты плохо понимаешь механику ставок.

Если никто другой не ставит на контрслучай, то ты просто получаешь свою ставку обратно (минус пошлина в пользу организаторов).

А в описанном тобой случае ты получаешь свою ставку минус пошлина и ставку твоего друга минус пошлина.

Если кроме тебя и твоего друга ставил кто-то еще тогда профит будет. Иначе - нет. На себя разумеется ставить нельзя.

А что если то же самое, но вместо котировок ценных бумаг будет тот самый пресловутый "уровень сигнала".

Желательно не на результирующий уровень, а на данные по онлайну за неделю.

То есть фактически ставки будут делаться на прогноз колебаний онлайна других игроков.

Однако он получает энергию от встроенной солнечной панели.

Если Алекс вернёт еще и дождь в Улей, то индикатор может пригодиться. Возможно, станет актуальным зарядить робота опытом и таки еще понизить энергопотребление.

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

Предлагаю зайти в эвил и посмотреть что делает робот со скрина на варпе cubus

Пришло время для моей собственной первой темы.

Когда-то я наткнулся на возможность менять цвет индикатора у роботов и чуть погодя, реализовал отображение заряда робота с помощью изменения этого самого индикатора.

 

Сейчас всего 4 градации Синий для заряженного больше чем на 75%, сине-зеленый для заряженного больше чем наполовину, оранжевый для заряда больше 25% и тускло-красный для заряда меньше 25%

 

Распространяется через hpm, он же hel package manager любезно предоставленный Totoro доступный вот в этой теме. Для установки нужно установить hpm с помощью

pastebin run vf6upeAN

и затем

hpm install blues

для установки файла blues.lua в /etc/rc.d/blues.lua, после чего нужно выполнить регистрацию нового rc модуля командой

rc blues enable

И перезагрузить робота.

 

 

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

Дополнительные ссылки:

Пакет на hel.fomalhaut.me

Код на gitlab.com

 

огромного костыля в виде таймера и pullSignal

Родина дала тебе event.listen, используй его мудро!

 

Вот пример кода

local valid_users = {["man_cubus"] = true}

local function valid(name)
  return valid_users[name]
end

function common.motion_handler(...)
local evt = {...}
  -- evt[1] всегда равно "motion" потому что именно это событие мы и будем слушать,
  -- остальные поля в соответствии с описанием события на ocdoc.cil.li
  if valid(evt[6]) then
    common.red_actions.process_sensor(evt[2]) --[[эта функция тут не показана,
    но evt[2] - это будет адрес сенсора движения, от которого поймано сообщение]]
  end
end

common.event.listen("motion", common.motion_handler)

Обновил код, теперь там отлаженная версия.

Тут Fingercomp говорил о "свинской" уязвимости и я думаю, нелишне упомянуть тут об этом: если биркой назвать существо (например свинью) именем того пользователя, который есть в списке valid_users, то сенсор на это существо сработает.

Так что не для критично важных вещей типа управления реактором, такую штуку использовать крайне осторожно.

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

Возможно.

Но есть пара возражений по существу и одно субъективное:

1. Открытие двери не требует вот прямо моментальной реакции как правило. И для event.listen лаг сведен к достаточно малой величине чтобы не задумываться о нём.
2. Упрощённые компьютеры - это замечательно, но если дверей/люков десяток, а игроков, которые ходят через них туда-сюда не так много (зачастую один владелец привата) , то один выделенный компьютер может быть более выгодным и легче расширяемым вариантом. Например если понадобится добавить еще и умное освещение на таких же сенсорах.
3. RC рулит . А если серьёзно, то rc кроме всего прочего позволяет в rc.conf хранить конфиг к модулю и не переписывать код при добавлении новых сенсоров и редстоун-контроллеров.

P.S.

Решил допилить до варианта с многими сенсорами и многими редстоун-контроллерами

Хм,при rc sense start https://imgur.com/a/q7gbQct 

Битая ссылка

 

Отладить смогу через полтора часа. А пока попробуй сам.

Вариант для RC

common = {}
common.event = require("event")
common.cmp = require("component")
common.side = require("sides").top
common.red = common.cmp.redstone
common.r_on = 15
common.r_off = 0
 
function common.reset_red()
  for i = 0, 5 do --хотя вообще-то так делать не стоит
    common.red.setOutput(i, common.r_off)
  end
end
 
function common.red_on()
  common.red.setOutput(common.side, common.r_on)
end

function common.red_off()
  common.red.setOutput(common.side, common.r_off)
end
 
function start(args)
  local valid_users = {["man_cubus"] = true}
  local sensitivity = 64
  local r_timeout = 1
  local sensor = common.cmp.motion_sensor
  sensor.setSensitivity(sensitivity)
 
  local function valid(name)
    return valid_users[name]
  end
 
  function common.motion_handler(...)
    local evt = {...}
    local function off()
      common.red_off()
    end
    if valid(evt[6]) then
      common.red_on()
      common.event.timer(r_timeout, off, 1)
    end
  end
 
  common.reset_red()
  common.event.listen("motion", common.motion_handler)
end
 
function stop()
  common.event.ignore("motion", common.motion_handler)
  common.red_off()
end

Код сохранить в /etc/rc.d/sense.lua и выполнить

rc sense enable
rc sense start

Сигнал отправляется через верхнюю сторону блока, но ты сможешь это изменить (строка common.side = require("sides").top)

Я дополнительно добавил возможность указать пользователей, которых детектор будет замечать чрез функцию valid. Если нужно чтобы сенсор срабатывал для всех, то просто возвращай из этой функции true

Я всё прослоупочил, но вдогонку вот мои 5 копеек:

 

>1) Где читать инфу о Lua именно для майна.

 

http://ocdoc.cil.li/

Для меня этот ресурс - основной как раз что касается именно майна.

 

Если про луа вообще - есть 3 возможности:

1. Официальная вики http://lua-users.org/wiki/

2. Вот этот чувак неплохо (да еще и по-русски) объясняет некоторые неочевидные моменты https://ilovelua.wordpress.com/

3. Fingercomp в ирке (прости, Фингер)

 

тут как бы смысл не в том, чтобы "посетить" варп сколько-то там раз, а именно в том, чтобы своим квадратным тельцем как можно дольше его прогружать именно и зарабатывать баллы

Я не думал о такой возможности. Видимо в духе последних событий по инерции подумал о варианте с торговлей.

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

Я бы занялся, но перед этим мне нужно понять 2 вещи:

  1. Как определять факт покидания варпа любым игроком.

    а. Если игрок телепортируется любым способом, включающим: /home , /warp <другой варп>, персональный телепортер из грависьюита или подобный ему телепортирующий предмет, запрос от другого игрока. Или любым другим способом.

    б. В случае выхода игрока с сервера.

    в. В случае перезапуска сервера с вылетом вообще всех.

 

  Лично я по факту вижу возможность  регистрировать появления игроков и считать именно их. Составлять рейтинг частых посетителей, а не тех, кто на варпе пробыл долго. Эта задача по исполнению проще, но это уже не данные про длительность нахождения игроков на варпе а частота появления в условную единицу времени. И эта единица времени должна быть достаточно большой. Например - час. Соответственно и обновлять статистику посещений нужно раз в час или реже.

 

  2. Каким образом корректнее сообщать статистику вместо той фигни что ты предлагаешь? Потому что давай по-чесноку, никому оно не нужно будет в мониторе строчечки разглядывать, на варп обычно по делу приходят а не топ посетителей смотреть.

 

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

 

 

Предложения:

• Если варп торговый, то вместе с сообщением о топе игроков логично предлагать какие-то плюшки частым гостям, но тогда нужно регистрировать не столько посещения сколько посещения плюс покупки игрока и с определенными весами их учитывать. Для примера можно так:
  
  Если стоимость_покупок_посетителя ненулевая
     Ценность_приза_покупателю = Коэффициент_бонуса * (0,9 * сумма_покупок + 0,1 * частота_посещений_магазина)
  иначе
     Ценность_приза_покупателю = 0
  
  Где Коэффициент_бонуса можно выставить как 0,01 * (11 - позиция_в_топ_10) и тогда для самого активного покупателя будет бонус около 10%, для менее активного - 9% и так далее.
   
• Возможно, стоит предусмотреть "защиту от накруток" путём постановки вокруг центрального датчика дополнительных датчиков чтобы было невозможно просто выходить и входить в зону действия радара накручивая себе посещения.

 

В таком, обдуманном варианте, задачка посложнее пары строк.

 

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