Alpvax
-
Posts
297 -
Joined
-
Last visited
-
Days Won
3
Posts posted by Alpvax
-
-
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).
-
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.
-
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 codeIn 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.)
-
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).
-
18 hours ago, Losokos said:
But i mean this works perfectly fine, and strikes lightning on player every second
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.
-
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.
-
6 minutes ago, Losokos said:
Thread.sleep(1000);
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.
-
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
-
I haven't done anything with entity renderers in a very long time, but it might be because your whole model is being rotated. If this is the case, you probably have the vine rotating further/faster than the grass.
One thing that might fix your issue would be to rotate the grass in the opposite direction (so the whole model rotates, but the grass is rotated back the other way so it is in the same orientation).
-
Try checking whether the other block is`this` (which is an easier way to check if it it red slime). If it is, return true.
If it is not this block, but is sticky (or it is slime or honey, because you say they do not return true for isSticky), return false.
Otherwise (for all other blocks) return true.
-
On 12/4/2021 at 4:11 PM, matthew123 said:
This entity is spawned only on the client
Why?
On 12/4/2021 at 4:11 PM, matthew123 said:if(blockPosition().getY() >= startingBlockPos.getY()){ remove(); return; }
If it has moved so it is above where it started, stop. That's why your tick method only runs once.
I imagine that things are going wrong because you're using a client-side only Entity. Just do what the FallingBlockEntity does and use the same Entity both sides
-
Quote
It's been a long time coming, but this is the final release for 1.17 as we move onto 1.18.
This marks the deprecation of 1.17 and the sustainance of 1.16 as our LTS version.
Should that deprecation / sustainance be the other way around? Or am I mistaken and 1.16 is being kept as LTS?
-
In the "tick" method , you need to set the y component of the deltaMovement to be positive (to rise) or negative (to fall). The exact value that you use will determine how fast.
//FallingBlockEntity uses the following values (when gravity is not disabled) //by adding the velocity, it allows the entity to have smooth movement and allows directions other than straight down this.setDeltaMovement(this.getDeltaMovement().add(0.0D, -0.04D, 0.0D));
Looking at the tick method of the FallingBlockEntity class it may give you a better idea of how it works.
-
I would do it by creating a subclass of FallingBlock (if it is still called that) and adding a targetHeight field, then making the block "fall" or "rise" to meet that height, before turning into the specified block. That way most of the code should be reusable from the parent class.
You will have to register it as a new EntityType.
Then when your block rises, you create a new instance of your entity, with the targetHeight one block higher than the current y position.
-
You should attach it to any itemstacks which might use it at any point in the future (so if is based on an enchantment, you only have to attach it to items which can be affected by that enchantment for example)
-
Always attach the capability provider to the item and add the check to the getCapability method of the provider instead. AttachCapabilitiesEvent is only fired when items are created
-
You must have a licence to drive a car. "Must is a strong word, the car runs without it".
Just because it works doesn't mean that it won't cause you problems down the line. And if you do it correctly from the start, you won't have to spend the time finding and fixing bugs later on.
-
21 hours ago, uSkizzik said:
If you're using IntelliJ, under External Libraries and then under Gradle: net.minecrafforge:forge:1.17.1-<Forge Versin>_mapped_<Mappings>
20 hours ago, Luis_ST said:another way to find the class would be to search for it
The IntelliJ shortcut to search is CTRL + N (by default)
-
On 10/15/2021 at 3:55 PM, jayxo said:
public class StatsManager extends WorldSavedData implements Supplier
Why are you implementing Supplier? (Also, you should include the generic type of Supplier).
You probably want to add a getter for a specific player. something like the following:
public DefaultStatsCapability getStats(UUID playerID) { // Bear in mind this can return null if the player stats have not been added yet. // You might want to use computeIfAbsent instead. return players.get(playerID); }
Then wherever you need the DefaultStatsCapability (for example in your book update function), get your instance of StatsManager, then get the DSC from it using the new getter.
On 10/15/2021 at 3:55 PM, jayxo said:public PlayerEntity player = Minecraft.getInstance().player;
A) This will crash on servers (which is where loading and saving of data occurs)
B) What is this for? All the players should be saved in the map.
-
17 hours ago, jayxo said:
for the players capability data, what kind of information would I put there?
Whatever you used to have attached to each player (only now it doesn't need to be a capability). All the stuff you want to display in the book
-
18 minutes ago, jayxo said:
it stores the players uuid if that would work?
Yes, I think that is linked to the player's GameProfile, so should never change.
13 minutes ago, jayxo said:in response to the level/world capability, how would i actually do that? im not sure if it’s useful, also eventually wanted to be able to use a command to get a players book even if they’re offline.
The same way you attach the capability to the player, but just attach a capability with a Map<player id, your current player capability data> to the overworld Level instead of attaching the data to the player directly. Then when you want to modify the data, get the capability from the overworld (which is always loaded) and get the data for the player with the given id.
Alternatively, you could use Saved Data (which used to be WorldSavedData), again using the overworld to access the player data.
That way it doesn't matter if the player is offline, because the data is saved to the overworld, so you just need to look up the data for the player by player id.
-
1
-
-
What do you mean? that you want the player to be able to have creative style flying when you activate an item? Or more like how fireworks work with elytra?
You need to override Item#useOn (for using on a block) or Item#use (for using the item on air (and possibly blocks with no right click action, I can't really remember)).
For the first approach, you need to set Player#getAbilities().mayfly to true (mojmap mappings). Remember to set it back to false when you want to stop.
For the second approach, you need to get the current Player#getDeltaMovement(), add a vec3 to it (either just a y component for straight up, or based on the Player#getViewVector() for "forwards")
-
On 10/11/2021 at 4:21 PM, jayxo said:
it would always show the player who opened it info.
I assumed that was what you wanted. Currently you get the capability of the player opening the book:
@SubscribeEvent public void onUse(PlayerInteractEvent.RightClickItem event) { PlayerEntity player = event.getPlayer(); ...
You need to use the player who "owns" the book instead. So store the "owner's" id in the book somehow (NBT/capablility), then when the book is opened, get the player from the id (they may not exist/be offline, in which case you can't reasonably update), then update the data.
It might be a better idea to change to a level (overworld) capability / saveddata if you need to access the data for offline players, then retrieve that data for displaying in your book.
As die7 says, it will probably be better to create a custom gui (based on the vanilla book screen, you can possibly subclass it, although I'm not sure), then retrieve the latest data on demand, rather than updating the item nbt each time.
-
Just now, Luis_ST said:
@Alpvaxthis is 1.16, storage and factory have been removed in 1.17.
please edit the posts you create and remove the wrong informationYes, that is what I am saying. Remove the old code (from the storage / default factory, which no longer exists) and put it in the Capability Provider directly.
(1.16.5 MCP) shoot particles
in Modder Support
Posted
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()).