Basically development has been on hold, not much to talk about. I'm caught up with IRL stuff, along with most of the other members of the team. It's near the end of the year for school, exams are coming up, soccer tryouts for me, track meets, and my life to enjoy (field trips - yay).

Anyways, while you all wait for the next update, run this jar https://www.dropbox.com/s/o5q7pmzkzwwezi4/trident-1.0-SNAPSHOT-jar-with-dependencies.jar?dl=0 like craftbukkit, but with the trident-1.0-SNAPSHOT.jar instead. We'd love to hear feedback on how it is.

 

xTrollxDudex, Developer of Concurrency/Testing

February Update

Lots of stuff happening this week with Trident, and a small troll that I don't find amusing (anymore).

First off, I'd like to announce that in my personal opinion, not any other of TridentSDK's 4 members, think that Trident is production-ready. This means that CPU/Memory usage are decently stabilized enough to be used on a regular server. I highly recommend using it to test plugins, as much of the API is fully implemented (events will have to wait, especially on entities). We still have a lot of Vanilla features to implement, I'll discuss that later on.

Second, this week, memory usage is massively improved. Before, you could stay on for about 5 minutes with 7 view distance. Now, you can fly at maximum speed for over 1.5K chunks (* 49pi if you want the real amount of chunks loaded) before running out of heap space. This is using 4GB of memory on the default, or "Throughput" GC. I strongly, strongly recommend using the CMS if your hardware supports it. If you do some research, you'll find it takes up slightly more CPU - don't worry! Trident uses under 5% CPU usage (during non stop-the-world pauses) with 1 player sprinting around. It is enabled with JVM flags -XX:+UseConcMarkSweepGC -XX:+UseParNewGC. Additionally, this will instantly cause you to handle 6x more chunks loaded (in my tests, it fluctuates around 4-6). This means an extra 10K chunks for you just to play around with.

Third, some new additions.

API Changes:
- Added Services API
  - Transactions (tracking of transactions, such as economy and trade)
  - Chat formatter, modified prefix, suffix, prompt, and player name
  - Permissions (WIP)
- Added Injection API
  - Runtime
  - Mythbusterma is against this, don't depend on it being there
- Refactor Player "...speed()" methods

Implementation changes:
- Chunk unloading
- Better memory reclaimation
- Reduced chunk memory footprint
- Benchmarked ConcurrentTaskExecutor
- Start concurrent world management
- Create a world if it doesn't exist
- World saving

This is not all, basically, just the ones that come to mind as important. You can see the full changes at our GitHub, there's a link to it in the navbar.

Fourth, we still have a TODO list! A high one for me is implementing Permissions, as the other services are already done. Other TODOs for me include concurrent simplex noise, and more memory optimizations (the average job as a concurrency developer).

Here are stuff we want to do:
- Water flow
- Send block placement
- Fix player list
- Fix player count
- Fix skins
- Work on metadata (Mazen)
- Fix world block manipulation

Basically, that's a pretty decent TODO list for a snapshot release.

Finally, the troll. Our GitHub repository for Trident has an excess of 5K watchers in a single day. Yes, I have read, as well as every other member of the team, the story of that guy who got 5K followers (or something). Of course, we already know about this. We didn't do it. We are not responsible nor associated with the person who did this. That said, we hope GitHub will apprehend the culprit appropriately.

That's pretty much it for this month so far. Stay tuned, and be sure to sprea the word. Trident. Is. Coming.

xTrollxDudex, Developer of Concurrency/Testing

January Update

I thought that there was an update for this month already, but that is apparently not true... Anyways, here's another update on the internal state of TridentSDK.

First, I'm hopeful we can release Trident (yes, Trident, the implementation) at the end of February, however I am plagued with doubts on whether we can do it or not. The limited amount of sheer manpower and support is , unfortunately perturbing. For those who are interested, simply sharing Trident is enough if you aren't able to assist programmtically. Otherwise, there are things you can do if you are a developer.

In this post, I mention the list of things to do before we try to release:

1. There are TODOs in the code

2. Preventing the NPE if a player joins twice without restarting the server

3. Creating a default world if none exists

4. Block manipulation

5. Correctness of concurrency

6. CPU and memory usage analysis

7. API structure

This is not particuarly in order by priority. Before I move on to explain, let us pause and look at what the 3 of us in TridentSDK are doing. We are all currently working on fixing bugs with general player joining, including world generation, chunks, and world saving. Mazen is core bug fixing, Mythbusterma develops the implementation, although he has some IRL incidents which impedes his work. We are both (Mythbusterma, and me) going over concurrency, performance, and memory. That given, we are trying to complete multiple steps of the release todo list at once, between only 3 developers. I expect the first release to be for testing purposes, to flesh out all of the bugs that we haven't caught ourselves. The two that we'd like to finish are numbers 2 and 3 on the release todo list. If help can be found for what we are currently doing with world and chunk sending, that would be awesome as well.

I have also expressed interest in contacting competing development teams and previous generation developers to attain both feedback and faults in our code, as well as things we can learn from previous APIs. Because only the 3 of us make executive decisions, there is no feedback from the community, and we continue on to develop the API the way that we all would like, not what the community would like. This is why sharing Trident is important, because we are striving to perfect the API before it is released. The API is designed around the way it best fits the implementation, while making it essentially unextensible as a result (which, again we are juggling to figure out what we want - extensibility or conformation).

Second, I am personally going to be less active for this week, as it is semester finals for Science/Math/French, as well as starting a new online course in preparation for the case which we might move to a new district. 

xTrollxDudex, Developer of Concurrency/Testing 

Here is a draft of the software design document:

Dropbox

 

It's a PDF so it should be able to be displayed without having to download the actual file, unless your browser is incredibly stupid. Enjoy the read, it's a good 21 pages long.

Copyright © 2018 TridentSDK
Made by Vilsol