Antibird

Ладно, ерунда. =) У меня порядка 600 vehicle'ов, к ним прикреплены триггеры разнообразные, чтобы игрок мог взаимодействовать. (Естественно, все грузится не сразу, а при streamIn/out vehicle'ов.) По сути - обычная строчка забитая в elementData. Первоначально все хранилось и работало через таблицы, потом вот - нашел себе приключений. Это верно, нас таких немного Hydra на скорости 275 km/h преодолевает 16 Km менее, чем за 4 минуты. Постоянный blink в новую локацию, пусть даже и мгновенный, со временем начинает надоедать. Буде это 70 Km, время возрастает уже до 15 минут, что намного приятнее. А мы такие, мы носимся только в путь, нам места мало. И неба было мало и земли. И острова наши разбросаны по всему морю-окияну, и на многих есть аэродромы с техникой; и теперь вот я не могу эту технику туда поставить, ибо неведомая хрень со стороны сервера скидывает все в кучу на рубеже 8192, а на клиенте vehicle'ы не сделаешь, в отличие от объектов. То на сервере работает, на клиенте - нет (colShape), то вот, наоборот. Вот, в общем, моя печальная история и вся подноготная.

qaisjp, indeed. Colshape-related functions and events do the business server-side just fine, I wonder why client-side it's made so only entities are detected, while dummies are ignored?

Это просто пример. У меня colSphere приаттачена к игроку и перемещалась вместе с перемещением игрока. Есть событие "onClientColShapeHit", где элементом прописан parent всех моих dummy. Не работало, сменил на resource_root. Стало срабатывать на все entity, а на non-entity, соответственно, нет. Вот по этому и хотелось использовать предлагаемый инструментарий. У меня несколько тысяч dummy, некоторые статические, большая часть перемещаются. А я помню, что colShape усовершенствовали, чтобы проверять только в stream range вокруг игрока, или что-то вроде этого. В общем, это все моя мотивация, можно считать вопрос исчерпанным. Вернусь к таблицам. Всем спасибо за потраченные буквы. Так и поступаем, но хотелось бы клепать из кусков 50x50, а не 16x16. Никто обычно не понимает, зачем. Но вот надо, просто надо. В SAMP'e, откуда я вылез, игровой мир 40x40 км, но других лимитов по размещению нет. Приходится втискиваться в узкие рамки, при том, что вокруг - вселенная простора.

Натура у меня такая неуёмная. Ну да все, 1:1, предлагаю сменить тематику Требуется: создать лодку в координатах (10000, 10000, 0) при старте сервера, затем зайти на сервер, переместиться в эту точку и сесть в лодку. На последнем этапе начинается самое интересное. Суть подвоха в тех же 8192 метрах ограничения о которых я упомянул постом выше. И если для объектов оно обходимо, то для класса vehicle, это головоломка похлеще. Если сначала зайти, потом создавать и перемещать, то все работает, но это не вариант. Был бы очень рад, если поделитесь рецептом от этой головной боли, может опыт есть какой?

Ответы зачастую отрицательными выходят, вот в чем дело. Ну и серьезно: 1. Я действительно сам расписал, почему не работает. 2. В P.S. отметил, что пути решения вопроса мне известны. Но вопрос то все равно был о другом, без обид. В той ветке eAi ответил, что действительно, colShape для подобных элементов неприменим. Что печально, хотелось по максимуму использовать функционал MTA, прежде чем верстать собственную системку. (Про то, а почему на сервере работает, а на клиенте - нет, я переспрашивать не стану.) [off]Было дело, интересовался, как создать объекты на расстоянии от SA порядка 20 км (а там какие-то ограничения, максимальная дальность составляет 8192), и объяснял, ну вот "нужно мне, и все тут". Все равно лезли и лезли все подряд со своими ахами, "накой мне столько места", квадратные километры высчитывали, едреть их. "I have no freaking idea what do you need it for.." - да зачем это? Есть вопрос, не ответа, зато море воды. Пока тот же eAi не отрезал, что так есть и будет и нечего ждать, на чем и успокоилось. Извините.[/off]

Ээх, это все хорошо. Но вопрос в общем-то был конкретно о том, как заставить двигаться non-entity элементы и о применимости colShape'ов для работы с ними. Обо всем остальном упомянутом уже расписано в самом посте (#6) и коде в нем же.

Дык каждому свое, не спорю. А у меня вот погода зонирована, да еще время замедленно, так что все ручками, увы =) Разрешите вклиниться с другим вопросом. В основном из за того, что эту ветку регулярно читает представитель команды разработчиков, нам, простым смертным, очень удобно получать быстрый фидбэк. Надеюсь, не сильно напрягаю товарища. Могу ли я получить ответ вот на это? И еще,что за "legacy reasons" такие, что портят всю малину в случае с GetElementsWithinColShape?. Заранее спасибо.

Kernell, setRainLevel() в 1.1 реализован. Посмотри вот в этом списке, пока, правда, описания нет. Но принимает один параметр. Дефолтный, вроде, 0.8. setFarClipDistance, setFogDistance...( там же ) Теперь setWeatherBlended() не так уж и нужна https://wiki.multitheftauto.com/wiki/Ser ... _functions

О как. Спасибо.

И это прекрасно, кроме шуток. В (одном известном мультиплеере) в версии 0.2 добавили погоду, было дело. От мы веселились. Пардон, offtop. В общем, коли у нас пошла такая беседа и статут темы как курилки позволяет, спрошу о наболевшем, теплю надежду, что lil Toady может знать. Возможно ли каким-нибудь образом в далеком будущем в далекой далекой галактике добавить возможность перемещать солнце/луну в любую точку неба. Или все это из области фантастики и обращаться на bugtracker не имеет особого смысла. Я, как средне-статистический end-user в вопросах "что возможно, а что - нет" увы, не компетентен.

I'd like to bump this bearded topic since I still have some questions left. The reason of non-working was obvious: GetElementsWithinColShape() have some limitations client-side as said there. I don't mind being tolerant of that limitations, but how the heck can I make my custom/virtual/dummy/non-entity element to move so it could be detected by colshape? And that's how I failed moving it: addCommandHandler( "doCheck", function( x, y, z, e, v, c ) x, y, z = getElementPosition( getLocalPlayer() ) c = createColSphere( x, y, z, 10 ) --// Create a colshape so it's there before elements to check setTimer( --// Wait for a bit just to make sure =) function() e = createElement( "anElement", "anElementID" ) --// A custom element setElementPosition( e, x, y + 3, z ) --// Move it to us from ( 0,0,0 ) v = createVehicle( 400, x, y + 3, z ) --// A vehicle --// Check isElementWithinColShape() outputChatBox( "\nvehicle: " .. tostring( isElementWithinColShape( v, c ) ) ) outputChatBox( "custom: " .. tostring( isElementWithinColShape( e, c ) ) .. "\nlist:" ) --// Check getElementsWithinColShape() for i, v in ipairs( getElementsWithinColShape( c ) ) do outputChatBox( i .. ": " .. getElementType( v ) ) end --// Move custom element and check again outputChatBox( "#one more time" ) setElementPosition( e, x, y + 1, z ) --// Since this is not what means "to move" - I give up =/ --// Here goes the same result again outputChatBox( "vehicle: " .. tostring( isElementWithinColShape( v, c ) ) ) outputChatBox( "custom: " .. tostring( isElementWithinColShape( e, c ) ) .. "\nlist:" ) for i, v in ipairs( getElementsWithinColShape( c ) ) do outputChatBox( i .. ": " .. getElementType( v ) ) end end , 500, 1 ) end ) Any suggestions are welcome. P.S. I know I can do the check myself, just want to know if collision functions suitable for use with custom elements

И за 5 минут может небо затянуть, а потом грянуть. В горах, например. Это к слову =) Появление замечательных рычагов вроде setRainLevel(), кстати, неплохо компенсирует сабж, в некоторых случаях даже превосходит по гибкости. Ну и раз уж речь зашла о погоде: не понимаю, почему, говоря о setWindVelocity(), пишут "This affects just the trees". Вертолеты сдувает на счет раз.

Дык ведь было уже давно: http://bugs.mtasa.com/view.php?id=3327

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

Молоток.

Basically, http://www.lua.org/manual/5.1/manual.html#2.6

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

Подскажите пожалуйста, cegui какой версии использует mta 1.0.4 - 1.1 и где бы подсмотреть список тех свойств из полного списка, которые доступны для использования в guiSetProperty(). Сейчас в вышеприведенном списке наблюдаю интересные штуковины, вроде http://cegui.org.uk/static/WindowsLookP ... #YRotation. Второй вопрос, а будет ли переход на новые версии cegui, или вплоть до MTA 2.0 ждать не стоит? ( http://bugs.mtasa.com/view.php?id=3314 )

X always goes south to north, Y west to east, Z from earth depths to the outer space. Setting the same velocity again and again must give the same results no doubt.

https://wiki.multitheftauto.com/wiki/Eng ... ODDistance Read before "Syntax" goes.

No guys do understand your question I suppose =/

Basically I was trying to say you need to detect going upside-down and back somehow and either skip the stunt calculations for the moment or calculate in another way, fixing pitch/roll/yaw values or whatever. That's it. Sorry, I can't get you any details now, I haven't been thinking deep into this issue =/ P.S. Can't getVehicleTurnVelocity() be used alternatively?

You have 2 typical states for the vehicle "normal" and "upside-down". So since roll and yaw changes +/-180 when the vehicle goes from one state to another, you need to check if the new vehicle state is the same as it used to be on last frame. If not - do not add the rotation and resume calculations when the condition is met.

How are you going to determine whether it was pitch or roll made the vehicle upside-down? If you pitch the vehicle and it goes through this point, you want rotX to be 180, but while you roll the vehicle it still goes through the same position. Also if the vehicle make the full loop, the rotation drops back to 0. So please tell us how do you calculate stunt bonus.

This is the base code to get element rotation instead of what you may be using now (getElement/Vehicle/Rotation() ? ) The code gives correct pitch/roll/yaw values even while upsidedown. local m = getElementMatrix( theVehicle ) local pitch = math.deg( math.asin( m[2][3] ) ) -- (-90,90) local roll = math.deg( math.atan2( m[1][3], m[3][3] ) ) --(-180,180) local yaw = math.deg( math.atan2( m[2][1], m[2][2] ) ) --(-180,180) You can get rid of negative values if you need to, should be easy done.