Noortvel

https://www.mdpi.com/2072-4292/9/5/483/htm тут описан один из алгоритмов.

Никак. TCP - это труба байт. Вы должны самостоятельно разделять поток байт на пакеты.

TCP это поток байтов, какими порциями оно будет приходить вы почти не контролируете.

Если пишете пакеты по 16 байт, то и читайте по 16 байт.

var buffer = new byte[16];
var offset = 0;
var read = 0;
while(offset < buffer.Length && (read = stream.Read(buffer, offset, buffer.Length - offset)) > 0)
{
    offset += read;
}

if (offset < buffer.Length) {  /* EOS */ }

Но конечно эффективней читать чем-то кратным размеру пакета и сразу много пакетов.

Поставьте гном терминал
Просто подмена бинарника не создаст в пантеоне апи для дебага

os.system("command arg1 arg2")

import subprocess
subprocess.call(['command', 'arg1', 'arg2'])

Не нужно так делать
Сделайте отдельную фукнцию, которая будет возвращать результат в консоль и перед выводом будет его форматировать

ссылка

Можно а порой и очень даже нужно.. )

ССЫЛКА НА ПЛАГИН

This is a plugin embedding a whole Python VM (versions 3.x [the default and suggested one] and 2.7) In Unreal Engine 4 (both the editor and runtime).

The Python VM tries to give easy access to all of the UE4 internal api + its reflection system. This means you can use the plugin to write other plugins, to automate tasks and to implement gameplay elements.

It is not meant as a way to avoid blueprints or c++ but as a good companion to them (albeit reducing the amount of c++ required for coding a game could be an interesting thing ;). If your development pipeline is already python-based (Maya, Blender, ...), this plugin could easily help you in intgrating unreal into it.

Another funny feature is that you can change your python code even after the project has been packaged. You can potentially build a completely new game from an already packaged one.

Есть объект.
У объекта есть:
* Поля
 * Свойства
 * Методы
 * Конструкторы
 * События
 * Вложенные типы

**Поля**
Поле описывает и содержит часть состояния типа. Поля могут иметь любой тип, поддерживаемый средой выполнения. Поля чаще всего имеют уровень доступности private или protected, поэтому они доступны только изнутри самого класса или из производных от него классов. Если значение поля может быть изменено извне его типа, то для этого обычно используется метод доступа набора свойств.

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

**Методы**
Метод описывает операции, доступные в определенном типе. Сигнатура метода указывает допустимые типы всех его параметров и возвращаемого значения.

Выбор между свойствами и методами

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

В следующих ситуациях используйте метод, а не свойство.
* Использование операции во много раз медленнее, чем использование метода для установки поля. Если даже вы собираетесь предоставить асинхронную версию операции с целью избежать блокирование потока, использование операции, вероятно, будет слишком затратным, чтобы быть свойством. В частности, операции, осуществляющие доступ к сети или файловой системе (в отличие от однократного доступа для инициализации), следует проектировать методами, а не свойствами.
* Операция является преобразованием, таким как Object.ToString method.
Каждый раз при вызове операция возвращает новый результат, даже если параметры не изменяются. Например, каждый раз при вызове метод NewGuid возвращает новое значение.
* Операция имеет существенный и наблюдаемый побочный эффект. Обратите внимание, что заполнение внутреннего кэша обычно не считается наблюдаемым побочным эффектом.
* Операция возвращает копию внутреннего состояния (не включаются копии объектов типа значения, возвращаемых на стеке).
* Операция возвращает массив.

Доступ к свойству такой же быстрый как доступ к полю если get;set; имеют простую реализацию и компилятор сделал инлайн оптимизацию, в которой вызов метода заменился его телом.

Начиная с C#6.0: nameof(val)

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

// MyClass - тип объекта, который хотим подменить
// унаследоваться необходимо, чтобы не сломать совместимость типов
class MyProxy extends MyClass {

  // наш спрятанный объект, который будем заменять в будущем
  private MyClass hidden;

  @Override
  public int hashCode() {
    return hidden.hashCode();
  }

  @Override
  public boolean equals(Object o) {
    return hidden.equals(o);
  }
  // и так далее заоверрайдить все-все публичные
  // методы наследуемого класса

  // правда, с публичными свойствами будет проблема - для
  // их замены необходима более сложная логика:
  @Override
  public int calculate() {
    hidden.var = var; // на случай если поле было изменено извне
    int result = hidden.calculate();
    var = hidden.var; // а это если поле было изменено изнутри
    return result;
  }

  public int var;

  // а вот и главный заменщик
  void setObject(MyClass new_o) {
    hidden = new_o;
    var = new_o.var;
  }
}

Потом останется только найти все места, где создаётся объект и заменить его на прокси объект. Далее настоящий объект подменяется вызовом setObject().

Если у проксируемого объекта есть final поля или методы, то придётся отказаться от наследования MyClass и заменить во всём проекте тип ссылок MyClass на MyProxy.

Называется это точкой роста, вы оставляете метод чтобы в него потом можно было что-то дописать
Например, обновления какой-то конструкции после присваивания переменной числа более 10, что будете делать, если переменная будет публичной? Переписывать весь код, где она использовалась?

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

Тут надо понимать, что такое "мусор" в jave. Как правило, это объекты, на которых не осталось указателей. Или все указатели друг на друга замкнуты. Такой "мусор" вызывает рост использованной памяти, при том, что никто ей и не пользуется. Это называется "утечка памяти". Естественно, такое положение дел никого не устраивает, и время от времени запускается сборщик мусора, который и грохает все утечки.
Теперь, переходим к С++. Тут все управление памятью ложиться на пользователя.
Выделение памяти бывает двух видов: на стеке и в куче. На стеке - самое простое, но не самое безопасное, когда значение должно где-то храниться.
Самый простой пример int x[10]; - выделяет 10*sizeof(int) байт на стеке.
Сразу покажу чем это плохо: предположим, у вас есть два потока, и надо заполнить и передать задание второму потоку. Мы создаем внутри функции массив, заполняем его, передаем второму потоку и выходим из функции. Память при этом освободилась и уже какой-то другой поток в нее пишет.
Второй поток при этом наконец-то добрался до задания и начинает работать с переданным массивом.
В итоге, он сам получает бред, да еще и если пишет в массив выходные значения, то и портит память другому потоку. Тоже самое будет, если вы сохраните указатель на массив во внешнее поле и попробуете получить к нему доступ из другой функции.
Так мы приходим к тому, что нам нужна независимая память. Или память на куче.
int* x = new int[10];
С такой памятью легче все работать как с передаваемым массивом. Эта память нигде не испортится и в общем и целом, с ней все будет хорошо. Есть только одна проблема: ее надо прибрать. Т.е. где-нибудь должен быть delete.
Пока один поток и четкая и понятная структура приложения, все легко и просто. Когда у нас начинается многопоточность и самописные библиотеки, то все резко усложняется. И тут на помощь приходят умные указатели - shared_ptr, к примеру, делает следующее: увеличивает счетчик владений объектом на единицу каждый раз, когда указатель присваивается. И уменьшает на ту же единицу, когда вызывается деструктор. Если счетчик хранения равен нулю, то умный указатель корректно удаляет объект и утечки памяти не происходит.
В общем и целом, советую почитать про умные указатели.