Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

SerpentDagger

Members
  • Posts

    157
  • Joined

  • Last visited

  • Days Won

    4

SerpentDagger last won the day on June 22

SerpentDagger had the most liked content!

Converted

  • Location
    Whatsitsplace, Whoknowsforshire

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

SerpentDagger's Achievements

Creeper Killer

Creeper Killer (4/8)

25

Reputation

  1. I was going to make a tweak in a 1.12.2 mod. (The graphing calculator linked to in my signature.) I've done that now, and everything works. The 1.12 version of LWJGL didn't overwrite the 1.16 one (Their file paths diverge at the version number of LWJGL), which left me somewhat puzzled as to what happened to the 1.12 stuff to begin with. Between these two Minecraft projects, I ported the graphing calculator to a standalone Java application, and installed my own version of LWJGL to work with. I think that must have overwritten the 1.12 set, and then was overwritten by the 1.17 set before I missed the 1.12, leaving me to think that 1.17 was responsible for both. All very irritating. lol I ought to apologize for this post, then, since it isn't really a Forge issue. When I do more work with my personal LWJGL projects, I'll install the libraries to a different directory from the one Forge uses, since apparently the installer has the same default. Thanks for the help!
  2. I want to develop my 1.16 mod on and off (and update to 1.17), but also be able to tweak mods in older versions of the game, without having to re-download the LWGJL dependencies every time I switch. This would be accomplished by having each version of Forge download LWGJL to an independent directory, instead of the default (which is what causes the new version to overwrite the old). Indeed. I'm not asking for help in outdated versions, just trying to work with more than one at a time. I do that also, but the problem is that the dependencies (LWJGL3, to be specific) of the new version of Forge overwrite the dependencies of the old one, since they're downloaded to the same workspace-external directory. The build path is also set up to expect them there, so if I were to move the files, I'd have to manually reconfigure the build path to point to the new location. That would be tedious to do for every single file, and the problem would rear up again if I ever had to re-run setup for some other reason. This is interesting. In truth, I haven't re-run setup for the older version, because doing so would overwrite the newer LWGJL files, and I'd rather be able to keep developing in the current version. I was mostly expecting it to work, however, when I tried it. Does this mean that it isn't possible to develop in old versions at all, or simply that the new resulting file structure wouldn't necessarily match the expected build path of my old project? If the latter, wouldn't re-running setup also reformat the build path to match? I thought that was automatic.
  3. I've long-since switched over to Forge 1.16, but recently got a feature request on an older mod, which I wanted to look into implementing. I opened up my old workspace, and discovered that the build path is no longer valid, because the new Forge dependencies overwrote the old ones. I suppose I could rerun the setup tasks every time I switched workspace (right?), but that seems like an impractical solution. Is there any way to have non-colliding build paths for the two workspaces, so that I can develop in multiple versions simultaneously?
  4. I've done some testing, and there are 3 things that cause the item to move. The first is when you return a success, the item will swing. Updating the returns as previously discussed achieves the desired result in this context. The second is when you return a consume, the item will bob if it is not in use. This means that if you try to use the pan while not able to do any panning, it will bob repeatedly (but not jarringly quickly). If you don't want this, you can return a pass, which has no visual effect. The third is when you set the damage value every tick. This is what causes the glitchy-looking vibration, and it would seem you can fix it by setting the damage less frequently (once every 3 ticks eliminated all unwanted movement in my experiments).
  5. This is your problem. The boolean parameter of ActionResult<T>#sidedSuccess is whether or not the game is running on the logical client, and so returns success on true, or consume on false. Your condition will usually be true, so a success is usually returned, which causes the item to swing. I don't think it's necessary to use sidedSuccess for this, but if you do, you should pass in World.isClientSide, or an equivalent. Regardless, the condition should be updated.
  6. Please post your code, so that I can see what might be causing this (I won't be able to respond until tomorrow, though, since I need to sleep now). I've never done this before, so my knowledge is limited. Here is a link to the documentation on the topic, though, which seems fairly straightforward.
  7. Yup, that's about right. The exact details of when you should do what depend on how you want it to work and look. Ultimately, that's up to you, so you should try to set something up using these tools, experiment a bit, and figure out what produces the best result. It seems like you mostly understand what's going on here, so that ought to go fairly well.
  8. It is responsible for determining how the hand moves, but it also does a bit more. Each ActionResult<T> has an ActionResultType and an object T. In the case of the ActionResult<ItemStack>, the ItemStack object of the returned ActionResult<ItemStack> is set as the held item. Additionally, these ActionResultTypes dictate what happens after your Item's logic has been run. They are queried with the ActionResultType#shouldSwing and ActionResultType#consumesAction methods. The former is self-explanitory, while the latter dictates whether or not the click will be further processed. For example, ActionResultType.SUCCESS both consumes the action and swings. This means that if you held an ender pearl in your offhand, and clicked with an item that returns a successful ActionResult<ItemStack>, the main item would swing, and no ender pearl would be thrown. ActionResultType.PASS doesn't swing or consume, so returning that would result in no animation of the main item, and an unblocked, thrown ender pearl. ActionResultType.CONSUME consumes the action, but doesn't swing, so that's probably what you want here. ActionResultType.FAIL behaves as PASS, but is used more in the context of Block placement, I think, and as a message to prevent a behaviour. For your purposes, I would probably recommend returning CONSUME unless LIvingEntity#getUseItemRemainingTicks (this is the value passed into Item#onUseTick) fits your requirements (you could also use LivingEntity#getTicksUsingItem), in which case you would return SUCCESS. It might also be helpful to return true from Item#useOnRelease, so that your item is used when released, in addition to initially.
  9. Within Item#use, you should call PlayerEntity#startUsingItem. This will start using the item when the item is used. You can set the maximum number of ticks that the item can be used for with the return value of Item#getUseDuration. While the item is being used, Item#onUseTick will be called every tick, and its integer parameter is the number of ticks left in the use duration. This is probably where you want to put your logic, since you mentioned that the player should be able to keep holding the item to keep the process going. At some point, the player will release the item, which calls Item#releaseUsing. Its integer parameter is the number of ticks that the item was used for, so you could also put some logic there.
  10. You should almost certainly use the Capability system for this purpose. Here is a link to its documentation.
  11. This is a warning that no category in the recipe book corresponds to those IRecipeTypes. The method that determines that is hardcoded for vanilla types only, so this is to be expected. It doesn't mean you've done anything wrong, or that the recipes will fail to work, and I don't think there's any way to get rid of it for custom IRecipeTypes.
  12. This effect is hardcoded for the Nether portal only. If you wanted to recreate the effect, I think you could perform similar operations on the projection matrix before rendering, which would be done in the EntityViewRenderEvent.CameraSetup. Unfortunately, this event is fired after the projection matrix is already loaded into RenderSystem, and with no reference to the general-purpose new MatrixStack that is passed around for rendering. In order to modify it, then, you would use RenderSystem#multMatrix() with your effect matrix. This method is marked as deprecated, which means it's not supposed to be called in general. I don't know what the consequences of doing so are.
  13. runData has an output folder that is specified by the build.gradle file. I think the default is src/generated. It will overwrite files that it's previously put there. The idea, I think, is that you move the files you need from the generated folder into your main resources folder, but the problem I found there is that the build.gradle file by default allows assets to be kept in the src/generated folder, and will look for them there, which causes weird conflicts if you don't delete everything from the generated folder and refresh the IDE. That's not very convenient, so I changed my build.gradle to ignore the assets in src/generated. These strings do not refer to textures, they refer to models, as I mentioned in my previous post. BlockState → Model → Shape & Texture. Because of the previous point, you are referencing the item model, which is a flat image that generally appears in the hand. The texture reference in the item model is defined correctly. Again, this is the block model, not the texture. The model is found correctly, and the parent is defined correctly, resulting in the correct shape, but the texture is not found. There should be an error message in the console window that tells you more information about the problem. These error messages tend to be quite helpful, so do look for it. It's probably a typo in the model json, a typo in the texture file's name, or a misplaced texture file. Since the model (again: model, not texture) doesn't exist, neither the shape nor the texture (both of these are defined by the model file) can be determined. This means that the game uses the default shape (a block) with the default texture (the "missing" texture).
  14. The Material specifies generic properties like whether or not the block can be collided with, how it interacts with pistons, whether it burns, etc. It won't solve your rendering problem, but will dictate some other relevant behaviors. Using the settings of PLANT is probably exactly what you want in this regard. In .minecraft/versions/[version_folder] there is a jar file, which you can extract somewhere convenient. In this extracted folder, there is an assets/minecraft folder, which contains the Minecraft assets which you can use as reference. A BlockState describes a combination of IProperty<?>s. Your Block's blockstate file maps these combinations to a number of model files to use for each one. You don't need to alter the BlockState of your flower to change its default model, but if you want to add different models for different combinations of IProperty<?>s, you would do so with BlockStates. Here is a link to how one interacts with BlockStates in code. Here is a link to documentation on writing a blockstate file. What you're looking for to change the default model of the block is the model file, not the blockstate file. A model file defines the elements and textures of a model in the world. Alternatively, the model file can reference a different model file that is already defined (the "parent" model), and simply alter the textures of that parent model. This is what the line "parent": "block/cross" does. It defines the parent model as being the one named cross in the folder block. To make your flower render with a cross model, then, you would use its model file to define its parent to be block/cross, and then alter the textures tag to use your own flower texture. textures is a tag containing a number of String variables, whose names should correspond to the parent model's definitions. The cross model has only one textures variable, which is named cross.
×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.