LexManos

Forge Code God
 View Profile  See their activity

  • Content Count

    8589

  • Joined

  • Last visited

  • Days Won

    41

Posts posted by LexManos

  5. Posted

    3 hours ago, Draco18s said:

    Yes. I know that. That wasn't my question. My question was why the separation between hasCap and getCap even existed at all.

    I'm trying to understand the separation between hasCap and getCap. You have more experience than I do, you designed it, but its really frustrating for me to communicate with you. :(

     

    13 hours ago, LexManos said:

    has == instanceof

    get == cast

    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?

  6. Posted

    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?

  7. Posted

    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.

  8. Posted

    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...

  9. Posted

    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.

  12. Posted

    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.

  15. Posted

    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.

  18. Posted

    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.

  21. Posted

    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.