frozen ether
It takes AGES to make a setup like this - and most of the time? You have to make debug names that you either leave in the pack, or remove.
Can the various random features in the mods please detect flags we can add to entities we spawn in with commands? Something like "etfskin=1, emfmodel=43" etc, to bypass the randomness for our own galleries, to view the various entity variants we add?
To a similar degree, it was also present here. The gold and fiery owls had to be picked from a massive pool of spawned-in owls, then moved into location. The rest, culled.
somber falcon
I don't really see the point in this. You don't really know if it's working unless you set it up properly
Have you tried using /fillbiome?
It takes almost no time
As for rare variants, just change the weights
Or, as you said, debug names. The only real reason for this is to be able to show them all off together, so changing the weights should work
frozen ether
Have you tried using `/fillbiome`?
yes, but the biomes are nebulous clumpy areas. But even so, the main reason is yes, trying to test things out. to specify the precise model and texture for diagnosis and display.
frozen ether
Or, as you said, debug names. The only real reason for this is to be able to sho...
the issue is, for these to take priority, they need to be at the top of the file. but files are read top to bottom, and ETF/EMF has taken the decision to kneecap itself, demanding sequential argument listing.
so every new argument could be ages and ages of tedious editing
I have a creeper properties file that is 68 cases long. each one has 2 or 3 arguments. so that is around 170 numbers to manually edit, every time I want to add a debug variant. every. time.
my test world stretches out far, far into the distance in order to try to contain a sample of each biome - and it's not even a clean even distribution as biomes are nebulous.
somber falcon
so every new argument could be ages and ages of tedious editing
Not really
Duplicate the main folder, change the extension to "txt" or "disabled" or whatever, and then modify the duplicate to be a good testing file
As for the biome issue, just use blocks specific to what you want it to be and always fill from bottom of the world to top
frozen ether
Duplicate the main folder, change the extension to "txt" or "disabled" or whatev...
this opens the gates to make mistakes. if I do this, I am maintaining 2 branches of the same resource pack. the textures may be different, fixes may not carry over, it'll be a complete mess.
frozen ether
As for the biome issue, just use blocks specific to what you want it to be and a...
Copy/paste doesn't account for rewrites due to larger-scale entity updates. As for biomes, unsure what you mean. All I know is this is my current setup, and it's just ungodly huge.
I just feel a specific argument baked into the mod to change texture/model version based on a unique identifier would be exceptionally useful to those developing these packs.
Case in point, I have a Herobrine creeper. Which is to say, a creeper that looks like herobrine from afar, but looks like a creeper up close. If I add a debug, I need to remove the debug after, and also redo all of those 170 numbers. I could try to use a second resource pack, but I'd never be entirely sure if everything is up to date for my pack in the main branch
having arguments for debug built into the main ETF/EMF mod for resource pack creators would be absolutely perfect. It removes needing to add debug arguments, all of the argument renaming necessary to add/remove those debug arguments and also maintaining 2 branches of the resource pack.
all replaced with adding a simple component tag to the mob. a system that all of Minecraft is currently pivoting towards
somber falcon
What 😭
Component tags are server-side
Making client-side components would be horrific
Components also aren't a thing for entities
Entities use NBT still, which are also server-side
I could see maybe a /texture apply command but even then that'd be low priority because of how easy it is to make a .properties file for debugging
If testing and showing off textures is something you often do, I'd recommend making the .properties for showing off textures in tandem with making the base one. It doesn't take twice as long, just for the debug one you're using a name property
frozen ether
Component tags are server-side
I could add any data to an entity from what I understand, even if unused. either way, we have control over adding a small custom bit of code to entities that etf/emf could read. something that could negate any need for any rewrite, dual-write or the like system, so I know the pack I release is visually functional. technically functional is a pain I can deal with some other way - and would need to do so even if a debug system existed or not.
somber falcon
I could add any data to an entity from what I understand, even if unused. either...
Yes that data you add is server-side
And can't be read by the client
That's why for datapacks you have to use the team feature to have your datapack stuff read by EXF mods
It's one of the only command-driven things that can just be read by the client
frozen ether
And can't be read by the client
I don't understand, is the entity data cut up and sent piecemeal or selectively? Doesn't the server send the entire entity's data to the client?
somber falcon
No it sends whatever data is necessary
Mojang and server mods dictate what data is client-necessary afaik
That's why hack mods that send "all NBT to the client" never send all NBT to the client
They just send in chat what the client was already receiving
The more data of an entity you want, the heavier that packet is. They limit the data sent to the client to avoid making heavy packets that are taxing on servers