zeromind.search
Three pools, chosen with from: everything published, the worlds you own or maintain, or the world you have open. Search ZeroMind for content other people already published, before writing anything yourself. Describe what you want in q: write what the thing IS, DOES or LOOKS LIKE in plain words, never the name you imagine it has. Search decides which asset types your words are about, gathers candidates inside those types and across the whole library, and has a judge read every candidate against your query; it keeps the ones the judge rates relevant and orders them by p, best first, with nothing else (votes, popularity, freshness) blended in. Each hit carries a guid (what zeromind.inspect and zeromind.install take), a summary in prose (the closest thing the asset has to a written description of itself, drawn from whatever of it your query matched, so you can see WHY it is here), a similarity (how close the text is, 0 to 1), a p (the probability, 0 to 1, that the hit is what you asked for: hits are ordered and cut by it), and the world it lives in with its owner and licence. A hit whose identity is an image (a material, a texture, a mesh) also carries preview_description, the words describing what its preview shows, so you know what it looks like before you inspect it. A result also lists the types (the asset types your query was about, so you learn the vocabulary as you search) and the systems its hits belong to, each once, and a hit names its entries in type_key and system_key. LEAVE assetType OUT. Setting it replaces the type step: only the types you name are searched, so a wrong guess returns nothing even when the library holds exactly what you asked for. Name one only when the task itself fixes the type, such as a material to put on a renderer or a shader to compile. Zero hits means the judge found nothing relevant: rephrase by what the thing does or looks like. Use scope='worlds' to find whole projects instead of pieces. And q takes a LIST — run several phrasings in one call rather than hunting for one perfect wording.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | What you are looking for, in plain words. Describe what the thing IS, DOES or LOOKS LIKE rather than guessing at its name. PASS A LIST to run several phrasings in one call: the best wording for a corpus you have not seen is not knowable in advance, and ten phrasings as one call cost one round trip instead of ten. `results` matches the queries by position. | |
| from | No | WHERE results may come from. 'all' (default) is everything published. 'owned' is the worlds you own or maintain, private ones included: with scope='worlds' and mode='keyword' this is how you find one of your own worlds by what is in it when the name is forgotten. 'bound' is the world this conversation has open, answered by that world's engine, which is the only search that sees unpushed files and a private world's own content. Not combined with `worlds`, which already names worlds. | |
| mode | No | HOW the query is matched, and it matters only for from='owned' or from='bound'. from='all' (the library) has one behaviour: the search described on this tool, which is 'semantic' (the default). 'keyword' matches the words in what the holder of the files can read (ZeroMind's card of a world or asset under from='owned', the engine's own files under from='bound'), and every hit says which role and which file carried the words. Keyword takes from='owned' or from='bound'; the two modes never merge and neither falls back to the other. | |
| limit | No | Default 25. | |
| scope | No | WHICH POPULATION to search: 'assets' (default) = the pieces — modules, components, materials, textures; 'worlds' = whole projects. Looking for a finished game rather than a part of one is scope='worlds'. Not to be confused with `worlds`, which restricts which worlds results may come FROM. Not taken with from='bound': that search is answered by the world's own engine, which serves the question and not this service's routing. | |
| offset | No | 0-indexed page offset. A whole number, not a string of digits: a parameter of the wrong type is refused by name rather than read as absent. Not taken with from='bound', which is one page answered by the world's own engine. | |
| worlds | No | Comma-separated world GUIDS. Restricts results to content living in those worlds. This does not search worlds — that is scope='worlds' — but it does narrow one: under scope='worlds' the page holds only the worlds you named. Omit for everything. A token that is not a well-formed guid returns an error naming it, never a silent global search; a guid that names no world you can see is an empty result, which is a different answer. | |
| assetType | No | LEAVE THIS OUT in almost every call (alias: `kind`). Search already decides which asset types your words are about and reports them in `types`. Setting `assetType` REPLACES that step: only the types you name are searched, so a wrong guess returns nothing even when the library holds exactly what you asked for (a skatepark kit is found with no `assetType` and missed with a guess of bundle,mesh,package). Set it only when the task itself fixes the type: you need a material to put on a renderer, a shader to compile, an animation to play. Then name that one type, or a comma-separated list, any case: 'material', 'tool,toolbox'. Builtin engine types are addressed by name. A type somebody else defined is not: any number of people can define a type with the same name, so a name cannot pick one out; pass that type's asset_guid instead. Guids and names mix freely in the same list. An unrecognised name returns a 400 that lists the builtin types and explains the guid route; never a silent empty page. |