Jump to content

Alpvax

Members
  • Posts

    304
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by Alpvax

  1. 7 hours ago, Koolade446 said:

    the issue with this is if a player gets on a saw and player.tickCount % 20 is 14 the player could have 19 ticks or almost a whole second to get off the saw before a tick of damage would be delt so if they like ran across it they may not take damage.

    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

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

  3. 15 hours ago, ElTotisPro50 said:

    getEyeHeight or getHeight makes that the particles doesnt spawn i dont know if i have to add or substract something to eyeheight but it doesnt matter so im using getPosY() + 1.5

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

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

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

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

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

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

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

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

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

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

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

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

×
×
  • Create New...

Important Information

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