#Technical blocks
1 messages ยท Page 4 of 1
this seems to work
Set<String> ignored = Set.of("facing", "horizontal_facing", "vertical_direction", "axis", "rotation", "east", "west", "south", "north");
List<ItemStack> itemStacks = blockItems.stream()
.flatMap(blockItem -> blockItem.getBlock().getStateManager().getStates().stream()
.map(state -> {
BlockStateComponent comp = new BlockStateComponent(BlockStateComponent.DEFAULT.properties());
for (Property<?> prop : state.getProperties()) {
if (!ignored.contains(prop.getName())) {
comp = comp.with(prop, state);
}
}
return Map.entry(blockItem, comp);
})
.filter(entry -> !entry.getValue().properties().isEmpty())
.distinct()
.map(entry -> {
ItemStack stack = new ItemStack(entry.getKey());
stack.set(DataComponentTypes.BLOCK_STATE, entry.getValue());
stack.set(DataComponentTypes.ITEM_NAME, Text.literal(entry.getValue().toString()));
return stack;
}))
.toList();
follow order
i should really cache it
ItemTooltipCallback.EVENT.register((itemStack, context, type, textList) -> {
NbtComponent component = itemStack.get(DataComponentTypes.CUSTOM_DATA);
if (component != null && component.contains(MOD_ID + "_tooltip")) {
BlockStateComponent blockStateComponent = itemStack.get(DataComponentTypes.BLOCK_STATE);
if (blockStateComponent != null) {
blockStateComponent.properties().forEach((propName, propValue) -> {
Text text = Text.literal(propName + ": " + propValue).formatted(Formatting.GRAY);
textList.add(1, text);
});
}
}
});
i not only add the blockstate but also a tiny nbt
just to know its from my mod
ItemStack stack = new ItemStack(entry.getKey());
stack.set(DataComponentTypes.BLOCK_STATE, entry.getValue());
NbtCompound nbtCompound = new NbtCompound();
nbtCompound.putBoolean(MOD_ID + "_tooltip", true);
stack.set(DataComponentTypes.CUSTOM_DATA, NbtComponent.of(nbtCompound));
i pushed the commits to github
next step is
to update this mod
i have some work to do
so i can't do it rn
maybe tomorrow
wow it needs architectury
and uses mojang mappings
Arch loom, or architectury?
Architectury
Fun
it's not
that tiny of a mod
to port
๐
plugins {
id "architectury-plugin" version "3.4-SNAPSHOT"
id "dev.architectury.loom" version "1.7-SNAPSHOT" apply false
}
upstream repository might be dead
so i have to learn to jar in jar
using gradle 8.8
and somehow it's failing on project :fabric
The authors have been very busy. Afaik, it's not dead, they just had bigger problems
With what?
yes
suppose so
everyone is busy
Configure project :
Architect Plugin: 3.4.161
Architectury Loom: 1.10.431
This version of Architectury Loom is in beta! Please report any issues you encounter: https://github.com/architectury/architectury-loom/issues
Configure project :common
:remapping 2 mods from modImplementation (java-api)
:remapped 2 mods (intermediary -> named) in 1.403 s
:remapping sources (Mercury, intermediary -> named)
Configure project :fabric
"Lock for cache='/home/ceg/.gradle/caches/fabric-loom', project=':fabric'" is currently held by pid '289354'.
Found existing cache lock file (ACQUIRED_ALREADY_OWNED), rebuilding loom cache. This may have been caused by a failed or canceled build.
FAILURE: Build failed with an exception.
- What went wrong:
A problem occurred configuring project ':fabric'.
Failed to notify project evaluation listener.
'java.lang.String org.gradle.api.artifacts.ProjectDependency.getPath()'
- Try:
Run with --stacktrace option to get the stack trace.
Run with --info or --debug option to get more log output.
Run with --scan to get full insights.
Get more help at https://help.gradle.org.
CONFIGURE FAILED in 10s
Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.
You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.
For more on this, please refer to https://docs.gradle.org/8.8/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.
okay
yeah
wdym vertical stuff
remember up and down
oh also with the other method of placement
it would be nice if it could be a config option
so you could be able place illicit stuff anywhere without block updates
like u can place it on ceilings?
i think down is just the floor
as in like forced placement
by without block updates you mean what
like it doesnt tell any other blocks that it updated
yes
well that idk
but this yes
yeah that's what I meant
no not that
by on github I meant like the latest blockstate generation thing
besides models, vertical stuff, and backporting
I don't really see much to be added
what is vertical stuff
remember up and down placement
uhh
wait
I think
get vertical placement
then take on the beast that is backporting
I think 24w14potato should be first
then 1.20.1
1.20.1 has a bunch of mods and modpacks
24w14potato is components but on Java 17
obviously there is a little bit more but it should be simple enough
1.20.1 though is NBT
so stuff would have to be reworked
huh
you mean make the
illicit blocks
be able to be placed below blocks
yeah
on the ground below
and on ceilings above
hmm
so like
blocks that need ceiling support should still be able to be placed on the ground
and blocks that need ground support
should still be able to be placed on the ceiling
no like piston heads
huh
so like you mean
piston heads should face down
when you place on ceiling
and face up
when you place on floor (if looking below)
yeah exactly
yes
okay so
i think
uh
rn i only set the racing
facing
to be opposite
of the horizontal facing
doesnt factor in verticality
if (blockState != null && blockState.contains(Properties.FACING)) {
blockState = blockState.with(Properties.FACING, context.getHorizontalPlayerFacing().getOpposite());
}
this is how
pistons do it in mc
and other blocks
that support facing up and down
public BlockState getPlacementState(ItemPlacementContext ctx) {
return this.getDefaultState().with(FACING, ctx.getPlayerLookDirection().getOpposite()).with(EXTENDED, false);
}
maybe if i replace horizontalPlayerFacing
with getPlayerLookDirection
yeah do that
whatever a piston does just copy it
also a fix for wall signs
just make it point to a flat model
that is the name
so for instance like
cherry_wall_sign
it would point to an item texture
that being cherry_sign
also we still have the end gateway and portal problem
so like you want to
remove the hardcoded 2d textures
entirely
for gateway and portal
i thought it's already supported
i made it use the 2d textures
yeah
like render the end portal texture in a square for end portals
and a cubic shape for gateways
this stuff is hard but it's kinda mandatory if we want to make everything as authentic as possible
so I think for the top list of priorities at the moment
vertical orientation -> fix wall signs (also darken moving piston) -> backporting
you want the wall signs to be 3d
no
modded wall signs are somehow broken
purple and black instead of their item texture
this is with cinderscapes
i did not try with cinderscapes
bop and terrestria work fine
probably cinderscape uses different names for their texture file
or something is different
if you have logs
maybe you can send them
likely
lol
ask
also*
in the original issue i made
they said they fixed the wood types
in 1.21.6
they wouldn't do it for 1.21.5 because it'd take too much effort
for too little benefit
given a model for the block, you could extract the texture?
hmm
I know a guy who has done it, but I've never wanted to
can't think from the top of my head
on how i'd get
textures from a block
probably uh
i can use your
getModel thing
and do something with it
getting textures from a
UnbakedModel
interface Context {
@Nullable
UnbakedModel getModel(Identifier id);
this could probably work
if i wanted to
make it 3d
and if they use the same model
as the normal mc
just different textures
(not the case, same problem with terrestria using oak as the wood type)
newest commit, i added this
for now im just gonna use the same system like i did with terrestria
to fix the models
just pushed that one
Erm
[15:39:37] [Worker-Main-6/WARN] (Minecraft) Missing textures in model cinderscapes:potted_luminous_pod:
minecraft:textures/atlas/blocks.png:cinderscapes:block/luminous_pod
okay this is because
theres something a bit different with how potted plants work
luminous pod is a double block plant
and its a bit different for a double block plant and a potted plant
i made a fix for it
moving pistons darker
for end portal and end gateway issue
i proposed this
hmmm
what do you think
i dont know if i am able to access textures
outside the block folder
if i have a parent that uses the cube model inside blocks model
i tried and it didnt work
I think 24w14potato should be first
then 1.20.1
ill see if i can port to that
hmm
sources donwloaded
idk what class to check
BakedModelManager
i found ModelLoader
nvm bakedmodelmanager
exists
that looks a bit wonky
hmm
actually i think i remember that
modelloadingplugin
could be used
hmm
is this the right mc version
# Done to increase the memory available to gradle.
org.gradle.jvmargs=-Xmx1G
# Fabric Properties
# check these on https://modmuss50.me/fabric.html
minecraft_version=24w14potato
yarn_mappings=24w14potato+build.4
loader_version=0.16.14
# Mod Properties
mod_version=24w14potato
maven_group=com.github.cargocats
archives_base_name=illicitblocks
# Dependencies
# check this on https://modmuss50.me/fabric.html
fabric_version=0.96.14+24w14potato
"depends": {
"fabricloader": ">=${loader_version}",
"fabric": "*",
"minecraft": "1.20.5-alpha.24.12.potato"
}
there we go
wow i havent actually played the april fools thing
at all
ive never seen this
new experience for me
poop
java.lang.StackOverflowError: null
at knot/com.github.cargocats.illicitblocks.item.IllicitBlockItem.getTranslationKey(IllicitBlockItem.java:38) ~[main/:?]
at knot/net.minecraft.block.WallTorchBlock.getTranslationKey(WallTorchBlock.java:54) ~[minecraft-common-917be8ecad-24w14potato-net.fabricmc.yarn.24w14potato.24w14potato+build.4-v2.jar:?]
at
...
okay i got it to uh
load
but item models
are missing
gonna publish first draft
for it
Contribute to cargocats/IllicitBlocks development by creating an account on GitHub.
this is working
package com.github.cargocats.illicitblocks.client;
import com.github.cargocats.illicitblocks.IllicitBlocks;
import net.fabricmc.fabric.api.client.model.loading.v1.ModelLoadingPlugin;
import net.minecraft.client.render.model.json.JsonUnbakedModel;
import net.minecraft.util.Identifier;
import java.util.List;
import static com.github.cargocats.illicitblocks.IllicitBlocks.createdBlockItems;
import static com.github.cargocats.illicitblocks.IllicitBlocks.moddedBlocks;
public class IllicitModelPlugin implements ModelLoadingPlugin {
@Override
public void onInitializeModelLoader(Context pluginContext) {
pluginContext.resolveModel().register(context -> {
Identifier id = context.id();
if (id.equals(new Identifier("minecraft", "item/water"))) {
IllicitBlocks.LOG.info("Injecting model for {}", id);
return JsonUnbakedModel.deserialize("""
{
"parent": "item/generated",
"textures": {
"layer0": "minecraft:block/dirt"
}
}
""");
}
return null;
});
pluginContext.addModels(createdBlockItems);
}
}
you likely don't need most of it, as the model loading api was more powerful back then
and
yes
you got it lol
yes
didn't read to the bottom
its a bit more work
public class IllicitModelPlugin implements ModelLoadingPlugin {
private static final HashMap<Identifier, Identifier> blockIdToItemId = new HashMap<>();
private static final HashMap<Identifier, Identifier> itemIdToBlockId = new HashMap<>();
// This is necessary because these mods don't use their own WoodTypes
private static final List<String> annoyingMods = List.of("terrestria", "cinderscapes");
@Override
public void onInitializeModelLoader(Context pluginContext) {
// make sure it is checking all our models
pluginContext.addModels(createdBlockItems);
createdBlockItems.forEach(blockId -> {
Identifier itemId = new Identifier(blockId.getNamespace(), "item/" + blockId.getPath());
blockIdToItemId.put(blockId, itemId);
itemIdToBlockId.put(itemId, blockId);
});
pluginContext.resolveModel().register(context -> {
// can be either :block/ or :item/
Identifier id = context.id();
if (blockIdToItemId.containsValue(id)) {
String theResult = getModelForId(id, context);
Identifier blockId = blockIdToItemId.get(id);
IllicitBlocks.LOG.info("THE RESULT {}, ITEM ID: {}, BLOCK ID: {}", theResult, id, blockId);
return JsonUnbakedModel.deserialize(theResult);
}
return null;
});
IllicitBlocks.LOG.info("LOADED ILLICIT MODEL PLUGIN");
}
trying to get it to work
now
instead of making everything a dirt
dirt is fun
well its working
for the most part
except for the tints,
and special models
gonna push another commit for what i have rn
potato snapshot is above 1.20.1
guess thats a okayish starting point
so i can move down
backporting
got banners to work
Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.
Erm
> Task :remapJar FAILED
Mapping source name conflicts detected:
net/minecraft/entity/mob/MegaSpudEntity METHOD isPotato (()Z) -> [net/minecraft/entity/mob/MegaSpudEntity/method_58887, net/minecraft/entity/Entity/method_58842]
net/minecraft/entity/mob/PoisonousPotatoZombieEntity METHOD isPotato (()Z) -> [net/minecraft/entity/mob/PoisonousPotatoZombieEntity/method_58887, net/minecraft/entity/Entity/method_58842]
net/minecraft/entity/Entity METHOD isPotato (()Z) -> [net/minecraft/entity/Entity/method_58887, net/minecraft/entity/Entity/method_58842]
net/minecraft/entity/passive/BatatoEntity METHOD isPotato (()Z) -> [net/minecraft/entity/Entity/method_58842, net/minecraft/entity/passive/BatatoEntity/method_58887]
net/minecraft/entity/mob/GuardianEntity METHOD isPotato (()Z) -> [net/minecraft/entity/mob/GuardianEntity/method_58887, net/minecraft/entity/Entity/method_58842]
what does your gradle.porperties look like
i added the tints
and supported the other things
should be extremely close
to 1.21.5 version
now
also committed and pushed
forgot to remove
some logs
took me the entire evening to port
hmm
same as yours
maybe it wants J21 or something
I think like
for the mod porting sequence
just 24w14potato and 1.20.1
then we can go backwards to 1.18.2 and then if possible 1.16.5 and 20w14infinite
๐
try
starting from scratch
got clone
git clone
git checkout -b 24w14potato
and try compiling from there
hmm
1.16.5 probably not
i don't see a
branch for it
in fabric api
not sure if model api is there
any updates
True
fabric api doesn't miss versions, but sometimes they reuse branches
with a fresh new clone
?
im not experienced with this mapping source name conflicts thing
all i know is mappings just gives names
this honestly looks a bit like outdated intermediary, although i have no clue why it would happen to them
this error happens when a class implements a method that has the same name as another in dev, but two different names in prod
but like
that's vanilla
so I have no clue what happened
are you on the latest intermediary / mapping version (for that version)?
i did a mixin to register items just before the registry freezes
i think its neat
package com.github.cargocats.illicitblocks.mixin;
import com.github.cargocats.illicitblocks.IllicitBlocks;
import com.github.cargocats.illicitblocks.item.IllicitBlockItem;
import net.fabricmc.fabric.api.itemgroup.v1.ItemGroupEvents;
import net.minecraft.registry.Registries;
import org.spongepowered.asm.mixin.Debug;
import org.spongepowered.asm.mixin.Mixin;
import org.spongepowered.asm.mixin.injection.At;
import org.spongepowered.asm.mixin.injection.Inject;
import org.spongepowered.asm.mixin.injection.callback.CallbackInfo;
import java.util.ArrayList;
@Debug(export = true)
@Mixin(Registries.class)
public class RegistriesMixin {
@Inject(method = "freezeRegistries", at = @At("HEAD"))
private static void beforeFreeze(CallbackInfo ci) {
ArrayList<IllicitBlockItem> blockItems = IllicitBlocks.registerBlockItems();
ItemGroupEvents.modifyEntriesEvent(IllicitBlocks.ILLICIT_BLOCKS_ITEM_GROUP_KEY)
.register(group -> blockItems.forEach(blockItem -> {
group.add(blockItem);
IllicitBlocks.generateItemStacksFromBlockItem(blockItem).forEach(group::add);
}));
IllicitBlocks.LOG.info("Finished registering IllicitBlocks items");
}
}
gives me this when exported
hmm
so that my
injection has higher priority
if other mods mixins
also mixin into freezeRegistries?
nah
that's the default item components event
so you should be before it so your items can work with it
yeah
how high can the priority be
@Debug(export = true)
@Mixin(value = Registries.class, priority = 69420)
higher means later
ah
negative infinity ๐ง
there isn't a need to
Probably 1
Because the general convention is to reserve the negatives for fapi
And 0 requires another mod to go negative to usurp you, if they need to for some reason,
Like if they want to register blocks before you make items so they can be included, but also right before the freeze
hopefully not too many mods do that
I see
does it compile
well for me it does
if you cant compile it i can compile it for you
but maybe your not comfortable with that
could you setup actions to compile it for you?
no idea how to set up github workflow
there is an example in the fabric template, iirc
I find workflow_dispatch helpful also
btw i found out
what was causing
the weird getpath thing in condensed creative
Oh?
this works
plugins {
id "architectury-plugin" version "3.4-SNAPSHOT"
id "dev.architectury.loom" version "1.7-SNAPSHOT" apply false
}
but this doesnt
plugins {
id "architectury-plugin" version "3.4-SNAPSHOT"
id "dev.architectury.loom" version "1.10-SNAPSHOT" apply false
}
now im trying to figure out how
to make it use a more up to date loom
Mod was built with a newer version of Loom (1.10.1), you are using Loom (1.7.423)
well erm
it seems 1.7 is the max version
Have you checked their maven
yeah my thing was gradle 8.14
okay so
this is too much porting
io/wispforest/condensed_creative/data/CondensedEntriesLoader.java
Lol
i just annihilated
features i didnt want to port
๐ง
like data driven condensed items
okay im going to annihilate owocompat
okay stupid mixin stuff
nvm then
too much porting
well im gonna quit but atleast i did this
uhh what
interesting
hmmm
3.4k messages oh ths post is crazy.
It's honestly probably gonna have 6+ before it's done
Damn
okay
inside the artifacts.zip
i gotta do it
for other branches
now
damn
even github workflows
has the same issue
as he does
another case of the mysterious works on my machine
ok well thats weird
somehow it managed to compile for 1.20.1
but not 24w14potato
got it to compile
magical one line change solution
Huh
Okay lol
!fabricVersion 24w14potato
build.gradle (constants inside the build script)
minecraft "com.mojang:minecraft:24w14potato"
mappings "net.fabricmc:yarn:24w14potato+build.4:v2"
modImplementation "net.fabricmc:fabric-loader:0.16.14"
// Fabric API
modImplementation "net.fabricmc.fabric-api:fabric-api:0.46.6+1.18"
}```
**gradle.properties** (constants in a separate file, as with Example Mod)
```minecraft_version=24w14potato
yarn_mappings=24w14potato+build.4
loader_version=0.16.14
# Fabric API
fabric_version=0.46.6+1.18```
**Mappings Migration** ([more info](https://fabricmc.net/wiki/tutorial:migratemappings))
```gradlew migrateMappings --mappings "24w14potato+build.4"```
Note that the Fabric API version is usually only correct for the latest minor MC release (e.g. 1.16.5 or 1.15.2) due to implementation limitations. Check [CurseForge](https://minecraft.curseforge.com/projects/fabric/files) for a more precise listing.
On this branch you already have V2 though?
build 4, still version 2
The versions are iterations of the yarn spec
There are only three
Tmk
what is tmk
To my knowledge
i just
thought of that
thanks
just got it to compile for 24w14potato if you're interested https://github.com/cargocats/IllicitBlocks/actions/runs/15646522540 @dire blade
yay
can't test right now
so we have blockstates + grouping
we have 24w14potato
models are pretty decent
I think the only way might be backwards
1.20.1 is done as well
wait what
check the github
That moment when cargo cat shipped everything while you were busy
yeah when I saw stuff I was like what
somehow managed yesterday to do anything but test illicitblocks
I have an idea
maybe have an option to change pickblock functionality
since the mod generates all illicit blocks
an option to pick the absolute block would be nice to have
so instead of a powder snow bucket when you middle click on powder snow
it would be actual powder snow
okay
True
cant think of an way
to track if the block was placed by my illicitblockitem
if you had powder snow that was placed by my illicitblockitem
that powder snow block has their own pick item stack functionality
idk how you would
differentiate
a powder snow block
that was placed with a powder snow bucket
vs my illicit powder snow
this could go with over blocks too
can confirm that illicitblocks builds on J17
true
okay
yes
and it crashes
with illicitblocks
erm
I bypassed the mixin java requirement and still got a crash
even though it targets a mc version of java 17
it complains about that
yeah
hmm
okay i fixed it
perfect
the potato update blocks are quite underwhelming
try now
the only new blocks are potato wall signs lol
hmm
well
the potato update did add
a ton of blocks
but there was already
existing blockitems
to place those blocks
is it on github
yeah
yes
compiled just now and it still wants J21 on launch
erm
did you pull the latest commits
I did git clone -b 24w14potato https://github.com/cargocats/illicitblocks
already up to date
hmm
maybe let's see again
what if I bypass it again
yep it works
huh
you should probably set the java compatibility level in mixins to J17
after editing the mixin files in the root of the jar it worked
picom shader
I have wanted to make my desktop use 1bit color for a REALLY long time
and I finally did it
so
I think that everything is very close
but here are some things
I think by this point
all we need to do is fix 1.20.1 NBT
fix end portals
and get condensed creative to somehow work

im gonna retry porting it
but strip out some things
i dont know if there is a block state component equivalent
for nbt
luckily git makes this very nice
im just gonna rollback some files
well
actually
condensed creative
pretty much works
for 1.21.5
it's just
the plus and negative icons
are gone
(at least from what i tested(
Try the Ctrl + Middle Mouse thing
See what it generates
No clue
i'll test
oh wait
you're talking about inside mc
and not intellij
Yup
there is
that's a bit of like a
weird thing
condensed creative is
what's it called
wdym
I'm not sure
could probably find it with one of those nbt helper mods
the minecraft wiki isn't very helpful with obscure stuff like this
or a breakpoint
true
fixed the block state thing
apparently
u put a nbt compound tag on blockitem
with the key of "BlockStateTag"
found as a constant in BlockItem
hmm
so
it works
but weirdly soul fire places fire
and it has no blockstates for it
however I didn't restart the game
yeah
if I restart the game soul fire is still weird
1 item in the tab for soul fire
no other blockstates
and placing it gives normal fire
this actually seems like proper behavior weirdly
when placed on soul blocks it does give soul fire
and it doesn't really spread
so somehow fire was reworked at some point
I would imagine fire uses scheduled ticks, and isn't being kicked off properly
well setblock places nothing if soul fire is on the wrong block
Okay? Doesn't really have anything to do with kicking off a scheduled tick loop
7 days ๐ฅ
I guess then by this point
there isn't really anything for the most part
I'm going to test 1.20.1 and stuff for compatibility and give the ranges so the fabric jsons can be as accurate as possible
yeah
like I have no other ideas for this mod
models are ok (I'll make a better end portal texture)
true
then wait for release day!!
it should be perfectly fine
hmm
models should be fine
-XX:+AllowEnhancedClassRedefinition
they probably didn't do stuff to the model system
what does that do
yeah
ah I see
well able to hotswap in more different contexts
so i dont have to
relaunch mc
398293742938428 times
alright
the potato version should be compatible with 24w09a - 24w14potato
wow i got it to work
im gonna have to gut some things ofc
specifically data driven entry
and auto condensing of paintings
(i have no idea how to make these work because of this huge code base)
damn a lot of these warnings
came from the original code
YES
1.20.1 should be 1.20 - 24w07a
from there
I think 1.19 might work
I have no idea though
what
yeah
I think what we need is just a REALLY compact and limited version of condensed creative that only groups illicit blocks
that could work i guess
making my own implementation
of condensed creative
that only works
for the item gorup
illicit blocks
i have no idea how to include
the condensed creative jar i made
and i wouldn't need to go through the process
of having to depend on another mod
doesnt need to be super complicated
like no data driven stuff
just a small implementation for my mod
this is actually pretty hard
do you have any
pointers
this is probably gonna be
days
Unfortunately, not really
for now i am going to try to use condensed creative
damn
gotta find somehow to integrate this
with this
condensed creative compat has to be in its own entrypoint
from fabric.mod.json
this actually sucks
nothing ive tried works
Theoretically, you should do everything except cc compat outside of the cc compat entrypoint
Especially because, hypothetically, the cc entrypoint should be called way after the freeze
hmm
ill see
as it turns out
it does it when
u load into the world
also before
i think i did something wrong
i did make it stand alone
before
but something happened
also for some reason
it sometimes prints
sometimes it doesnt
public class CondensedCreativeCompat implements CondensedCreativeInitializer {
@Override
public void registerCondensedEntries(boolean refreshed, DynamicRegistryManager access) {
IllicitBlocks.LOG.info("Initializing condensed entries");
like rn it doesnt work
package com.github.cargocats.illicitblocks;
import com.github.cargocats.illicitblocks.item.IllicitBlockItem;
import io.wispforest.condensed_creative.registry.CondensedCreativeInitializer;
import io.wispforest.condensed_creative.registry.CondensedEntryRegistry;
import net.minecraft.registry.DynamicRegistryManager;
import net.minecraft.registry.Registries;
import net.minecraft.util.Identifier;
public class CondensedCreativeCompat implements CondensedCreativeInitializer {
@Override
public void registerCondensedEntries(boolean refreshed, DynamicRegistryManager access) {
IllicitBlocks.LOG.info("Initializing condensed entries");
for (var blockItem : IllicitBlocks.createdBlockItems) {
var mainItem = Registries.ITEM.get(blockItem);
var variants = IllicitBlocks.generateItemStacksFromBlockItem((IllicitBlockItem) mainItem).stream()
.distinct()
.toList();
CondensedEntryRegistry.fromItemStacks(
Identifier.of(IllicitBlocks.MOD_ID, "condensed/" + blockItem.getPath()), // Unique ID
mainItem,
variants
).addToItemGroup(IllicitBlocks.ILLICIT_BLOCKS_ITEM_GROUP_KEY);
}
}
}
okay it has this habit of semi working
i hate it when
it sometimes works
not just a always doesnt work or always work
quasi working
if i dont do this it doesnt work even though it has no connection thing to the condensed creative
/*
ItemGroupEvents.modifyEntriesEvent(IllicitBlocks.ILLICIT_BLOCKS_ITEM_GROUP_KEY)
.register(group -> blockItems.forEach(blockItem -> {
group.add(blockItem);
IllicitBlocks.generateItemStacksFromBlockItem(blockItem).forEach(group::add);
})); */
this log doesnt even get printed
IllicitBlocks.LOG.info("Initializing condensed entries");
then when i uncomment this
it has an often more chance to fail
than generate
im gonna quit this
1.21.6 released
did u test the release candidate
if not you can probably test the 1.21.6
hmmmmm
real
compiling latest
true
hopefully
yep
it works perfectly fine
is there a way to set multiple fabric versions
set fabric.mod.json to >=1.20.5
it gets weird with snapshots
maybe 2xwx or something
snapshots work, they're translated to 1.21.6.alpha.25.20.1 or something
True
what would 24w14a translate to
would it be
1.21.5.alpha.24.14.1
something like that
the wow starts now
(testing version compatibility)
it seems like
the correct syntax is 1.20.5-alpha.24.14.a
so uh
what I have
24w14a-1.21.3 crashes
1.21.4 opens the window then crashes
1.21.5 is fine
25w02a crashes
25w10a is fine
25w05a works
25w03a crashes
ok
here's the range for 1.21.5 version
=1.21.5-alpha.25.04.a
so this means we need a version for 1.21.3
time for more testing
24w14a - 24w46a crashes
so what we have
25w04a+ works perfectly fine
1.21.4 - 25w03a shows window then crashes
and 24w46a - 24w14a crashes
this will have to be the next version
24w14a
was not able to test 1.21.4 pre1 - rc1 because FAPI doesn't support them for some reason
24w46a log
oh oops
wait
24w14a crash report
hopefully
this is enough to fix these versions and have a port for 24w14a - 24w46a and 1.21.4 - 25w03a
now it's time to go the other way around
with the potato and 1.20.1 version
hmm
Yeah, modrinth is hiring privately currently, iirc
as in, I do think they're trying to fix it, just can't see it. I know of someone who got hired recently by then
that epic fail makes me very
ed
9/28
so we know this
so 24w14a - 24w46a needs a port
1.21.4 - 25w03a need a port
just tested illicitblocks and it works perfectly fine on 24w09a
so potato is 24w09a - 24w14potato
1.20.1 - 24w07a works for the 1.20.1 version
we need a backport to 1.19.4
I think for backporting
this is how it should go
24w14a - 24w46a -> 1.21.4 - 25w03a -> 1.20-
modrinth got released
so what is the expected mc versions for 1.21.5, 1.20.1 and 24w14potato
i see u described it
for 1.20.1 and 24w14 potato
not 1.21.5
=1.21.5-alpha.25.04.a
ah
so 25w04a and above
for 1.21.5 version of the mod
im gonna clean up some of the code to match the main branch first for 1.20.1 and 24w14potato
yeah
1.20.1 goes from 1.20 - 24w07a
24w14potato is 24w09a - 24w14potato
24w14a - 24w46a will need a port
1.21.4 - 25w03a will need a port
and 1.21.5 works on 25w04a+
idk how to actaully write the versions
so im just gonna make it
but label the right versions
on modrinth
i did specify a minimum versions for the 1.20.1 and 1.21.5
but not for the 24w14potato
just labelled it on modrinth
so what kind of versions u need backported
these two
once there are those two
we can start going even further back
I would probably want to stop at 1.18.2
once we get down to 1.18.2 I think from there it's sort of like
how feasible would a 1.17, 1.16, and possibly 20w14infinite port be
the main obstacles will probably be FAPI, registry stuff, and potentially models
but models from 1.20 on 1.16 should be fine
Fapi?
fabric api
there might have to be some minor changes
with the 1.20.1 port there had to be a slight code fix
!fabricVersion 1.20.1-rc1
build.gradle (constants inside the build script)
minecraft "com.mojang:minecraft:1.20.1-rc1"
mappings "net.fabricmc:yarn:1.20.1-rc1+build.2:v2"
modImplementation "net.fabricmc:fabric-loader:0.16.14"
// Fabric API
modImplementation "net.fabricmc.fabric-api:fabric-api:0.92.6+1.20.1"
}```
**gradle.properties** (constants in a separate file, as with Example Mod)
```minecraft_version=1.20.1-rc1
yarn_mappings=1.20.1-rc1+build.2
loader_version=0.16.14
# Fabric API
fabric_version=0.92.6+1.20.1```
**Mappings Migration** ([more info](https://fabricmc.net/wiki/tutorial:migratemappings))
```gradlew migrateMappings --mappings "1.20.1-rc1+build.2"```
Note that the Fabric API version is usually only correct for the latest minor MC release (e.g. 1.16.5 or 1.15.2) due to implementation limitations. Check [CurseForge](https://minecraft.curseforge.com/projects/fabric/files) for a more precise listing.
why doesn't modrinth have FAPI be compatible with that version then
weird
!fabricVersion 25w03a
build.gradle (constants inside the build script)
minecraft "com.mojang:minecraft:25w03a"
mappings "net.fabricmc:yarn:25w03a+build.3:v2"
modImplementation "net.fabricmc:fabric-loader:0.16.14"
// Fabric API
modImplementation "net.fabricmc.fabric-api:fabric-api:0.46.6+1.18"
}```
**gradle.properties** (constants in a separate file, as with Example Mod)
```minecraft_version=25w03a
yarn_mappings=25w03a+build.3
loader_version=0.16.14
# Fabric API
fabric_version=0.46.6+1.18```
**Mappings Migration** ([more info](https://fabricmc.net/wiki/tutorial:migratemappings))
```gradlew migrateMappings --mappings "25w03a+build.3"```
Note that the Fabric API version is usually only correct for the latest minor MC release (e.g. 1.16.5 or 1.15.2) due to implementation limitations. Check [CurseForge](https://minecraft.curseforge.com/projects/fabric/files) for a more precise listing.
!fabricVersion 25w04a
build.gradle (constants inside the build script)
minecraft "com.mojang:minecraft:25w04a"
mappings "net.fabricmc:yarn:25w04a+build.10:v2"
modImplementation "net.fabricmc:fabric-loader:0.16.14"
// Fabric API
modImplementation "net.fabricmc.fabric-api:fabric-api:0.46.6+1.18"
}```
**gradle.properties** (constants in a separate file, as with Example Mod)
```minecraft_version=25w04a
yarn_mappings=25w04a+build.10
loader_version=0.16.14
# Fabric API
fabric_version=0.46.6+1.18```
**Mappings Migration** ([more info](https://fabricmc.net/wiki/tutorial:migratemappings))
```gradlew migrateMappings --mappings "25w04a+build.10"```
Note that the Fabric API version is usually only correct for the latest minor MC release (e.g. 1.16.5 or 1.15.2) due to implementation limitations. Check [CurseForge](https://minecraft.curseforge.com/projects/fabric/files) for a more precise listing.
this will likely be
the absolutely final new feature
taking the end portal effect and rendering it on end portal and gateway items
hmmm
but how could we render it on to a texture or something
You wouldn't really need to. Just need to give the item a different RenderLayer.
I don't remember how to do that though...
hmmmmmmmmmmmmmmmmmmmmmmmm
how hard would assigning rendering to a texture be
because then anything that points to like

