Jump to content

imacatlolol

Forge Modder
  • Posts

    274
  • Joined

  • Days Won

    5

Posts posted by imacatlolol

  1. 8 minutes ago, samjviana said:

    So at this point it isn't possible? At least not by the usual way?

    I would recommend trying and seeing if it works anyways just for the heck of it.

    Forge is in beta right now for 1.16, so some issues are to be expected.

    They're working quite hard to get things figured out, but it may take a little while.

    • Like 1
  2. 15 minutes ago, Kikoz said:

    Well I made the part where it changes when raining by looking at the cauldron - fillWithRain. I just need a way to make it change back when it stops raining.

    Oh! Neat, I didn't recognize that as a vanilla method.

    Actually, looking at your code a little closer, you're misusing World#setBlockState and BlockState#cycle entirely. The integer parameter is for flags which are used for updating and syncing. You should use a flag of 11 for both lighting and un-lighting the block.

    As for the BlockState, you should use the with method instead of cycle.

  3. You're passing com.monroth.arcanapp.master_of_magic.MOD_ID as the deferred registry's ID, which is "arcpp" from the sounds of it. However, your mod's id is "mom".

    Also, your assets aren't in the right directory for either of those ids, as that's titled "master_of_magic".

    My recommendation would be to pick one of those three and stick with it.

  4. 16 hours ago, Alpvax said:

    How true is this? Does it do nothing, or are the methods stripped during build/run? I have used it in the past as a marker for methods which I know must only be used on the client. Does this have a functional use or is it safe to use as a marker?

    I'm... not too sure, to be honest. Stripping the methods seems like a viable use case, but the annotation itself doesn't seem to be referenced anywhere (except for annotating things obviously). It's intended to only be used by FML/Forge and the javadocs say for modders not to use it, so I personally advocate against it. As far I'm aware, it's just a marker; FML/Forge merges the client and server and @OnlyIn is used to indicate the differences.

    So it's probably safe for you to use as a marker yourself, but I'm not sure. I imagine one reason for not using it is because people might misunderstand it and somehow believe that it'll magically make certain code not run on the server/client, when it seemingly does nothing in reality.

     

    Probably a good question for Lex or someone else who works on the lower levels of Forge, I'm curious as well.

  5. 32 minutes ago, YaBoiChips said:

    so i cant use playertickevent then. so i have to re-write it (also

    
    @OnlyIn

    is what they use in vanilla)

    OnlyIn does literally nothing for modders. It's an internal marker for Forge/FML only, so modders shouldn't use it.

    A TickableSound would probably be ideal for this, as already mentioned.

    You could use Item#inventoryTick to start the sound by checking the item in the player's hand, kind of like how maps work

    .

  6. 1 hour ago, Jacrispy said:

    So if I want to render my own stuff - this makes it sound like I need to import assets for the HUD if I want to render them anywhere but the default location?

    In a sense, yes. There's no quick way of changing the HUD layout since it's all hardcoded. However, you don't actually have to "import" anything since TextureManager#bindTexture handles all the heavy lifting (it simply takes a path to the texture via a ResourceLocation).

    I recommend spending some time dissecting the vanilla code and playing around with it to see what does what. I generally advocate against copy-pasting vanilla code (partially for copyright reasons, among others), but since you mentioned that you're good with Java there shouldn't be a problem with doing so as long as it's just for learning/prototyping.

  7. 31 minutes ago, BlockyPenguin said:

    Also, as a sidenote, all aesthetics and nice-feeling timings aside, how effective is having a counter at decreasing server lag?

    A counter is fine, but an another way of doing it would be to increase a number every tick and then use the modulo operator to compare the current value.

    So for example, create a ticks field, run ++ticks every tick to increment, then do if (ticks % 10 == 0). It will return true every ten ticks.

    The modulo operator is basically a division operator that returns the remainder, so comparing it to zero will only return true if the value is cleanly divisible.

    It won't make a noticeable difference performance-wise, but you may find the code to be a little cleaner. It's just a personal preference thing.

    • Like 1
  8. Yes, sadly most documentation is outdated or lacking, and few tutorials are comprehensive enough for more advanced feature implementation.

    The inner-classes of RenderGameOverlayEvent are what you need. Specifically, for changing the vanilla HUD elements, you'd want to cancel the Pre event for a specific element (e.g. the hotbar) to stop it from rendering normally and then render your own stuff manually. Take a look at ForgeIngameGui for more details on how the HUD is rendered.

    Always make to check the element type when using the event, otherwise you will end up rendering something multiple times and cause other graphical issues.

  9. 11 minutes ago, Alex Sim said:

    I was just experimenting for now but my (probably unreachable) goal is to light every pixel differently (maybe using the alpha level) like so

    I see! That would certainly be achievable without needing a custom render type or lightmap.

    In this case, you would want to make a custom IModelLoader and model to use with your block JSONs. See MultiLayerModel and its usages for roughly what that process would be.

    Applied Energistics actually achieved this effect, but their repo is outdated and most of the actual code no longer applies. It's still a good reference for how you could try implementing it yourself if you get stumped. Just take a look at the charged certus quartz ore.

  10. 1 hour ago, Novârch said:

    I just copied the vanilla FogRenderer code.

    There's your problem.

    The event is normally intended to be used by simply setting the fog density via the event's setDensity method. The same goes for the fog color.

    A density of 0.3 will produce a very similar effect as the vanilla method, but it's not perfectly identical since vanilla uses more complex methods. However, the difference is very subtle and none of your users will likely even notice.

    If you really want an identical effect, you should set the density to 0 and then use those four RenderSystem method calls towards the end.

  11. The effect is controlled by FogRenderer#updateFogColor, and FogRenderer#setupFog. Look for the usages of Effects.BLINDNESS to see the exact math it performs.

    Hook on to the EntityViewRenderEvent$FogDensity and EntityViewRenderEvent$FogColors events to override the vanilla behavior and do your own logic (the former event will need to be canceled for your stuff to work).

    I recommend using a lower event priority and then checking the state of the events so that other mods can override your system if desired.

  12. Sadly, almost all of the documentation (even the JavaDocs in the code) is horribly outdated or lacking, as you mentioned.

    For your case, the "ItemStack sensitive version" comment refers to the hasContainerItem and getContainerItem in IForgeItem, which Item implements. Basically, just add an ItemStack parameter to the deprecated versions and it will override the new versions.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.