TTP_cond to batch

Small node, and its own author is candid about how small: the pack's README describes it as "reserved for future functionality expansion" - which is a refreshingly honest way to flag that this is currently doing one narrow job and might grow later, rather than pretending it's more than it is.

What it does today. It takes conditionings (a CONDITIONING input - in practice, multiple individually-encoded prompts, one per tile if you're building a tiled-conditioning workflow) and converts that list into a single batched CONDITIONING output. That's it. No strength adjustment, no area assignment - just the list-to-batch conversion.

Why you'd want that specifically. If you're building the classic TTP Tile 1.0 regional-conditioning setup - a different prompt's influence per tile, stamped to that tile's area via TTP_condsetarea_merge - that merge node expects a conditioning_batch input, not a loose list of individually-encoded conditionings. This node is the step in between: encode each tile's prompt separately (however many CLIP Text Encode nodes that takes), feed all of them into TTP_condtobatch, and hand its single batched output to the merge node's conditioning_batch slot.

Where it fits in the chain. Per-tile prompts → CLIP Text Encode (one per tile) → TTP_condtobatch → conditioning_batch on TTP_condsetarea_merge, alongside TTP_CoordinateSplitter's output feeding that same merge node's coordinates input.

Install. ComfyUI Manager, search "Comfyui_TTP_Toolset", or cd ComfyUI/custom_nodes && git clone https://github.com/TTPlanetPig/Comfyui_TTP_Toolset, then restart. No models, no extra Python dependencies - this is a pure data-structure node, so there's nothing to download beyond the pack itself.

Why "reserved for future functionality" is worth taking at face value. Nodes in an actively-developed pack sometimes ship a step ahead of the feature that will eventually justify them - a placeholder for batching logic that isn't fully built out yet. That's a reasonable read here: today it does one thing (list to batch), and the author's own wording suggests more may be layered onto it later. If you're building around this node, don't assume undocumented behavior beyond "takes a list, returns a batch" - that's the only contract the schema and the README actually commit to right now.

Common issues. There isn't much to go wrong here mechanically - it's a batching operation, not a transformation with hidden logic - but the thing worth double-checking is order. The batch this node produces has to line up, entry for entry, with the coordinates list TTP_CoordinateSplitter produces, or TTP_condsetarea_merge will stamp the wrong prompt onto the wrong tile's region. If your tiled-conditioning result looks scrambled - a face tile getting a background prompt's influence, say - check that your per-tile prompt encode nodes are feeding into this node in the same order the tiles themselves came out of TTP_Image_Tile_Batch, since nothing here is matching tiles by name or label, only by position in the batch. And if you're only working with a single conditioning rather than a genuine per-tile batch, you likely don't need this node at all - it earns its place specifically in multi-tile, multi-prompt setups.