Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Alpvax

  1. Why don't you want to use the forge config system? What are you trying to achieve? Any configuration should either be in datapacks or in forge configs, for maximum compatibility and ease of users changing things.
  2. @BogieninYou almost definitely shouldn't be setting the base value, that pretty much completely negates the point of the attribute system. You should add attribute modifiers to the entity instead. @FantaLaToneI think you should be able to just add multiple attribute modifiers to the effect, although I haven't actually done it before. If not you can override the methods in the effect class to add/remove the modifiers (by UUID) when the effect is added/removed from an entity.
  3. There isn't one, you have to loop through all the (shapeless) recipes and check them yourself (i.e. check that there is a single ingredient and it is in the logs tag (and probably also check the output is something sensible, as I mentioned before)). Alternatively, you might be able to look up the recipes manually by looping through the items in the logs tag, converting them to a single ingredient, then looking up the recipe for that single ingredient. I haven't ever tried, so I don't know how that would work, but it is probably more efficient.
  4. There is no "Exact code". You need to loop through the list of logs (that you got from the tag), and then compare those blocks with recipes which you can find from the recipemanager. Minecraft doesn't make any links between logs and planks other than the recipes. There is no good way to do what you want, because there is no way to define "Block Y is a plank version of log X". Just "If you craft log X by itself, you get block Y". If someone adds a recipe for a single log to a diamond block, does that make a diamond block a plank?
  5. Even so, what is the advantage of making your own slot, deliberately stopping players using your mod with loads of other mods, and having to write the code (which is already written in the other mod) yourself?
  6. You need to actually get the Item instance form the registry (by calling #get). Also, DON'T SHARE VANILLA CODE! You do not have the rights to share it, and we can all look it up for ourselves.
  7. implement the IItemHandler capability for the album itemstack and open the container when right clicking the item, just the same as you would for a block entity container
  8. Is your saveEntity function called? If you enable the debug data in game, can you see the tag on the itemstack (F3 + H I think allows you to view NBT by holding ctrl maybe? If not, there is always the data command)
  9. You should save this somewhere static, instead of computing it every time. That's not how forge events work. The event doesn't fire to set the size, it fires when the size is changed to allow mods to override it. It is called from the (mojmap) method `Entity#refreshDimensions`, so if you call that method you should restore the entity size. Alternatively, if you don't want to allow other mods to react to the change in size, just recompute the AABB as vanilla does (either setPos, or setBoundingBox(makeBoundingBox())), but I would strongly suggest using the first method.
  10. The best approach is to do what vanilla beds and doors do i.e. have multiple blocks placed when you place the item. Then when you break any of the blocks, break them all and drop a single item.
  11. There are 2 approaches to fix that: either increase the frequency and reduce the damage (e.g. % 10 do 0.75 damage) so that they have less chance to escape (but don't die instantly). Alternatively, perform the check every tick, but save whether or not the player was on the blade the previous tick, and if not, start damaging once/sec. This approach requires you to save the tick that the player stepped on the blade however (and check that `(current tick - start tick) % 20 = 0`) as well as whether or not the player was previously on the blade. I would suggest using capabilities (or at the minimum an NBT tag containing your modid) for this approach
  12. Did you make sure to call `Registration.init()` from your main mod constructor?
  13. It is called setParticleSpeed using the mojang mappings, I'm not sure what it's called using the MCP ones, sorry.
  14. Unfortunately I haven't actually looked at particles before, so can't be much help. However, if you look at the source of the constructor you are using you can see that it divides the velocity by the magnitude of the velocity (plus some other maths) so the particles won't move very far/fast. I would suggest experimenting with the `setParticleSpeed` method, which just sets the raw values.
  15. Yes, although if you have a server side container (which I assume you do for a BlockEntity based GUI) then you should only need the first part, as you already know the block entity.
  16. Don't EVER trust the client to report the correct amounts. Do all calculation of amount on the server, and just send "client requested X amount" to the server. The server should then verify that there is that amount in the block before giving it to the player. The client should never tell the server what the new amount in the block is.
  17. Yes, the eye height is the height difference between the player's feet and their eyes. You still need to use the player's y position as a baseline (i.e. getPosY() + getEyeHeight()).
  18. For position, I believe that the player position is where the player's feet are, so you should probably add an offset to fix that (player eye height would be a useful start point, but I'm not sure how it would look to spawn particles inside the player's head). As for the speed, that should probably be the player's look vector scaled by some amount (depending on how fast you want the particles to travel).
  19. PipeBlock uses blockstates to save the sides, and as a result can only have "connected" or "not connected" variants (it's the base for the chorus plant blocks). It doesn't help with having multiple parts possible for each side as well as "not connected" (for example my wire was initially 3 possibilities per side = 3⁶ = 729 states). For that you would need to have a dynamic model and use the modelData from the BlockEntity.
  20. You need to have a single block which can render any combination of "parts" on each side. I would suggest using a multipart model and using the modelData to decide which parts to render. I have some code I used before here, using a custom model but I was experimenting at the time, and the code is very messy. Edit: removed link to old, confusing code In essence, I had an enum for which part was on a face, and a model for each part, which I then combined with a rotation based on each face to produce the correct result. You might need a custom baked model, as I had (with custom loader I believe is necessary, but I can't really remember), or you might be able to use the standard multipart model. In my BlockEntity I had the following: private final Map<Direction, ConnectionState> connections = Util.make(Maps.newEnumMap(Direction.class), (map) -> { for (Direction d : Direction.values()) { map.put(d, ConnectionState.NONE); } }); @Nonnull @Override public IModelData getModelData() { ModelDataMap.Builder b = new ModelDataMap.Builder(); connections.forEach((d, s) -> b.withInitial(BakedWireModel.DIRECTION_DATA.get(d), s.getString())); return b.build(); } Unfortunately I don't know how much of the above has changed. (That was originally made for early 1.16.)
  21. Make sure your file encoding is set to unicode (utf-8). But you should probably be using translation TextComponents and putting your text in the ru_ru.json language file (note that you will need to have an en-us translation to see it on the server side, as the server doesn't load other languages).
  22. No, it doesn't. For each player on the server wearing the helmet, the game would freeze for 1 second each tick (there should be 20 per second). This would mean that if there were 2 players wearing the helmet, 1 in-game second would take about 40 seconds, otherwise known as the game freezing.
  23. Get the x and z positions of the bounding box, and only check the blocks that those positions are in (e.g if AABB is x = -0.2 to 0.8, and z = 1.6 - 2.6 then you need to check the blocks at: (-1, y, 1), (0, y, 1), (-1, y, 2) & (0, y, 2) (use floor to find the integers to get the blockPos)). That way you only check the 4 blocks that you know the player is standing in.
  24. You can't do that. "Every game tick while this is equipped, add a 1 second delay". You need to either count ticks (probably updating the item NBT so that it carries over saves) or check the time (probably save the "lastLightningTime" to NBT and compare it against the level time. Alternatively you could just do level time % 1000, but then everyone wearing the helmet would have lightning at the same time). As for your actual request, you need to loop through all blocks above the player position (player y to world height), and check that they are air.
  25. Bear in mind that players are 2 blocks tall, and I believe that the position is where their feet are. You need to either check whether or not the player's AABB is inside a block (i.e. loop through all blockpos which the AABB intersects with and check the block), or you need to use the position of the player's eyes. It depends what you are trying to achieve
  • Create New...

Important Information

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