Get desktop application:
View/edit binary Protocol Buffers messages
Returns basic info about the editor's current state. All servers must implement this. Editor resources are parts of an editor which can be individually loaded or unloaded. Once a resource is loaded, various objects and functionality can be straightforwardly accessed within it.
Get objects matching a search query, with requested properties. A property does not have to be requested to search against it.
Returns a single object, within an editor resource type. This can be used if the exact key is known, or to get more properties after a broader search. It returns empty if object is not found (as opposed to an error).
Returns objects in batch, within an editor resource type. It returns only the objects which could be found.
Open a resource, like a map by name.
(message has no fields)
Jump to or frame the given object within the editor.
(message has no fields)
Start a given search in the editor.
Likewise, editors can do this if supported
(message has no fields)
Used in:
, ,Identifier for the object, to use for subsequent UI operations
All requested properties. The same property name can repeat multiple times, like EntityGroupIDs. Alternatively, PropertyValue could support arrays.
Used in:
For the moment, use a string key here. This could become more richly typed in the future.
Used in:
Some relatively unique identifier for a game object: the file it's in and an id within it. Clients should not examine this directly. Prefer to use properties. Note that EntityID is *not* a valid primary key. It would be a property of an entity. Clients should avoid constructing this key object directly. Instead, use high-level methods in a C# library to ensure that different editors use the same representation for game objects. Failing that, try to use keys returned by servers, rather than constructing them in clients. It is possible for key representations to change over time (and maybe even proto fields), but try to maintain backwards compatibility if it's not too arduous. This system is meant for data in straightforward key-value pairs, not complex recursive data.
Used in:
, , ,The lowercase name of the file that this game object appears in, after the interrot prefix (or other redundant prefixes if no interroot), and without the dcx extension. Overall, it should be reasonably stable across games. This might be "map/mapstudio/m10_00_00_00.msb" for a map, which is a top-level file. For a resource within a BND, this would be the path name, like "script/talk/m10_00_00_00/t204101000.esd" or "chr/c0000/tae/a00.tae" or "param/GameParam/ThrowParam.param". Note that protobuf interns strings while deserializing, so this is fairly cheap, but if necessary we can do some kind of reference table or RLE-type compression.
Optionally, a namespace within a file for scoping ids. For instance, in MSB, names are disambiguated only within regions/parts. FMGs don't need this - all ids are entry ids. Feel free to create dozens of these as appropriate for disambiguation purposes, but don't rely on this for precise type information (e.g. distinguishing enemies and objects) - use properties for that.
If there are multiple instances of something with the same id, like a param row for instance, this identifies which one it is, starting from 0, then 1, etc. This number should be stable but is not otherwise meaningful.
The main stable identifier for the object, scoped within the file and namespace. Generally, this should represent how the object is referenced within the format. If the object has a numerical identifier, use that. If it has a name field, use that. Try to avoid indices if there is a more stable alternative. If there is a multipart numerical id, separate parts using underscores. If this field is missing, this primary key can be used to mean the entire file.
String name, or specially formatted name
Integer id (any width)
Used in:
A game file with a unique path. This includes both bnd files and files within bnds.
A key-value entry in a game file.
An internal representation of a type of a PrimaryKey object. This is mainly for filtering search results.
Used in:
,A template version of the PrimaryKey file key, using {0} {1} by convention. For instance, using the examples given in PrimaryKey, the types would be "script/talk/{0}/{1}.esd" or "chr/{0}/tae/{1}.tae" or "param/GameParam/{0}.param".
The PrimaryKey namespace. Must not be unspecified.
Some basic search condition like EntityID == 5555
Used in:
Representation of a search. For anything more complex, an expression language can be added later.
Used in:
,Conjunctive normal form (AND of ORs)
This is a wrapper for scalar values supported by SearchProperties. The oneof includes a case enum by default, plus the value itself. shorts/bytes are represented using varint 32-bit values, as they have no special proto type.
Used in:
,This is quite a few values, but tag numbers are kept in one byte (<2^4, protobuf-net tag number performance) and it's stored with low overhead (private object value_).