parchmentmc / parchment Goto Github PK

Minecraft version: 1.20.1
Mappings version: 2023.07.30

(mojmap)

Minecraft version: 1.19
Mappings version: 1.18.2-2022.07.10-1.19

The second argument in net.minecraft.world.entity.ai.sensing.Sensor::doTick is called attacker but should this is the entity that is sensing. Other places call it entity or brainHolder

It can be a pain to figure out from which commit a release was created for. Finding it out is certainly possible -- referencing the date of the release, knowing that releases are created at 12PM UTC on Sundays (as of writing), looking at past commits and finding the commit before that day) -- but it is still a time-consuming tag.

To alleviate this, we can implement the use of Git tags to mark releases, specifically using lightweight tags. During the release creation process, the CI should be able to create a lightweight tag on the latest commit in the release, and push it to the main repository.

While annotated tags would allow for attaching a message to the release, it would be more difficult to configure because of the requirement of a committer identity to the CI agent just before creating the annotated tag. However, we may reconsider on this point if it proves that the benefits of using annotated tags outweights the difficulty in CI configuration.

Minecraft version: 1.18, 1.19
Mappings version: 2022.09.04-1.18.2

The mapping for isAcceptableNeighbor erroneously names a BlockPos as level

Minecraft version: 1.20.1
Mappings version: 2023.06.26

Typo in first parameter of assertValidNamespace:
pNamespae -> pNamespace

[If your topic fits an already existing template, please use those for the proper labels to be applied.]

Minecraft version: [1.21]
Mappings version: [2024.06.23]

[Typo in "baseSlorDescription" ]
[Should be "baseSlotDescription"]

Minecraft version: 1.20.4 (but I am using mappings for 1.20.3)
Mappings version: 2023.12.31

The parameters for AbstractFurnaceBlockEntity#canBurn and AbstractFurnaceBlockEntity#burn seem to be shifted left by one:

boolean canBurn(RegistryAccess pRecipe, @Nullable RecipeHolder<?> pInventory, NonNullList<ItemStack> pMaxStackSize, int p_155008_)
boolean burn(RegistryAccess pRecipe, @Nullable RecipeHolder<?> pInventory, NonNullList<ItemStack> pMaxStackSize, int p_267157_)

It seems like it should be registryAccess for the first parameters and then all the other names are basically fine if you shift them to the right by one.

Early in the design stage of Parchment, it was decided to have the mapping data use obfuscated names instead of Mojang names or other intermediates, for the following reasons:

• In the case of Mojang names, we wanted to avoid hosting the Mojang names in our files, due to the potential legality of such.
• In the case of intermediate names, one design choice beforehand was to not have any reliance on any particular intermediate (such as Forge's SRG via MCPConfig or Fabric's Intermediary), to be as neutral as we can in regards to these intermediaries (we still use them for version migration and such, but they are not required for the operation of Parchment).

However, we are now reconsidering that decision and leaning towards moving to Mojang names for the following reasons:

1. It is difficult for reviewers to ascertain what changes are done in a PR/commit because they are in obfuscated names. It requires then for people to use external services or tools to translate these obfuscated names into their Mojang names, which adds an extra layer of difficulty to reviews.

2. Because of the nature of obfuscated names, moving between any two versions of Minecraft would mean most of the names changing what actual Mojang class they represent, which means a large amount of shifting of the data would occur. For example, if Mojang added a class which when obfuscated became the new ab, all obfuscated names after that would be shifted.

3. While the legality of the project is not fully clear without actual consultation from a lawyer, we can abide by the letter (and spirit) of the obfuscation mappings license by only storing in the repository Mojang names which have additional data attached, such as parameter names and documentation.

   Furthermore, as we are already publishing and distributing these names through our exports (which use Mojang names), that is a permanent source of legal 'risk', in the sense that even if we were to keep to obfuscated names, our exports are still a potential target if we are to be struck down by Mojang.

   Note: While we are considering the risk of being struck down by Mojang, we have faith in Mojang's goodwill towards the modding community, that these mappings are released with the expectation that they are to be used by the community.

   (Personal opinion: It is my firm belief that if Mojang were to strike down the modding community, it would be through striking down the relevant portion of the Minecraft EULA and then pursing legal action. However, it is also my strong belief that Mojang has faith and trust towards the modding community, and that they will continue this faith and goodwill long into the future.)

For these reasons, it is proposed that we move the data currently in the repository to use Mojang names, and use them for the forseeable future.

it should be technically possible to auto-publish builds for new Minecraft versions, as Quilt does with hashed mappings. this would allow using parchment for snapshot development as well as relieve some maintenance burden, along with opening up new possibilities for parchment to collaborate with other mapping sets.

As mentioned in #184, Parchment does not typically accept mappings for snapshots. However, I feel this is a unique case.

23w13a_or_b (The Vote Update) is a unique update containing exclusive code (namely that for the Vote API). Looking at this partially mapped code, it is pretty heavily standardized (new Rules can be added via an internal Registry), and ripe for modding (adding additional Rule types could be a lot of fun, I'm experimenting with that now).

Additionally, the code cannot simply be documented later (since its features will certainly not be added to the snapshot and stable versions after this).

My suggestion is to create a working branch for the snapshot; relevant mappings added by newer versions can be backported via PR, as can new mappings. I volunteer myself to help with this effort, as I am exploring the de-obfuscated code base now and getting used to how voting functionality is implemented.

Minecraft version: [1.20.4 neoforge]
Mappings version: [2024.04.14]

This issue results of this conversation in the parchment dc: https://discord.com/channels/851855518398152725/853128034377531402/1232686744823009403

Some record files appear unmapped in my workspace even though they are mapped in enigma.
However there doesn't seem to be a pattern, like eg. all records are unmapped etc.
Some records are mapped in my workspace some are not and some only partly. Even though all of those records are properly mapped in enigma.
Regular class files are mapped correctly in 90% of the time. When I found a not fully mapped class file it also wasn't mapped in enigma, so this seems to only affect record files.

Example 1: fully unmapped in workspace

Example 2: partly unmapped in workspace

Example 3: fully mapped in workspace

Let me know if there's any further information needed!

Minecraft version: 1.20.6
Mappings version: 2024.05.01

In the following methods (that I have noticed):

• initiateServerboundPlayConnection
• initiateServerboundConnection

The param disconnectListener is incorrect. This is not a listener for just disconnecting but it the initial listener intended to be paired with the initial clientboundProtocol also provided in these methods.

It should be named packetListener

Minecraft version: 1.20.1
Mappings version: 2023.09.03-1.20.1

p_44001_ should be simpleContainer and p_267165_ should be registryAccess

Before

What it should be

Or simpleContainer could just be container

Metadata

Eclipse Version: 2021-06
Minecraft Version: 1.20.1
Mod Loader: Forge
OS: Windows 10

build.gradle

plugins {
    id 'eclipse'
    id 'idea'
    id 'maven-publish'
    id 'net.minecraftforge.gradle' version '[6.0,6.2)'
    id 'org.parchmentmc.librarian.forgegradle' version '1.+'
    id 'org.spongepowered.mixin' version '0.7.+'
}

version = mod_version
group = mod_group_id

base {
    archivesName = mod_id
}

// Mojang ships Java 17 to end users in 1.18+, so your mod should target Java 17.
java.toolchain.languageVersion = JavaLanguageVersion.of(17)

println "Java: ${System.getProperty 'java.version'}, JVM: ${System.getProperty 'java.vm.version'} (${System.getProperty 'java.vendor'}), Arch: ${System.getProperty 'os.arch'}"
minecraft {
    // The mappings can be changed at any time and must be in the following format.
    // Channel:   Version:
    // official   MCVersion             Official field/method names from Mojang mapping files
    // parchment  YYYY.MM.DD-MCVersion  Open community-sourced parameter names and javadocs layered on top of official
    //
    // You must be aware of the Mojang license when using the 'official' or 'parchment' mappings.
    // See more information here: https://github.com/MinecraftForge/MCPConfig/blob/master/Mojang.md
    //
    // Parchment is an unofficial project maintained by ParchmentMC, separate from MinecraftForge
    // Additional setup is needed to use their mappings: https://parchmentmc.org/docs/getting-started
    //
    // Use non-default mappings at your own risk. They may not always work.
    // Simply re-run your setup task after changing the mappings to update your workspace.
    mappings channel: mapping_channel, version: mapping_version

    // When true, this property will have all Eclipse/IntelliJ IDEA run configurations run the "prepareX" task for the given run configuration before launching the game.
    // In most cases, it is not necessary to enable.
    // enableEclipsePrepareRuns = true
    // enableIdeaPrepareRuns = true

    // This property allows configuring Gradle's ProcessResources task(s) to run on IDE output locations before launching the game.
    // It is REQUIRED to be set to true for this template to function.
    // See https://docs.gradle.org/current/dsl/org.gradle.language.jvm.tasks.ProcessResources.html
    copyIdeResources = true

    // When true, this property will add the folder name of all declared run configurations to generated IDE run configurations.
    // The folder name can be set on a run configuration using the "folderName" property.
    // By default, the folder name of a run configuration is the name of the Gradle project containing it.
    // generateRunFolders = true

    // This property enables access transformers for use in development.
    // They will be applied to the Minecraft artifact.
    // The access transformer file can be anywhere in the project.
    // However, it must be at "META-INF/accesstransformer.cfg" in the final mod jar to be loaded by Forge.
    // This default location is a best practice to automatically put the file in the right place in the final jar.
    // See https://docs.minecraftforge.net/en/latest/advanced/accesstransformers/ for more information.
    accessTransformer = file('src/main/resources/META-INF/accesstransformer.cfg')

    // Default run configurations.
    // These can be tweaked, removed, or duplicated as needed.
    runs {
        // applies to all the run configs below
        configureEach {
            workingDirectory project.file('run')

            // Recommended logging data for a userdev environment
            // The markers can be added/remove as needed separated by commas.
            // "SCAN": For mods scan.
            // "REGISTRIES": For firing of registry events.
            // "REGISTRYDUMP": For getting the contents of all registries.
            property 'forge.logging.markers', 'REGISTRIES'

            // Recommended logging level for the console
            // You can set various levels here.
            // Please read: https://stackoverflow.com/questions/2031163/when-to-use-the-different-log-levels
            property 'forge.logging.console.level', 'debug'
            
            property 'mixin.env.remapRefMap', 'true'
            property 'mixin.env.refMapRemappingFile', "${projectDir}/build/createSrgToMcp/output.srg"

            mods {
                "${mod_id}" {
                    source sourceSets.main
                }
            }
        }

        client {
            // Comma-separated list of namespaces to load gametests from. Empty = all namespaces.
            property 'forge.enabledGameTestNamespaces', mod_id
        }

        server {
            property 'forge.enabledGameTestNamespaces', mod_id
            args '--nogui'
        }

        // This run config launches GameTestServer and runs all registered gametests, then exits.
        // By default, the server will crash when no gametests are provided.
        // The gametest system is also enabled by default for other run configs under the /test command.
        gameTestServer {
            property 'forge.enabledGameTestNamespaces', mod_id
        }

        data {
            // example of overriding the workingDirectory set in configureEach above
            workingDirectory project.file('run-data')

            // Specify the modid for data generation, where to output the resulting resource, and where to look for existing resources.
            args '--mod', mod_id, '--all', '--output', file('src/generated/resources/'), '--existing', file('src/main/resources/')
        }
    }
}

// Include resources generated by data generators.
sourceSets.main.resources { srcDir 'src/generated/resources' }

repositories {
    // Put repositories for dependencies here
    // ForgeGradle automatically adds the Forge maven and Maven Central for you

    // If you have mod jar dependencies in ./libs, you can declare them as a repository like so.
    // See https://docs.gradle.org/current/userguide/declaring_repositories.html#sub:flat_dir_resolver
    // flatDir {
    //     dir 'libs'
    // }
    
    maven {
        // location of the maven that hosts JEI files before January 2023
        name = "Progwml6's maven"
        url = "https://dvs1.progwml6.com/files/maven/"
    }
    maven {
        // location of the maven that hosts JEI files since January 2023
        name = "Jared's maven"
        url = "https://maven.blamejared.com/"
    }
    maven {
        // location of a maven mirror for JEI files, as a fallback
        name = "ModMaven"
        url = "https://modmaven.dev"
    }
}

dependencies {
    // Specify the version of Minecraft to use.
    // Any artifact can be supplied so long as it has a "userdev" classifier artifact and is a compatible patcher artifact.
    // The "userdev" classifier will be requested and setup by ForgeGradle.
    // If the group id is "net.minecraft" and the artifact id is one of ["client", "server", "joined"],
    // then special handling is done to allow a setup of a vanilla dependency without the use of an external repository.
    minecraft "net.minecraftforge:forge:${minecraft_version}-${forge_version}"

    // Example mod dependency with JEI - using fg.deobf() ensures the dependency is remapped to your development mappings
    // The JEI API is declared for compile time use, while the full JEI artifact is used at runtime
    // compileOnly fg.deobf("mezz.jei:jei-${mc_version}-common-api:${jei_version}")
    // compileOnly fg.deobf("mezz.jei:jei-${mc_version}-forge-api:${jei_version}")
    // runtimeOnly fg.deobf("mezz.jei:jei-${mc_version}-forge:${jei_version}")

    // Example mod dependency using a mod jar from ./libs with a flat dir repository
    // This maps to ./libs/coolmod-${mc_version}-${coolmod_version}.jar
    // The group id is ignored when searching -- in this case, it is "blank"
    // implementation fg.deobf("blank:coolmod-${mc_version}:${coolmod_version}")

    // For more info:
    // http://www.gradle.org/docs/current/userguide/artifact_dependencies_tutorial.html
    // http://www.gradle.org/docs/current/userguide/dependency_management.html
    annotationProcessor 'org.spongepowered:mixin:0.8.5:processor'
    
    compileOnly(fg.deobf("mezz.jei:jei-${minecraft_version}-common-api:${jei_version}"))
    compileOnly(fg.deobf("mezz.jei:jei-${minecraft_version}-forge-api:${jei_version}"))
    // at runtime, use the full JEI jar for Forge
    runtimeOnly(fg.deobf("mezz.jei:jei-${minecraft_version}-forge:${jei_version}"))
}

mixin {
    // MixinGradle Settings
    add sourceSets.main, mod_mixin_refmap_file
    config mod_mixin_file
}

// This block of code expands all declared replace properties in the specified resource targets.
// A missing property will result in an error. Properties are expanded using ${} Groovy notation.
// When "copyIdeResources" is enabled, this will also run before the game launches in IDE environments.
// See https://docs.gradle.org/current/dsl/org.gradle.language.jvm.tasks.ProcessResources.html
tasks.named('processResources', ProcessResources).configure {
    var replaceProperties = [
            minecraft_version: minecraft_version, minecraft_version_range: minecraft_version_range,
            forge_version: forge_version, forge_version_range: forge_version_range,
            loader_version_range: loader_version_range,
            mod_id: mod_id, mod_name: mod_name, mod_license: mod_license, mod_version: mod_version,
            mod_authors: mod_authors, mod_description: mod_description,
    ]
    inputs.properties replaceProperties

    filesMatching(['META-INF/mods.toml', 'pack.mcmeta']) {
        expand replaceProperties + [project: project]
    }
}

// Example for how to get properties into the manifest for reading at runtime.
tasks.named('jar', Jar).configure {
    manifest {
        attributes([
                'Specification-Title'     : mod_id,
                'Specification-Vendor'    : mod_authors,
                'Specification-Version'   : '1', // We are version 1 of ourselves
                'Implementation-Title'    : project.name,
                'Implementation-Version'  : project.jar.archiveVersion,
                'Implementation-Vendor'   : mod_authors,
                'Implementation-Timestamp': new Date().format("yyyy-MM-dd'T'HH:mm:ssZ"),
                'MixinConfigs': mod_mixin_file
        ])
    }

    // This is the preferred method to reobfuscate your jar file
    finalizedBy 'reobfJar'
}

tasks.withType(JavaCompile).configureEach {
    options.encoding = 'UTF-8' // Use the UTF-8 charset for Java compilation
}

gradle.properties

# Sets default memory used for gradle commands. Can be overridden by user or command line properties.
# This is required to provide enough memory for the Minecraft decompilation process.
org.gradle.jvmargs=-Xmx3G
org.gradle.daemon=false


## Environment Properties

# The Minecraft version must agree with the Forge version to get a valid artifact
minecraft_version=1.20.1
# The Minecraft version range can use any release version of Minecraft as bounds.
# Snapshots, pre-releases, and release candidates are not guaranteed to sort properly
# as they do not follow standard versioning conventions.
minecraft_version_range=[1.20.1,1.21)
# The Forge version must agree with the Minecraft version to get a valid artifact
forge_version=47.2.23
# The Forge version range can use any version of Forge as bounds or match the loader version range
forge_version_range=[47,)
# The loader version range can only use the major version of Forge/FML as bounds
loader_version_range=[47,)
# The mapping channel to use for mappings.
# The default set of supported mapping channels are ["official", "snapshot", "snapshot_nodoc", "stable", "stable_nodoc"].
# Additional mapping channels can be registered through the "channelProviders" extension in a Gradle plugin.
#
# | Channel   | Version              |                                                                                |
# |-----------|----------------------|--------------------------------------------------------------------------------|
# | official  | MCVersion            | Official field/method names from Mojang mapping files                          |
# | parchment | YYYY.MM.DD-MCVersion | Open community-sourced parameter names and javadocs layered on top of official |
#
# You must be aware of the Mojang license when using the 'official' or 'parchment' mappings.
# See more information here: https://github.com/MinecraftForge/MCPConfig/blob/master/Mojang.md
#
# Parchment is an unofficial project maintained by ParchmentMC, separate from Minecraft Forge.
# Additional setup is needed to use their mappings, see https://parchmentmc.org/docs/getting-started
mapping_channel=parchment
# The mapping version to query from the mapping channel.
# This must match the format required by the mapping channel.
mapping_version=2023.09.03-1.20.1


## Mod Properties

# ...

## JEI Properties
jei_version=15.3.0.8

Description

For some reason Eclipse seems to reference the official mappings in the editor, although the parchment mappings are used to compile and debug (But the source text is still from the original mappings).

I have tried looking up explanations and haven't found any, so I am hoping on some help/luck here.

The official mappings show up in the Project & External Dependencies Tab

But the parchment mappings show up in the referenced libraries:

But parchment mappings are loaded during runtime (but eclipse still uses the official mappings as source)

Minecraft version: 1.16.5
Mappings version: 2021.08.29
Librarian version: 1.1.4

In ITextProperties (FormattedText with mojmap) the method of(String, Style) contains an anonymous class where the parameter pStyle from the method in ITextProperties conflicts with a parameter from a method inside the anonymous class. This causes all style information including click and hover events to be missing from the chat ingame. This is becasue instead of the style from the formatted text being merged onto the base style, the base style is merged onto itself.

Discussion in internal channels have determined consensus for the following actions:

• Remove the requirement of the p prefix in the mapping standards for parameter names (namely, #2, #6, #8).
• Remove the p prefix in the repository data.
• Have two exports: the main prefixed version (prefixing all parameter names with p and capitalizing the second letter), and a non-prefixed version (the raw parameter names).

This was driven and supported by the following reasons:

• Users would rather prefer using parameter names which do not have a mandatory prefix, for readability purposes.
• The original reason for the prefix was to prevent conflicts between the parameter names and local variable names (as determined by the decompiler). However, loaders may choose to do their own adjustments to ensure that parameter names do not conflict with the parameter names, which would not be difficult to do.
  • Additionally, it is usually rare that a local variable will conflict to a parameter name, as usually local variable names outputted by decompilers are in a deterministic and simplisitic format.
• Contribution to parameter names would be easier without needing to keep in mind the p prefix.
• Parameter names are simple enough (as constrained by the standards) that auto-prefixing of the data with p is very possible.

While the possibility of exporting only a non-prefixed version of the data was discussed, one of the goals of the exports is that they are 'working mappings', in that they do not need modification by the loaders/consumers to ensure they work as the p prefix ensures that it never matches any decompiler's output for local variables, whereas the unprefixed names have a possibility of conflicting with decompiler output. Therefore, we will export both a prefixed and non-prefixed version, and loaders can opt to use the non-prefixed version if they chooose to do so.

One further question that needs to be addressed is how to publish the unprefixed version. There are two possbilities: exporting it as a separate artifact under a different classifier (possibly even being the no classifier version), or exporting it as an additional file in the no classifier artifact (possibly under the file name of unprefixed.json).

It is difficult to programatically determine available minecraft versions for parchment. it would be great if there was a file somewhere on the maven containing supported minecraft versions.
I'm thinking somewhere like org/parchmentmc/data/parchment-versions.json
and the contents would be something like

[
 "1.16.5", "1.17", "1.17.1"
]

Minecraft version: 1.20.6
Mappings version: 2024.06.16

A lot of mappings are missing in the Gui.java class such as p_333627_ aswell as many more

You might need to port to 1.19 because there is already Forge 1.19 which just took a few hours for them to port to 1.19 along with Fabric so they can still use it in 1.19.

Just happened now, was working before

Hello!

I recently went through learning about parchment and setting it up on my project and I have some feedback about minor roadblocks I hit.

The first place I landed was https://parchmentmc.org/ but I found it difficult to understand what Parchment was, and there was no way for me see how to set it up in my project. It actually took some digging through GitHub and other places before I found out how to set it up, and I never found information about what exactly it accomplishes or what its limitations are.

It seems like the current information is optimized for contributors, but I think at this stage it should shift to focus primarily on users.

I think the most streamlined experience would be a simple-to-understand "before and after" screenshot of your IDE where you have messed up parameter names, and then tada parchment is added and you can understand.
Then, jump right into the wiki on setting up your build.gradle.
I think that's all a user needs to get on board, everything else is icing on top and people can get funneled there as they dig deeper.

Thanks for the mappings!

Minecraft version: 1.19.2
Mappings version: 2022.09.18

The javadoc says "it will drop teh item", this should probably be "it will drop the item"
I believe this is the line to blame:

Do you think it would be feasible to add the inofficial docs for codecs to Parchment?
https://kvverti.github.io/Documented-DataFixerUpper/snapshot/com/mojang/serialization/Codec.html

Since codecs are such a complicated topic and not really beginner-friendly for new modders, I think some docs would be very helpful.

Needs mappings update for 22w43a or beyond. I porting Polymorph mod for latest snapshot of Minecraft. Some mappings are incorrect or still obfuscated.

Currently, we are considering the use of Enigma as a user-friendly interface for inputting mappings. This has been used to great success by Fabric's Yarn mapping project, and would mean that we are able to use code which has been tested to work (rather than rolling our own solution).

However, there are two things (to my knowledge) which are currently blocking our adoption of the tool: restricting Enigma to only allow parameter names and documentation (which is a task that's being worked upon), and using a format which Enigma understands. Of revelance to this repository is the second point.

To resolve the second point, we have three options:

1. Modify Enigma to support the Parchment mapping data format. This would mean PRing these changes upstream, or maintaining a custom fork of Enigma which adds support for our format.

   The second choice would add a burden of maintenance on ParchmentMC's development team which would potentially mean that we would have to closely look at FabricMC/Enigma and rebase our changes constantly. For long-term maintainability, this is not preferred.

2. Create intermediate tasks which transform the data in our repository to a format understood by Enigma and back again to our own mapping data format.

   This represents a compromise between changing our data format, and being able to use Enigma. This also means we can potentially reuse the inputs systems to read in the data. However, this adds an not-insignificant cost to contributing (once which is already compounded by our whole inputs system and Gradle task chain), which may discourage small contributions on the basis of too much work involved.

3. Move the data in-repository to the Enigma file format, natively understood by Enigma and specifically designed for storing data in git repositories.

   This would necessitate moving all the current data across our two branches to the new format, and implementing support for the format in Compass (so that it can run validations and export the data). However, this gives the advantages of: using Enigma without any modifications on the format front, using a tried and tested (by the Yarn mapping project) mapping format which is designed for ease of storage and mergability in a Git repository, and would remove some undesired artifacts in our current mode of storage (such as pure additions in terms of data requiring a line deletion due to comma placement).

As the issue title suggests, I am leaning towards moving the repository to the Enigma mapping format instead of introducing overhead via intermediate tasks, which also grants us the benefits of the format (such as merge conflicts being easy to fix).

[Elaborate on what change should be made to the mapping standards or processes, and why.]

Hello.
Could you please add a release for 1.19?
Thnaks

Minecraft version: 1.19
Mappings version: 2023.06.25-1.19.3

if i try to do () -> new Item(new Item.Properties() and then .tab it does not work and instead i have to use m_41491_

Minecraft version: 1.20.6
Mappings version: 2024.05.01

public void renderLevel(
        float pPartialTick,
        long pNanoTime,
        boolean pRenderBlockOutline,
        Camera pCamera,
        GameRenderer pGameRenderer,
        LightTexture pLightTexture,
        Matrix4f pProjectionMatrix,
        Matrix4f pFrustrumMatrix
    )

pProjectionMatrix is pFrustrumMatrix and pFrustrumMatrix is pProjectionMatrix