Сообщений в теме: 1486

[Schatten]

например вот

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

Думаю, такой древний (аж 2007-го года) магазин не стоит даже рассматривать.
Вот более свежий пример:

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

.
 

sqf это что за язык?

https://arma3.ru/for...kriptopisaniiu/

Сообщение отредактировал Schatten: 21 June 2017 - 13:37

[hewl2]

 

например вот

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

Думаю, такой древний (аж 2007-го года) магазин не стоит даже рассматривать.
Вот более свежий пример:

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

.
 

sqf это что за язык?

https://arma3.ru/for...kriptopisaniiu/

 

благодарю, я это видел уже правда, но не понял ничего( , попробую еще раз

[peterwinter]

Хотелось бы написать скрипт, убирающий возможность перезаряжать пулеметы на ходу. Подскажите, как (можно ли) запретить юниту перемещение, когда он перезаряжает оружие, класс которого унаследован от LongRifle, например?

[lopster102]

Хотелось бы написать скрипт, убирающий возможность перезаряжать пулеметы на ходу. Подскажите, как (можно ли) запретить юниту перемещение, когда он перезаряжает оружие, класс которого унаследован от LongRifle, например?

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

 

_пулеметныймассив = ["пулемет1","пулемет2"......];

если (инпутакшен "перезарядка" == 1)тогда

{

   _текущееоружие = текущееоружие игрок;

      если(_текущееоружие  в _пулеметныймассив)тогда

      {

      

   // здесь сам код по типу проверки кординат объекта

если разные значит делать свичакшен если одинаковые то не делать ничего просто перезарядить

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

 

      };

}

 

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

Сообщение отредактировал lopster102: 27 July 2017 - 21:40

[Ilias]

Здравствуйте, я тут чуть поспешно собрал:

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

и начал заниматься,

кто нибудь может помочь информацией|объяснением на тему создание отдельного процесса для CPU скриптингом с армой ?

[Ilias]

//удалено, (коду форума нужно дополнение предотвращающее повторное создание поста с тем же текстом при повторном нажатии "Отправить" до обновления страницы)

Сообщение отредактировал Ilias: 18 August 2017 - 23:33

[vlad333000]

Ilias, *поток (Процесс ты можешь создать только через расширения, которое вызовет нужную программу), да и сам этот поток весьма условный, а не настоящий
spawn/exec/execVM/execFSM и остальные команды которые вызывают какой-либо код отдельно (Например, обработчики событий)

Сообщение отредактировал vlad333000: 19 August 2017 - 00:13

[Ilias]

Ilias, *поток (Процесс ты можешь создать только через расширения, которое вызовет нужную программу), да и сам этот поток весьма условный, а не настоящий
spawn/exec/execVM/execFSM и остальные команды которые вызывают какой-либо код отдельно (Например, обработчики событий)

Ладно, допустим "поток" (раз "процесс" занято |выполняемой программой|),

 

spawn/exec/execVM/execFSM создают "потоки" складываемые в один "поток" sheduler'а армы (scheduled environment),

eventhandlers создают "потоки" армой комбинируемые в "поток||и|" для CPU, после выполнения которых даётся разрешение на рендеринг следующей frame ("unscheduled environment"),

 

проблема в том что арма в 1 "поток" для CPU комбинирует |больше|не следуемые к объединению между собой(например из за времени нужного на выполнение)| 'unsheduled' "поток|ов|и|" |чем следует|_| для производительности,

(суть в том что например скриптовые комманды не должны выполняться одновременно, но например отрисовка текстур может идти одновременно с проработкой симуляции (физики) и т.д..)

 

(но если например в скрипте только |локальные действия| и|или |действия для получения информации (например; получение переменных)| (не влияющие на другие процессы программы), и например есть только назначение глобальной переменной в конце, то вплоть до этой комманды назначения скрипт мог бы независимо выполняться в своём CPU "потоке")

вопрос в том как сделать чтобы к CPU отправился "поток" из выбранного (1 script или комбинированные выбранные скрипты)

Сообщение отредактировал Ilias: 19 August 2017 - 05:50

[vlad333000]

Ilias, никак, машина .sqf сама все распределяет как ей нужно и ты никак на это повлиять не можешь, сначала замедляя рендер исполняются скрипты в "не запланированном" пространстве, затем машинное время распределяется между скриптами в "запланированном пространстве" и это распределение зависит от текущей нагрузки, чем она выше тем выше задержка между выполнением команд (Максимум ~50 мс между любыми командами когда все ужасно плохо) и эти скрипты не влияют на скорость рендера напрямую (Изменяя его только дополнительными командами на отрисовку)
PS Разве когда-то арма хорошо владела более чем 2 потоками ЦП что бы даже думать об этом?

[Ilias]

Ilias, никак, машина .sqf сама все распределяет как ей нужно и ты никак на это повлиять не можешь, сначала замедляя рендер исполняются скрипты в "не запланированном" пространстве, затем машинное время распределяется между скриптами в "запланированном пространстве" и это распределение зависит от текущей нагрузки, чем она выше тем выше задержка между выполнением команд (Максимум ~50 мс между любыми командами когда все ужасно плохо) и эти скрипты не влияют на скорость рендера напрямую (Изменяя его только дополнительными командами на отрисовку)
PS Разве когда-то арма хорошо владела более чем 2 потоками ЦП что бы даже думать об этом?

( , (влияют в unsheduled enviroement, задерживая рендеринг, если  они длинные  или  их много (arma складывает их в заданное количество потоков для CPU и они(потоки) получаются длинными)

sp: ну не думаю что \этот вопрос задавался )

оцените: 

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

? (надеюсь язык не проблема)

Сообщение отредактировал Ilias: 19 August 2017 - 15:45

[vlad333000]

Ilias, все равно вы никак на этом повлиять не можете, машина .sqf сама сделает так как ей нужно и ею управлять скриптами армы нельзя

[Ilias]

Ilias, все равно вы никак на этом повлиять не можете, машина .sqf сама сделает так как ей нужно и ею управлять скриптами армы нельзя

ответил же: "(", (здесь просто поправка)

Скажете что нибудь по поводу suggestion ?

[vlad333000]

Ilias, что?! Вы хоть сами понимаете что пишите? что за suggestion и как оно относится .sqf? Хватит уже писать ответы как ребус, мы тут не ванги что бы понять, что вы хотели написать

[Ilias]

Ilias, что?! Вы хоть сами понимаете что пишите? что за suggestion и как оно относится .sqf? Хватит уже писать ответы как ребус, мы тут не ванги что бы понять, что вы хотели написать

'suggestion' (предложение, внушение, предположение, Совет, намек, указание сущ) (если бы я имел ввиду комманду например: я бы написал |suggestion|, (вот почему я так делаю))

ссылку на которое я скинул (

Пожалуйста Войдите или Зарегистрируйтесь чтобы увидеть скрытое содержание

)

Сообщение отредактировал Ilias: 19 August 2017 - 16:11

[vlad333000]

Ilias, я вам открою тайну: мы тут пишем на человеческом языке и писать нужно как "Как вам мое предложение/идея", а не писать предложение с кучей непонятных символов и без причинным смешением различных языков

[Ilias]

Ilias, я вам открою тайну: мы тут пишем на человеческом языке и писать нужно как "Как вам мое предложение/идея", а не писать предложение с кучей непонятных символов и без причинным смешением различных языков

. скажете что нибудь по поводу всё таки ?

[vlad333000]

Ilias, крайне тяжело будет реализовать (Одновременный доступ к одному и тому же набору данных из разных потоков и синхронизация разных потоков), и еще будет стоять вопрос: "где и для чего применять?"

[Ilias]

Одновременный доступ к одному и тому же набору данных из разных потоков и синхронизация разных потоков

Сейчас же комманды для выполнения отправляются в систему в которой организуются в очередь для CPU потока ?,

дополнительная система (в которую будут отправляться команды из 'separate' скриптов) или увеличение нынешней системы (пускающее команды из 'separate' скриптов по другому порядку действий) для:

     организации дополнительных потоков:

          в варианте |1| на основании оценки требующих организации команд, нагрузки на процессор и своих переменных формирующей подходящее количество 'separate' потоков для CPU

          в варианте |2| на основании информации о  arma's потоке (выполняемом коде)  и  запрошенного действия (параметров 'formThread' комманды|блока) формирующей потоки для CPU

,возврат результата:

     в |1| зависит от наличия у системы возможности создавать CPU потоки не требующие задержки рендеринга:,

     в |2|

          при задержке рендеринга: также как и сейчас, просто рассматривать 'separate' код как одну команду,

          без задержки рендеринга: тоже самое, только потом результат прогонять по той же|подобной схеме по которой сейчас результат соотносится со своим действием из sheduler'а

.

где и для чего применять?

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

 

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

//'результат'=(первая 'not local' команда кода)

//a=1;
CPU поток0: задача{_a=a+1}результат{a=_a}
CPU поток1: задача{_a=a+1}результат{a=_a}
//сейчас на следующей frame гарантированно a==3 (кажется);
//будет маленький шанс что a будет ==2;

), хмм..

     в |1| это можно решить например сверкой целей 'результат'ов кода при компоновке CPU потоков (если затрагивается один набор данных (в примере--a) блоки выполняются только вместе(в одном CPU потоке)),

     но так это ещё один плюс к варианту |2| (отсутствие необходимости это решать) (если скриптер сам решает использовать ли этот способ выполнения, может это учесть)

Сообщение отредактировал Ilias: 19 August 2017 - 22:09

[vlad333000]

Ilias, конечно вы тут написали кучу всего не сусветного, что не соотносится с действительность... Но вы реально думаете что БЕСы будут этим заниматься? Для них магией был перенос с 32-бит на 64-бит платформу (Где из существенного только длина адреса меняется (Если они конечно не на ассемблере писали)), а тут вы предлагаете им многопоточность вставить в игру...

PS Правильным вариантом тут будет только автоматическое раскидывание задач по потокам (Есть блок из N команд и у ЦП M ядер >> каждая ядро в идеале выполняет блок из N / M команд), ручное скорее всего приведет наоборот к падению производительности ибо не каждый скриптер понимает что это такое

[Ilias]

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

Наличие полностью только ручной(|2|) возможно приведёт к периодическому не использованию всего потенциала скриптерами

(что не особо страшно учитывая что эти возможности не необходимы пока для всего где подходят),

но по причине своей работы |1| скорее всего будет немного менее производительна чем можно будет сделать с |2|

(но разумеется я тоже за идеальную автоматическую систему,

проблема в том что на доверии 'идеальная' немного беспокоит (BI же не выложат код на github),

и главное  время на разработку  ,:

так что 'пожалуйста хотя бы только |2| только как можно быстрее')

 

будут этим заниматься? Для них магией был перенос с 32-бит на 64-бит платформу (Где из существенного только длина адреса меняется (Если они конечно не на ассемблере писали)), а вы предлагаете им многопоточность вставить в игру...

поддержку многоядерности вставили, и 'многопоточность' одна из основных вещей для программы (сейчас arma использует 51 CPU поток

(суть в том что например скриптовые комманды не должны выполняться одновременно, но например отрисовка текстур может идти одновременно с проработкой симуляции (физики) и т.д..)

имел ввиду это как они сделали)

 

ps:

конечно вы тут написали кучу всего не сусветного, что не соотносится с действительность...

??

Сообщение отредактировал Ilias: 19 August 2017 - 21:33