LexManos
-
Posts
9270 -
Joined
-
Last visited
-
Days Won
68
Posts posted by LexManos
-
-
It's a stupid simple concept. It was literally designed to replace these instanceof/cast in a non-hard dep way.
has == instanceof
get == cast.
If has == true
Then get using the same cap&side MUST not return null
I hate people doing `if has(){ cap = get(); if (cap != null)` because thats not how it was designed.
I'm not taking everything as a personal slight, I just stated that Dies was spreading the exact opposite of what to do.
So I informed you of what the design was. {As I have informed people many, many, MANY times since the system was designed}
This entire system is moot however, as 1.13+ now uses LazyOptionals because people couldn't understand the concept of instanceof/cast.
People are NOW being stupid and returning new instances of the LazyOptional every get call.. and that's just even more stupid...
It's a simple system, with TONS of examples in Forge/Vanilla. how can people screw it up so much?
-
5 minutes ago, Draco18s said:
Is hasCap supposed to return true for a given capability, even if that capability is only exposed on one side?
Does my get only return a cap if its on a specifc side? No it returns caps for all sides. What did you expect the code to look like?
if (cap == MYCAP){ if (side == UP) return true else return true }You know what that condenses down to?
Are you starting to see what I mean by lightweight code?
5 minutes ago, Draco18s said:Also, why would you check this here? Wouldn't you create the handler in the TE constructor?
https://en.wikipedia.org/wiki/Lazy_initialization If nobody wants your cap, why bother creating it?
5 minutes ago, Draco18s said:Also no one (that I know of) does this. The worst case I know about is doing CombinedInventoryWrappers and that's usually only for when the side is null (block breaking covering 90% of cases where it would be called with a null side). And if the Combined wrapper is really that expensive, then fine, I can cache it, no problem.
Who knows, caps can be anything. Cap initialization can take whatever values you want. What about say.. a cap that keeps track of all entities within a BB around the TE. Instead of having every BB list tracked for every chunk every tick. You could delay capturing that snapshot of entities until the getCap is called. And it could add it's chunk event handlers lazily. I dont know, thats not really a good example but my point is. Building the caps COULD be expensive both CPU wise and memory wise. You can use lazy initialization in your get to save those costs.
-
The IDEA is to have complex logic in get, and lightweight logic in has.
As in:
has(cap, side) { if (cap == MYCAP) return true; } get(cap, side) { if (cap == MYCAP) { if (side == UP) { if (myUpHandler == null) { myUpHandler = superComplexMethodThatCalculatesMyUpHandler(); } return myUpHandler; } else { if (myOtherHandler == null) { myOtherHandler = otherSuperComplexCodeThatTakesTime(); } return myOtherHandler; } } }We now have that complex logic in the Supplier for the LazyOptional in 1.13+.
But people are STILL not doing it right...
-
Don't call hasCapability only to then immediately call getCapability. getCapability will return null if the capability is not present (which you already check for...).
That's actually the exact opposite of how things were designed. Get is costly, has should be fast
And thus better to run. But whatever nobody ever implemented it right.
-
the installer jar is a executable jar. Run it with java.
-
No, The exe is just a wrapper around the jar installer.
Just use the jar installer.
-
Whenever I say "It's not possible to do right now" I mean that the vanilla code base is written in a way that makes doing that thing require re-writing large swafts of it causing breaking changes with any other loading system out there. So instead of Forge doing it ourselves. We work with Mojang and try to get them to make the vanilla engine better. Which they eventually did, and we enhance to make super resiliant and more featureful.
There is a line with keeping vanilla compatibility that we have to stick to. So we can't just make major changes to the engine itself. However Mojang has been working on both addinjg new content to the game. And cleaning up the engine itself to work better. It's a slow process but it's going.
-
1.13.2 mods do not work on 1.14.4. Notibly, world edit is crashing.
-
Currently in 1.14.4, it only fires on the server due to Mojang's major refactor of the code where we hooked in.
We have no re-implemented client side events yet.
When we do isRemote will be true for client side.
-
1
-
-
Ok dude, you posted on the github and failed to follow the directions there about posting logs and actual useful information.
Then I directed you here, and you STILL failed to post any useful information as described in the EAQs.
You really shouldn't be making a mod if you can't follow basic directions.
We are not magical we can not read your mind and have no idea what is going on without the information that you have.
So post logs.
Post code
Post your configs
Post everything even remotely related to the problem.
As it sits, best guess you fucked up your build.gradle and are actually still using 12.
-
A patch got missed in the 1.14.4 update, https://github.com/MinecraftForge/MinecraftForge/commit/7411b444d3810c94d53c8edf6ec560c4e30cb4ef
Update to 28.0.14+
-
1
-
-
Provide your logs.
Also make sure you're checking the correct folders.
-
You are the 1%, just because you use something doesnt mean everyone does.
Forge will never again ship an extra language by default. you can already get a standardized language loader that you only need to download once.
That's why we built that system.
-
you don't. Mojang has specifcally asked that people do not screw with capes.
Don't do it.
-
If you download from unofficial sites, you wont get the real Forge.
Forge is never packaged with anything but Forge. No Chromium or other crap.
There isn't anything we can do fix you guys downloading from bad sites.
Be better at using the internet.
-
Forge will always target the version of java that Minecraft targets. So, currently J8.
Once Mojang upgrades, we can upgrade and utilize a lot of new features. Our loader re-write was actually done to support J9+ better.
As for upgrading ASM, it's on the todo. But it has a lot of side effects that break things.
-
GradleStart no longer exists in FG3+
Use the run configs provided. Which should be generated by running the eclipse task.
-
Fixed: https://github.com/MinecraftForge/InstallerTools/commit/7e6f8d0e6457f9a027a54e6aaa6d7c2c3694a276
The proper work around for older versions is to just run the vanilla launcher first. Or manually make the directory.
Umbra is correct, you should not be redistributing Mojang's libraries.
-
No idea, modders just scream that they want direct GL without articulating why or what they are doing. Or how the system we currently have is not adequate.
-
Stop using cracked launchers. The installer installs the file fine.
-
Vanilla is attempting that, it just moves slowly. And modders are vilently resistant to change. So in theory a system could be developed to do 99% of what modders need. But it would never be used.
-
Issue with the twitch servers. I have reported it to them. They should fix it eventually. Until then, Use Forge directly, or manually add that file where it needs to be.
-
you can not install the client headless, but we have a --installServer option for installing the server headless.You can get all information by passing --help
-
Did a quick google, Seems this is adware called WebDiscover: https://malwaretips.com/blogs/webdiscover-removal/
You installed it somehow, so go uninstall it, i'd also recommend running a deep scan with your anti-virus. (I personally recommend Malware Bytes)
Help with auto-ejecting items
in Modder Support
Posted
There are many instances where you don't give a shit about the actual content of the cap. You just want to know if it IS a thing.
For example pipes, you don't care when you render the pipes what exact items are inside a block.
Just that that block has a inventory, and you should render that side being connected.
You don't want to spend the massive amount of time every frame getting the large object as a return value and checking null. When you could just call a SIMPLE implementation that tells you directly the information you want to know.
Hell even more reason to have the items be lazy initialized is because the client doesn't need to know, and have in memory, the inventory of a block. Because it would always be useless/empty unless you specifically add a sync packet that sends over all the inventory contents.
Is that simple enough for you to understand?