| Latest revision |
Your text |
| Line 3: |
Line 3: |
| | <code>ActorSerializeParameter</code> is a property on each object in an <code>ActorGeneratorList</code>. It contains much of the "per-instance" characteristics of the enemy it is generating, and contains parameter such as AI, object life and audio. | | <code>ActorSerializeParameter</code> is a property on each object in an <code>ActorGeneratorList</code>. It contains much of the "per-instance" characteristics of the enemy it is generating, and contains parameter such as AI, object life and audio. |
| | | | |
| − | Each member of <code>ActorSerializeParameter</code> is an object containing <code>Static</code> and <code>Dynamic</code> properties, both of which are varying-width arrays of 8bit integers that represent other data types. | + | Each membor of <code>ActorSerializeParameter</code> is an object containing <code>Static</code> and <code>Dynamic</code> properties, both of which are varying-width arrays of 8bit integers that represent other data types. |
| | | | |
| | <source lang="JSON"> | | <source lang="JSON"> |
| Line 11: |
Line 11: |
| | "AI": { | | "AI": { |
| | "Static": [], | | "Static": [], |
| − | "Dynamic": []; | + | "Dynamic": [] |
| − | }, | + | } |
| − | "Hash": { ... },
| |
| − | "CheckComp": { ... },
| |
| − | "ActorParameter": { ... },
| |
| − | "SubAI": { ... },
| |
| − | "Life": { ... },
| |
| − | "PortalTrigger": { ... },
| |
| − | "DemoTrigger": { ... },
| |
| − | "Pikmin": { ... },
| |
| − | "CharacterEdit": { ... },
| |
| − | "PopPlace": { ... },
| |
| − | "Strategy": { ... },
| |
| − | "CakEmitterConfig": { ... },
| |
| − | "CakSimpleState": { ... },
| |
| − | "CakTrigger": { ... },
| |
| − | "CakMultiplePosition": { ... },
| |
| − | "CakAudioTable": { ... },
| |
| − | "WaterTrigger": { ... },
| |
| − | "NavMeshTrigger": { ... },
| |
| − | "Affordance": { ... },
| |
| − | "HiddenBoxTrigger": { ... },
| |
| − | "NarrowSpaceBoxTrigger": { ... },
| |
| − | "WarpTrigger": { ... },
| |
| − | "ActionMarker": { ... },
| |
| | } | | } |
| | } | | } |
| Line 41: |
Line 18: |
| | </source> | | </source> |
| | | | |
| − | For the majority of actors in the game, most of the fields within <code>ActorSerializeParameter</code> are the same for each type of enemy - that is, all Kochappys in the game have the same Life, ActorParameter, CheckComp, etc. A data scrape of each unique value that each type of enemy can have can be found [https://github.com/Chagrilled/P4-DandoriDesktop/blob/master/src/api/entityData.json/ here]. This can be used for sourcing the non-changing values, or for various examples of each byte array for every creature and object. (Generating code is [https://github.com/Chagrilled/P4-DandoriDesktop/blob/master/scrape.js/ here]). | + | For the majority of actors in the game, most of the fields within <code>ActorSerializeParameter</code> are the same for each type of enemy. A data scrape of each unique value that each type of enemy can have can be found [https://github.com/Chagrilled/P4-DandoriDesktop/blob/master/src/api/entityData.json/ here] (note, does not include night enemies). This can be used for sourcing the non-changing values, or for various examples of each byte array for every creature and object. (Generating code is [https://github.com/Chagrilled/P4-DandoriDesktop/blob/master/scrape.js/ here]). |
| | | | |
| | == AI == | | == AI == |
| | | | |
| − | AI is the interesting and important parameter. It controls per-instance parameters for actors such as drops, territory, and configuration for gimmicks. I currently believe that AI is mapped on top of an entity's own blueprint configuration from its <code>Placeables/</code> file, with AI able to send overrides to parts of it, though I've yet to work out where these bytes go. We can see traces of the Sublevels files showing AI gen variables with overriden base parameters. | + | AI is the interesting and important parameter. It controls per-instance parameters for actors such as drops, territory, and configuration for gimmicks. I currently believe that AI is mapped on top of an entity's own blueprint configuration from its <code>Placeables/</code> file, with AI able to send overrides to parts of it. |
| | + | |
| | + | Thus far, 3 types of teki AI have been partly charted, mostly pertaining to the inventory system. |
| | | | |
| | === Concepts === | | === Concepts === |
| Line 63: |
Line 42: |
| | == Charts == | | == Charts == |
| | | | |
| − | Attempts have been made to chart the bytes of various AI parameters to uncover patterns and the locations of values in order to manipulate them. | + | Attempts have been made to chart the bytes of various AI parameters to uncover patterns and the locations of values in order to manipulate them. The current diagrams mostly illustrate the inventory system. |
| | | | |
| − | There are many bytes AFTER the end of the inventory which ends in 4 bytes of <code>255, 255, 255, 255</code> (<code>-1</code>), but I have no idea what they do yet. I believe they're probably the overrides for the enemy's AI_GEN_VARIABLE, and other objects like <code>SniffPointParameter</code>. | + | There are many bytes AFTER the end of the inventory which ends in 4 bytes of <code>255, 255, 255, 255</code> (<code>-1</code>), but I have no idea what they do. I believe they're probably the overrides for <code>TekiAIParameter</code> and each enemy's custom AI arguments. |
| | | | |
| | === Creature AI === | | === Creature AI === |
| − | Details the drop system for a regular enemy (and eggs). The inventory system (<code>DropParameter</code>) used here is nearly universal in the game, with objects having a slightly different structure for some reason, but is mostly the same, so it helps to understand creatures first. | + | Details the drop system for a regular enemy (and eggs). The inventory system used here is the same as in GroupDropManager's, so it helps to understand creatures first. |
| | | | |
| | [[File:P4-creature-ai-inventory-bytes.png|500px|thumb|center|]] | | [[File:P4-creature-ai-inventory-bytes.png|500px|thumb|center|]] |
| Line 80: |
Line 59: |
| | | | |
| | [[File:P4-gdm-ai.png |500px|thumb|center|]] | | [[File:P4-gdm-ai.png |500px|thumb|center|]] |
| − |
| |
| − | === NoraSpawner AI ===
| |
| − |
| |
| − | [[File:P4-noraspawner-ai.png |500px|thumb|center|]]
| |
| − |
| |
| − | === PortalTrigger Gen Variable ===
| |
| − |
| |
| − | This chart is for the <code>PortalTrigger.Static</code> part of <code>ActorSerializeParameter</code> and will usually be used in conjunction with portal objects like <code>MadoriRuins</code> and <code>DownPortal</code>.
| |
| − |
| |
| − | [[File:p4-portaltrigger-ai.png |500px|thumb|center|]]
| |
| − |
| |
| − | === AreaBase AI Gen Variable ===
| |
| − |
| |
| − | This chart is for the base camps.
| |
| − |
| |
| − | [[File:p4-areabasecamp-ai.png |500px|thumb|center|]]
| |
| − |
| |
| − |
| |
| − | === Sprinkler AI and ObjectAIParameter ===
| |
| − |
| |
| − | Objects mostly seem composed of two objects - <code>ObjectAIParameter</code> and an entity-specific object, like <code>SprinklerAIParameter</code>. The former contains inventories (<code>DropParameter</code>) and some stuff to do with edge collision it seems, while the latter controls everything specific to the entity. The chart below illustrates it for sprinklers.
| |
| − |
| |
| − | * To have a valve that is permanently on - enable `bSprinklerOnly` and set `valveID` to `None`.
| |
| − | * To connect a valve, match the `valveID` to the valve object's ID. The only valve config I've found works is to use the `Build` workType. This setup will have a sprinkler turn on once for `OpenTime` number of seconds upon valve activation, then turn off - this is how Cave013 douses fire.
| |
| − | * To have a sprinkler always on, make a `NavMeshTriggerLinkForSplash` object on top of the sprinkler, and make the `NavMeshTriggerID`s for both match. The sprinkler and valve cannot have the same `demoBindName`. I've not played much with these, but I believe they _may_ be to do with saving the state of the sprinkler after the cutscene has played. In my working example, I used `GSprinkler05` and `GValveOnce06` for my `demoBindName`s, and `demoId` of `0`.
| |
| − |
| |
| − | [[File:p4-sprinkler-objectAI.png |500px|thumb|center|]]
| |
| − |
| |
| − | === Valve AI ===
| |
| − |
| |
| − | Valves have a few properties in their parameter, but ObjectParameter is mostly unused here. There are some missing values that I haven't found the indexes for, but you can see the default values in FModel's blueprint. The enum values for EValveWorkType are also unknown, but 2 and 6 are confirmed.
| |
| − |
| |
| − | [[File:p4-valveai.png |500px|thumb|center|]]
| |
| − |
| |
| − | === NavMeshTriggers ===
| |
| − |
| |
| − | There are 3 types: <code>NavMeshTrigger</code>, <code>NavMeshTriggerClear</code> and <code>NavMeshTriggerLinkForSplash</code> (for sprinklers). My current understanding is that these triggers send pulses to whatever they're linked to on a timer or some conditions. These bytes come from the <code>NavMeshTrigger</code> part of <code>ActorSerializeParameter</code>, and seem to be some of the only objects in the game that use that property. It is worth noting that the <code>AI</code> property for <code>NavMeshTriggerLinkForSplash</code> is identical for every instance of this actor across the game. <code>NavMeshTriggerClear</code> has several different sets of AI bytes though.
| |
| − |
| |
| − | [[File:p4-navmeshtrigger.png |500px|thumb|center|]]
| |
| − |
| |
| − | === Geyser AI ===
| |
| − |
| |
| − | The geyser's AI bytes are actually comprised of an <code>ObjectAIParameter</code> as usual, followed by the <code>GeyserAI_GEN_VARIABLE</code> and then the <code>NavLink_GEN_VARIALBE</code>. What's interesting to note about this is that it means the <code>AI.Static</code> array can contain more than just what is in <code>AI_GEN_VARIABLE</code>. Primitive geysers can be made simply by editing the <code>Right</code> vector, which applies the vector to your coordinates with some velocity number.
| |
| − |
| |
| − | [[File:p4-geyser-ai.png |500px|thumb|center|]]
| |
| | | | |
| | === Researching === | | === Researching === |
| Line 130: |
Line 64: |
| | The best way of breaking down the AI parameter (I have found) is to combine the blueprint JSONs from the <code>Sublevels/</code> folder, with the <code>ActorPlacementInfo</code> file of the same type. The Sublevels files contain the gen_variables that seem to be encoded into the byte arrays of ActorSerializeParameter. | | The best way of breaking down the AI parameter (I have found) is to combine the blueprint JSONs from the <code>Sublevels/</code> folder, with the <code>ActorPlacementInfo</code> file of the same type. The Sublevels files contain the gen_variables that seem to be encoded into the byte arrays of ActorSerializeParameter. |
| | | | |
| − | AI parameters can be found by searching for <code>{entity}AI_GEN_VARIABLE</code>, for example <code>ElecMushiAI_GEN_VARIABLE</code> for Anode Beetles. Most of the contents of that object's <code>Properties</code> will be encoded in that actor's <code>ActorSerializeParameter.AI.Static</code> in the <code>ActorPlacementInfo</code> file, so you can compare things like the drop numbers, asset path and other such floats for occurrences of those values in the AI array. Strings are often the easiest to find/locate with due to their easy to spot nature (look for the big sequence of non-0 numbers and decode it to see if it matches what you need). Finding two instances in Sublevel files that have different values for a given property (or the property being set at all for infrequent ones) will tell you which actor instances to look for in the AP files, which you can then anaylse the bytes for to find your different value, giving you its array index/type. | + | AI parameters can be found by searching for <code>{entity}AI_GEN_VARIABLE</code>, for example <code>ElecMushiAI_GEN_VARIABLE</code> for Anode Beetles. Most of the contents of that object's <code>Properties</code> will be encoded in that actor's <code>ActorSerializeParameter.AI.Static</code> in the <code>ActorPlacementInfo</code> file, so you can compare things like the drop numbers, asset path and other such floats for occurrences of those values in the AI array. Strings are often the easiest to find/locate with due to their easy to spot nature (look for the big sequence of non-0 numbers and decode it to see if it matches what you need). |
| − | | |
| − | A scrape of all of the sublevel files can be found in [https://github.com/Chagrilled/P4-DandoriDesktop/blob/master/src/api/sublevels.json Dandori Desktop's repo] which collects every parameter that each entity ever defines - so every drop, and config param ever given to any Kochappy, for example. This is very useful for finding all the potential values of random things like <code>GameRulePermissionFlag</code> or <code>CustomParameter</code>, and is a great starting point for piecing parts of the AI puzzles together, as params like <code>ObjectAIParameter</code> and <code>TekiAIParameter</code> are shared frequently, with individual properties being set on certain entities. This isn't comprehensive as many properties are just left defaulted, which doesn't mean they can't be changed, just that we don't have 2 differing examples to easily locate them in the bytes.
| |
| − | | |
| − | The blueprints can also be viewed in FModel (in <code>Placeables/</code>), and you can find the <code>AI_GEN_VARIABLE</code>s which should have all the property names and their default values. I've had limited success here, as you often can't just find the value in the AI bytes, but it can definitely give insight into what must be available in the object, and other possible enum values etc. This leads me to think it's possible that non-overriden fields of the gen variable objects are left zeroed, which doesn't make much sense, because how would you set a value of zero? idk.
| |
| − | | |
| − | === Data Dumps ===
| |
| − | | |
| − | * [https://github.com/Chagrilled/P4-DandoriDesktop/blob/master/src/api/entityData.json/ entityData.json] - a dump of every unique value every actor has in the game from the AP files
| |
| − | * [https://github.com/Chagrilled/P4-DandoriDesktop/blob/master/src/api/sublevels.json Sublevels.json] - a dump of every value each actor can have from the Sublevels files - these are the English overriden parameter names
| |
| − | * [https://github.com/Chagrilled/P4-DandoriDesktop/blob/master/scrape.js/ scrape.js] - the code to generate the above lists - can be supplied an actor name to extract its section from <code>entityData.json</code> given how bulky that file is. Clone Dandori Desktop and run <code>node scrape.js Kochappy</code> to dump Kochappy's data into the <code>extractions/</code> folder
| |
| | | | |
| | [[Category:Pikmin 4]] | | [[Category:Pikmin 4]] |
| | [[Category:Parameters]] | | [[Category:Parameters]] |
