Pikmin Technical Knowledge Base - User contributions [en]

Pikmin 4 instructions

2025-10-06T21:55:23Z

Noodl:

Basic information about ''Pikmin 4''.

Until we have more information about ''Pikmin 4'', I will be consolidating all the research we find into [https://docs.google.com/document/d/1DU4ix_WIJW3f59-QoBVV7i1bitGmpC7_3c2dv6pG7To/edit?usp=sharing|this document here]. You can make changes to this page if you would like or you can comment on changes to the sheet we already have.

== Tools ==

To get started modding Pikmin 4, download [[Dandori Desktop]] to get started. Refer [https://github.com/Chagrilled/P4-DandoriDesktop/?tab=readme-ov-file#%EF%B8%8F-setupworkflow these instructions] to setup or [https://www.youtube.com/watch?v=v8bnNXRQmy8&t=62s this video]

[[Category:Instructions]]
[[Category:Pikmin 4]]

P4UassetEditor

2025-09-22T20:34:47Z

Noodl:

'''P4UassetEditor''' is a tool made by [[Infinity Divided]] that allows the decompiling and compiling of uasset files that can be edited with ease using simple json.

== Noodl's Version ==
* Compiled into an exe using Cython to remove the Python dependency (just download and run)
* Includes the required manifest/global files already pre-packed
* [https://github.com/Chagrilled/P4-Utils/raw/refs/heads/master/tooling/P4UassetEditor.zip Download Link]

== Prerequisites ==
* [https://www.python.org/downloads/ Python]
* PIP + Cityhash

== Installing PIP + Cityhash ==
* To install PIP Cityhash, when downloading Python, make sure to tick "Add python.exe to PATH" during installation.

* Open command prompt and type "python get-pip.py" to install PIP, press enter to run the command.

* After installing PIP, install cityhash by returning to command prompt and running "pip install cityhash".

== Link ==
* [https://pixeldrain.com/u/m3ctP8sL Download Link]

== Usage ==
To use this tool you'll need to first extract your "global.ucas" from your copy of Pikmin 4 and place it into the "_GLOBAL_UCAS" folder on the directory of the tool, next click generate_global_names.bat to generate your global names from your "global.ucas", to decode your files simply click drop your ".uasset" file into the "INPUT" directory and click "decode.bat", to pack your files place your json in the "EDIT" directory and click "encode.bat".

[[Category:Pikmin 4]]
[[Category:Tools]]

P4UassetEditor

2025-09-22T20:34:15Z

Noodl:

'''P4UassetEditor''' is a tool made by [[Infinity Divided]] that allows the decompiling and compiling of uasset files that can be edited with ease using simple json.

== Noodl's Version ==
* Compiled into an exe using Cython to remove the Python dependency
* Includes the required manifest/global files already pre-packed
* [https://github.com/Chagrilled/P4-Utils/raw/refs/heads/master/tooling/P4UassetEditor.zip Download Link]

== Prerequisites ==
* [https://www.python.org/downloads/ Python]
* PIP + Cityhash

== Installing PIP + Cityhash ==
* To install PIP Cityhash, when downloading Python, make sure to tick "Add python.exe to PATH" during installation.

* Open command prompt and type "python get-pip.py" to install PIP, press enter to run the command.

* After installing PIP, install cityhash by returning to command prompt and running "pip install cityhash".

== Link ==
* [https://pixeldrain.com/u/m3ctP8sL Download Link]

== Usage ==
To use this tool you'll need to first extract your "global.ucas" from your copy of Pikmin 4 and place it into the "_GLOBAL_UCAS" folder on the directory of the tool, next click generate_global_names.bat to generate your global names from your "global.ucas", to decode your files simply click drop your ".uasset" file into the "INPUT" directory and click "decode.bat", to pack your files place your json in the "EDIT" directory and click "encode.bat".

[[Category:Pikmin 4]]
[[Category:Tools]]

UCas/UToc Packer

2025-09-22T20:32:56Z

Noodl:

'''UCas/UToc Packer''' is a tool forked by [[brekko]], that allows users to pack their mods into a compiled format for Pikmin 4.

== Link ==
* [https://pixeldrain.com/u/YDpPqRUA Download Link]
* [https://github.com/Chagrilled/P4-Utils/raw/refs/heads/master/tooling/castoc.zip Backup Link]

== Usage ==
To use this tool simply extract the packer into a new directory and create a directory as listed below

PACKINPUT\Carrot4\Content\Carrot4\(File X)

File X = file to be replaced

Insert your new files into the newly created directory and run "PACKFILES.bat"

Your packed files will be located in the "PACKOUTPUT" directory

*NOTE: Packer is case sensitive, please be aware that files and file directory names must be 1:1

[[Category:Pikmin 4]]
[[Category:Tools]]

AddLand Units

2025-09-06T23:47:39Z

Noodl:

=== AddLand Units ===
AddLand entities are placeable objects in Pikmin 4 that are usually mounds. They have full collision and can be used as a form of custom geometry. All images are taken by inserting 3 mounds in the starting spawn of Sun Speckled Terrace.

{| class="wikitable"
|+ AddLand Units
|-
! Entity Name !! In-Game
|-
| AddLand01_Area001_M || [[File:AddLand01_Area001_M.png|thumb]]
|
|-
| AddLand02_Area001_M|| [[File:AddLand02_Area001_M.png|thumb]]
|-
| AddLand03_Area001_M|| [[File:AddLand03_Area001_M.png|thumb]]
|
|-
| AddLand04_Area001_M|| [[File:AddLand04_Area001_M.png|thumb]]
|
|-
| AddLand01_Area002_M|| [[File:AddLand01_Area002_M.png|thumb]]
|
|-
| AddLand02_Area002_M|| [[File:AddLand02_Area002_M.png|thumb]]
|
|-
| AddLand01_Area003_L01|| [[File:AddLand01_Area003_L01.png|thumb]]
|
|-
| AddLand02_Area003_L|| [[File:AddLand02_Area003_L.png|thumb]]
|}

[[Category:Pikmin 4]]
[[Category:Stage Generation]]

AddLand Units

2025-09-06T18:24:19Z

Noodl:

AddLand Units

2025-09-06T18:23:44Z

Noodl:

=== AddLand Units ===
AddLand entities are placeable objects in Pikmin 4 that are usually mounds. They have full collision and can be used as a form of custom geometry.

{| class="wikitable"
|+ AddLand Units
|-
! Entity Name !! In-Game
|-
| AddLand01_Area001_M || [[File:AddLand01_Area001_M.png|thumb]]
|
|-
| AddLand02_Area001_M|| [[File:AddLand02_Area001_M.png|thumb]]
|-
| AddLand03_Area001_M|| [[File:AddLand03_Area001_M.png|thumb]]
|
|-
| AddLand04_Area001_M|| [[File:AddLand04_Area001_M.png|thumb]]
|
|-
| AddLand01_Area002_M|| [[File:AddLand01_Area002_M.png|thumb]]
|
|-
| AddLand02_Area002_M|| [[File:AddLand02_Area002_M.png|thumb]]
|
|-
| AddLand01_Area003_L01|| [[File:AddLand01_Area003_L01.png|thumb]]
|
|-
| AddLand02_Area003_L|| [[File:AddLand02_Area003_L.png|thumb]]
|}

AddLand Units

2025-09-06T18:23:30Z

Noodl:

=== ActorSpawner AI ===
AddLand entities are placeable objects in Pikmin 4 that are usually mounds. They have full collision and can be used as a form of custom geometry.

{| class="wikitable"
|+ AddLand Units
|-
! Entity Name !! In-Game
|-
| AddLand01_Area001_M || [[File:AddLand01_Area001_M.png|thumb]]
|
|-
| AddLand02_Area001_M|| [[File:AddLand02_Area001_M.png|thumb]]
|-
| AddLand03_Area001_M|| [[File:AddLand03_Area001_M.png|thumb]]
|
|-
| AddLand04_Area001_M|| [[File:AddLand04_Area001_M.png|thumb]]
|
|-
| AddLand01_Area002_M|| [[File:AddLand01_Area002_M.png|thumb]]
|
|-
| AddLand02_Area002_M|| [[File:AddLand02_Area002_M.png|thumb]]
|
|-
| AddLand01_Area003_L01|| [[File:AddLand01_Area003_L01.png|thumb]]
|
|-
| AddLand02_Area003_L|| [[File:AddLand02_Area003_L.png|thumb]]
|}

AddLand Units

2025-09-06T18:20:48Z

Noodl: Created page with "=== ActorSpawner AI === AddLand entities are placeable objects in Pikmin 4 that are usually mounds. They have full collision and can be used as a form of custom geometry. {| class="wikitable" |+ AddLand Units |- ! Entity Name !! In-Game |- | AddLand01_Area001_M || thumb | |- | AddLand02_Area001_M|| thumb |- | AddLand03_Area001_M|| thumb | |- | AddLand04_Area001_M|| File:..."

=== ActorSpawner AI ===
AddLand entities are placeable objects in Pikmin 4 that are usually mounds. They have full collision and can be used as a form of custom geometry.

{| class="wikitable"
|+ AddLand Units
|-
! Entity Name !! In-Game
|-
| AddLand01_Area001_M || [[File:AddLand01_Area001_M.jpg|thumb]]
|
|-
| AddLand02_Area001_M|| [[File:AddLand02_Area001_M.jpg|thumb]]
|-
| AddLand03_Area001_M|| [[File:AddLand03_Area001_M.jpg|thumb]]
|
|-
| AddLand04_Area001_M|| [[File:AddLand04_Area001_M.jpg|thumb]]
|
|-
| AddLand01_Area002_M|| [[File:AddLand01_Area002_M.jpg|thumb]]
|
|-
| AddLand02_Area002_M|| [[File:AddLand02_Area002_M.jpg|thumb]]
|
|-
| AddLand01_Area003_L01|| [[File:AddLand01_Area003_L01.jpg|thumb]]
|
|-
| AddLand02_Area003_L|| [[File:AddLand02_Area003_L.jpg|thumb]]
|}

File:AddLand04 Area001 M.png

2025-09-06T18:18:38Z

Noodl:

File:AddLand03 Area001 M.png

2025-09-06T18:18:31Z

Noodl:

File:AddLand02 Area003 L.png

2025-09-06T18:18:23Z

Noodl:

File:AddLand02 Area002 M.png

2025-09-06T18:18:15Z

Noodl:

File:AddLand02 Area001 M.png

2025-09-06T18:18:06Z

Noodl:

File:AddLand01 Area003 L01.png

2025-09-06T18:17:57Z

Noodl:

File:AddLand01 Area002 M.png

2025-09-06T18:17:46Z

Noodl:

File:AddLand01 Area001 M.png

2025-09-06T18:17:37Z

Noodl:

Main Page

2025-09-06T18:11:12Z

Noodl: AddLand Page

{{MainTemplate
| welcome = Welcome to the '''''Pikmin'' Technical Knowledge Base'''!
| blurb = A wiki dedicated to the internal files in ''Pikmin'' games.
| about_title = About
| about_content =
Throughout the years, ''Pikmin'' fans have tinkered with the files inside the games in order to better learn how they work, and to create custom content. Since there are a lot of nuances in every little thing, and since newcomers to the concept of file editing show up all the time, this wiki was created with the purpose of serving as a knowledge base for all that the fans know!

'''Partners''':
* [https://pikminwiki.com Pikipedia] - the ''Pikmin'' wiki
* [https://discord.gg/msMKc3G Pikcord] - the ''Pikmin'' community Discord server
* [https://discord.gg/G7Pgkdh Hocotate Hacker] - the ''Pikmin'' hacking community Discord server
| other_title = What this wiki is ''not''
| other_content =
* It's not a wiki about pirating ''Pikmin'' games.
* It's not a file-sharing service.
* It's not a wiki where you document...
** Canon content. Try [https://pikminwiki.com/ Pikipedia] instead.
** Fan-made content. Try [https://pikminfanon.com/ Pikmin Fanon] instead.
** Unused content or regional differences. Try [https://tcrf.net TCRF] instead.
* It's not an official source of info. The information here is mostly obtained via experimenting, and is subject to change as new discoveries are made.
}}

== Global information ==
{| class="wikitable" style="margin: auto; width: 75%;"
! colspan="3" | Global info
|-
| colspan="3" |
{| style="margin: auto;"
|
* [[General instructions]]
* [[Glossary]]
* [[Save files]]
* [[:Category:Tools|Tools]]
|}
|}

== Game-specific information ==
{| class="wikitable" style="margin: auto; width: 75%;"
! width="20%;" | ''Pikmin'' (and ''New Play Control! Pikmin'')
! width="20%;" | ''Pikmin 2'' (and ''New Play Control! Pikmin 2'')
! width="20%;" | ''Pikmin 3'' (and ''Pikmin 3 Deluxe'')
! width="20%;" | ''Hey! Pikmin''
! width="20%;" | ''Pikmin 4''
|-

! colspan="5" | General
|-
| valign="top" |
* [[Pikmin|Main information]]
* [[Pikmin instructions|Instructions]]
* [[Pikmin cheat codes|Useful cheat codes]]
* [[Pikmin memory addresses|Memory addresses]]
* [[Pikmin glossary|Glossary]]

| valign="top" |
* [[Pikmin 2|Main information]]
* [[Pikmin 2 instructions|Instructions]]
* [[Pikmin 2 cheat codes|Useful cheat codes]]
* [[Pikmin 2 memory addresses|Memory addresses]]
* [[Pikmin 2 troubleshooting|Troubleshooting]]
* [[Pikmin 2 glossary|Glossary]]

| valign="top" |
* [[Pikmin 3|Main information]]
* [[Pikmin 3 instructions|Instructions]]
* [[Pikmin 3 troubleshooting|Troubleshooting]]
* [[Pikmin 3 glossary|Glossary]]

| valign="top" |
* [[Hey! Pikmin|Main information]]
* [[Hey! Pikmin instructions|Instructions]]
* [[Hey! Pikmin troubleshooting|Troubleshooting]]
* [[Hey! Pikmin glossary|Glossary]]

| valign="top" |
* [[Pikmin 4|Main information]]
* [[Pikmin 4 instructions|Instructions]]
* [[Pikmin 4 troubleshooting|Troubleshooting]]
* [[Pikmin 4 glossary|Glossary]]
|-

! colspan="5" | File lists
|-
| valign="top" |
* [[Pikmin directory tree|Directory tree]]
* [[JAM file list|JAM file list (Pikiseq.arc)]]
* [[STX file list|STX file list]]
* [[CIN file list|CIN file list]]

| valign="top" |
* [[Pikmin 2 directory tree|Directory tree]]
* [[AST file list|AST (streamed music)]]
* [[Pikmin 2 BMS file list|BMS (sequenced music)]]
* [[Pikmin 2 CND file list|CND (sequenced music for caves)]]
* [[Se.bms|Sound effects list]]
* [[Pikmin 2 cave units information|List of information of each cave unit]]

| valign="top" |
* [[Pikmin 3 directory tree|''Pikmin 3'' directory tree]]
* [[Pikmin 3 Deluxe directory tree|''Pikmin 3 Deluxe'' directory tree]]
* [[BFSTM file list|BFSTM (streamed music)]]
* [[MSBT file list|MSBT (text string)]]

| valign="top" |
* [[Hey! Pikmin directory tree|Directory tree]]
* [[BCSTM file list|BCSTM (music)]]

| valign="top" |
* [[Pikmin 4 directory tree|directory tree]]
|-

! colspan="5" | Constants
|-
| valign="top" |
* [[Pikmin identifiers|Identifiers]]
* [[Olimar's voyage log table]]

| valign="top" |
* [[Pikmin 2 identifiers|Identifiers]]
* [[Pikmin 2 Pikmin states|Pikmin states]]

| valign="top" |
* [[Pikmin 3 identifiers|Identifiers]]
* [[Pikmin 3 progress value|Progress value]]

| valign="top" |
* [[Hey! Pikmin identifiers|Identifiers]]

| valign="top" |
* [[Pikmin 4 identifiers|Identifiers]]
* [[Pikmin 4 text identifiers|Text Identifiers]]
|-

! colspan="5" | Particle effects
|-
| valign="top" |
* [[PCR particles]]

| valign="top" |
* [[JPC particles]]

| valign="top" |
* [[PTCL particles (Pikmin 3)]]

| valign="top" |
* [[PTCL particles (Hey Pikmin)]]

| valign="top" |

|-

! colspan="5" | Stage generation
|-
| valign="top" |
* [[Pikmin binary GEN format|Binary GEN format]]
* [[Pikmin route|Routes]]

* Outdated pages
** [[Pikmin area generator file|Generator]]
** [[Pikmin gen codes|Gen codes]]

| valign="top" |
* Overworld
** [[Pikmin 2 area generator file|Overworld generation parameters]]
** [[Pikmin 2 map lighting files|Lighting]]
** [[Pikmin 2 waterboxes|Waterbox]]
** [[Pikmin 2 collision format|Collision]]
* Caves
** [[Cave generation parameters|Cave generation parameters]]
** [[Pikmin 2 Challenge Mode settings|Challenge Mode]]
** [[Pikmin 2 cave lighting files|Lighting]]
* Units (cave rooms)
** [[Cave unit generation|Cave unit generation]]
** [[Cave unit definition file|Cave unit definition]]
** [[Cave fixed layout|Cave fixed layout]]
* [[Pikmin 2 route|Routes]]

| valign="top" |

| valign="top" |

| valign="top" |
* Teki Units
** [[NoraSpawner]]
* [[Dandori Battles]]
* [[Disabling Pikmin]]
* [[AddLand Units]]
|-

! colspan="5" | File formats
|-
| valign="top" |
* Archive Formats
** [[Paired ARC+DIR file]]
** [[BUN file]] (also ANM)
** [[BARC file]]
* Binary formats
** [[MOD file]] (3D Model)
** [[TXE file]] (Texture)
** [[BTI file]] (Texture)
** [[BLO file]] (2D screen data)
** [[PCR file]] (Particle effect parameters)
** [[DC? files]] (Identifier for either DCA or DCK)
*** [[DCA file]] (Animation)
*** [[DCK file]] (Animation)
** [[H4M file]] (Pre-rendered video)
** [[JAM file]] (Sequenced music)
** [[STX file]] (Streamed music)
** [[AW file]] (Sound Bank)
** [[BX file]] (Sound system archive)
** [[Pikmin parameter files|Parameter Files]]
* Plaintext Formats
** [[CIN file]] (Cutscene resource manager)
** [[DSK file]] (Cutscene data)
** [[DMD file]] (Intermediary 3D model)
** [[CNV file]] (Intermediary conversion file)
* Unknown Formats
** [[GST file]]
** [[ACT file]]
** [[CARD file]]
* Missing Formats
** [[DVW file]] (Material file?)
** [[JMP file]] (Intermediary plaintext 3D model file?)
** [[MD3 file]] (3D Model)
** [[BSP flle]] (3D Model)

| valign="top" |
* Archive Formats
** [[SZS file]]
** [[RARC file]]
* [[BMD file]] (J3D model)
* [[BTI file]] (Texture)
* [[BTK file]] (Animated texture)
* [[JPC file]] (Particle effect container)
** [[JPA file]] (Particle effect)
* [[BCA file]] (Animation)
* [[BCK file]] (Animation)
* [[AAF file]] (Sound system archive)
* [[BMS file]] (Sequenced music)
* [[AST file]] (Streamed music)
* [[AW file]] (Soundfont)
* [[THP file]] (Pre-rendered video)
* [[BLO file]] (2D screen data)
* [[STB file]] (Cutscene data)
* [[BMG file]] (Text)
* [[BPK file]]
* [[BRK file]]
* [[BMC file]]

* Misc.
** [[DWN file]] (e-Reader minigames?)
** [[DMD file]] (Intermediary 3D model)
** [[Pikmin 2 title screen|Title screen]]
** [[Pikmin 2 save file|Saved game data]]
** [[2-Player Battle stage parameters]]
** [[Mail]]

| valign="top" |

* [[Pikmin 3 radar files|Radar]]
* [[BFSTM file|BFSTM (streamed music)]]
* [[BFRES file|BFRES (file container, usually for 3D models and animations)]]
* [[BFLYT file|BFLYT (2D layout data)]]
* [[MSBT file (Pikmin 3)|MSBT (text string)]]
* [[MSBF file (Pikmin 3)|MSBF (message flow)]]
* [[FSKB file]] (Unknown)

| valign="top" |

* [[Hey! Pikmin save file|Saved game data]]
* [[ARC file (Hey! Pikmin)|ARC (archive)]]
* [[BCH file|BCH (animation)]]
* [[BFLIM file|BFLIM (image)]]
* [[MSBT file (Hey! Pikmin)|MSBT (text string)]]
* [[Z file|Z (archive)]]

| valign="top" |
* [[WEBM file|WEBM (video)]]
* [[BNVIB file|BNVIB]]
* [[UTOC/UCAS file|UTOC/UCAS (Archive for UASSET Files)]]
* [[UASSET file|UASSET File (Unreal Engine Asset File)]]
* [[UFONT file|UFONT]]
* [[LOCRES file|LOCRES]]
* [[WEM file|WEM]]
* [[BNK file|BNK]]
* [[Save Files]]

|-

! colspan="5" | Parameters
|-
| valign="top" |
* [[Pikmin labeled parameter file|Labeled]]
** [[Pikmin AI constants|AI constants]]
** [[Pikmin cunit parameters|Cuint]]
** [[Pikmin demo parameters|Demo]]
** [[Pikmin game parameters|Game parameters]]
** [[Pikmin navi parameters|NaviMgr]]
** [[Pikmin piki parameters|PikiMgr]]
** [[Pikmin sound parameters|Sound]]
** [[Pikmin wave parameters|Wave]]
** [[Pikmin prefs parameters|Prefs]]
** [[Pikmin boss parameters|Boss]]
* [[Pikmin unlabeled parameter file|Unlabeled]]
** [[Pikmin camera parameters|Camera]]
** [[Pikmin key parameters|Key]]
** [[Pikmin enemy parameter file format|Enemy]]

| valign="top" |
* [[naviParms|Leader]]
* [[pikiParms|Pikmin]]
* [[CameraParms|Camera]]
* [[Pikmin 2 enemy parameters|Entity]]
* [[Titan Dweevil parameters]]
* [[Trackmap parameters|trackMap parameters]]
* [[Pikmin 2 day time parameters|Day time parameters]]

| valign="top" |
* [[carryParam|Carry]]
* [[fruitsParam|Fruit]]
* [[pikminParam|Pikmin]]
* [[itemprogressParam|Item progress]]
* [[Mission settings]]
* [[GameobjectParam|Object]]

| valign="top" |

| valign="top" |

* [[ActorSerializeParameter and AI]]
* [[Data Table/Actor Parameters]]
* [[Enemy Parameters]]
* [[ActorGeneratorList]]

|-

! colspan="5" | Managers
|-
| valign="top" |
* [[pikibank.bx|Pikmin audio system]]
* [[Pikmin pellet manager|Pellets]]
* [[Pikmin anim manager|Animations]]
* [[Pikmin teki manager|Tekis (DOL)]]
* [[Pikmin stage manager|Stage manager]]
* [[Pikmin stage information|Stage information / lighting]]

| valign="top" |
* [[PSound.aaf|Audio system]]
* Pellet List
** [[Pikmin 2 otakara_config.txt|Treasure Config]]
** [[Pikmin 2 item_config.txt|Upgrade Config]]
** [[Pikmin 2 carcass_config.txt|Carcass Config]]
** [[Pikmin 2 numberpellet_config.txt|Number Pellet Config]]
* [[Pikmin 2 animmgr.txt|Animation Manager]]
* [[Pikmin 2 collinfo.txt|Collision Info]]

* [[Mail Table]]

| valign="top" |

| valign="top" |

| valign="top" |

|-

! colspan="5" | Screens
|-
| valign="top" |
* [[Screen file list (Pikmin)]]
| valign="top" |
* [[Screen file list (Pikmin 2)]]
| valign="top" |

| valign="top" |

| valign="top" |

|-

! colspan="5" | Explanations and Notes
|-
| valign="top" |
* [[Pikmin unread files|Unread files]]
* [[Pikmin disable archives trick|Disable loading from archives]]
* [[Pikmin Emperor crash|Emperor crash]]
* [[Minty Ramblings]]
* [[Custom sequenced Pikmin music|Custom sequenced music]]

| valign="top" |
* [[Cave spawning]]
* [[Custom models|Custom models]]
* [[How J3D model materials work]]
* [[Submerged Castle oddities|Special cave properties]]
* [[How Pikmin 2 loads text|How ''Pikmin 2'' loads text]]
* [[Sound Replacement Tutorial|Sound Replacement Tutorial]]
* [[Enemy Memory Usage]]
* [[Disassembly instructions]]
* [[Jsystem]]
* [[Pikmin 2 gEnemyInfo|gEnemyInfo]]
* [[Epoch Notes]]
* [[User:Captain Salty/Blo Editing Notes|Blo Editing Notes]]
* [[Cutscene Editing and Creation]]
* [[Cutscene Notes]]
* [[Creating Interactive BMS Files|Creating interactive area music]]
* [[Creating cave music|Creating interactive cave music]]
* [[Editing code with Decomp|Editing code with Decomp]]

| valign="top" |
* [[Pikmin 3 oddities|Oddities]]
* [[Story mode maps in other modes]]
* [[Pikmin 3 Bingo Battle|Bingo Battle]]

| valign="top" |
* [[Hey! Pikmin unread files|Unread files]]

| valign="top" |
* Documentation
** [[Lilith's P4 Notes]]
** [[Pikmin 4 Demo Research]]
* Tutorials
** [[Model Importing Tutorial]]
** [[WEM Audio Modding Tutorial]]
** [[Enemy Duplication Tutorial (WIP)]]
|-

! colspan="5" | Tools
|-
| valign="top" |
* [[PikBinGen]]
* [[Archive Toolkit]]
* [[OpenGL / Dolphin System|OpenGL / Dolphin System]]

| valign="top" |
* [[Cave Creator]]
* [[Pikmin 2 Routes Editor & Gen Editor]]
* [[obj2grid]]
* [[DOL-Ckit]]
* [[Drought Enders Cave Creator]]
* [[SuperBMD]]
* [[FinModelUtility]]
* [[GameCube File Tools]]
* [[pyblo2-gui]]
* [[pikminBMGtool]]
* [[btk-conv]]

| valign="top" |
* [[Gen Editor]]

| valign="top" |
* [[Hey! Pikmin stage viewer]]

| valign="top" |
* [[P4UassetEditor]]
* [[Modified FModel]]
* [[UCas/UToc Packer]]
* [[Dandori DB]]
* [[Dandori Desktop]]
* [[UE4LocalizationsTool]]

|}

== Tasks ==
* [[:Category:Pages with things to do|Things to do]]
* [[:Category:Pages with unsure information|Unsure info that needs to be confirmed]]

[[Category:PikminTKB]]

ActorSerializeParameter and AI

2025-01-27T21:12:47Z

Noodl: Fix filename

All of the info on this page (thus far) is research and assumptions by [[Noodl]] - it may not all be entirely correct.

<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.

<source lang="JSON">

{
"ActorSerializeParameter": {
"AI": {
"Static": [],
"Dynamic": [];
},
"Hash": { ... },
"CheckComp": { ... },
"ActorParameter": { ... },
"SubAI": { ... },
"Life": { ... },
"PortalTrigger": { ... },
"DemoTrigger": { ... },
"Pikmin": { ... },
"CharacterEdit": { ... },
"PopPlace": { ... },
"Strategy": { ... },
"CakEmitterConfig": { ... },
"CakSimpleState": { ... },
"CakTrigger": { ... },
"CakMultiplePosition": { ... },
"CakAudioTable": { ... },
"WaterTrigger": { ... },
"NavMeshTrigger": { ... },
"Affordance": { ... },
"HiddenBoxTrigger": { ... },
"NarrowSpaceBoxTrigger": { ... },
"WarpTrigger": { ... },
"ActionMarker": { ... },
}
}

</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]).

== 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.

=== Concepts ===

Before trying to break down a byte array, it helps to understand a few concepts of the data types used:

* Each integer in the array is a single 8-bit/1-byte value, so can only go up to 255.
* The arrays are not fixed to 32-bit boundaries. A 4-byte float can be adjacent to a 16bit integer.
* Booleans are 4-bytes with the 0/1 being in the first index
* Floats are little-endian, and 4 bytes long. For example the value <code>100</code> will be 4 bytes of <code>0, 0, 200, 66</code>.
* Integers can also be encoded across 2-bytes (two integers of this array). For example, the value <code>271</code> would be <code>15,1</code> - 15 + (256 * 1). They are also sometimes just 1-byte long with the value at index 0.
* Strings are encoded by 4 bytes dictating the length of the string (null terminator included) followed by the string's characters in ASCII codes, ending with <code>0</code>. For example the string of <code>None</code> will be encoded as <code>5, 0, 0, 0, 78, 111, 110, 101, 0</code>, with 5 being the length of the string (4 chars + <code>0</code>).
* When arrays/objects are used (for fields like <code>DropConditions</code> or <code>bSetTerritory</code>, there is often a 4 byte boolean that dictates if the rest of the object is present, or the number of items in the array. For example, with territory, if <code>bSetTerritory</code> is <code>false</code>, the bytes will look like <code>0, 0, 0, 0, ... </code> followed by whatever else comes after. However if it is true (<code>1, 0, 0, 0</code>), 5 floats (X, Y, Z, HalfHeight and Radius) will follow, making the array vary in length.
* The <code>GeneratorVersion</code>/<code>AssetVersion</code> matter. There are 3 versions in the game. The main noted difference is <code>8626647418</code> and <code>8626647626</code> having 4 extra bytes in <code>ObjectAIParameter</code>, while version <code>8626647386</code> does not. This makes it important to know which version the bytes are from when charting in case index comparisons are off by 4 resulting in undefined behaviour if giving the game an array where everything is +-4. This is easily observable by compare the Geyser in Area001 to any other geyser in the game.

[[Dandori Desktop]] provides tools for byte conversions that can aid in finding values.

== 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.

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>.

=== 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.

[[File:P4-creature-ai-inventory-bytes.png|500px|thumb|center|]]

=== ActorSpawner AI ===
ActorSpawners are a little different, and their only drop is the thing they spawn, with some configuration for it.

[[File:P4-actorspawner-ai.png|500px|thumb|center|]]

=== GroupDropManager AI ===

[[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|]]

=== Treasure AI ===

[[File:P4-otakara-ai.png |500px|thumb|center|]]

=== WaterBox AI ===

WaterBoxes have a few components all detailed in the chart. They can be sent logical pulses by entities like switches, valves and drains by linking the <code>waterBoxSwitchID</code>. Drains (Mizunuki), while charted here, are not actually interactible entities, instead the thought is that they get triggered by <code>Excavation</code> holes on top of them, which are not yet charted. As usual, [https://github.com/Chagrilled/P4-DandoriDesktop/blob/master/src/api/types.js#L152-L182 Dandori Desktop] has a list of sound IDs and map texture paths scraped from the game.

It is not at all understood what <code>WaterBoxNav</code>s do or what its vector could be applied to, nor <code>WaterBoxFluctuation</code>s although the latter may just be the moving ones. I haven't tested tonnes.

[[File:P4-Waterbox-Ais.png |500px|thumb|center|]]

=== Researching ===

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.

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 (non-night)
* [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:Parameters]]

ActorSerializeParameter and AI

2025-01-27T21:12:08Z

Noodl: Waterboxes and GeneratorVersion

All of the info on this page (thus far) is research and assumptions by [[Noodl]] - it may not all be entirely correct.

<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.

<source lang="JSON">

{
"ActorSerializeParameter": {
"AI": {
"Static": [],
"Dynamic": [];
},
"Hash": { ... },
"CheckComp": { ... },
"ActorParameter": { ... },
"SubAI": { ... },
"Life": { ... },
"PortalTrigger": { ... },
"DemoTrigger": { ... },
"Pikmin": { ... },
"CharacterEdit": { ... },
"PopPlace": { ... },
"Strategy": { ... },
"CakEmitterConfig": { ... },
"CakSimpleState": { ... },
"CakTrigger": { ... },
"CakMultiplePosition": { ... },
"CakAudioTable": { ... },
"WaterTrigger": { ... },
"NavMeshTrigger": { ... },
"Affordance": { ... },
"HiddenBoxTrigger": { ... },
"NarrowSpaceBoxTrigger": { ... },
"WarpTrigger": { ... },
"ActionMarker": { ... },
}
}

</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]).

== 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.

=== Concepts ===

Before trying to break down a byte array, it helps to understand a few concepts of the data types used:

* Each integer in the array is a single 8-bit/1-byte value, so can only go up to 255.
* The arrays are not fixed to 32-bit boundaries. A 4-byte float can be adjacent to a 16bit integer.
* Booleans are 4-bytes with the 0/1 being in the first index
* Floats are little-endian, and 4 bytes long. For example the value <code>100</code> will be 4 bytes of <code>0, 0, 200, 66</code>.
* Integers can also be encoded across 2-bytes (two integers of this array). For example, the value <code>271</code> would be <code>15,1</code> - 15 + (256 * 1). They are also sometimes just 1-byte long with the value at index 0.
* Strings are encoded by 4 bytes dictating the length of the string (null terminator included) followed by the string's characters in ASCII codes, ending with <code>0</code>. For example the string of <code>None</code> will be encoded as <code>5, 0, 0, 0, 78, 111, 110, 101, 0</code>, with 5 being the length of the string (4 chars + <code>0</code>).
* When arrays/objects are used (for fields like <code>DropConditions</code> or <code>bSetTerritory</code>, there is often a 4 byte boolean that dictates if the rest of the object is present, or the number of items in the array. For example, with territory, if <code>bSetTerritory</code> is <code>false</code>, the bytes will look like <code>0, 0, 0, 0, ... </code> followed by whatever else comes after. However if it is true (<code>1, 0, 0, 0</code>), 5 floats (X, Y, Z, HalfHeight and Radius) will follow, making the array vary in length.
* The <code>GeneratorVersion</code>/<code>AssetVersion</code> matter. There are 3 versions in the game. The main noted difference is <code>8626647418</code> and <code>8626647626</code> having 4 extra bytes in <code>ObjectAIParameter</code>, while version <code>8626647386</code> does not. This makes it important to know which version the bytes are from when charting in case index comparisons are off by 4 resulting in undefined behaviour if giving the game an array where everything is +-4. This is easily observable by compare the Geyser in Area001 to any other geyser in the game.

[[Dandori Desktop]] provides tools for byte conversions that can aid in finding values.

== 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.

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>.

=== 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.

[[File:P4-creature-ai-inventory-bytes.png|500px|thumb|center|]]

=== ActorSpawner AI ===
ActorSpawners are a little different, and their only drop is the thing they spawn, with some configuration for it.

[[File:P4-actorspawner-ai.png|500px|thumb|center|]]

=== GroupDropManager AI ===

[[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|]]

=== Treasure AI ===

[[File:P4-otakara-ai.png |500px|thumb|center|]]

=== WaterBox AI ===

WaterBoxes have a few components all detailed in the chart. They can be sent logical pulses by entities like switches, valves and drains by linking the <code>waterBoxSwitchID</code>. Drains (Mizunuki), while charted here, are not actually interactible entities, instead the thought is that they get triggered by <code>Excavation</code> holes on top of them, which are not yet charted. As usual, [https://github.com/Chagrilled/P4-DandoriDesktop/blob/master/src/api/types.js#L152-L182 Dandori Desktop] has a list of sound IDs and map texture paths scraped from the game.

It is not at all understood what <code>WaterBoxNav</code>s do or what its vector could be applied to, nor <code>WaterBoxFluctuation</code>s although the latter may just be the moving ones. I haven't tested tonnes.

[[File:P4-Waterbox-Ais.png.png |500px|thumb|center|]]

=== Researching ===

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.

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 (non-night)
* [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:Parameters]]

File:P4-Waterbox-Ais.png

2025-01-27T21:00:54Z

Noodl:

File:P4-sprinkler-objectAI.png

2025-01-27T21:00:38Z

Noodl: Noodl uploaded a new version of File:P4-sprinkler-objectAI.png

== Summary ==
Charts the sprinklerAI bytes, and what I can find of ObjectAIParameter, which every object is comprised of (+ their unique AI gen var, like SprinklerAI)

Disabling Pikmin

2024-07-29T22:25:35Z

Noodl: Disable behaviour

{{DISPLAYTITLE:Disabling Pikmin}}

In the bytes of a CavePortal's PortalTrigger there is a 4-byte integer called <code>disablePikminFlags</code>. This number looks random but can be broken down.

It is a little endian binary bit string. Taking the number as an example:

<source>
0000 0010 1111 1110
</source>

We will be looking at the number as if it was reversed, so "index 0" is actually the last number. Each number in the string represents which pikmin type is disabled. The pikmin order can be obtained from <code>DT_PikminProperty</code> in the <code>Core/</code> folder. It is basically this with bean at 8, and ninjin, undef and DrkMinion between photon and notset.

<source lang="JSON">
{
0: "PikminRed",
1: "PikminBlue",
2: "PikminYellow",
3: "PikminRock",
4: "PikminWing",
5: "PikminPurple",
6: "PikminWhite",
7: "PikminIce",
9: "PikminPhoton",
16: "Not set (PongashiColor only)"
}
</source>

By matching the above enum to the number, we can see that only index 0 is a 0, with the rest being 1. This means that red pikmin are the only ones enabled (and bean I guess). If you also wanted to enable yellow, you'd flip index 3 to a 0 too. After index 9 for photon, it doesn't really matter. By converting this uint16 back to decimal you would get <code>766</code> which is what gets encoded to <code>254, 2, 0, 0</code> in the AGL (which you can see for Area010's stovetop cave where this is used).

Some notes on disable behaviour:

* Disable flags can be applied to in-cave entrances (<code>DownPortal</code>s) where they will just magic-away the disabled types. Haven't tested if they get saved to the onion, I presume they do like a regular overworld pikmin selection would.
* By changing the in-cave portal's to the overworld <code>MadoriRuins</code> you can get the sublevel selection screen and pikmin selector with the disable flags applied, so you can redistribute and reset your squad between floors.

[[Category:Stage Generation]]
[[Category:Pikmin 4]]

Main Page

2024-07-29T22:07:05Z

Noodl: Disbaling Pikmin page

{{MainTemplate
| welcome = Welcome to the '''''Pikmin'' Technical Knowledge Base'''!
| blurb = A wiki dedicated to the internal files in ''Pikmin'' games.
| about_title = About
| about_content =
Throughout the years, ''Pikmin'' fans have tinkered with the files inside the games in order to better learn how they work, and to create custom content. Since there are a lot of nuances in every little thing, and since newcomers to the concept of file editing show up all the time, this wiki was created with the purpose of serving as a knowledge base for all that the fans know!

'''Partners''':
* [https://pikminwiki.com Pikipedia] - the ''Pikmin'' wiki
* [https://discord.gg/msMKc3G Pikcord] - the ''Pikmin'' community Discord server
* [https://discord.gg/G7Pgkdh Hocotate Hacker] - the ''Pikmin'' hacking community Discord server
| other_title = What this wiki is ''not''
| other_content =
* It's not a wiki about pirating ''Pikmin'' games.
* It's not a file-sharing service.
* It's not a wiki where you document...
** Canon content. Try [https://pikminwiki.com/ Pikipedia] instead.
** Fan-made content. Try [https://pikminfanon.com/ Pikmin Fanon] instead.
** Unused content or regional differences. Try [https://tcrf.net TCRF] instead.
* It's not an official source of info. The information here is mostly obtained via experimenting, and is subject to change as new discoveries are made.
}}

== Global information ==
{| class="wikitable" style="margin: auto; width: 75%;"
! colspan="3" | Global info
|-
| colspan="3" |
{| style="margin: auto;"
|
* [[General instructions]]
* [[Glossary]]
* [[Save files]]
* [[:Category:Tools|Tools]]
|}
|}

== Game-specific information ==
{| class="wikitable" style="margin: auto; width: 75%;"
! width="20%;" | ''Pikmin'' (and ''New Play Control! Pikmin'')
! width="20%;" | ''Pikmin 2'' (and ''New Play Control! Pikmin 2'')
! width="20%;" | ''Pikmin 3'' (and ''Pikmin 3 Deluxe'')
! width="20%;" | ''Hey! Pikmin''
! width="20%;" | ''Pikmin 4''
|-

! colspan="5" | General
|-
| valign="top" |
* [[Pikmin|Main information]]
* [[Pikmin instructions|Instructions]]
* [[Pikmin cheat codes|Useful cheat codes]]
* [[Pikmin memory addresses|Memory addresses]]
* [[Pikmin glossary|Glossary]]

| valign="top" |
* [[Pikmin 2|Main information]]
* [[Pikmin 2 instructions|Instructions]]
* [[Pikmin 2 cheat codes|Useful cheat codes]]
* [[Pikmin 2 memory addresses|Memory addresses]]
* [[Pikmin 2 troubleshooting|Troubleshooting]]
* [[Pikmin 2 glossary|Glossary]]

| valign="top" |
* [[Pikmin 3|Main information]]
* [[Pikmin 3 instructions|Instructions]]
* [[Pikmin 3 troubleshooting|Troubleshooting]]
* [[Pikmin 3 glossary|Glossary]]

| valign="top" |
* [[Hey! Pikmin|Main information]]
* [[Hey! Pikmin instructions|Instructions]]
* [[Hey! Pikmin troubleshooting|Troubleshooting]]
* [[Hey! Pikmin glossary|Glossary]]

| valign="top" |
* [[Pikmin 4|Main information]]
* [[Pikmin 4 instructions|Instructions]]
* [[Pikmin 4 troubleshooting|Troubleshooting]]
* [[Pikmin 4 glossary|Glossary]]
|-

! colspan="5" | File lists
|-
| valign="top" |
* [[Pikmin directory tree|Directory tree]]
* [[JAM file list|JAM file list (Pikiseq.arc)]]
* [[STX file list|STX file list]]
* [[CIN file list|CIN file list]]

| valign="top" |
* [[Pikmin 2 directory tree|Directory tree]]
* [[AST file list|AST (streamed music)]]
* [[Pikmin 2 BMS file list|BMS (sequenced music)]]
* [[Pikmin 2 CND file list|CND (sequenced music for caves)]]
* [[Guide_To_Sound_File_Names|List of sound effect files in the first bank]]
* [[Pikmin 2 cave units information|List of information of each cave unit]]

| valign="top" |
* [[Pikmin 3 directory tree|''Pikmin 3'' directory tree]]
* [[Pikmin 3 Deluxe directory tree|''Pikmin 3 Deluxe'' directory tree]]
* [[BFSTM file list|BFSTM (streamed music)]]
* [[MSBT file list|MSBT (text string)]]

| valign="top" |
* [[Hey! Pikmin directory tree|Directory tree]]
* [[BCSTM file list|BCSTM (music)]]

| valign="top" |
* [[Pikmin 4 directory tree|directory tree]]
|-

! colspan="5" | Constants
|-
| valign="top" |
* [[Pikmin identifiers|Identifiers]]
* [[Olimar's voyage log table]]

| valign="top" |
* [[Pikmin 2 identifiers|Identifiers]]
* [[Pikmin 2 Pikmin states|Pikmin states]]

| valign="top" |
* [[Pikmin 3 identifiers|Identifiers]]
* [[Pikmin 3 progress value|Progress value]]

| valign="top" |
* [[Hey! Pikmin identifiers|Identifiers]]

| valign="top" |
* [[Pikmin 4 identifiers|Identifiers]]
* [[Pikmin 4 text identifiers|Text Identifiers]]
|-

! colspan="5" | Particle effects
|-
| valign="top" |
* [[PCR particles]]

| valign="top" |
* [[JPC particles]]

| valign="top" |
* [[PTCL particles (Pikmin 3)]]

| valign="top" |
* [[PTCL particles (Hey Pikmin)]]

| valign="top" |

|-

! colspan="5" | Stage generation
|-
| valign="top" |
* [[Pikmin binary GEN format|Binary GEN format]]
* [[Pikmin route|Routes]]

* Outdated pages
** [[Pikmin area generator file|Generator]]
** [[Pikmin gen codes|Gen codes]]

| valign="top" |
* Overworld
** [[Pikmin 2 area generator file|Overworld generation parameters]]
** [[Pikmin 2 map lighting files|Lighting]]
** [[Pikmin 2 waterboxes|Waterbox]]
** [[Pikmin 2 collision format|Collision]]
* Caves
** [[Cave generation parameters|Cave generation parameters]]
** [[Pikmin 2 Challenge Mode settings|Challenge Mode]]
** [[Pikmin 2 cave lighting files|Lighting]]
* Units (cave rooms)
** [[Cave unit generation|Cave unit generation]]
** [[Cave unit definition file|Cave unit definition]]
** [[Cave fixed layout|Cave fixed layout]]
* [[Pikmin 2 route|Routes]]

| valign="top" |

| valign="top" |

| valign="top" |
* Teki Units
** [[NoraSpawner]]
* [[Dandori Battles]]
* [[Disabling Pikmin]]

|-

! colspan="5" | File formats
|-
| valign="top" |
* Archive Formats
** [[Paired ARC+DIR file]]
** [[BUN file]] (also ANM)
** [[BARC file]]
* Binary formats
** [[MOD file]] (3D Model)
** [[ACT file]] (Hierarchy Model File)
** [[TXE file]] (Texture)
** [[BTI file]] (Texture)
** [[BLO file]] (2D screen data)
** [[PCR file]] (Particle effect parameters)
** [[DC? files]] (Identifier for either DCA or DCK)
*** [[DCA file]] (Animation)
*** [[DCK file]] (Animation)
** [[H4M file]] (Pre-rendered video)
** [[JAM file]] (Sequenced music)
** [[STX file]] (Streamed music)
** [[AW file]] (Sound Bank)
** [[Pikmin parameter files|Parameter Files]]
* Plaintext Formats
** [[CIN file]] (Cutscene resource manager)
** [[DSK file]] (Cutscene data)
** [[DMD file]] (Intermediary 3D model)
** [[CNV file]] (Intermediary conversion file)
* Unknown Formats
** [[GST file]]
** [[CARD file]]
* Missing Formats
** [[DVW file]] (Material file?)
** [[JMP file]] (Intermediary plaintext 3D model file?)
** [[MD3 file]] (3D Model)
** [[BSP flle]] (3D Model)

| valign="top" |
* Archive Formats
** [[SZS file]]
** [[RARC file]]
* [[BMD file]] (J3D model)
* [[BTI file]] (Texture)
* [[BTK file]] (Animated texture)
* [[JPC file]] (Particle effect container)
** [[JPA file]] (Particle effect)
* [[BCA file]] (Animation)
* [[BCK file]] (Animation)
* [[BMS file]] (Sequenced music)
* [[AST file]] (Streamed music)
* [[AW file]] (Soundfont)
* [[THP file]] (Pre-rendered video)
* [[BLO file]] (2D screen data)
* [[STB file]] (Cutscene data)
* [[BMG file]] (Text)
* [[BPK file]]
* [[BRK file]]
* [[BMC file]]

* Misc.
** [[DWN file]] (e-Reader minigames?)
** [[DMD file]] (Intermediary 3D model)
** [[Pikmin 2 title screen|Title screen]]
** [[Pikmin 2 save file|Saved game data]]
** [[2-Player Battle stage parameters]]
** [[Mail]]

| valign="top" |

* [[Pikmin 3 radar files|Radar]]
* [[BFSTM file|BFSTM (streamed music)]]
* [[MSBT file (Pikmin 3)|MSBT (text string)]]
* [[FSKB file]] (Unknown)

| valign="top" |

* [[Hey! Pikmin save file|Saved game data]]
* [[ARC file (Hey! Pikmin)|ARC (archive)]]
* [[BCH file|BCH (animation)]]
* [[BFLIM file|BFLIM (image)]]
* [[MSBT file (Hey! Pikmin)|MSBT (text string)]]
* [[Z file|Z (archive)]]

| valign="top" |
* [[WEBM file|WEBM (video)]]
* [[BNVIB file|BNVIB]]
* [[UTOC/UCAS file|UTOC/UCAS (Archive for UASSET Files)]]
* [[UASSET file|UASSET File (Unreal Engine Asset File)]]
* [[UFONT file|UFONT]]
* [[LOCRES file|LOCRES]]
* [[WEM file|WEM]]
* [[BNK file|BNK]]
* [[Save Files]]

|-

! colspan="5" | Parameters
|-
| valign="top" |
* [[Pikmin labeled parameter file|Labeled]]
** [[Pikmin AI constants|AI constants]]
** [[Pikmin cunit parameters|Cuint]]
** [[Pikmin demo parameters|Demo]]
** [[Pikmin game parameters|Game parameters]]
** [[Pikmin navi parameters|NaviMgr]]
** [[Pikmin piki parameters|PikiMgr]]
** [[Pikmin sound parameters|Sound]]
** [[Pikmin wave parameters|Wave]]
** [[Pikmin prefs parameters|Prefs]]
** [[Pikmin boss parameters|Boss]]
* [[Pikmin unlabeled parameter file|Unlabeled]]
** [[Pikmin camera parameters|Camera]]
** [[Pikmin key parameters|Key]]
** [[Pikmin enemy parameter file format|Enemy]]

| valign="top" |
* [[naviParms|Leader]]
* [[pikiParms|Pikmin]]
* [[CameraParms|Camera]]
* [[Pikmin 2 enemy parameters|Entity]]
* [[Titan Dweevil parameters]]
* [[Trackmap parameters|trackMap parameters]]

| valign="top" |
* [[carryParam|Carry]]
* [[fruitsParam|Fruit]]
* [[pikminParam|Pikmin]]
* [[itemprogressParam|Item progress]]
* [[Mission settings]]
* [[GameobjectParam|Object]]

| valign="top" |

| valign="top" |

* [[ActorSerializeParameter and AI]]
* [[Data Table/Actor Parameters]]
* [[Enemy Parameters]]
* [[ActorGeneratorList]]

|-

! colspan="5" | Managers
|-
| valign="top" |
* [[BX file]] (Soundfont index)
* [[Pikmin pellet manager|Pellets]]
* [[Pikmin anim manager|Animations]]
* [[Pikmin teki manager|Tekis (DOL)]]
* [[Pikmin stage manager|Stage manager]]
* [[Pikmin stage information|Stage information / lighting]]

| valign="top" |
* [[AAF file]] (Soundfont index)
* Pellet List
** [[Pikmin 2 otakara_config.txt|Treasure Config]]
** [[Pikmin 2 item_config.txt|Item Config]]
** [[Pikmin 2 otakara_config.txt|Otakara Config]]
** [[Pikmin 2 carcass_config.txt|Carcass Config]]
** [[Pikmin 2 numberpellet_config.txt|Number Pellet Config]]
* [[Pikmin 2 animmgr.txt|Animation Manager]]
* [[Pikmin 2 collinfo.txt|Collision Info]]

* [[Mail Table]]

| valign="top" |

| valign="top" |

| valign="top" |

|-

! colspan="5" | Explanations and Notes
|-
| valign="top" |
* [[Pikmin unread files|Unread files]]
* [[Pikmin disable archives trick|Disable loading from archives]]
* [[Pikmin Emperor crash|Emperor crash]]
* [[Minty Ramblings]]
* [[Custom sequenced Pikmin music|Custom sequenced music]]

| valign="top" |
* [[Cave spawning]]
* [[Custom models]]
* [[Submerged Castle oddities|Special cave properties]]
* [[How Pikmin 2 loads text|How ''Pikmin 2'' loads text]]
* [[Sound Replacement Tutorial|Sound Replacement Tutorial]]
* [[Enemy Memory Usage]]
* [[Disassembly instructions]]
* [[Jsystem]]
* [[Pikmin 2 gEnemyInfo|gEnemyInfo]]
* [[Epoch Notes]]
* [[Cubes Yap Notes]]
* [[User:Captain Salty/Blo Editing Notes|Blo Editing Notes]]
* [[Cutscene Notes]]
* [[Creating Interactive BMS Files|Creating interactive area music]]
* [[Creating cave music|Creating interactive cave music]]

| valign="top" |
* [[Pikmin 3 oddities|Oddities]]
* [[Story mode maps in other modes]]
* [[Pikmin 3 Bingo Battle|Bingo Battle]]

| valign="top" |
* [[Hey! Pikmin unread files|Unread files]]

| valign="top" |
* Documentation
** [[Lilith's P4 Notes]]
** [[Pikmin 4 Demo Research]]
* Tutorials
** [[Model Importing Tutorial]]
** [[WEM Audio Modding Tutorial]]
** [[Enemy Duplication Tutorial (WIP)]]
|-

! colspan="5" | Tools
|-
| valign="top" |
* [[PikBinGen]]
* [[Archive Toolkit]]
* [[OpenGL / Dolphin System|OpenGL / Dolphin System]]

| valign="top" |
* [[Cave Creator]]
* [[Pikmin 2 Routes Editor & Gen Editor]]
* [[obj2grid]]
* [[DOL-Ckit]]
* [[Drought Enders Cave Creator]]
* [[SuperBMD]]
* [[pikminBMGtool]]
* [[btk-conv]]

| valign="top" |
* [[Gen Editor]]

| valign="top" |
* [[Hey! Pikmin stage viewer]]

| valign="top" |
* [[P4UassetEditor]]
* [[Modified FModel]]
* [[UCas/UToc Packer]]
* [[Dandori DB]]
* [[Dandori Desktop]]
* [[UE4LocalizationsTool]]

|}

== Tasks ==
* [[:Category:Pages with things to do|Things to do]]
* [[:Category:Pages with unsure information|Unsure info that needs to be confirmed]]

[[Category:PikminTKB]]

Dandori Battles

2024-07-20T21:02:40Z

Noodl: Make json complete

{{DISPLAYTITLE:Dandori Battles}}

Dandori Battles in Pikmin 4 are slightly different to regular maps. The generator lists live in <code>Maps/Madori/Ddb/</code> where there exist two sets of files: <code>AP_{map}LVS_{type}.json</code> and <code>AP_{map}_{type}.json</code>. The <code>LVS</code> files are for the title screen Dandori Battles.

Most of the spawns in Dandori Battles are driven by <code>PopPlaceActor</code>s. These are hidden entities that spawn other entities. Similar to <code>ActorSpawner</code>s. I haven't mapped out the bytes of them yet, but all pertinent configuration is in the <code>ActorSerializeParameter.PopPlace.Static</code> array. The <code>ActorParameter</code> and <code>AI</code> are always the same.

The second byte of <code>PopPlace</code> is the <code>GroupId</code>. This is how the game determines what the <code>PopPlaceActor</code> should spawn, and how. These groups are actually defined in <code>Carrot4/Core/VS/Pop/SettingTable/{type}/DT_Pop_{type}{something}.uasset</code>. An excerpt of one from Trial run (DDB_AI001):

<source lang="JSON">
{
"コチャッピー_リポップ_積み木の下": { // "Kochappi_Repop_Under the building blocks"
"StartTime": 0.0,
"EndTime": 240.0,
"IntervalType": "EVsPopIntervalType::Always",
"Interval": 40.0,
"IntervalJitter": 5.0,
"TargetGroupIds": [
2
],
"MaxPopObjectNum": 2,
"MaxPopObjectJitterNum": 0,
"PopObjectList": [],
"GenerateClassArray": [
{
"ObjectName": "BlueprintGeneratedClass'GKochappy_C'",
"ObjectPath": "/Game/Carrot4/Placeables/Teki/GKochappy.0"
}
],
"bIsExcludeSystemPopLimit": false,
"bIsForcePopBuriedPoint": false
}
}
</source>

Which defines Group ID 2 to spawn at most 2 kochappies every (40 ±5) seconds from the start of the battle. However this means DDB spawns are linked to DataTable files, and not just the actors in the AGL.

Presently, the UassetEncoder mangles the <code>GenerateClassArray</code> to something unhelpful:

<source lang="JSON">
{
"GenerateClassArray": [
-7902643105768047879
]
}
</source>

Meaning we can't edit and re-encode the files to add more/edit the groups for each Dandori Battle, currently leaving them as only editable by using regular entities, ActorSpawners, or the existing groups.

[[Category:Formats]]
[[Category:Pikmin 4]]

Dandori Battles

2024-07-20T21:01:42Z

Noodl: Fix code block

{{DISPLAYTITLE:Dandori Battles}}

Dandori Battles in Pikmin 4 are slightly different to regular maps. The generator lists live in <code>Maps/Madori/Ddb/</code> where there exist two sets of files: <code>AP_{map}LVS_{type}.json</code> and <code>AP_{map}_{type}.json</code>. The <code>LVS</code> files are for the title screen Dandori Battles.

Most of the spawns in Dandori Battles are driven by <code>PopPlaceActor</code>s. These are hidden entities that spawn other entities. Similar to <code>ActorSpawner</code>s. I haven't mapped out the bytes of them yet, but all pertinent configuration is in the <code>ActorSerializeParameter.PopPlace.Static</code> array. The <code>ActorParameter</code> and <code>AI</code> are always the same.

The second byte of <code>PopPlace</code> is the <code>GroupId</code>. This is how the game determines what the <code>PopPlaceActor</code> should spawn, and how. These groups are actually defined in <code>Carrot4/Core/VS/Pop/SettingTable/{type}/DT_Pop_{type}{something}.uasset</code>. An excerpt of one from Trial run (DDB_AI001):

<source lang="JSON">
{
"コチャッピー_リポップ_積み木の下": { // "Kochappi_Repop_Under the building blocks"
"StartTime": 0.0,
"EndTime": 240.0,
"IntervalType": "EVsPopIntervalType::Always",
"Interval": 40.0,
"IntervalJitter": 5.0,
"TargetGroupIds": [
2
],
"MaxPopObjectNum": 2,
"MaxPopObjectJitterNum": 0,
"PopObjectList": [],
"GenerateClassArray": [
{
"ObjectName": "BlueprintGeneratedClass'GKochappy_C'",
"ObjectPath": "/Game/Carrot4/Placeables/Teki/GKochappy.0"
}
],
"bIsExcludeSystemPopLimit": false,
"bIsForcePopBuriedPoint": false
}
}
</source>

Which defines Group ID 2 to spawn at most 2 kochappies every (40 ±5) seconds from the start of the battle. However this means DDB spawns are linked to DataTable files, and not just the actors in the AGL.

Presently, the UassetEncoder mangles the <code>GenerateClassArray</code> to something unhelpful:

<source lang="JSON">
"GenerateClassArray": [
-7902643105768047879
],
</source>

Meaning we can't edit and re-encode the files to add more/edit the groups for each Dandori Battle, currently leaving them as only editable by using regular entities, ActorSpawners, or the existing groups.

[[Category:Formats]]
[[Category:Pikmin 4]]

Dandori Battles

2024-07-20T21:00:51Z

Noodl: DDBs

{{DISPLAYTITLE:Dandori Battles}}

Dandori Battles in Pikmin 4 are slightly different to regular maps. The generator lists live in <code>Maps/Madori/Ddb/</code> where there exist two sets of files: <code>AP_{map}LVS_{type}.json</code> and <code>AP_{map}_{type}.json</code>. The <code>LVS</code> files are for the title screen Dandori Battles.

Most of the spawns in Dandori Battles are driven by <code>PopPlaceActor</code>s. These are hidden entities that spawn other entities. Similar to <code>ActorSpawner</code>s. I haven't mapped out the bytes of them yet, but all pertinent configuration is in the <code>ActorSerializeParameter.PopPlace.Static</code> array. The <code>ActorParameter</code> and <code>AI</code> are always the same.

The second byte of <code>PopPlace</code> is the <code>GroupId</code>. This is how the game determines what the <code>PopPlaceActor</code> should spawn, and how. These groups are actually defined in <code>Carrot4/Core/VS/Pop/SettingTable/{type}/DT_Pop_{type}{something}.uasset</code>. An excerpt of one from Trial run (DDB_AI001):

<code>
{
"コチャッピー_リポップ_積み木の下": { // "Kochappi_Repop_Under the building blocks"
"StartTime": 0.0,
"EndTime": 240.0,
"IntervalType": "EVsPopIntervalType::Always",
"Interval": 40.0,
"IntervalJitter": 5.0,
"TargetGroupIds": [
2
],
"MaxPopObjectNum": 2,
"MaxPopObjectJitterNum": 0,
"PopObjectList": [],
"GenerateClassArray": [
{
"ObjectName": "BlueprintGeneratedClass'GKochappy_C'",
"ObjectPath": "/Game/Carrot4/Placeables/Teki/GKochappy.0"
}
],
"bIsExcludeSystemPopLimit": false,
"bIsForcePopBuriedPoint": false
}
}
</code>

Which defines Group ID 2 to spawn at most 2 kochappies every (40 ±5) seconds from the start of the battle. However this means DDB spawns are linked to DataTable files, and not just the actors in the AGL.

Presently, the UassetEncoder mangles the <code>GenerateClassArray</code> to something unhelpful:

<code>
"GenerateClassArray": [
-7902643105768047879
],
</code>

Meaning we can't edit and re-encode the files to add more/edit the groups for each Dandori Battle, currently leaving them as only editable by using regular entities, ActorSpawners, or the existing groups.

[[Category:Formats]]
[[Category:Pikmin 4]]

Dandori Desktop

2024-07-20T20:47:44Z

Noodl: Added latest release

Dandori Desktop is a tool created by [[Noodl]] that allows visualising and editing of local game files. Inspired by DandoriDB, this takes that concept and moves it to the local environment for direct editing.

In lieu of detailed guides for actor and ActorGeneratorList editing, without intimate detail of its contents, Dandori Desktop is an easy way to get started modifying map generator files.

It can be downloaded from the repo's releases page. Refer to the repo's readme for setup instructions.

== Link ==
* [https://github.com/Chagrilled/P4-DandoriDesktop/ GitHub Repo]
* [https://github.com/Chagrilled/P4-DandoriDesktop/releases/latest Latest Release]

== Usage ==
* Right click to create entities
* ctrl+Z to undo deleted entities
* ctrl+V to duplicate the selected entity

[[Category:Pikmin 4]]
[[Category:Tools]]

Main Page

2024-07-20T20:46:44Z

Noodl: Moved P4 save files to file formats

{{MainTemplate
| welcome = Welcome to the '''''Pikmin'' Technical Knowledge Base'''!
| blurb = A wiki dedicated to the internal files in ''Pikmin'' games.
| about_title = About
| about_content =
Throughout the years, ''Pikmin'' fans have tinkered with the files inside the games in order to better learn how they work, and to create custom content. Since there are a lot of nuances in every little thing, and since newcomers to the concept of file editing show up all the time, this wiki was created with the purpose of serving as a knowledge base for all that the fans know!

'''Partners''':
* [https://pikminwiki.com Pikipedia] - the ''Pikmin'' wiki
* [https://discord.gg/msMKc3G Pikcord] - the ''Pikmin'' community Discord server
* [https://discord.gg/G7Pgkdh Hocotate Hacker] - the ''Pikmin'' hacking community Discord server
| other_title = What this wiki is ''not''
| other_content =
* It's not a wiki about pirating ''Pikmin'' games.
* It's not a file-sharing service.
* It's not a wiki where you document...
** Canon content. Try [https://pikminwiki.com/ Pikipedia] instead.
** Fan-made content. Try [https://pikminfanon.com/ Pikmin Fanon] instead.
** Unused content or regional differences. Try [https://tcrf.net TCRF] instead.
* It's not an official source of info. The information here is mostly obtained via experimenting, and is subject to change as new discoveries are made.
}}

== Global information ==
{| class="wikitable" style="margin: auto; width: 75%;"
! colspan="3" | Global info
|-
| colspan="3" |
{| style="margin: auto;"
|
* [[General instructions]]
* [[Glossary]]
* [[Save files]]
* [[:Category:Tools|Tools]]
|}
|}

== Game-specific information ==
{| class="wikitable" style="margin: auto; width: 75%;"
! width="20%;" | ''Pikmin'' (and ''New Play Control! Pikmin'')
! width="20%;" | ''Pikmin 2'' (and ''New Play Control! Pikmin 2'')
! width="20%;" | ''Pikmin 3'' (and ''Pikmin 3 Deluxe'')
! width="20%;" | ''Hey! Pikmin''
! width="20%;" | ''Pikmin 4''
|-

! colspan="5" | General
|-
| valign="top" |
* [[Pikmin|Main information]]
* [[Pikmin instructions|Instructions]]
* [[Pikmin cheat codes|Useful cheat codes]]
* [[Pikmin memory addresses|Memory addresses]]
* [[Pikmin glossary|Glossary]]

| valign="top" |
* [[Pikmin 2|Main information]]
* [[Pikmin 2 instructions|Instructions]]
* [[Pikmin 2 cheat codes|Useful cheat codes]]
* [[Pikmin 2 memory addresses|Memory addresses]]
* [[Pikmin 2 troubleshooting|Troubleshooting]]
* [[Pikmin 2 glossary|Glossary]]

| valign="top" |
* [[Pikmin 3|Main information]]
* [[Pikmin 3 instructions|Instructions]]
* [[Pikmin 3 troubleshooting|Troubleshooting]]
* [[Pikmin 3 glossary|Glossary]]

| valign="top" |
* [[Hey! Pikmin|Main information]]
* [[Hey! Pikmin instructions|Instructions]]
* [[Hey! Pikmin troubleshooting|Troubleshooting]]
* [[Hey! Pikmin glossary|Glossary]]

| valign="top" |
* [[Pikmin 4|Main information]]
* [[Pikmin 4 instructions|Instructions]]
* [[Pikmin 4 troubleshooting|Troubleshooting]]
* [[Pikmin 4 glossary|Glossary]]
|-

! colspan="5" | File lists
|-
| valign="top" |
* [[Pikmin directory tree|Directory tree]]
* [[JAM file list|JAM file list (Pikiseq.arc)]]
* [[STX file list|STX file list]]
* [[CIN file list|CIN file list]]

| valign="top" |
* [[Pikmin 2 directory tree|Directory tree]]
* [[AST file list|AST (streamed music)]]
* [[Pikmin 2 BMS file list|BMS (sequenced music)]]
* [[Pikmin 2 CND file list|CND (sequenced music for caves)]]
* [[Guide_To_Sound_File_Names|List of sound effect files in the first bank]]
* [[Pikmin 2 cave units information|List of information of each cave unit]]

| valign="top" |
* [[Pikmin 3 directory tree|''Pikmin 3'' directory tree]]
* [[Pikmin 3 Deluxe directory tree|''Pikmin 3 Deluxe'' directory tree]]
* [[BFSTM file list|BFSTM (streamed music)]]
* [[MSBT file list|MSBT (text string)]]

| valign="top" |
* [[Hey! Pikmin directory tree|Directory tree]]
* [[BCSTM file list|BCSTM (music)]]

| valign="top" |
* [[Pikmin 4 directory tree|directory tree]]
|-

! colspan="5" | Constants
|-
| valign="top" |
* [[Pikmin identifiers|Identifiers]]
* [[Olimar's voyage log table]]

| valign="top" |
* [[Pikmin 2 identifiers|Identifiers]]
* [[Pikmin 2 Pikmin states|Pikmin states]]

| valign="top" |
* [[Pikmin 3 identifiers|Identifiers]]
* [[Pikmin 3 progress value|Progress value]]

| valign="top" |
* [[Hey! Pikmin identifiers|Identifiers]]

| valign="top" |
* [[Pikmin 4 identifiers|Identifiers]]
* [[Pikmin 4 text identifiers|Text Identifiers]]
|-

! colspan="5" | Particle effects
|-
| valign="top" |
* [[PCR particles]]

| valign="top" |
* [[JPC particles]]

| valign="top" |
* [[PTCL particles (Pikmin 3)]]

| valign="top" |
* [[PTCL particles (Hey Pikmin)]]

| valign="top" |

|-

! colspan="5" | Stage generation
|-
| valign="top" |
* [[Pikmin binary GEN format|Binary GEN format]]
* [[Pikmin route|Routes]]

* Outdated pages
** [[Pikmin area generator file|Generator]]
** [[Pikmin gen codes|Gen codes]]

| valign="top" |
* Overworld
** [[Pikmin 2 area generator file|Overworld generation parameters]]
** [[Pikmin 2 map lighting files|Lighting]]
** [[Pikmin 2 waterboxes|Waterbox]]
** [[Pikmin 2 collision format|Collision]]
* Caves
** [[Cave generation parameters|Cave generation parameters]]
** [[Pikmin 2 Challenge Mode settings|Challenge Mode]]
** [[Pikmin 2 cave lighting files|Lighting]]
* Units (cave rooms)
** [[Cave unit generation|Cave unit generation]]
** [[Cave unit definition file|Cave unit definition]]
** [[Cave fixed layout|Cave fixed layout]]
* [[Pikmin 2 route|Routes]]

| valign="top" |

| valign="top" |

| valign="top" |
* Teki Units
** [[NoraSpawner]]
* [[Dandori Battles]]

|-

! colspan="5" | File formats
|-
| valign="top" |
* Archive Formats
** [[Paired ARC+DIR file]]
** [[BUN file]] (also ANM)
** [[BARC file]]
* Binary formats
** [[MOD file]] (3D Model)
** [[ACT file]] (Hierarchy Model File)
** [[TXE file]] (Texture)
** [[BTI file]] (Texture)
** [[BLO file]] (2D screen data)
** [[PCR file]] (Particle effect parameters)
** [[DC? files]] (Identifier for either DCA or DCK)
*** [[DCA file]] (Animation)
*** [[DCK file]] (Animation)
** [[H4M file]] (Pre-rendered video)
** [[JAM file]] (Sequenced music)
** [[STX file]] (Streamed music)
** [[AW file]] (Sound Bank)
** [[Pikmin parameter files|Parameter Files]]
* Plaintext Formats
** [[CIN file]] (Cutscene resource manager)
** [[DSK file]] (Cutscene data)
** [[DMD file]] (Intermediary 3D model)
** [[CNV file]] (Intermediary conversion file)
* Unknown Formats
** [[GST file]]
** [[CARD file]]
* Missing Formats
** [[DVW file]] (Material file?)
** [[JMP file]] (Intermediary plaintext 3D model file?)
** [[MD3 file]] (3D Model)
** [[BSP flle]] (3D Model)

| valign="top" |
* Archive Formats
** [[SZS file]]
** [[RARC file]]
* [[BMD file]] (J3D model)
* [[BTI file]] (Texture)
* [[BTK file]] (Animated texture)
* [[JPC file]] (Particle effect container)
** [[JPA file]] (Particle effect)
* [[BCA file]] (Animation)
* [[BCK file]] (Animation)
* [[BMS file]] (Sequenced music)
* [[AST file]] (Streamed music)
* [[AW file]] (Soundfont)
* [[THP file]] (Pre-rendered video)
* [[BLO file]] (2D screen data)
* [[STB file]] (Cutscene data)
* [[BMG file]] (Text)
* [[BPK file]]
* [[BRK file]]
* [[BMC file]]

* Misc.
** [[DWN file]] (e-Reader minigames?)
** [[DMD file]] (Intermediary 3D model)
** [[Pikmin 2 title screen|Title screen]]
** [[Pikmin 2 save file|Saved game data]]
** [[2-Player Battle stage parameters]]
** [[Mail]]

| valign="top" |

* [[Pikmin 3 radar files|Radar]]
* [[BFSTM file|BFSTM (streamed music)]]
* [[MSBT file (Pikmin 3)|MSBT (text string)]]
* [[FSKB file]] (Unknown)

| valign="top" |

* [[Hey! Pikmin save file|Saved game data]]
* [[ARC file (Hey! Pikmin)|ARC (archive)]]
* [[BCH file|BCH (animation)]]
* [[BFLIM file|BFLIM (image)]]
* [[MSBT file (Hey! Pikmin)|MSBT (text string)]]
* [[Z file|Z (archive)]]

| valign="top" |
* [[WEBM file|WEBM (video)]]
* [[BNVIB file|BNVIB]]
* [[UTOC/UCAS file|UTOC/UCAS (Archive for UASSET Files)]]
* [[UASSET file|UASSET File (Unreal Engine Asset File)]]
* [[UFONT file|UFONT]]
* [[LOCRES file|LOCRES]]
* [[WEM file|WEM]]
* [[BNK file|BNK]]
* [[Save Files]]

|-

! colspan="5" | Parameters
|-
| valign="top" |
* [[Pikmin labeled parameter file|Labeled]]
** [[Pikmin AI constants|AI constants]]
** [[Pikmin cunit parameters|Cuint]]
** [[Pikmin demo parameters|Demo]]
** [[Pikmin game parameters|Game parameters]]
** [[Pikmin navi parameters|NaviMgr]]
** [[Pikmin piki parameters|PikiMgr]]
** [[Pikmin sound parameters|Sound]]
** [[Pikmin wave parameters|Wave]]
** [[Pikmin prefs parameters|Prefs]]
** [[Pikmin boss parameters|Boss]]
* [[Pikmin unlabeled parameter file|Unlabeled]]
** [[Pikmin camera parameters|Camera]]
** [[Pikmin key parameters|Key]]
** [[Pikmin enemy parameter file format|Enemy]]

| valign="top" |
* [[naviParms|Leader]]
* [[pikiParms|Pikmin]]
* [[CameraParms|Camera]]
* [[Pikmin 2 enemy parameters|Entity]]
* [[Titan Dweevil parameters]]
* [[Trackmap parameters|trackMap parameters]]

| valign="top" |
* [[carryParam|Carry]]
* [[fruitsParam|Fruit]]
* [[pikminParam|Pikmin]]
* [[itemprogressParam|Item progress]]
* [[Mission settings]]
* [[GameobjectParam|Object]]

| valign="top" |

| valign="top" |

* [[ActorSerializeParameter and AI]]
* [[Data Table/Actor Parameters]]
* [[Enemy Parameters]]
* [[ActorGeneratorList]]

|-

! colspan="5" | Managers
|-
| valign="top" |
* [[BX file]] (Soundfont index)
* [[Pikmin pellet manager|Pellets]]
* [[Pikmin anim manager|Animations]]
* [[Pikmin teki manager|Tekis (DOL)]]
* [[Pikmin stage manager|Stage manager]]
* [[Pikmin stage information|Stage information / lighting]]

| valign="top" |
* [[AAF file]] (Soundfont index)
* Pellet List
** [[Pikmin 2 otakara_config.txt|Treasure Config]]
** [[Pikmin 2 item_config.txt|Item Config]]
** [[Pikmin 2 otakara_config.txt|Otakara Config]]
** [[Pikmin 2 carcass_config.txt|Carcass Config]]
** [[Pikmin 2 numberpellet_config.txt|Number Pellet Config]]
* [[Pikmin 2 animmgr.txt|Animation Manager]]
* [[Pikmin 2 collinfo.txt|Collision Info]]

* [[Mail Table]]

| valign="top" |

| valign="top" |

| valign="top" |

|-

! colspan="5" | Explanations and Notes
|-
| valign="top" |
* [[Pikmin unread files|Unread files]]
* [[Pikmin disable archives trick|Disable loading from archives]]
* [[Pikmin Emperor crash|Emperor crash]]
* [[Minty Ramblings]]
* [[Custom sequenced Pikmin music|Custom sequenced music]]

| valign="top" |
* [[Cave spawning]]
* [[Custom models]]
* [[Submerged Castle oddities|Special cave properties]]
* [[How Pikmin 2 loads text|How ''Pikmin 2'' loads text]]
* [[Sound Replacement Tutorial|Sound Replacement Tutorial]]
* [[Enemy Memory Usage]]
* [[Disassembly instructions]]
* [[Jsystem]]
* [[Pikmin 2 gEnemyInfo|gEnemyInfo]]
* [[Epoch Notes]]
* [[Cubes Yap Notes]]
* [[User:Captain Salty/Blo Editing Notes|Blo Editing Notes]]
* [[Cutscene Notes]]
* [[Creating Interactive BMS Files|Creating interactive area music]]
* [[Creating cave music|Creating interactive cave music]]

| valign="top" |
* [[Pikmin 3 oddities|Oddities]]
* [[Story mode maps in other modes]]
* [[Pikmin 3 Bingo Battle|Bingo Battle]]

| valign="top" |
* [[Hey! Pikmin unread files|Unread files]]

| valign="top" |
* Documentation
** [[Lilith's P4 Notes]]
** [[Pikmin 4 Demo Research]]
* Tutorials
** [[Model Importing Tutorial]]
** [[WEM Audio Modding Tutorial]]
** [[Enemy Duplication Tutorial (WIP)]]
|-

! colspan="5" | Tools
|-
| valign="top" |
* [[PikBinGen]]
* [[Archive Toolkit]]
* [[OpenGL / Dolphin System|OpenGL / Dolphin System]]

| valign="top" |
* [[Cave Creator]]
* [[Pikmin 2 Routes Editor & Gen Editor]]
* [[obj2grid]]
* [[DOL-Ckit]]
* [[Drought Enders Cave Creator]]
* [[SuperBMD]]
* [[pikminBMGtool]]
* [[btk-conv]]

| valign="top" |
* [[Gen Editor]]

| valign="top" |
* [[Hey! Pikmin stage viewer]]

| valign="top" |
* [[P4UassetEditor]]
* [[Modified FModel]]
* [[UCas/UToc Packer]]
* [[Dandori DB]]
* [[Dandori Desktop]]
* [[UE4LocalizationsTool]]

|}

== Tasks ==
* [[:Category:Pages with things to do|Things to do]]
* [[:Category:Pages with unsure information|Unsure info that needs to be confirmed]]

[[Category:PikminTKB]]

Main Page

2024-07-20T20:45:42Z

Noodl: Dandori Battles link

{{MainTemplate
| welcome = Welcome to the '''''Pikmin'' Technical Knowledge Base'''!
| blurb = A wiki dedicated to the internal files in ''Pikmin'' games.
| about_title = About
| about_content =
Throughout the years, ''Pikmin'' fans have tinkered with the files inside the games in order to better learn how they work, and to create custom content. Since there are a lot of nuances in every little thing, and since newcomers to the concept of file editing show up all the time, this wiki was created with the purpose of serving as a knowledge base for all that the fans know!

'''Partners''':
* [https://pikminwiki.com Pikipedia] - the ''Pikmin'' wiki
* [https://discord.gg/msMKc3G Pikcord] - the ''Pikmin'' community Discord server
* [https://discord.gg/G7Pgkdh Hocotate Hacker] - the ''Pikmin'' hacking community Discord server
| other_title = What this wiki is ''not''
| other_content =
* It's not a wiki about pirating ''Pikmin'' games.
* It's not a file-sharing service.
* It's not a wiki where you document...
** Canon content. Try [https://pikminwiki.com/ Pikipedia] instead.
** Fan-made content. Try [https://pikminfanon.com/ Pikmin Fanon] instead.
** Unused content or regional differences. Try [https://tcrf.net TCRF] instead.
* It's not an official source of info. The information here is mostly obtained via experimenting, and is subject to change as new discoveries are made.
}}

== Global information ==
{| class="wikitable" style="margin: auto; width: 75%;"
! colspan="3" | Global info
|-
| colspan="3" |
{| style="margin: auto;"
|
* [[General instructions]]
* [[Glossary]]
* [[Save files]]
* [[:Category:Tools|Tools]]
|}
|}

== Game-specific information ==
{| class="wikitable" style="margin: auto; width: 75%;"
! width="20%;" | ''Pikmin'' (and ''New Play Control! Pikmin'')
! width="20%;" | ''Pikmin 2'' (and ''New Play Control! Pikmin 2'')
! width="20%;" | ''Pikmin 3'' (and ''Pikmin 3 Deluxe'')
! width="20%;" | ''Hey! Pikmin''
! width="20%;" | ''Pikmin 4''
|-

! colspan="5" | General
|-
| valign="top" |
* [[Pikmin|Main information]]
* [[Pikmin instructions|Instructions]]
* [[Pikmin cheat codes|Useful cheat codes]]
* [[Pikmin memory addresses|Memory addresses]]
* [[Pikmin glossary|Glossary]]

| valign="top" |
* [[Pikmin 2|Main information]]
* [[Pikmin 2 instructions|Instructions]]
* [[Pikmin 2 cheat codes|Useful cheat codes]]
* [[Pikmin 2 memory addresses|Memory addresses]]
* [[Pikmin 2 troubleshooting|Troubleshooting]]
* [[Pikmin 2 glossary|Glossary]]

| valign="top" |
* [[Pikmin 3|Main information]]
* [[Pikmin 3 instructions|Instructions]]
* [[Pikmin 3 troubleshooting|Troubleshooting]]
* [[Pikmin 3 glossary|Glossary]]

| valign="top" |
* [[Hey! Pikmin|Main information]]
* [[Hey! Pikmin instructions|Instructions]]
* [[Hey! Pikmin troubleshooting|Troubleshooting]]
* [[Hey! Pikmin glossary|Glossary]]

| valign="top" |
* [[Pikmin 4|Main information]]
* [[Pikmin 4 instructions|Instructions]]
* [[Pikmin 4 troubleshooting|Troubleshooting]]
* [[Pikmin 4 glossary|Glossary]]
|-

! colspan="5" | File lists
|-
| valign="top" |
* [[Pikmin directory tree|Directory tree]]
* [[JAM file list|JAM file list (Pikiseq.arc)]]
* [[STX file list|STX file list]]
* [[CIN file list|CIN file list]]

| valign="top" |
* [[Pikmin 2 directory tree|Directory tree]]
* [[AST file list|AST (streamed music)]]
* [[Pikmin 2 BMS file list|BMS (sequenced music)]]
* [[Pikmin 2 CND file list|CND (sequenced music for caves)]]
* [[Guide_To_Sound_File_Names|List of sound effect files in the first bank]]
* [[Pikmin 2 cave units information|List of information of each cave unit]]

| valign="top" |
* [[Pikmin 3 directory tree|''Pikmin 3'' directory tree]]
* [[Pikmin 3 Deluxe directory tree|''Pikmin 3 Deluxe'' directory tree]]
* [[BFSTM file list|BFSTM (streamed music)]]
* [[MSBT file list|MSBT (text string)]]

| valign="top" |
* [[Hey! Pikmin directory tree|Directory tree]]
* [[BCSTM file list|BCSTM (music)]]

| valign="top" |
* [[Pikmin 4 directory tree|directory tree]]
|-

! colspan="5" | Constants
|-
| valign="top" |
* [[Pikmin identifiers|Identifiers]]
* [[Olimar's voyage log table]]

| valign="top" |
* [[Pikmin 2 identifiers|Identifiers]]
* [[Pikmin 2 Pikmin states|Pikmin states]]

| valign="top" |
* [[Pikmin 3 identifiers|Identifiers]]
* [[Pikmin 3 progress value|Progress value]]

| valign="top" |
* [[Hey! Pikmin identifiers|Identifiers]]

| valign="top" |
* [[Pikmin 4 identifiers|Identifiers]]
* [[Pikmin 4 text identifiers|Text Identifiers]]
|-

! colspan="5" | Particle effects
|-
| valign="top" |
* [[PCR particles]]

| valign="top" |
* [[JPC particles]]

| valign="top" |
* [[PTCL particles (Pikmin 3)]]

| valign="top" |
* [[PTCL particles (Hey Pikmin)]]

| valign="top" |

|-

! colspan="5" | Stage generation
|-
| valign="top" |
* [[Pikmin binary GEN format|Binary GEN format]]
* [[Pikmin route|Routes]]

* Outdated pages
** [[Pikmin area generator file|Generator]]
** [[Pikmin gen codes|Gen codes]]

| valign="top" |
* Overworld
** [[Pikmin 2 area generator file|Overworld generation parameters]]
** [[Pikmin 2 map lighting files|Lighting]]
** [[Pikmin 2 waterboxes|Waterbox]]
** [[Pikmin 2 collision format|Collision]]
* Caves
** [[Cave generation parameters|Cave generation parameters]]
** [[Pikmin 2 Challenge Mode settings|Challenge Mode]]
** [[Pikmin 2 cave lighting files|Lighting]]
* Units (cave rooms)
** [[Cave unit generation|Cave unit generation]]
** [[Cave unit definition file|Cave unit definition]]
** [[Cave fixed layout|Cave fixed layout]]
* [[Pikmin 2 route|Routes]]

| valign="top" |

| valign="top" |

| valign="top" |
* Teki Units
** [[NoraSpawner]]
* [[Save Files]]
* [[Dandori Battles]]

|-

! colspan="5" | File formats
|-
| valign="top" |
* Archive Formats
** [[Paired ARC+DIR file]]
** [[BUN file]] (also ANM)
** [[BARC file]]
* Binary formats
** [[MOD file]] (3D Model)
** [[ACT file]] (Hierarchy Model File)
** [[TXE file]] (Texture)
** [[BTI file]] (Texture)
** [[BLO file]] (2D screen data)
** [[PCR file]] (Particle effect parameters)
** [[DC? files]] (Identifier for either DCA or DCK)
*** [[DCA file]] (Animation)
*** [[DCK file]] (Animation)
** [[H4M file]] (Pre-rendered video)
** [[JAM file]] (Sequenced music)
** [[STX file]] (Streamed music)
** [[AW file]] (Sound Bank)
** [[Pikmin parameter files|Parameter Files]]
* Plaintext Formats
** [[CIN file]] (Cutscene resource manager)
** [[DSK file]] (Cutscene data)
** [[DMD file]] (Intermediary 3D model)
** [[CNV file]] (Intermediary conversion file)
* Unknown Formats
** [[GST file]]
** [[CARD file]]
* Missing Formats
** [[DVW file]] (Material file?)
** [[JMP file]] (Intermediary plaintext 3D model file?)
** [[MD3 file]] (3D Model)
** [[BSP flle]] (3D Model)

| valign="top" |
* Archive Formats
** [[SZS file]]
** [[RARC file]]
* [[BMD file]] (J3D model)
* [[BTI file]] (Texture)
* [[BTK file]] (Animated texture)
* [[JPC file]] (Particle effect container)
** [[JPA file]] (Particle effect)
* [[BCA file]] (Animation)
* [[BCK file]] (Animation)
* [[BMS file]] (Sequenced music)
* [[AST file]] (Streamed music)
* [[AW file]] (Soundfont)
* [[THP file]] (Pre-rendered video)
* [[BLO file]] (2D screen data)
* [[STB file]] (Cutscene data)
* [[BMG file]] (Text)
* [[BPK file]]
* [[BRK file]]
* [[BMC file]]

* Misc.
** [[DWN file]] (e-Reader minigames?)
** [[DMD file]] (Intermediary 3D model)
** [[Pikmin 2 title screen|Title screen]]
** [[Pikmin 2 save file|Saved game data]]
** [[2-Player Battle stage parameters]]
** [[Mail]]

| valign="top" |

* [[Pikmin 3 radar files|Radar]]
* [[BFSTM file|BFSTM (streamed music)]]
* [[MSBT file (Pikmin 3)|MSBT (text string)]]
* [[FSKB file]] (Unknown)

| valign="top" |

* [[Hey! Pikmin save file|Saved game data]]
* [[ARC file (Hey! Pikmin)|ARC (archive)]]
* [[BCH file|BCH (animation)]]
* [[BFLIM file|BFLIM (image)]]
* [[MSBT file (Hey! Pikmin)|MSBT (text string)]]
* [[Z file|Z (archive)]]

| valign="top" |
* [[WEBM file|WEBM (video)]]
* [[BNVIB file|BNVIB]]
* [[UTOC/UCAS file|UTOC/UCAS (Archive for UASSET Files)]]
* [[UASSET file|UASSET File (Unreal Engine Asset File)]]
* [[UFONT file|UFONT]]
* [[LOCRES file|LOCRES]]
* [[WEM file|WEM]]
* [[BNK file|BNK]]

|-

! colspan="5" | Parameters
|-
| valign="top" |
* [[Pikmin labeled parameter file|Labeled]]
** [[Pikmin AI constants|AI constants]]
** [[Pikmin cunit parameters|Cuint]]
** [[Pikmin demo parameters|Demo]]
** [[Pikmin game parameters|Game parameters]]
** [[Pikmin navi parameters|NaviMgr]]
** [[Pikmin piki parameters|PikiMgr]]
** [[Pikmin sound parameters|Sound]]
** [[Pikmin wave parameters|Wave]]
** [[Pikmin prefs parameters|Prefs]]
** [[Pikmin boss parameters|Boss]]
* [[Pikmin unlabeled parameter file|Unlabeled]]
** [[Pikmin camera parameters|Camera]]
** [[Pikmin key parameters|Key]]
** [[Pikmin enemy parameter file format|Enemy]]

| valign="top" |
* [[naviParms|Leader]]
* [[pikiParms|Pikmin]]
* [[CameraParms|Camera]]
* [[Pikmin 2 enemy parameters|Entity]]
* [[Titan Dweevil parameters]]
* [[Trackmap parameters|trackMap parameters]]

| valign="top" |
* [[carryParam|Carry]]
* [[fruitsParam|Fruit]]
* [[pikminParam|Pikmin]]
* [[itemprogressParam|Item progress]]
* [[Mission settings]]
* [[GameobjectParam|Object]]

| valign="top" |

| valign="top" |

* [[ActorSerializeParameter and AI]]
* [[Data Table/Actor Parameters]]
* [[Enemy Parameters]]
* [[ActorGeneratorList]]

|-

! colspan="5" | Managers
|-
| valign="top" |
* [[BX file]] (Soundfont index)
* [[Pikmin pellet manager|Pellets]]
* [[Pikmin anim manager|Animations]]
* [[Pikmin teki manager|Tekis (DOL)]]
* [[Pikmin stage manager|Stage manager]]
* [[Pikmin stage information|Stage information / lighting]]

| valign="top" |
* [[AAF file]] (Soundfont index)
* Pellet List
** [[Pikmin 2 otakara_config.txt|Treasure Config]]
** [[Pikmin 2 item_config.txt|Item Config]]
** [[Pikmin 2 otakara_config.txt|Otakara Config]]
** [[Pikmin 2 carcass_config.txt|Carcass Config]]
** [[Pikmin 2 numberpellet_config.txt|Number Pellet Config]]
* [[Pikmin 2 animmgr.txt|Animation Manager]]
* [[Pikmin 2 collinfo.txt|Collision Info]]

* [[Mail Table]]

| valign="top" |

| valign="top" |

| valign="top" |

|-

! colspan="5" | Explanations and Notes
|-
| valign="top" |
* [[Pikmin unread files|Unread files]]
* [[Pikmin disable archives trick|Disable loading from archives]]
* [[Pikmin Emperor crash|Emperor crash]]
* [[Minty Ramblings]]
* [[Custom sequenced Pikmin music|Custom sequenced music]]

| valign="top" |
* [[Cave spawning]]
* [[Custom models]]
* [[Submerged Castle oddities|Special cave properties]]
* [[How Pikmin 2 loads text|How ''Pikmin 2'' loads text]]
* [[Sound Replacement Tutorial|Sound Replacement Tutorial]]
* [[Enemy Memory Usage]]
* [[Disassembly instructions]]
* [[Jsystem]]
* [[Pikmin 2 gEnemyInfo|gEnemyInfo]]
* [[Epoch Notes]]
* [[Cubes Yap Notes]]
* [[User:Captain Salty/Blo Editing Notes|Blo Editing Notes]]
* [[Cutscene Notes]]
* [[Creating Interactive BMS Files|Creating interactive area music]]
* [[Creating cave music|Creating interactive cave music]]

| valign="top" |
* [[Pikmin 3 oddities|Oddities]]
* [[Story mode maps in other modes]]
* [[Pikmin 3 Bingo Battle|Bingo Battle]]

| valign="top" |
* [[Hey! Pikmin unread files|Unread files]]

| valign="top" |
* Documentation
** [[Lilith's P4 Notes]]
** [[Pikmin 4 Demo Research]]
* Tutorials
** [[Model Importing Tutorial]]
** [[WEM Audio Modding Tutorial]]
** [[Enemy Duplication Tutorial (WIP)]]
|-

! colspan="5" | Tools
|-
| valign="top" |
* [[PikBinGen]]
* [[Archive Toolkit]]
* [[OpenGL / Dolphin System|OpenGL / Dolphin System]]

| valign="top" |
* [[Cave Creator]]
* [[Pikmin 2 Routes Editor & Gen Editor]]
* [[obj2grid]]
* [[DOL-Ckit]]
* [[Drought Enders Cave Creator]]
* [[SuperBMD]]
* [[pikminBMGtool]]
* [[btk-conv]]

| valign="top" |
* [[Gen Editor]]

| valign="top" |
* [[Hey! Pikmin stage viewer]]

| valign="top" |
* [[P4UassetEditor]]
* [[Modified FModel]]
* [[UCas/UToc Packer]]
* [[Dandori DB]]
* [[Dandori Desktop]]
* [[UE4LocalizationsTool]]

|}

== Tasks ==
* [[:Category:Pages with things to do|Things to do]]
* [[:Category:Pages with unsure information|Unsure info that needs to be confirmed]]

[[Category:PikminTKB]]

File:P4-creature-ai-inventory-bytes.png

2024-07-14T02:04:09Z

Noodl: Noodl uploaded a new version of File:P4-creature-ai-inventory-bytes.png

== Summary ==
Charted bytes of a creature's AI

File:P4-creature-ai-inventory-bytes.png

2024-07-14T02:02:29Z

Noodl: Noodl uploaded a new version of File:P4-creature-ai-inventory-bytes.png

== Summary ==
Charted bytes of a creature's AI

File:P4-otakara-ai.png

2024-07-14T02:00:31Z

Noodl:

ActorSerializeParameter and AI

2024-07-14T02:00:05Z

Noodl:

All of the info on this page (thus far) is research and assumptions by [[Noodl]] - it may not all be entirely correct.

<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.

<source lang="JSON">

{
"ActorSerializeParameter": {
"AI": {
"Static": [],
"Dynamic": [];
},
"Hash": { ... },
"CheckComp": { ... },
"ActorParameter": { ... },
"SubAI": { ... },
"Life": { ... },
"PortalTrigger": { ... },
"DemoTrigger": { ... },
"Pikmin": { ... },
"CharacterEdit": { ... },
"PopPlace": { ... },
"Strategy": { ... },
"CakEmitterConfig": { ... },
"CakSimpleState": { ... },
"CakTrigger": { ... },
"CakMultiplePosition": { ... },
"CakAudioTable": { ... },
"WaterTrigger": { ... },
"NavMeshTrigger": { ... },
"Affordance": { ... },
"HiddenBoxTrigger": { ... },
"NarrowSpaceBoxTrigger": { ... },
"WarpTrigger": { ... },
"ActionMarker": { ... },
}
}

</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]).

== 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.

=== Concepts ===

Before trying to break down a byte array, it helps to understand a few concepts of the data types used:

* Each integer in the array is a single 8-bit/1-byte value, so can only go up to 255.
* The arrays are not fixed to 32-bit boundaries. A 4-byte float can be adjacent to a 16bit integer.
* Booleans are 4-bytes with the 0/1 being in the first index
* Floats are little-endian, and 4 bytes long. For example the value <code>100</code> will be 4 bytes of <code>0, 0, 200, 66</code>.
* Integers can also be encoded across 2-bytes (two integers of this array). For example, the value <code>271</code> would be <code>15,1</code> - 15 + (256 * 1). They are also sometimes just 1-byte long with the value at index 0.
* Strings are encoded by 4 bytes dictating the length of the string (null terminator included) followed by the string's characters in ASCII codes, ending with <code>0</code>. For example the string of <code>None</code> will be encoded as <code>5, 0, 0, 0, 78, 111, 110, 101, 0</code>, with 5 being the length of the string (4 chars + <code>0</code>).
* When arrays/objects are used (for fields like <code>DropConditions</code> or <code>bSetTerritory</code>, there is often a 4 byte boolean that dictates if the rest of the object is present, or the number of items in the array. For example, with territory, if <code>bSetTerritory</code> is <code>false</code>, the bytes will look like <code>0, 0, 0, 0, ... </code> followed by whatever else comes after. However if it is true (<code>1, 0, 0, 0</code>), 5 floats (X, Y, Z, HalfHeight and Radius) will follow, making the array vary in length.

[[Dandori Desktop]] provides tools for byte conversions that can aid in finding values.

== 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.

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>.

=== 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.

[[File:P4-creature-ai-inventory-bytes.png|500px|thumb|center|]]

=== ActorSpawner AI ===
ActorSpawners are a little different, and their only drop is the thing they spawn, with some configuration for it.

[[File:P4-actorspawner-ai.png|500px|thumb|center|]]

=== GroupDropManager AI ===

[[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|]]

=== Treasure AI ===

[[File:P4-otakara-ai.png |500px|thumb|center|]]

=== Researching ===

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.

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 (non-night)
* [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:Parameters]]

File:P4-creature-ai-inventory-bytes.png

2024-06-30T21:47:11Z

Noodl: Noodl uploaded a new version of File:P4-creature-ai-inventory-bytes.png

== Summary ==
Charted bytes of a creature's AI

ActorSerializeParameter and AI

2024-06-10T22:13:57Z

Noodl: specify non-night

All of the info on this page (thus far) is research and assumptions by [[Noodl]] - it may not all be entirely correct.

<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.

<source lang="JSON">

{
"ActorSerializeParameter": {
"AI": {
"Static": [],
"Dynamic": [];
},
"Hash": { ... },
"CheckComp": { ... },
"ActorParameter": { ... },
"SubAI": { ... },
"Life": { ... },
"PortalTrigger": { ... },
"DemoTrigger": { ... },
"Pikmin": { ... },
"CharacterEdit": { ... },
"PopPlace": { ... },
"Strategy": { ... },
"CakEmitterConfig": { ... },
"CakSimpleState": { ... },
"CakTrigger": { ... },
"CakMultiplePosition": { ... },
"CakAudioTable": { ... },
"WaterTrigger": { ... },
"NavMeshTrigger": { ... },
"Affordance": { ... },
"HiddenBoxTrigger": { ... },
"NarrowSpaceBoxTrigger": { ... },
"WarpTrigger": { ... },
"ActionMarker": { ... },
}
}

</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]).

== 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.

=== Concepts ===

Before trying to break down a byte array, it helps to understand a few concepts of the data types used:

* Each integer in the array is a single 8-bit/1-byte value, so can only go up to 255.
* The arrays are not fixed to 32-bit boundaries. A 4-byte float can be adjacent to a 16bit integer.
* Booleans are 4-bytes with the 0/1 being in the first index
* Floats are little-endian, and 4 bytes long. For example the value <code>100</code> will be 4 bytes of <code>0, 0, 200, 66</code>.
* Integers can also be encoded across 2-bytes (two integers of this array). For example, the value <code>271</code> would be <code>15,1</code> - 15 + (256 * 1). They are also sometimes just 1-byte long with the value at index 0.
* Strings are encoded by 4 bytes dictating the length of the string (null terminator included) followed by the string's characters in ASCII codes, ending with <code>0</code>. For example the string of <code>None</code> will be encoded as <code>5, 0, 0, 0, 78, 111, 110, 101, 0</code>, with 5 being the length of the string (4 chars + <code>0</code>).
* When arrays/objects are used (for fields like <code>DropConditions</code> or <code>bSetTerritory</code>, there is often a 4 byte boolean that dictates if the rest of the object is present, or the number of items in the array. For example, with territory, if <code>bSetTerritory</code> is <code>false</code>, the bytes will look like <code>0, 0, 0, 0, ... </code> followed by whatever else comes after. However if it is true (<code>1, 0, 0, 0</code>), 5 floats (X, Y, Z, HalfHeight and Radius) will follow, making the array vary in length.

[[Dandori Desktop]] provides tools for byte conversions that can aid in finding values.

== 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.

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>.

=== 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.

[[File:P4-creature-ai-inventory-bytes.png|500px|thumb|center|]]

=== ActorSpawner AI ===
ActorSpawners are a little different, and their only drop is the thing they spawn, with some configuration for it.

[[File:P4-actorspawner-ai.png|500px|thumb|center|]]

=== GroupDropManager AI ===

[[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 ===

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.

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 (non-night)
* [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:Parameters]]

File:P4-actorspawner-ai.png

2024-05-15T23:02:24Z

Noodl: Noodl uploaded a new version of File:P4-actorspawner-ai.png

== Summary ==
Charted bytes of ActorSpawner's AI

Dandori Desktop

2024-05-13T01:26:45Z

Noodl: Fix text

Dandori Desktop is a tool created by [[Noodl]] that allows visualising and editing of local game files. Inspired by DandoriDB, this takes that concept and moves it to the local environment for direct editing.

In lieu of detailed guides for actor and ActorGeneratorList editing, without intimate detail of its contents, Dandori Desktop is an easy way to get started modifying map generator files.

It can be downloaded from the repo's releases page. Refer to the repo's readme for setup instructions.

== Link ==
* [https://github.com/Chagrilled/P4-DandoriDesktop/ GitHub Repo]

== Usage ==
* Right click to create entities
* ctrl+Z to undo deleted entities
* ctrl+V to duplicate the selected entity

[[Category:Pikmin 4]]
[[Category:Tools]]

Pikmin 4 enemy parameters

2024-05-13T01:22:36Z

Noodl: fix link

{{DISPLAYTITLE:Data Table/Actor Parameters}}

Enemy behaviour parameters are configured in each enemy's blueprint file, or sometimes its superclass file. These exist in <code>Carrot4/Placeables/Teki</code> and <code>Carrot4/Placeables/Teki/Base</code> for superclasses and can be edited as JSON, once decoded. For enemy parameters relating to economy/health/carrying/damage see [[Data Table/Actor Parameters]].

While the blueprint files are quite large, they are mostly full of irrelevant code for the common user. The file is split into "generator variables" which are used to set the base characteristics of an enemy at runtime, likely laid underneath an enemy's instance-parameters, which come from [[ActorSerializeParameter and AI]].

The gen variables one is likely looking for are:

{| class="wikitable sortable"
! Gen var || Meaning
|-
| <code>AttackAffordance_GEN_VARIABLE</code> || Possibly the properties of if an entity believes it can attack
|-
| <code>{EntityName}AI_GEN_VARIABLE</code> || Configures an enemy's behaviour and values
|-
| <code>CarrotMove_GEN_VARIABLE</code> || Speed values
|-
| <code>Life_GEN_VARIABLE</code> || Health, health bar and some damage properties
|-
| <code>PointerAssist_GEN_VARIABLE</code> || Cursor properties
|}

[[Category:Constants]]
[[Category:Pikmin 4]]

ActorSerializeParameter and AI

2024-05-12T22:45:09Z

Noodl: Geysers

All of the info on this page (thus far) is research and assumptions by [[Noodl]] - it may not all be entirely correct.

<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.

<source lang="JSON">

{
"ActorSerializeParameter": {
"AI": {
"Static": [],
"Dynamic": [];
},
"Hash": { ... },
"CheckComp": { ... },
"ActorParameter": { ... },
"SubAI": { ... },
"Life": { ... },
"PortalTrigger": { ... },
"DemoTrigger": { ... },
"Pikmin": { ... },
"CharacterEdit": { ... },
"PopPlace": { ... },
"Strategy": { ... },
"CakEmitterConfig": { ... },
"CakSimpleState": { ... },
"CakTrigger": { ... },
"CakMultiplePosition": { ... },
"CakAudioTable": { ... },
"WaterTrigger": { ... },
"NavMeshTrigger": { ... },
"Affordance": { ... },
"HiddenBoxTrigger": { ... },
"NarrowSpaceBoxTrigger": { ... },
"WarpTrigger": { ... },
"ActionMarker": { ... },
}
}

</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]).

== 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.

=== Concepts ===

Before trying to break down a byte array, it helps to understand a few concepts of the data types used:

* Each integer in the array is a single 8-bit/1-byte value, so can only go up to 255.
* The arrays are not fixed to 32-bit boundaries. A 4-byte float can be adjacent to a 16bit integer.
* Booleans are 4-bytes with the 0/1 being in the first index
* Floats are little-endian, and 4 bytes long. For example the value <code>100</code> will be 4 bytes of <code>0, 0, 200, 66</code>.
* Integers can also be encoded across 2-bytes (two integers of this array). For example, the value <code>271</code> would be <code>15,1</code> - 15 + (256 * 1). They are also sometimes just 1-byte long with the value at index 0.
* Strings are encoded by 4 bytes dictating the length of the string (null terminator included) followed by the string's characters in ASCII codes, ending with <code>0</code>. For example the string of <code>None</code> will be encoded as <code>5, 0, 0, 0, 78, 111, 110, 101, 0</code>, with 5 being the length of the string (4 chars + <code>0</code>).
* When arrays/objects are used (for fields like <code>DropConditions</code> or <code>bSetTerritory</code>, there is often a 4 byte boolean that dictates if the rest of the object is present, or the number of items in the array. For example, with territory, if <code>bSetTerritory</code> is <code>false</code>, the bytes will look like <code>0, 0, 0, 0, ... </code> followed by whatever else comes after. However if it is true (<code>1, 0, 0, 0</code>), 5 floats (X, Y, Z, HalfHeight and Radius) will follow, making the array vary in length.

[[Dandori Desktop]] provides tools for byte conversions that can aid in finding values.

== 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.

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>.

=== 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.

[[File:P4-creature-ai-inventory-bytes.png|500px|thumb|center|]]

=== ActorSpawner AI ===
ActorSpawners are a little different, and their only drop is the thing they spawn, with some configuration for it.

[[File:P4-actorspawner-ai.png|500px|thumb|center|]]

=== GroupDropManager AI ===

[[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 ===

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.

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:Parameters]]

File:P4-geyser-ai.png

2024-05-12T22:38:32Z

Noodl: Byte chart for Geysers

== Summary ==
Byte chart for Geysers

ActorSerializeParameter and AI

2024-05-06T21:55:02Z

Noodl: Sprinkler findings

All of the info on this page (thus far) is research and assumptions by [[Noodl]] - it may not all be entirely correct.

<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.

<source lang="JSON">

{
"ActorSerializeParameter": {
"AI": {
"Static": [],
"Dynamic": [];
},
"Hash": { ... },
"CheckComp": { ... },
"ActorParameter": { ... },
"SubAI": { ... },
"Life": { ... },
"PortalTrigger": { ... },
"DemoTrigger": { ... },
"Pikmin": { ... },
"CharacterEdit": { ... },
"PopPlace": { ... },
"Strategy": { ... },
"CakEmitterConfig": { ... },
"CakSimpleState": { ... },
"CakTrigger": { ... },
"CakMultiplePosition": { ... },
"CakAudioTable": { ... },
"WaterTrigger": { ... },
"NavMeshTrigger": { ... },
"Affordance": { ... },
"HiddenBoxTrigger": { ... },
"NarrowSpaceBoxTrigger": { ... },
"WarpTrigger": { ... },
"ActionMarker": { ... },
}
}

</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]).

== 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.

=== Concepts ===

Before trying to break down a byte array, it helps to understand a few concepts of the data types used:

* Each integer in the array is a single 8-bit/1-byte value, so can only go up to 255.
* The arrays are not fixed to 32-bit boundaries. A 4-byte float can be adjacent to a 16bit integer.
* Booleans are 4-bytes with the 0/1 being in the first index
* Floats are little-endian, and 4 bytes long. For example the value <code>100</code> will be 4 bytes of <code>0, 0, 200, 66</code>.
* Integers can also be encoded across 2-bytes (two integers of this array). For example, the value <code>271</code> would be <code>15,1</code> - 15 + (256 * 1). They are also sometimes just 1-byte long with the value at index 0.
* Strings are encoded by 4 bytes dictating the length of the string (null terminator included) followed by the string's characters in ASCII codes, ending with <code>0</code>. For example the string of <code>None</code> will be encoded as <code>5, 0, 0, 0, 78, 111, 110, 101, 0</code>, with 5 being the length of the string (4 chars + <code>0</code>).
* When arrays/objects are used (for fields like <code>DropConditions</code> or <code>bSetTerritory</code>, there is often a 4 byte boolean that dictates if the rest of the object is present, or the number of items in the array. For example, with territory, if <code>bSetTerritory</code> is <code>false</code>, the bytes will look like <code>0, 0, 0, 0, ... </code> followed by whatever else comes after. However if it is true (<code>1, 0, 0, 0</code>), 5 floats (X, Y, Z, HalfHeight and Radius) will follow, making the array vary in length.

[[Dandori Desktop]] provides tools for byte conversions that can aid in finding values.

== 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.

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>.

=== 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.

[[File:P4-creature-ai-inventory-bytes.png|500px|thumb|center|]]

=== ActorSpawner AI ===
ActorSpawners are a little different, and their only drop is the thing they spawn, with some configuration for it.

[[File:P4-actorspawner-ai.png|500px|thumb|center|]]

=== GroupDropManager AI ===

[[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|]]

=== AreaBaseAI Gen Variable ===

This chart is for the base camps.

[[File:p4-areabasecamp-ai.png |500px|thumb|center|]]

=== SprinklerAI 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|]]

=== ValveAI ===

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|]]

=== Researching ===

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.

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:Parameters]]

ActorSerializeParameter and AI

2024-05-06T16:25:05Z

Noodl: Dumps and NMT deets

All of the info on this page (thus far) is research and assumptions by [[Noodl]] - it may not all be entirely correct.

<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.

<source lang="JSON">

{
"ActorSerializeParameter": {
"AI": {
"Static": [],
"Dynamic": [];
},
"Hash": { ... },
"CheckComp": { ... },
"ActorParameter": { ... },
"SubAI": { ... },
"Life": { ... },
"PortalTrigger": { ... },
"DemoTrigger": { ... },
"Pikmin": { ... },
"CharacterEdit": { ... },
"PopPlace": { ... },
"Strategy": { ... },
"CakEmitterConfig": { ... },
"CakSimpleState": { ... },
"CakTrigger": { ... },
"CakMultiplePosition": { ... },
"CakAudioTable": { ... },
"WaterTrigger": { ... },
"NavMeshTrigger": { ... },
"Affordance": { ... },
"HiddenBoxTrigger": { ... },
"NarrowSpaceBoxTrigger": { ... },
"WarpTrigger": { ... },
"ActionMarker": { ... },
}
}

</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]).

== 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.

=== Concepts ===

Before trying to break down a byte array, it helps to understand a few concepts of the data types used:

* Each integer in the array is a single 8-bit/1-byte value, so can only go up to 255.
* The arrays are not fixed to 32-bit boundaries. A 4-byte float can be adjacent to a 16bit integer.
* Booleans are 4-bytes with the 0/1 being in the first index
* Floats are little-endian, and 4 bytes long. For example the value <code>100</code> will be 4 bytes of <code>0, 0, 200, 66</code>.
* Integers can also be encoded across 2-bytes (two integers of this array). For example, the value <code>271</code> would be <code>15,1</code> - 15 + (256 * 1). They are also sometimes just 1-byte long with the value at index 0.
* Strings are encoded by 4 bytes dictating the length of the string (null terminator included) followed by the string's characters in ASCII codes, ending with <code>0</code>. For example the string of <code>None</code> will be encoded as <code>5, 0, 0, 0, 78, 111, 110, 101, 0</code>, with 5 being the length of the string (4 chars + <code>0</code>).
* When arrays/objects are used (for fields like <code>DropConditions</code> or <code>bSetTerritory</code>, there is often a 4 byte boolean that dictates if the rest of the object is present, or the number of items in the array. For example, with territory, if <code>bSetTerritory</code> is <code>false</code>, the bytes will look like <code>0, 0, 0, 0, ... </code> followed by whatever else comes after. However if it is true (<code>1, 0, 0, 0</code>), 5 floats (X, Y, Z, HalfHeight and Radius) will follow, making the array vary in length.

[[Dandori Desktop]] provides tools for byte conversions that can aid in finding values.

== 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.

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>.

=== 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.

[[File:P4-creature-ai-inventory-bytes.png|500px|thumb|center|]]

=== ActorSpawner AI ===
ActorSpawners are a little different, and their only drop is the thing they spawn, with some configuration for it.

[[File:P4-actorspawner-ai.png|500px|thumb|center|]]

=== GroupDropManager AI ===

[[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|]]

=== AreaBaseAI Gen Variable ===

This chart is for the base camps.

[[File:p4-areabasecamp-ai.png |500px|thumb|center|]]

=== SprinklerAI 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.

[[File:p4-sprinkler-objectAI.png |500px|thumb|center|]]

=== ValveAI ===

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|]]

=== Researching ===

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.

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:Parameters]]

ActorSerializeParameter and AI

2024-05-06T00:17:19Z

Noodl: NavMeshTrigger

File:P4-navmeshtrigger.png

2024-05-06T00:15:35Z

Noodl: NavMeshTrigger gen var bytes chart

== Summary ==
NavMeshTrigger gen var bytes chart

ActorSerializeParameter and AI

2024-05-04T00:41:40Z

Noodl:

ActorSerializeParameter and AI

2024-05-04T00:34:41Z

Noodl: Valve AI and extra descriptions

File:P4-valveai.png

2024-05-04T00:17:14Z

Noodl: Valve AI chart

== Summary ==
Valve AI chart

File:P4-sprinklerai.png

2024-05-04T00:16:52Z

Noodl: Sprinkler AI chart

== Summary ==
Sprinkler AI chart

ActorSerializeParameter and AI

2024-03-29T22:50:53Z

Noodl: Full ActorSerializeParameter