🇬🇧 English | 🇺🇦 Українська

4. Операції у Blueprint¶

Спільна форма всіх нод¶

Кожна операція — латентна нода з однаковим набором пінів. Вивчивши одну, ви знаєте решту.

Пін	Коли спрацьовує
On Started	Одразу, ще до передавання даних. Дає `Transfer` для скасування й прогресу
On Progress	У міру руху байтів, там де операція може це повідомити
On Success	Один раз, із результатом
On Failure	Один раз, із причиною та порадою, що змінити

Рівно один із On Success та On Failure спрацьовує завжди — тож очищення пишеться в одному місці, а не двічі. Усі піни спрацьовують в ігровому потоці.

Transfer є на всіх чотирьох пінах, а не лише на On Started. Це той самий дескриптор щоразу — брати його достатньо один раз, на On Started, у змінну; на On Progress/On Success/On Failure він просто повторно доступний, пересохраняти не треба. А от Progress/Result/Data мають сенс лише на «своєму» піні: наприклад, Progress на On Started чи на On Success завжди порожній — це не помилка, там просто нічого повідомляти.

Звідки брати клієнта¶

Клієнт — це перший пін кожної операції, і взяти його можна трьома способами. Різниця лише в тому, звідки береться конфігурація.

Сховище одне: клієнт за замовчуванням¶

Get S3 Subsystem → Get Default S3 Client

Підсистема створює клієнта з налаштувань проєкту, тримає його живим і повертає той самий екземпляр. Змінна не потрібна, збирач сміття його не забере.

Сховищ кілька: клієнт із ассета профілю¶

Коли сховищ більше одного, конфігурацію кожного зручно тримати в ассеті S3 Storage Profile (як його створити — 2. Налаштування). Щоб працювати з таким сховищем, змінюється рівно одна нода на початку ланцюжка:

Get S3 Subsystem
   │
   └─► Get S3 Client For Profile
          Profile : SP_Archive               ← ваш ассет S3 Storage Profile
          │
          └─► Return Value ──► Client (пін операції)
                                  │
                                  S3 Download File
                                     Bucket Name     : my-game-assets
                                     Object Key      : videos/intro.mp4
                                     Local File Path : Saved/Downloads/intro.mp4
                                        │
                                        ├─ On Started  → Transfer  → Set (змінна, для Cancel)
                                        ├─ On Progress → Progress  → Break S3 Transfer Progress
                                        ├─ On Success  → готово, файл на диску
                                        └─ On Failure  → Result → Get S3 Diagnostic Hint

Де взяти ноду. Правий клік у графі → категорія S3 → Get S3 Client For Profile. Пін Profile — звичайне посилання на об'єкт: оберіть ассет із випадного списку просто на ноді або підключіть змінну типу S3 Storage Profile.

Три речі, які варто знати одразу:


Клієнта не треба зберігати	Він створюється при першому зверненні й далі перевикористовується, тож викликати цю ноду з різних місць графа дешево
`Bucket Name` лишається на самій операції	Профіль задає адресу, регіон, стиль адресації та джерело ключів; бакет — параметр конкретної операції
Ключі беруться лише з `Credential Source` профілю	Якщо там `Supplied in code`, то `Set Runtime Credentials` цьому клієнтові не допоможе — вона налаштовує тільки клієнта за замовчуванням. Візьміть клієнта профілю й викличте на ньому Set Static Credentials

Розгорнуті приклади під кожну конфігурацію гри — у 13. Профілі на практиці.

Конфігурація відома лише в рантаймі¶

Якщо адреса й ключі приходять ззовні вже під час гри — наприклад, від вашого бекенда — ассет не допоможе, бо він фіксується на етапі розробки. Тоді збирайте конфігурацію нодою Make S3 Config (Provider) і беріть клієнта через Get Named S3 Client.

[отримали адресу й ключі від бекенда]
   │
   └─► Make S3 Config (Provider)
          Provider : Custom
          Endpoint : (з відповіді бекенда)
          ...
          │
          └─► Get S3 Subsystem → Get Named S3 Client
                                     Client Name : "BackendStorage"
                                     Config      : Return Value (зверху)
                                     │
                                     └─► Client (пін операції)

Що таке Client Name. Це не ідентифікатор, який видає S3, бекенд чи хтось іще, — це ім'я, яке придумуєте ви самі, просто щоб підписати клієнта в кеші підсистеми. Сама підсистема нічого про нього не знає, окрім того, що це ключ у мапі "ім'я → клієнт". Хоч "BackendStorage", хоч "MojeSховище" — важливо лише одне: вживати щоразу той самий рядок, коли треба той самий клієнт. Це ближче до імені змінної, ніж до налаштування.

Звідси й практика використання:

Виберіть одне стабільне ім'я на кожне окреме сховище, з яким працює гра (якщо сховище одне — підійде й буквальний "Default" чи назва проєкту). Одрук чи інший регістр у рядку — і нода тихо створить другий, незалежний клієнт, який ще не налаштований, замість того щоб віддати вже наявний.
Викликайте ноду з Config лише там, де конфігурація щойно зібрана (як на схемі вище) — зазвичай це один раз, одразу після відповіді бекенда. У решті графа, де клієнт із таким іменем уже мав би існувати, Config не так важливий: як нагадує таблиця в 2. Налаштування, він враховується тільки при першому зверненні під цим іменем, а далі мовчки ігнорується — тож можна передати Make S3 Config (Provider) з порожніми полями чи те саме значення, що й першого разу, різниці вже нема.
Це просте FName, тож зберігання в змінній Blueprint чи навіть на Data Table (коли сховищ кілька, а ключі до них приходять зовні) працює так само, як з будь-яким рядком.

Як дістати того самого клієнта деінде. Клієнт живе в кеші підсистеми, а не у вашій змінній — тож нести його через Event Dispatcher чи зберігати кудись спеціально не треба. Але для «дістати вже створене» є окрема нода — Find Named S3 Client — яка на відміну від Get Named S3 Client не просить Config узагалі, тільки ім'я:

[десь-інде в грі — наприклад, кнопка «Завантажити» на екрані інвентаря]
   │
   └─► Get S3 Subsystem → Find Named S3 Client
                              Client Name : "BackendStorage"      ← той самий рядок, що й при створенні
                              │
                              └─► Return Value ──► Client (пін S3 Download File)

Find Named S3 Client — чиста нода (немає піна виконання): підключення Client Name і використання Return Value — все, що потрібно. Якщо під цим іменем ще нічого не створювали (наприклад, граф виконався до Get Named S3 Client на BeginPlay), вона поверне Null — це не помилка, а сигнал, що творця треба викликати першим.

Чому не просто викликати Get Named S3 Client вдруге. Формально можна: вона теж поверне вже наявний клієнт, Config при повторному виклику однаково ігнорується (таблиця в 2. Налаштування). Але тоді доводиться городити зайву Make S3 Config (Provider) тільки для того, щоб підключити щось у обов'язковий пін — і це неочевидно, навіщо вона там, якщо насправді нічого не конфігурує. Find Named S3 Client існує саме для цього другого випадку: дістати — без конфігурації.

Завантаження¶

Шлях до файлу: абсолютний чи відносний¶

Local File Path — і на завантаженні, і на зчитуванні — приймає обидва варіанти.

Абсолютний шлях — повний шлях від кореня диска. Працює завжди й однозначно, платформа лише впливає на його вигляд:

Платформа	Приклад
Windows	`C:/Users/YourName/Desktop/save.png`
macOS	`/Users/YourName/Desktop/save.png`
Linux	`/home/YourName/Desktop/save.png`

Відносний шлях — короткий рядок без букви диска й без початкового слеша, наприклад Saved/Screenshots/shot.png. Плагін розгортає його відносно кореня проєкту (FPaths::ProjectDir()) — тієї самої теки, де лежать Content, Config і Saved. Це працює однаково в редакторі й у зібраній грі, на будь-якій платформі: результат завжди один і той самий рядок, розгорнутий в один і той самий абсолютний шлях.

Кілька готових прикладів відносного шляху:

Відносний шлях	Куди веде
`Saved/Screenshots/shot.png`	Тека `Saved/Screenshots` у корені проєкту
`Saved/SaveGames/slot1.sav`	Те саме місце, куди пише `Save Game to Slot`
`Content/Data/manifest.json`	Звичайний файл усередині теки `Content`, не ассет

Що не підходить. Шлях ассета на кшталт /Game/Textures/Icon — це посилання на об'єкт у Content Browser, а не на файл на диску; плагін працює з файловою системою, а не з реєстром ассетів. Щоб надіслати вміст ассета, спершу отримайте його байти (наприклад, Export To Bytes для текстури) і передайте їх нодою S3 Upload Bytes — вона приймає масив байтів напряму, без файлу на диску взагалі.

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

Get Project Saved Directory → Append ("Screenshots/") → Append (SlotName) → Append (".png")

Get Project Saved Directory (шукати в категорії Utilities|Paths) одразу повертає абсолютний шлях до Saved/, тож про відносність далі можна не думати. Поруч є Get Project Content Directory й Get Project Directory — для шляхів у Content/ і в корені проєкту відповідно.

S3 Upload File¶

Надсилає файл із диска.

Пін	Опис
`Bucket Name`	Бакет, наприклад `my-game-saves`
`Object Key`	Ключ, наприклад `saves/player1.sav`. Без слеша на початку, регістр важливий
`Local File Path`	Шлях до файлу — абсолютний або відносний кореня проєкту, наприклад `Saved/Screenshots/shot.png`. Правила й приклади — у розділі вище
`Content Type`	MIME-тип: `image/png`/`image/jpeg` для зображення, `application/json` для маніфесту, `text/plain` для тексту. Порожньо — двійкові дані, піде як `application/octet-stream`
`User Metadata`	Довільні пари ключ-значення поруч з об'єктом, наприклад `{"author": "player_42"}`

Великі файли автоматично йдуть багаточастинним завантаженням, кілька частин одночасно. Файл читається в міру надсилання, тож його розмір не перетворюється на витрату пам'яті.

S3 Upload Bytes¶

Те саме, але з масиву в пам'яті — знімок екрана, серіалізоване збереження, згенерований файл. Для того, що вже лежить на диску, беріть S3 Upload File.

Про метадані. S3 переводить ключі метаданих у нижній регістр. Записавши GameVersion, ви прочитаєте gameversion. Плагін робить так само на записі, щоб запис і читання були симетричними.

Як надіслати текст: пін `Data` очікує масив байтів, а не рядок¶

Unreal не має штатної ноди «рядок у байти» — це реальна прогалина, з якою стикається практично кожен, хто вперше хоче покласти в бакет невеликий текстовий файл. Плагін закриває її двома чистими (Pure) нодами:

"Welcome" ──► String To UTF-8 Bytes ──► Data  (S3 Upload Bytes)

String To UTF-8 Bytes перетворює FString на TArray<uint8> — саме той тип, який приймає пін Data. Результат для "Welcome" — рівно сім байтів, по одному на символ ASCII (W, e, l, c, o, m, e), без позначки порядку байтів (BOM). Це саме ті байти, які опиняться в об'єкті: відкривши його потім у текстовому редакторі чи в консолі провайдера, ви побачите слово Welcome, і нічого зайвого перед ним.

Повний граф для завантаження текстового файлу з словом Welcome:

Event BeginPlay
   │
   ├─► Get S3 Subsystem → Get Default S3 Client ──┐
   │                                                │
   └─► "Welcome" → String To UTF-8 Bytes ───────────┼─► S3 Upload Bytes
                                                     │        Bucket Name  : my-bucket
                                                     │        Object Key   : welcome.txt
                                                     │        Data         : (з String To UTF-8 Bytes)
                                                     │        Content Type : text/plain
                                                     │
                                                     ├─ On Success → Print String "Готово"
                                                     └─ On Failure → Print String (Get S3 Diagnostic Hint)

Content Type варто вказати явно як text/plain — порожнє значення плагін надішле як application/octet-stream, і хоча вміст файлу від цього не зміниться, деякі провайдери й браузери відкриють такий об'єкт як завантаження файлу замість показу тексту на сторінці.

UTF-8 Bytes To String — зворотна нода, для протилежного завдання: прочитати назад невеликий текстовий об'єкт після S3 Download Bytes.

S3 Download Bytes ──► Data ──► UTF-8 Bytes To String ──► Print String

Обидві ноди коректно працюють і з нелатинськими символами: "Привіт" перетвориться на більше байтів, ніж символів (кожна кирилична літера в UTF-8 займає два байти), і так само точно розгорнеться назад у той самий рядок.

Зчитування¶

S3 Download File¶

Пише об'єкт одразу у файл, у міру надходження. Пам'ять не залежить від розміру, прогрес рухається плавно, а не стрибком з нуля до кінця. Пін Data на успіху порожній — байти у файлі. Невдале зчитування не лишає недописаного файлу.

Local File Path тут — той самий абсолютний або відносний кореня проєкту шлях, що й у S3 Upload File; правила й приклади — у розділі «Шлях до файлу» вище. Відсутні теки за вказаним шляхом створюються; наявний файл за цим шляхом перезаписується.

S3 Download Bytes¶

Повертає вміст у пам'ять. Підходить для того, що ви одразу використаєте: текстура, конфіг, невелике збереження.

S3 Download Range¶

Частина об'єкта — заголовок файлу, прев'ю, один запис.

Пін	Опис
`Range Start`	Перший байт, від нуля
`Range End`	Останній байт включно. `-1` — до кінця файлу

У результаті є Total Object Size — повний розмір об'єкта, навіть якщо ви прочитали кілька байтів.

S3 Download File Chunked¶

Зчитує об'єкт серією діапазонних запитів, послідовно, і пише результат у файл.

Пін	Опис
`Local File Path`	Той самий абсолютний або відносний кореня проєкту шлях, що й у `S3 Download File`
`Chunk Size Bytes`	Розмір одного запиту. `0` — узяти розмір частини з налаштувань (`Multipart Part Size Bytes`)

Це єдина нода зчитування, яка вміє продовжувати перерване: діапазони дають змогу попросити лише те, чого бракує, тоді як S3 Download File є одним потоковим запитом і починає наново. Тому для файлу, втрата якого на половині має значення, беріть саме її. Другий випадок для неї — провайдер, який не повідомляє довжину об'єкта наперед.

Байти лягають у <файл>.s3part поруч і потрапляють за призначенням лише зібраними повністю. Якщо об'єкт переписали посеред зчитування, нода не склеїть дві версії: спрацює On Failure з Precondition Failed. Детальніше — 5. Передавання файлів.

Пін On Progress тут спрацьовує один раз на кожен діапазон, а не побайтово: перший виклик може прийти ще з bTotalKnown = false — загальний розмір об'єкта плагін дізнається лише з відповіді на перший запит.

Перелік¶

S3 List Objects¶

Одна сторінка переліку.

Пін	Опис
`Prefix`	Лише ключі, що починаються з цього. Порожньо — усе
`Delimiter`	`/` для групування за «текою»; порожньо — плаский перелік
`Max Keys`	Розмір сторінки, від 1 до 1000
`Continuation Token`	Порожньо для першої сторінки

Для перегляду «як у файловому менеджері» передайте / як роздільник: у результаті Common Prefixes міститиме «теки», а Objects — файли цього рівня.

Коли результат каже Is Truncated, викличте ноду ще раз, передавши Next Continuation Token із попереднього результату.

S3 List Buckets¶

Перелік бакетів облікового запису. Потребує права рівня акаунта, якого у ключів «на один бакет» зазвичай немає, і не всі провайдери це реалізують — Cloudflare R2 завжди відповідає відмовою. Якщо ви й так знаєте потрібний бакет, ця нода вам не потрібна.

Метадані й видалення¶

S3 Get Metadata¶

Розмір, тип, час зміни, ETag і власні метадані — без зчитування самого об'єкта.

Це ще й найдешевший спосіб спитати «чи існує такий об'єкт»: невдача з Not Found означає, що його немає.

S3 Set Metadata¶

Замінює метадані об'єкта.

S3 не вміє редагувати метадані на місці, тож нода копіює об'єкт сам у себе на боці провайдера. Байти не подорожують до вас і назад, але час останньої зміни оновлюється, а метадані, не перелічені у виклику, зникають.

S3 Copy Object¶

Копіює об'єкт цілком на боці провайдера — байти не проходять через гравця чи сервер, які викликали ноду. Той самий механізм, яким S3 Set Metadata замінює метадані без повторного надсилання вмісту, тут використовується напряму.

Пін	Опис
`Source Bucket` / `Source Key`	Звідки копіювати
`Destination Bucket` / `Destination Key`	Куди. Бакет призначення може збігатися з джерелом або бути іншим, доступним тим самим ключам

Призначення переписується цілком: часткового злиття вмісту не буває.

S3 Delete Object¶

Видаляє один об'єкт. Видалення того, чого немає, вважається успіхом: кінцевий стан у обох випадках той, якого просили.

S3 Delete Objects (Batch)¶

Видаляє багато об'єктів мінімальною кількістю запитів — тисяча ключів за один.

Окремі ключі можуть бути відхилені, тоді як сам запит успішний. Тоді спрацьовує On Success із результатом Partial Success — перевіряйте Error Count і масив Results, а не вважайте, що зникло все.

S3 Create Bucket¶

Створює бакет. Потрібно провайдерам, які не створюють їх на льоту — зокрема MinIO. На Amazon S3 імена бакетів унікальні серед усіх клієнтів, тож правдоподібне ім'я часто вже зайняте.

S3 Delete Bucket¶

Видаляє бакет — сам бакет, а не об'єкти в ньому.

Провайдер відмовить, поки бакет не порожній: On Failure з кодом помилки BucketNotEmpty. Нода навмисно не спорожняє бакет сама — це окрема, незворотна дія, яку варто робити свідомо, а не як побічний ефект видалення бакета:

S3 Delete Bucket
   │
   └─► On Failure (ErrorCode == "BucketNotEmpty")
          │
          ▼
       S3 Delete Objects (Batch)  ← спорожнити свідомо
          │
          ▼
       S3 Delete Bucket           ← повторити

На Wasabi акаунт може додатково заблокувати видалення навіть порожнього бакета власною функцією безпеки («Security Contacts») — це не помилка запиту; докладніше в розділі 8. Провайдери.

Теги¶

Теги чи метадані: що з них брати¶

Обидва — пари «ключ-значення» поруч з об'єктом, і саме тому їх плутають. Різниця одна, але вона визначає вибір повністю:

	User Metadata	Теги
Коли задаються	Під час запису об'єкта	Будь-коли після
Змінити пізніше	Тільки переписавши об'єкт (`S3 Set Metadata` копіює його сам у себе)	Одним запитом, об'єкт не змінюється
Час останньої зміни	Оновлюється	Не змінюється
Правила життєвого циклу	Не бачать	Можуть відбирати об'єкти за тегом
Політики доступу	Не бачать	Можуть надавати права за тегом
Обмеження	~2 КБ на всі метадані	10 тегів, ключ до 128 символів, значення до 256

Практичне правило: незмінне — у метадані, змінне — у теги. Хто завантажив і якою версією гри — метадані. Статус модерації, «позначено на видалення», «сезон 2» — теги.

S3 Get Object Tags¶

Читає теги об'єкта.

Пін	Опис
`Object Key`	Ключ об'єкта, наприклад `saves/player1.sav`
`Result` → `Tags`	Мапа тегів. Порожня на успіху означає, що тегів просто немає — це не помилка

S3 Set Object Tags¶

Замінює теги об'єкта, не переписуючи сам об'єкт і не змінюючи час його останньої зміни.

Пін	Опис
`Tags`	Повний набір на заміну, наприклад `{"status": "verified", "season": "2"}`

Це заміна, а не злиття. Усе, чого немає у переданому наборі, зникає. Щоб додати один тег до наявних — спершу прочитайте поточні через S3 Get Object Tags, додайте до мапи потрібне й запишіть результат назад.

Значення можуть містити будь-які символи — амперсанди, лапки, кирилицю: плагін екранує їх у XML-документі запиту й розгортає назад під час читання, тож те, що ви записали, ви й прочитаєте.

S3 Delete Object Tags¶

Знімає з об'єкта всі теги одним запитом. Зняти теги з об'єкта, у якого їх не було, — успіх.

Типове застосування¶

Гравець надіслав скріншот на модерацію
   │
   └─► S3 Upload File                          (сам файл + незмінні метадані)
          │
          └─ On Success → S3 Set Object Tags   {"moderation": "pending"}

Модератор схвалив
   │
   └─► S3 Set Object Tags   {"moderation": "approved"}
          (об'єкт не переписується, час зміни лишається старим)

Далі правило життєвого циклу може автоматично видаляти все з тегом moderation=rejected через тридцять днів — саме заради таких сценаріїв теги й існують окремо від метаданих. Як задати таке правило — нижче.

Правила життєвого циклу¶

Правило життєвого циклу — це інструкція, яку ви один раз даєте бакету, а провайдер далі виконує її сам, за власним розкладом. Нічого не викликається ні з гри, ні з сервера: об'єкти просто починають жити за правилами.

Розклад приблизний. Провайдер обходить бакет зазвичай раз на добу, тож об'єкт не зникає тієї ж миті, коли став достатньо старим. Сприймайте строки як «не пізніше ніж приблизно», а не як таймер.

Скасувати не можна. Правило з терміном життя видаляє об'єкти. Кошика немає.

S3 Set Incomplete Upload Cleanup¶

Найважливіша нода цього розділу, і саме її варто виконати один раз для кожного бакета.

S3 Set Incomplete Upload Cleanup
    Bucket Name : my-game-saves
    After Days  : 7

Навіщо. Перерване багаточастинне завантаження лишає надіслані частини в бакеті. Вони оплачуються як сховище і не видно в переліку об'єктів — тобто за них можна платити роками, не підозрюючи про це.

Для цього плагіна це важливіше, ніж зазвичай: обірване завантаження навмисно не скасовується, щоб його можна було продовжити (див. 5. Передавання файлів). Саме це правило й прибирає ті завантаження, які так ніхто й не продовжив.

Значення After Days беріть із запасом відносно найдовшого завантаження, яке ще має сенс відновлювати. Сім діб — розумно за замовчуванням.

Ця нода замінює весь набір правил бакета. Якщо в бакеті вже є інші правила, які треба зберегти, користуйтеся S3 Set Bucket Lifecycle.

S3 Get Bucket Lifecycle¶

Читає правила бакета. Порожній список на успіху означає, що правил немає — це не помилка. (Провайдер відповідає на такий запит кодом помилки; плагін перетворює його на успіх із порожнім списком, бо «правил немає» — це відповідь, а не збій.)

S3 Set Bucket Lifecycle¶

Замінює набір правил. Кожне правило — структура S3 Lifecycle Rule:

Поле	Опис
`Id`	Ім'я правила, унікальне в межах бакета, наприклад `expire-temp-uploads`
`Enabled`	Вимкнене правило лишається в конфігурації, але нічого не робить
`Prefix`	Лише об'єкти, чий ключ починається з цього, наприклад `temp/`. Порожньо — усі об'єкти бакета
`Tag Filters`	Лише об'єкти з усіма цими тегами, наприклад `{"moderation": "rejected"}`
`Expire After Days`	Видалити відповідні об'єкти через стільки днів. `0` — не видаляти
`Abort Incomplete Uploads After Days`	Скасувати незавершені завантаження через стільки днів. `0` — не чіпати
`Expire Orphaned Delete Markers`	Прибрати «осиротілі» маркери видалення на версійному бакеті — див. нижче

Що таке «осиротілий маркер видалення» і коли він взагалі виникає¶

На звичайному, неверсійному бакеті Expire After Days просто видаляє об'єкт фізично — і Expire Orphaned Delete Markers тут ні до чого, вмикати його не треба. Це стосується лише бакетів із увімкненим версіюванням.

На версійному бакеті провайдер (за специфікацією S3) не видаляє об'єкт одразу: він ставить поверх нього маркер видалення (delete marker), а самі версії лишаються позаду нього. Якщо згодом усі версії позаду маркера теж зникли — прибрані іншим правилом чи вручну — маркер лишається ні на що не вказувати: осиротілим. Він і далі показується в переліку об'єктів, ніби там щось видалили, назавжди, поки щось його не прибере. Expire Orphaned Delete Markers — це і є те «щось».

Специфікація S3 забороняє поєднувати Expire After Days і Expire Orphaned Delete Markers в одному правилі — тому це завжди друге, окреме правило з тим самим Prefix/Tag Filters, що й перше, але іншим Id.

На Amazon S3, MinIO, Cloudflare R2 і Wasabi це поле не обов'язкове — знадобиться, лише якщо ви свідомо ввімкнули версіювання бакета. На Backblaze B2 — інакше: там сховище версійне на нативному рівні, тож Expire After Days без парного правила Expire Orphaned Delete Markers (з тим самим Prefix) провайдер просто відхиляє кодом 400 MalformedXML. Докладніше й приклад пари правил — у розділі 8. Провайдери → Backblaze B2.

Це заміна, а не доповнення. Набір, переданий сюди, стає всією конфігурацією бакета. Щоб додати правило до наявних — спершу прочитайте їх через S3 Get Bucket Lifecycle.

Порожній масив нода відхиляє: стерти конфігурацію бакета має бути свідомою дією, а не наслідком незаповненої змінної. Для цього є окрема нода нижче.

S3 Delete Bucket Lifecycle¶

Прибирає всі правила бакета. Самі об'єкти не чіпаються — просто провайдер більше не діятиме на них. Те, що правило вже видалило, повернути не можна.

Приклад: прибирання за собою¶

(один раз під час налаштування бакета)
   │
   ├─► Make Array
   │     [0] Id = "sweep-uploads"        Abort Incomplete Uploads After Days = 7
   │     [1] Id = "expire-temp"          Prefix = "temp/"    Expire After Days = 1
   │     [2] Id = "expire-rejected"      Prefix = "screenshots/"
   │                                     Tag Filters = {"moderation": "rejected"}
   │                                     Expire After Days = 30
   │
   └─► S3 Set Bucket Lifecycle (Bucket Name: my-game-saves)

Три правила: недороблені завантаження прибираються за тиждень, тимчасові файли живуть добу, відхилені модератором скріншоти зникають за місяць — і все це без жодного рядка коду, який довелося б виконувати вашій грі.

Чого немає¶

Переходів між класами зберігання (Glacier тощо) плагін не задає навмисно: самі класи різняться між провайдерами, а в кількох їх немає взагалі, тож таке правило працювало б на Amazon і мовчки не працювало б у решти. Якщо вони вам потрібні — задайте їх у консолі провайдера, вони не конфліктують із правилами, заданими звідси.

Підписані посилання¶

Дві ноди, і обидві — чисті (pure), зелені, без пінів виконання: посилання обчислюється локально, підписом наявних облікових даних, без жодного запиту до провайдера. Звідси й наслідок, який на перший погляд плутає — на відміну від кожної іншої S3-ноди, тут немає On Started/On Success/On Failure: підписувати URL нічому провалюватися через мережу, тож немає що очікувати чи ловити.

Пін	Опис
`Method`	Метод, для якого підписуємо. Посилання не працює з іншим методом
`Expires In Seconds`	Строк життя. Максимум — 604800 (7 діб), обмеження самого Signature Version 4. Значення понад це плагін не відхиляє, а мовчки обрізає до максимуму й пише попередження в лог

Типова помилка: підписати PUT-посилання й відкрити його у браузері. Браузер надсилає GET, і провайдер відхиляє підпис.

Яку з двох нод брати¶

Make Presigned URL (статична, категорія S3|Operations) бере Client окремим піном і повертає готовий FString. Це тонка обгортка — під капотом викликає ту саму Generate Presigned URL і повертає лише її Url; якщо Client порожній, просто віддає пустий рядок замість попередження «Accessed None».

Generate Presigned URL — нода прямо на самому клієнті («Target is S3Client», як у S3 Upload File та решти), повертає структуру FDemoS3PresignedUrlResult із двома полями:

Поле	Що це
`Url`	Те саме посилання, що й у `Make Presigned URL`
`Expires At`	Момент у UTC, коли посилання перестане працювати — `UtcNow` плюс `Expires In Seconds`, вже пораховано за вас

Якщо треба лише рядок для передавання клієнту — простіше Make Presigned URL. Якщо інтерфейс має показати «посилання дійсне ще N хвилин» або запланувати оновлення до закінчення строку — Generate Presigned URL рахує цей момент сам, а не лишає віднімати Expires In Seconds вручну.

Допоміжні ноди¶

Нода	Що робить
Is S3 Success	Чи все вдалося
Is S3 Partial Success	Чи пакетна операція виконалася частково
Get S3 Error Message	Текст помилки від провайдера
Get S3 Error Code	Машинний код, наприклад `NoSuchBucket`
Get S3 Diagnostic Hint	Що саме змінити. Найкорисніше для логів під час налагодження
Get S3 Result Summary	Усе перелічене одним рядком
Format Bytes	`4398046` → `4.2 MB`
Format Transfer Rate	`3.4 MB/s`

Дескриптор передавання¶

Об'єкт із піна On Started.

Нода	Що робить
Cancel	Зупиняє передавання
Is Cancelled	Чи вже попросили зупинитися
Is Finished	Чи передавання завершилося
Get Status	Pending, Running, Succeeded, Failed, Cancelled
Get Progress	Повна структура прогресу
Get Progress Fraction	Від 0 до 1 — просто під'єднати до смужки прогресу

Зберігати дескриптор після завершення нешкідливо: він просто повідомляє кінцевий стан. Викинути його — теж: передавання дійде до кінця самостійно.

Далі: 5. Передавання файлів