API Design v2 #11

3 years ago

Avatar of teej107
teej107, Member
Offline

I know I said I would be happy to help. I've been busy though :P Sorry! Since this thread has mostly (if not all) command suggestions, what do you think of a system like this?

Also I wish there were more methods for packet sending. In Bukkit there is only AFAIK sendBlockChange and one for maps I think. A library for mob AI would be nice to. It could be as simple as making a mob walk to a block or maybe a factory type thing. 

One thing I never liked about Bukkit is it's lack of documentation about null ItemStacks or AIR ItemStacks. It would be easier to just have all null ItemStacks be AIR in the API's eyes.

 

0

API Design v2 #12

3 years ago

Avatar of sidboy55555
sidboy55555, Member
Offline

oh, sorry xTrollxDudex i'm not a big of a reader xd, but if I could script I would definitely help.

But if you need a tester you can always ask me, for people that want me on skype, my username is the same on skype.

1

API Design v2 #13

3 years ago

Avatar of xTrollxDudex
xTrollxDudex, Admin
Offline

teej, I think the commands idea looks great, and it has some concepts that I had going for a bit as well, but there are a few things that it fails to address.

 

One of those is repetition, which the builder would be advantageeous. Granted, you could use class wide annotations, but either way, making multiple groups of commands can take up a lot of class space in general.

 

For your annotations, it's a pretty generic idea. While you've compressed multiple possible annotations together in order to reduce total characters typed per command, it makes the superannotation is a bit unruly and difficult to type. Again, you counter by including default arguments, but again using many arguments will still repeat and result in more work than using a builder.

Your varargs and custom parameters which are injected is a very clever idea. In fact, I had thought about a similar system for events, but the code for handling events was much more difficult due to the variety of data types and defensive programming needed to counter the complexity of handing that (which was why it isn't included). However, for commands, that seems to be a great idea since everything is in String form. I'll think about that

 

Again, looks like good stuff despite my limited skimming of it. I will get back to it once I can get IntelliJ to work on my computer again :)

 

sidboy55555 certainly, you could test any time you want. Go to our GitHub page as click on Tridnet, there's download instructions on the README and you use it like any other terminal/cmd Java program.

0

API Design v2 #14

3 years ago

Avatar of Luke__
Luke__, Member
Offline

Thinking about it... You shouldn't work on any api implementations yet, or better yet: use Sponge plugin API. Your main focus should be building the "NTS(net.trindent.server) <- {This is random, you should ignore it}". If you can get that done. I would be more than happy to help you slove implementing one of the existing plugin API's. Also about that Chunk part... Chunk byte size is way to large. The default should be: BUFFER: 8096 and Chunk sector 2048 bytes

Last edit by Luke__, 3 years ago
1

API Design v2 #15

3 years ago

Avatar of xTrollxDudex
xTrollxDudex, Admin
Offline

Sponge plugin API

One of the things that TridentSDK tries to do is to ensure that we maximise compatibility and total control over both the implementation and the API exposed for it. We've discussed it as a team whether we could look to implement Sponge's API, but agreed that it was something we are not going to do. Sponge's API was designed for a minimally threaded server and their API was designed to meet different specifications and for different purposes than what we aim to do.

 

BUFFER: 8096 and Chunk sector 2048 bytes

This is where I am confused - I am assuming that your BUFFER refers to 'ChunkHandler' as in it is a chunk buffer to store chunks. 8096b is simply not enough to store all of the loaded chunks on the server, given that each (as I will mention later) ChunkSection is 2048b.

 

As for ChunkSectors, that is definitely something I believe I have missed myself. Assuming that your sector refers to the literal 'ChunkSection.java', then this must be what you are talking about, no?

I was thinking to address your second memory suggestion that we should null the raw data arrays and keep just char[] because those are useless during the normal running time of the server unless chunks don't change as they are saved, but we can spare some extra time to re-encode the raw data again.

 

Again, these are great suggestions, but it would be nice if you could provide a little extra detail pertaining to your terminology.

0

API Design v2 #16

3 years ago

Avatar of Luke__
Luke__, Member
Offline

Okay, I might start creating pull requests to optimize chunk encoding.

Also, by saying sponge API, I mean how the api is built, anyway this is what a command should look like:
http://pastebin.com/6htk5FBY

0

API Design v2 #17

3 years ago

Avatar of xTrollxDudex
xTrollxDudex, Admin
Offline

Ah, I will look at it and see what I can do. Chunks are slightly broken at the moment so you might have a little trouble with testing accurate numbers.

0

API Design v2 #18

3 years ago

Avatar of Luke__
Luke__, Member
Offline

Um, do you have a TODO?

Last edit by Luke__, 3 years ago
0

API Design v2 #19

3 years ago

Avatar of xTrollxDudex
xTrollxDudex, Admin
Offline

Yes. https://tridentsdk.atlassian.net/plugins/servlet/mobile#issue/TRD-17

Last edit by xTrollxDudex, 3 years ago
0
Copyright © 2018 TridentSDK
Made by Vilsol