Here's the message:
In material "mario_hand", a texture has not been set.
And the problem is, I DID set a texture for it.

Hello so while bug #83 got fixed in Blender 3.1.0 it still seems to be sometimes randomly showing up for example when clicking on create Material it sometimes throw the error of #83 which seems to happen due to Fast64 for whateveer reason choosing instead of the Normal SM64 Shaded Solid to use a Custom Preset and it also has bugs with textures by for example rendering my 32x32 Texture in complete black even tho i assigned it already

I get this error when doing the install for the fast64 plugin
i just did a fresh install of blender3.4.1 and new download of the plugin

Traceback (most recent call last):
File "C:\Program Files\Blender Foundation\Blender 3.0\3.0\scripts\modules\addon_utils.py", line 351, in enable
mod = import(module_name)
File "C:\Users\robin\AppData\Roaming\Blender Foundation\Blender\3.0\scripts\addons\fast64-main_init_.py", line 4, in
from .fast64_internal.operators import AddWaterBox
File "C:\Users\robin\AppData\Roaming\Blender Foundation\Blender\3.0\scripts\addons\fast64-main\fast64_internal_init_.py", line 1, in
from .f3d_material_converter import *
File "C:\Users\robin\AppData\Roaming\Blender Foundation\Blender\3.0\scripts\addons\fast64-main\fast64_internal\f3d_material_converter.py", line 5, in
from .f3d.f3d_material import *
File "C:\Users\robin\AppData\Roaming\Blender Foundation\Blender\3.0\scripts\addons\fast64-main\fast64_internal\f3d_init_.py", line 1, in
from .f3d_parser import *
File "C:\Users\robin\AppData\Roaming\Blender Foundation\Blender\3.0\scripts\addons\fast64-main\fast64_internal\f3d\f3d_parser.py", line 4, in
from .f3d_gbi import *
File "C:\Users\robin\AppData\Roaming\Blender Foundation\Blender\3.0\scripts\addons\fast64-main\fast64_internal\f3d\f3d_gbi.py", line 5, in
from ..utility import *
File "C:\Users\robin\AppData\Roaming\Blender Foundation\Blender\3.0\scripts\addons\fast64-main\fast64_internal\utility.py", line 1453
match context.scene.gameEditorMode:
^
SyntaxError: invalid syntax

OOT_ObjectProperties right now uses an IntProperty to hold its current version. However, in Blender, properties whose values haven't been changed from the defaults do not preserve their values when the default is changed. I haven't checked in depth, but I think SM64 also has this issue. For data added through operators this isn't an issue as the version can be set on creation (ex. F3D material creation), but if a user creates empties without using Fast64 operators, then the version will not be preserved on future updates.

Too many connecting vertices in skinned triangles for bone '000-offset.001'. Max is 14 on parent bone, currently at 21. Note that a vertex with different UVs/normals/materials in connected faces will count more than once. Try keeping UVs contiguous, and avoid using split normals.

im making a mod called Wonder96 dynos pack for mario 64 but I get this issue everytime I export

The nodes are duplicated, which makes SceneProperties get imported as SceneProperties.001. So if you do something like disable fog preview it won't work.

idk what the issue is I downloaded the same mario blend but still the same

I just press the button and this error shows up

Due to my computer being weak, I can't load the materials tab (or view materials) or it crashes. I would like to be able to have the materials in collision export in order like iProgramInCpp's EasyExporter:

// Material.006 Material...
COL_TRI_INIT(SURFACE_DEFAULT, 3),
COL_TRI(7,3,1),
COL_TRI(173,169,167),
COL_TRI(189,185,183),
// Material.007 Material...
COL_TRI_INIT(SURFACE_DEFAULT, 2),
COL_TRI(50,54,52),
COL_TRI(55,51,49),
// Material.008 Material...
COL_TRI_INIT(SURFACE_DEFAULT, 4),
COL_TRI(48,49,51),
COL_TRI(50,51,55),
COL_TRI(54,55,53),
COL_TRI(52,53,49),
// Material.009 Material...

It would be useful for editing manually since I'm kinda used to it at this point, and it'd prevent me from having to rely on other tools or ask others to help with it.

Hello so i have an issue when exporting the LowPolySkinnedMario.blend to a Binary Rom the weird thing is that it gives an error even tho exporting the armature work without any issue idk if this a part of my end or a bug in the tool :(

  File "/home/daria/.config/blender/3.0/scripts/addons/fast64-main/fast64_internal/sm64/sm64_geolayout_writer.py", line 2239, in execute
    addrRange, segPointer = exportGeolayoutObjectBinary(
  File "/home/daria/.config/blender/3.0/scripts/addons/fast64-main/fast64_internal/sm64/sm64_geolayout_writer.py", line 595, in exportGeolayoutObjectBinary
    return saveGeolayoutBinary(romfile, geolayoutGraph, fModel, exportRange,
  File "/home/daria/.config/blender/3.0/scripts/addons/fast64-main/fast64_internal/sm64/sm64_geolayout_writer.py", line 612, in saveGeolayoutBinary
    geolayoutGraph.save_binary(romfile, levelData)
  File "/home/daria/.config/blender/3.0/scripts/addons/fast64-main/fast64_internal/sm64/sm64_geolayout_classes.py", line 130, in save_binary
    geolayout.save_binary(romfile, segmentData)
  File "/home/daria/.config/blender/3.0/scripts/addons/fast64-main/fast64_internal/sm64/sm64_geolayout_classes.py", line 191, in save_binary
    romfile.write(self.to_binary(segmentData))
  File "/home/daria/.config/blender/3.0/scripts/addons/fast64-main/fast64_internal/sm64/sm64_geolayout_classes.py", line 185, in to_binary
    data += node.to_binary(segmentData)
  File "/home/daria/.config/blender/3.0/scripts/addons/fast64-main/fast64_internal/sm64/sm64_geolayout_classes.py", line 310, in to_binary
    data.extend(child.to_binary(segmentData))
  File "/home/daria/.config/blender/3.0/scripts/addons/fast64-main/fast64_internal/sm64/sm64_geolayout_classes.py", line 300, in to_binary
    data = self.node.to_binary(segmentData)
  File "/home/daria/.config/blender/3.0/scripts/addons/fast64-main/fast64_internal/sm64/sm64_geolayout_classes.py", line 762, in to_binary
    command.extend(encodeSegmentedAddr(start_address, segmentData))
  File "/home/daria/.config/blender/3.0/scripts/addons/fast64-main/fast64_internal/utility.py", line 1043, in encodeSegmentedAddr
    segment = getSegment(address, segmentData)
  File "/home/daria/.config/blender/3.0/scripts/addons/fast64-main/fast64_internal/utility.py", line 1054, in getSegment
    raise PluginError("Address " + hex(address) + \
TypeError: 'str' object cannot be interpreted as an integer```

I keep getting this error when i try to export to C, and i have no idea why. please get back to me ASAP.

So, I was trying to remove all of the Toad model's polygons so that it wouldn't appear in-game. I wanted the ROM to be compatible with other Super Mario 64 tools, so I set the Import/Export options to Binary. I was able to successfully import and edit the model, but once I go to export it, it gives me this error:
"Size too big: Data ends at 0x1e51e0, which is larger than the specified range."
What does this mean, and how do I fix it?

I know binary exporting is an abandoned thing but it's pretty useful to me
I've been trying to find the koopa's (with a shell) geolayout's start (and end) address for binary exporting.
I've got the model object and the level script address but I;ve been trying to get the start addresses but it just says the address is not provided in any of the segments.

Is there a way how to do this?

Apparently when empties are scaled with negative values it messes up the rotation export

This is probably not a fast64 bug itself but a warning would help immensely (there is no use case for negative scales on empties anyway)

Thanks to HailToDodongo for locating the issue in a blend from xDynasty

https://discord.com/channels/874816709855440926/874819026629574717/1130054574246461550

used blender 4.0 and blender 3.6.5 and got the same result.

How to reproduce:

• new blender file
• click "Add Scene" tool
• delete the plane mesh object (or unparent it from the room empty)
• export the scene

-> undescriptive error happens

instead fast64 should either print a legible error, or allow exporting rooms without any geometry attached

Hello so this happened fairly recently aka an hour ago :P basically i clicked like i normally would on the create F3D Material and all i got was this error tho while i can still use blender the texture is all black :( its a 12x812 texture tho i even large texture mode doesnt make help it :( oh btw im on blender 3.1.0 so that may be the issue >.>

EDIT: im also getting an bpy_prob_collection[index]: index 0 out of range, size 0

which also happens with 32x32 Textures now :(

It seems the decomp file now has a directory within the build folder called gc-eu-mq-dbg
This seems to be breaking fast64's exports. I think this needs to be updated, I am very new to this and
am not sure if I am correct here, but after I export a scene I need to copy the contents of gc-eu-mq-dbg into
build (along side gc-eu-mq-dbg), and everything builds again.

If I am on the correct track, Let me know and I would love to try to fix this :)

Traceback (most recent call last):
File "C:\Users\teste\AppData\Roaming\Blender Foundation\Blender\3.2\scripts\addons\fast64\fast64_internal\sm64\sm64_geolayout_writer.py", line 3084, in execute
exportGeolayoutArmatureInsertableBinary(
File "C:\Users\teste\AppData\Roaming\Blender Foundation\Blender\3.2\scripts\addons\fast64\fast64_internal\sm64\sm64_geolayout_writer.py", line 805, in exportGeolayoutArmatureInsertableBinary
saveGeolayoutInsertableBinary(geolayoutGraph, fModel, filepath, f3dType)
NameError: name 'f3dType' is not defined

okay so this is a thing that has been happening for a lot of months now that i have been struggling at getting to fix myself mainly due to my misunderstanding of certain N64 aspects anyways so basically what happens is trying to export the Mario Model inside the "LowPolySkinnedMario_V5.blend" File to any Super Mario 64 Repo so far i tried with sm64, ultrams64 and HackerSM64 with all of these causing issues with Mario being displayed as almost white?
So far from what i looked it seems nothing was noted regarding this anywhere in the README which is kinda bad as the Blend file is literally packed with every Single Fast64 Release

idk

Hello so the title explain the main issue so here is my Level

This Level ofc now work inside the Game itself but it required me to flip all my Faces

as you can see its impossible to work and edit this Model

This is for example how it normally looks when using the Face Oration where i can actually see Stuff inside Blender and which the Level was built with and what happens ingame

So i tried both the source zip and the releases zip but none of those installed.

They are currently not. So hiding a collection will cause everything in it to not get included with the export.

original report from discord:

Blender Version: 3.0.1
Game: OoT
Reproduction steps: Make a scene and hide the collection it's in and try to export it. receive errors 
Issue: Is there a way to have Fast64 still include things in exports if they are not visible in the viewport?
I am working on a gigantic scene now and keep most of my collections hidden as I complete work on them.
but ofc every time I want to export I need to unhide everything, export, re-hide. I have the
"export hidden geometry" option turned on.

Happens fer most .blend files that come with Fast64, specifically the Mario .blend, and the two Skinned Mario .blends, and also .blends that used the older 1.0 version. Ya export the armature geolayout and this happens.

Now that Ship of Harkinian has mod support, is there a chance of SoH being supported in Fast64? I'm aware of the SoH-specific branch, however it hasn't been updated in some time and breaks some features such as masks and boots.

• Parse header and create a scene empty with all the same properties
• Support alternate headers on import when creating the empty
• Reuse the code for not duplicating materials that is used in skelanime
• Make sure displaylists are imported on the correct draw layer
• When importing displaylists, disable collision on them
• Create a separate object for collision and disable rendering on it, and just make a different material for each polygon type

For some reason, Blender 3.0 always throws the following dialog when I try to enable Fast64.

The following appears in the console as well:

Python: Traceback (most recent call last):
  File "C:\Users\cratt\AppData\Roaming\Blender Foundation\Blender\3.0\scripts\addons\fast64-main\fast64_internal\f3d\f3d_material.py", line 1025, in draw
    elif not(material.use_nodes and material.is_f3d):
AttributeError: 'Material' object has no attribute 'is_f3d'

location: <unknown location>:-1
Exception in module register(): C:\Users\cratt\AppData\Roaming\Blender Foundation\Blender\3.0\scripts\addons\fast64-main\__init__.py
Traceback (most recent call last):
  File "C:\Program Files (x86)\Steam\steamapps\common\Blender\3.0\scripts\modules\addon_utils.py", line 387, in enable
    mod.register()
  File "C:\Users\cratt\AppData\Roaming\Blender Foundation\Blender\3.0\scripts\addons\fast64-main\__init__.py", line 324, in register
    mat_register()
  File "C:\Users\cratt\AppData\Roaming\Blender Foundation\Blender\3.0\scripts\addons\fast64-main\fast64_internal\f3d\f3d_material.py", line 3179, in mat_register
    return os.path.join(presetPath, filename) + ".py"
ValueError: register_class(...): already registered as a subclass 'F3DNodeA'

The max length can be changed in code so #172 turned the export error into a UI warning to make fast64 "compatible" with such changes

It may be a good idea to allow some of

• disable the UI warning
• change the max length
• take into account other factors to compute the max length (like a subkeep object being used or not)

when i try to export my custom mario model it gives me this error:
Size too big: Data ends at 0x122c600, which is larger than the specified range.

and when i put a normal rom with 8 mb it says it's very small but when i expand the rom it dosen't work and it gives me that error

pls help

Found out that on the recent fast64 builds don't boot due to an import error because in the utility.py it has the name? indent

Saving a blend file with Fast64 materials and re-opening it just crashes outright a fresh install of Blender 3.3.5 .

After some analysing, the issue seems to come from the Fast3D Library .blend file trying to load at boot.
It works the first time on an empty file, but the second time the loading path gets messed up and Blender crashes.

For example, it tries loading the library .blend file from C:\Users\Melon\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\fast64-main\fast64_internal\f3d\f3d_material_library.blend even though I installed the plugin locally in a folder on my desktop in my portable Blender install. It's also trying to load from the wrong version of Blender. (4.0 as opposed to 3.3.5)

PS: Modifying the plugin so it doesn't load the Library .blend file allows the file to load properly. But materials will be missing.

As suggested by #73, let's use black.

This is ongoing WIP, as PRs touch files

I got this weird error message saying "Cannot find level empty" whenever exporting some custom levels into decomp? so any fix this?

Using OoT here, probably same for others
Blender 4.0.2 (which is most likely unrelated)

When creating a material, the preset shown is "Custom" instead of "OoT Shaded Solid", which was the value up until now

Fresh blend, fresh object and just freshly created material:

Though the preset shown is "Custom" it does seem the material is set up like "OoT Shaded Solid"

Bug introduced by #201 based on intuition and then testing before/after:

$ git checkout 3d6f73097482b9db460f4cb7737d7624a7bf6362^
HEAD is now at 4f621f4 Fixed large uv wrapping (#249)
# -> new materials are "OoT Shaded Solid"

$ git checkout 3d6f73097482b9db460f4cb7737d7624a7bf6362
HEAD is now at 3d6f730 Merge pull request #271 from sauraen/ShowFogFix
# -> new materials are "Custom"

Fast64 currently will not emulate frontface culling, I suggest using the backface culling value from the geometry node to clip the geometry (with alpha clip or something similar).
I am available to do testing on low end hardware if needed.
If this ends up not being viable, a warning would be sufficient.

I'm not able to access the original file on BitBucket.

All vertices must be part of a vertex group, be non-trivially weighted (> 0.4), and the vertex group must correspond to a bone in the armature.
Groups of the bad vert that don't correspond to a bone: ['000-displaylist']. If a vert is supposed to belong to this group then either a bone is missing or you have the wrong group.
Groups of the bad vert below weight limit: []. If a vert is supposed to belong to one of these groups then make sure to increase its weight.
I don't know what I am doing wrong I did everting correctly

To reproduce try to import a player anim, gPlayerAnim_link_fighter_upper_pierce_kiru_end works for this error, I searched a bit it and looks like negative numbers is the issue? I'm not sure how it is supposed to work though, hence this issue

The error is inside getFrameData (oot_anim.py) in the frameData list when it tries to convert the str to an int, when it's a negative number (like "-0x00A2") it's reading "x0" for the first int value inside from_bytes

Traceback (most recent call last):
  File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\fast64\fast64_internal\oot\animation\operators.py", line 172, in execute
    ootImportAnimationC(armatureObj, settings, actorScale)
  File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\fast64\fast64_internal\oot\animation\operators.py", line 97, in ootImportAnimationC
    ootImportLinkAnimationC(
  File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\fast64\fast64_internal\oot\oot_anim.py", line 528, in ootImportLinkAnimationC
    frameData = getFrameData(animFilepath, animData, frameDataName)
  File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\fast64\fast64_internal\oot\oot_anim.py", line 634, in getFrameData
    frameData = [
  File "C:\Users\Yanis\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\fast64\fast64_internal\oot\oot_anim.py", line 635, in <listcomp>
    int.from_bytes([int(value.strip()[2:4], 16), int(value.strip()[4:6], 16)], "big", signed=True)
ValueError: invalid literal for int() with base 16: 'x0'

Confirmed for at least scene importing, by ZeeRoX
I assume this bug generalizes to most (all?) imports

Even if data is commented out in a .c, it can still be imported by fast64.

I think this is kind of expected behavior from a code perspective since C parsing is entirely regex-based afaik,
but it's confusing from a user perspective

An easy solution may be to strip comments from source before parsing (note: some stuff relies on comments for parsing, like the sm64 "keep block" thing I forgot the name of, maybe other stuff)

Upon exporting a modified version of Mario's model to a new ROM of Super Mario 64, I learned quickly that I couldn't get into the game's intro cutscene. All sound works as intended, the code just seemingly freezes up when it has to load Mario's model. I could confirm the sound part by waiting until one of the demos played, and it was just a white screen with the title music playing. The game doesn't respond to my inputs after this. I got curious and tested it with just the default mario.blend file, and it still froze. I've confirmed that both the original and extended ROMs work just fine, so it must be a problem with the plugin. If needed, I can disclose where I got my ROM privately. I'm not a Python expert, so I can't describe exactly what's wrong, but if I had to guess, it has something to do with the export code. I have yet to try C exporting. I've followed the tutorial videos to a T, if that helps.
Extra info:

• Windows 10 Pro 21H2
• Blender v3.2.0
• Fast64 v2.0.0
• ROM Region/Version: USA v1.0

Basically, when i click the create new material button in f3d, it just gives an error and sometimes crashes, I'm on version 3.6 of blender, I don't know if I should have an older one or something like that, here's the error that appears.

Currently displaylists can't be imported in oot because fast64 does not support included .vtx.inc files. This should be fixed to be handled the same way as importing textures which are #include'd as well.

Currently with the way that fast64 is structured, the code for each game mode (currently just oot and sm64) is mostly completely independent of each other. Ideally the user interface would be restructured in such a way that merges the functionality of the two as much as possible, as well as the backend. This means making displaylist exporting etc be the same code between all games ideally. We can further discuss what changes might be good for the UI here as well.

I was trying to remesh Mario's geolayout, and when I exported it, I got this message. It doesn't tell me any information on it, either, not the object in question, not the image file, nothing. I even tried changing all of the texture materials and files to RGBA16, and that didn't fix the issue. What could be causing this?

It appears that Fast64 exports the ActorEntry playerEntryList, in the scene.c file, in a random order. However the ordering is actually critical because if the order is incorrect you will spawn at the wrong location.

The following is a blend file containing 4 entrances. (As requested by Dragon421)
git_hub_Blend.zip

help

Hello so i finnaly decided to get the latest Version of Fast64 and while everything work great i am having an issue sadly with Enabling it may be its amn issue on my End as my Blender Version is 3.0.1 and idk if yall support it yet but it kinda is stopping from working on my stuff :(

Oot map importer enables segments 8 9 and A for all materials on import causing crashes without spending 30 minutes figuring out the correct settings by hand.

In Z64, the components of the normal are stored as a value ranging between -32767 to 32767, representing the value range -1.0 to 1.0. This is NOT the same as the range of values that can possibly stored in a short (-32768 to 32767).

Fast64 incorrectly multiplies the normal by 2^15, which is 32768 and clamps it to the range of a short here:

I'm not sure if this is related in any way to the dynapoly bug since normals should be recomputed anyway.