Radjah, отключение UAC первое, что надо делать.
Вот как сделают нормально UAC тогда и будем использовать.
Причин не использовать папку с каким либо именем для хранения данных не вижу.
Я вижу, что у меня есть все права и вижу, что любая программа (компилятор, ide, виртуалки) работают. ffmpeg нет.
Мне очень понравился DragonBones. А перед ним я попробовал Spine, Creature, Adobe Animate CC.
Лично для меня DragonBones интуитивно понятен. Там есть линейки, направляющие - часть фишек они перетянули туда из Spine. Пока нет желания уходить.
Не очень понятно про "делайте ногу из однотонных примитивов а контур дорисовывайте уже потом".
Мне нужно анимировать картинку.
Я не могу ничего нарисовать в DragonBones. Но могу там анимировать.
Я могу дорисовывать в фотошоп. Но нормально анимировать там вроде нельзя.
Поэтому обычно рисуют в редакторе, импортируют в DragonBones/Spriter/Creature/Adobe Animate и там анимируют. На выходе получают видео или набор png спрайтов. Вроде как то так.
Правильно ли я понял, что вы предлагаете сделать рисунок без контура, анимировать его, а контур дорисовать в графическом редакторе? Это долго.
Легче тогда делать покадровую анимацию, а не скелетную.
Насчет описания картинки как векторной - такого я пока не встречал. Обычно загружают растровые спрайты. Попробовал загрузить в DragonBones svg "картинку". Всё загрузилось, но работать с ней нельзя. Ни кость привязать, ни сетку исправить. А с растровым изображением можно.
Евгений Шатунов, пожалуйста пишите сообщения по теме вопроса.
Иначе П5.14 правил Тостера.
---
vc_redist - это Распространяемый пакет Visual C++ для Visual Studio 2015. Знать такие вещи надо.
Надеюсь, что текст C++ в " Распространяемый пакет Visual C++" вы увидели.
Андрей, всё состоит из байт. Но обычно принято как то это классифицировать.
Мы можем отправлять текстовые команды. И мы можем отправлять файлы.
Вот тут https://developer.mozilla.org/ru/docs/Web/HTTP/Bas...
пишут - text/plain является типом по умолчанию для текстовых файлов. Текстовый файл должен быть читаемым человеком и не должен содержать в себе бинарную информацию.
То есть от тор браузера к сторожевому узлу пакет приходит трижды зашифрованным, а потом от сторожевого узла к тор браузеру пакет (уже ответ) тоже приходит трижды зашифрованным?
SagePtr, TOR-клиент не разворачивает все слои шифрования. Это противоречит концепции TOR.
Разворачивание шифрование происходит последовательно на каждом из узлов.
Даже так - шифрование идет на узлах. TOR-клиент соединяется с каждым из них и оборачивает свой запрос шифруя его сначала на 3 узле, потом на 2, потом на 1 -сторожевом. Потом отправляет.
Расшифровка идет в обратном порядке. так это работает.
Что с ответом? Как всё это будет идти назад?
Пусть TOR-клиент - узел. Хоть это и не так. Но он самый конец цепочки. Что он расшифровывает?
Чей шифр? Какого узла? А выбора похоже тут нет. Ближайший узел сторожевой.
Значит этот узел знает ответ так как это последний слой шифрования ответа.
SagePtr, почему? Официально нет такой информации. Про конечный узел есть. Про сторожевой ни слова.
И как же тогда происходит расшифровка ответа? Ведь сторожевой узел это последний узел.
И он обязан знать ответ. Иначе если он передаст что то зашифрованное на компьютер пользователя возникнут 2 вопроса
1) а кто это зашифровал? больше уже некому. Сайт не шифрует. Мы говорим не про https.
2) кто это расшифрует? У нас луковичное, последовательное шифрование. И только узлы могут это делать. А сторожевой узел был последний.
АртемЪ, как осуществляется шифрование и расшифрование ответа?
Зеркально? А по другому ни как. Это финальная операция.
Что на стороне сайта, что на стороне браузера.
Если сторожевой узел не знает ответа (чушь же) то ему была передана зашифрованная информация.
Кто шифровал эту информацию? Какой узел?
Такого узла быть не может так как последовательная расшифровка предполагает расшифровку ближайшим узлом. Даже называют - луковичное шифрование.
Сайт не TOR - он ничего не шифрует. Не считая HTTPS. Но тут мы об этом не говорим.
Понимаете?
Почему? Луковичное шифрование предполагает обратную модель. По другому никак.
Узел связанный с оконечным узлом обязан произвести финальное расшифрование, иначе на сайт или компьютер придет зашифрованный текст.
Вы не поняли.
Я показал шифрование туда и обратно.
То есть я утверждаю, что
1) все запросы пользователя знает выходной узел. Это очевидно и официально подтверждено.
2) А все ответы знает сторожевой узел? Получается так? Исходя из луковичного шифрования или даже если просто отзеркалить ситуацию.
Но тогда
Глупо пользователю из страны А ставить первым узлом узел (сторожевой) из страны А.
Все его ответы будут видны.
А если я скажем шпионю за Волочковой? 0_0 И через тор посылаю фото её шпагатов в США.
А мне в ответ пишут - прекрасные фото Насти. Шли ещё. То ответ то будет раскрыт так как финальное расшифрование будет на узле в России. И Настя всё узнает.
В этом проблема.
Глупо пользователю из страны А ставить первым узлом узел (сторожевой) из страны А.
Так как все запросы через TOR знает выходной узел.
А все ответы знает сторожевой узел.
Получается так.
Как они решают? Я об этом и спрашивал.
Если я записал файл, удалил его и снова записал файл - то где он будет располагаться? Физически на том же месте? А если сделать так два раза?
Решения однотипные, подчиняются логике или зависят от других случайных условий?
Вот как сделают нормально UAC тогда и будем использовать.
Причин не использовать папку с каким либо именем для хранения данных не вижу.
Я вижу, что у меня есть все права и вижу, что любая программа (компилятор, ide, виртуалки) работают. ffmpeg нет.