Few little optimisations

[crafter23456]

Description

Use Vanilla Minecart Speeds

• Minecart is driving like it should, I didnt made any tests how far it fly etc only if it works normal

Optimize World Time Updates PaperMC/Paper@70e091b

• time went normal, /time set X works. so should be fine

I bumped some dependencies and updated the velocity repo cause the link was broken. Log4j should be fixed with only the core in fact Paper did only the trove4j and log4j core in their 1.8.8 log4j bugfix.
PaperMC/Paper@2894af0#diff-9f5fad4c579c54b5c3b0080702b87b856679a932ee4338409dab8b8cebe06292R16
Besides of that I got inspired by the spigot 1.18.1 pom and changed gitdescribe to scriptus.
All builds fine. No console errors.

Checklist:

• I have reviewed my code thoroughly.
• I have tested my code.
• My changes generate no new warnings

[HowardZHY]

will @crafter23456
Use Vanilla Minecart Speeds
have an influence with Train Carts pl ?

[crafter23456]

will @crafter23456 Use Vanilla Minecart Speeds have an influence with Train Carts pl ?

dunno. it only changes the speed back to default when the cart is flying...

[HeathLoganCampbell]

Personal I think this is a lot of changes in one pull request which makes things really messy, I would suggest breaking them up especially since dep bumping can be high risk

[HeathLoganCampbell]

Is it safe to remove these?

[crafter23456]

I would say. Paper only use the log4j core and the other thing I don't remember currently but we have that too. And my anticheat has a fix for log4j which only activates if the server didn't done it before. Isn't a 100% trust but if paper do it, I guess

[Sculas]

Even though it would be safe, I don't think it's recommended to combine multiple versions of a library.
IMO, this should be reverted. There's no reason for this.

[crafter23456]

okay thats quiet weird. on my fork it builds, and here not. in fact that it builded here until we commited entityhuman out...

[ghost]

okay thats quiet weird. on my fork it builds, and here not. in fact that it builded here until we commited entityhuman out...

That’s because it can’t find bungeecord-chat and you have it cached

[Sculas]

Did you add that dependency? If not, we might have a problem again. Need to look into a Maven repository sometime for this.

[crafter23456]

okay thats quiet weird. on my fork it builds, and here not. in fact that it builded here until we commited entityhuman out...

That’s because it can’t find bungeecord-chat and you have it cached

no i mean on my repo on GH with the same GH actions xd on my server yes thats cached

Did you add that dependency? If not, we might have a problem again. Need to look into a Maven repository sometime for this.

I changed the velocity repo link cause it was outdated and the normal build script but it builded here already until we added a commit which isnt related if the api doesnt get found

[ghost]

Did you add that dependency? If not, we might have a problem again. Need to look into a Maven repository sometime for this.

It’s caused by the removal of the sonatype parent, I have a fix in crafter23456#3

[crafter23456]

there still open conversations from heath

[Sculas]

Even though it would be safe, I don't think it's recommended to combine multiple versions of a library.
IMO, this should be reverted. There's no reason for this.

[sadcenter]

@Lucaskyy I personally like the time per player feature, and it has no performance impact so yea. I used time per player and it worked on nacho

[crafter23456]

Personal I think this is a lot of changes in one pull request which makes things really messy, I would suggest breaking them up especially since dep bumping can be high risk

i split the boat thing into another PR. so now its not that much

[HowardZHY]

Is this getBlock could cause NoCom exploit server crash? At 2022-03-26 16:22:23, "Heath L Campbell" ***@***.***> wrote: @HeathLoganCampbell commented on this pull request. In NachoSpigot-Server/src/main/java/org/bukkit/craftbukkit/block/CraftBlockState.java:

@@ -132,7 +129,7 @@ public int getTypeId() {

} public byte getLightLevel() { - return light; + return getBlock().getLightLevel(); Like this might be good if CraftBlockState gets generated everytime getblock is created and getLightLevel isn't hit alot — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[crafter23456]

@HeathLoganCampbell I removed the new world time patch. Is there anything else I missed?