1.11 Upgrade Status | Page 2 | Veterancraft Dedicated Server | Forum

A A A

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 4 characters - maximum search word length is 84 characters

No permission to create posts
sp_Feed Topic RSS dirt
1.11 Upgrade Status
Topic Rating: +4 (4 votes) 
December 30, 2016
4:38 pm
frelling
Senior Tech
Forum Posts: 3264
Member Since:
August 18, 2011
sp_UserOfflineSmall Offline
21sp_Permalink sp_Print
+1

All new development work has been completed. More code changes will probably be required here and there, but nothing to as detailed and in-depth as the past couple of weeks. The good news is that all this development has forced us to exercise most of our plugins and fix many pesky issues that are not always obviously.

BigScary - the author of GriefPrevention - gave me a big scareSmile While running a version check on 3rd-party plugins, I came across a statement  that s/he will be switching focus from Minecraft plugins to Indie game development. My face drained of all color as I had flashbacks recalling similar thing with Residence. Fortunately, BigScary's post on Facebook assures that all plugins have been handed off to others to maintain.

It is expected that any "test releases" will be short and intended mostly to perform any needed multi-user tests. Anyone is invited to given the test server a try when it is online, though at times we may restrict access for certain tests. Keep an eye on @veterancraft and the forums for more information.

Human beings, who are almost unique in having the ability to learn from the experiences of others, are also remarkable for their disinclination to do so. - D. Adams
January 2, 2017
9:28 pm
WallyBean
Salida, Colorado
Member
Members
Forum Posts: 128
Member Since:
November 25, 2012
sp_UserOfflineSmall Offline
22sp_Permalink sp_Print
0

Keeping an eye out for the test server to be online, will it be same address as before?

"The road to hell is paved with good intentions." -unknown
January 17, 2017
5:12 pm
frelling
Senior Tech
Forum Posts: 3264
Member Since:
August 18, 2011
sp_UserOfflineSmall Offline
23sp_Permalink sp_Print
0

I could swear that I posted a progress update last week, but I guess I did not do that. My apologies for not being more regular in keeping everyone informed. Given that this isn’t the first time, I think most of you figured out that something else got in the way or caused problems. While technically, “all new development work has been completed” remains true, I did not foresee the impact that plugin and server changes would have on the rest of the system.

JcChat, whose primary purpose was to provide chat-related functions, was also a “catch-all” for other functions (e.g. AFK management, spam fishing detector, newbie/Eden management, etc.; it was “messy”. We knew that it needed an overhaul, but didn’t expect that it needed to be done now. Once we realized the scope of changes, it was decided to abandon JcChat and fold its key features into JcCommunity, our general player-server admin plugin. This took time, some redesign, and coding to improve our abilities to manage player and intra-server communications.

One of the staple plugins for most Minecraft servers has been Essentials, providing a wide variety of commands and features. What some may not realize is that official development of Essentials was stopped in 2014, with its last official release on September 2014. Since then, Spigot and others have kept up maintenance versions, tweaking them as needed to accommodate changes in Minecraft, Spigot, etc. The good news is that Spigot’s md5 being a former author of Essentials is well-placed to keep it current.

Despite that assurance, Essentials or any of its branches (e.g. EssentialsX), while providing tons of commands, is also inflexible. Several years ago, we needed special requirement and condition checks to manage player AFK status and kicks. Our only choice was to implement our own AFK system as part of JcChat, which is now provided by JcCommunity. We need the same or similar abilities for several other Essential administrative commands. Also, sometime soon, we will replace Essentials sethome and teleportation features with our own. This is not only driven by the need to have better dynamic control over such features but to also provision EULA-compliant perks. Needless to say, we spent some additional time these past few weeks, porting several administrative Essentials commands.

We have been back in testing mode since the start of this week. Currently, we are feeling the effect of switching from our own permissions system to PEX. PEX is a great permissions system (central control, database driven, multi-world, multi-server). Unfortunately, it handles permissions in a different manner than we were accustomed to, particularly when it comes to groups and permission inheritance. We are currently reviewing permissions for all plugins and testing various configurations to attain the desires results.

Everything is being tested with Spigot 1.11.2. We still plan on releasing a test server, but are uncertain whether this will be a single test server or a full-clone of VC. More on that when we get closer.

Human beings, who are almost unique in having the ability to learn from the experiences of others, are also remarkable for their disinclination to do so. - D. Adams
January 18, 2017
12:17 pm
LightWarriorK
Aelfheim, Arda
Moderator
Members


Viceroy


Senior Mod
Forum Posts: 2154
Member Since:
June 1, 2012
sp_UserOfflineSmall Offline
24sp_Permalink sp_Print
0

Thanks for the update, frelling!  It's great to hear how things move along.  Good luck with the testing!

"Awake, oh man, and be wise." -Thoth
January 18, 2017
3:55 pm
SmellyTramp
Indiana
Member

Ambassador

Members
Forum Posts: 15
Member Since:
May 29, 2013
sp_UserOfflineSmall Offline
25sp_Permalink sp_Print
0

Just wanted to say how much I appreciate all the information you have been giving us on the updates. Very excited to check it all out! Good luck. :-)

Shhh...
January 18, 2017
4:11 pm
JSchub
Kentucky, USA
Member
Members
Forum Posts: 51
Member Since:
May 12, 2015
sp_UserOfflineSmall Offline
26sp_Permalink sp_Print
0

Thanks for all the hard work! Looking forward to 1.11. There will be plenty to learn and relearn. 

February 12, 2017
5:46 pm
Gide
Sweden
Member
Members
Forum Posts: 23
Member Since:
July 18, 2013
sp_UserOfflineSmall Offline
27sp_Permalink sp_Print
0
February 12, 2017
8:47 pm
spiketickett
Member
Members
Forum Posts: 7
Member Since:
March 29, 2012
sp_UserOfflineSmall Offline
28sp_Permalink sp_Print
0

Hope all of this works; I would like to finally have a mesa on VeteranCraft, either if it's a test server or a full one.Laugh

http://squiby.net/view/8751555.png
March 13, 2017
8:23 pm
LightWarriorK
Aelfheim, Arda
Moderator
Members


Viceroy


Senior Mod
Forum Posts: 2154
Member Since:
June 1, 2012
sp_UserOfflineSmall Offline
29sp_Permalink sp_Print
0

I've moved all the recent posts about the state of the server into this thread: http://www.veterancraft.net/fo.....ure-of-vc/

I HIGHLY encourage that the discussion be continued, but please keep this thread about the update.  Thanks!

"Awake, oh man, and be wise." -Thoth
April 24, 2017
2:08 am
Mr_Macintosh
Nashville
Member
Members


Viceroy
Forum Posts: 48
Member Since:
February 21, 2013
sp_UserOfflineSmall Offline
30sp_Permalink sp_Print
0

Any updates frelling? Smile I know I am anxious to see the server updated before the 95 degrees and 100% humidity of summer force me to spend more time indoors! Wink

If we don't study the mistakes of the future, we're doomed to repeat them for the first time.

April 24, 2017
2:51 pm
LightWarriorK
Aelfheim, Arda
Moderator
Members


Viceroy


Senior Mod
Forum Posts: 2154
Member Since:
June 1, 2012
sp_UserOfflineSmall Offline
31sp_Permalink sp_Print
0

Hey Mac!  I'll let frelling know, I know everyone is interested in an update, myself included.

As an fyi from myself, I know I've been MIA...I'm finally drawing to a close with Breath of the Wild and am itching to finish and get back on VC full time.  If anything needs doing, please PM me in the forums here.

"Awake, oh man, and be wise." -Thoth
April 25, 2017
3:07 am
frelling
Senior Tech
Forum Posts: 3264
Member Since:
August 18, 2011
sp_UserOfflineSmall Offline

One of these days I will write An Essay on VeteranCraft that provides an insight of what and how VC has evolved and the experiences - good and bad - it has had. I’m not joking, this essay will be written at some point; hopefully serving as a case study for any small software-based service. However, that effort would be as much of an undertaking, if not more, as this current rebuild of VC has been.

The good news is that we* have been working on extensive unit testing of our plugins and moderate integration testing of our plugins, third-party plugins, and Spigot for the past two months. The bad news is that we have been extensively testing for the past two months.

There are far more underlying reasons and motivations why testing is taking so long; whose explanation I will have to leave for that eventual essay. Even then I will have to keep them short to avoid the essay turning into a treatise on software development and philosophy.

In simple terms, all programmers, including us, tend to write code that sucks**, to some degree or another. Anyone that denies this is lying to themselves. The first version of any software we have written looks nothing like its later versions. It is only after multiple design iterations, unit testing, design reviews, integration testing, and actual use, that - if everyone is honest with themselves - higher quality code emerges. This is one of the reasons why VeteranCraft will almost never use a third-party plugin for which source code is not available.

Anyone that has written a plugin knows that there is a certain level of “construction” work or boilerplate code that must be written before it can get to the meat of the matter, i.e. the design and business logic that implements the intended purpose of the plugin. Over the years, we created a collection of support libraries that eliminated or reduced this boilerplate code to a couple of lines, allowing us to concentrate on business logic design, when other developers resorted to copying and pasting the same code from one plugin to the next, over and over again.

Our library contained routines for classifying blocks, processing command line arguments, interfacing with database servers, exception handling, a plugin base, intelligent command and event handlers, processing location data, handling metadata, processing text, and a couple utility classes handling a variety of purposes. The benefits of such should be obvious. If an update breaks a library function, it can be fixed and tested in one place, inherently fixing at once one or a dozen plugins that broke because they used this function.

Alas, over the years, this library collected a lot of technical debt; most commonly the downstream cost of suffering the effects of a quick fix rather than rewriting to do it right. At other times, we came up with better ways to do something but applied it only to the plugin that caused the inspiration. Ideally, we should have updated all older plugins to use the same, but when rushing to minimize update times, it is easy to ignore the eventual “bill”. It is no different than charging to a credit card; a painless process until the credit card statement arrived. Sooner or later it must be paid before interest piles up.

A couple of years ago, we were forced to pay off some technical debt as part of the transition from Vetronia to Arda. Although there were other factors of a personal nature that contributed to Arda’s delay, the partial payment of technical debt had a significant contribution.

When we restarted update efforts late last November, we knew that we had to pay off the whole debt. Not only did the library need to be redesigned, we needed to update all existing plugins to use it, biting the bullet to remove legacy code and structures such that all plugin designs are consistent. Knowing full well that VC needed to be scalable to handle other server instances for specialized purposes, we had to plan the design to allow for better server, data, and player management in the future. Additionally, we needed to write a few new plugins to replace ailing plugins such as iConomy, JcChat, etc.

The last hurdle was unit testing. Bukkit on its own is horribly unsupportive of unit tests. Over the years, we had collected a reasonable test library that supported plugin unit testing; but to be blunt it sucked. Back in December, I posted the article Nuts & Bolts of Unit Testing that discussed one issue. At that time, our unit test library allowed us to test basic functionality, but as with our main libraries, it acquired a lot of technical debt also. We had several different ways to test and it wasn’t consistent across all plugins. The result being that while we did unit testing it wasn’t thorough.

As a result, numerous bugs remained undiscovered until integration and manual testing. We knew this had to stop. It is too time consuming to test every possible permutation and combination in which a plugin can be used manually. If VC is going to grow and required other plugins developed by us or third-parties, we needed to be more proactive with unit testing. Alas, we paid off that technical debt by redesigning our unit test framework and environment. The cost was hefty. We started plugin testing early February and are still rewriting parts of our testing environment. The result is that rather than having at most a dozen unit tests per plugin, the average count is about 40, with our heavy-hitter plugins having 70+ tests each. This does not count unit tests of third-party plugins, which is something we are intentionally holding off on. Unit testing continues to improve. For example, last week, I refactored all plugin unit tests for a third time due to a fundamental – but needed – change to the framework to reduce unit test execution times. I could have ignored it, but that would be falling back on old habits.

An unfortunate, but beneficial, side-effect of increased unit testing uncovered that we still write code that sucks – a little – resulting in more rewrites and refactoring of our plugin and libraries. However, today, we have greater confidence that our code will run as intended whenever changes are made. It is not a 100% guarantee, which itself is an asymptotic goal, though every iteration will increase that guarantee.

Alas, unit testing for all its benefits, is not a panacea. While we can also use the same approach to perform integration testing between our own plugins, third-party integration can only happen at runtime via manual testing. A common cause of problems at runtime are plugins stealing or processing events in an unexpected manner. Again, Bukkit has very limited support for debugging event handling in a live environment short of timing tests. This is a problem that all server administrators face.

In the past, we maintained a customized version of whatever Bukkit version we used that had the means of logging events as they are fired, what plugins processed them and the order in which they were processed. While this was extremely useful, it had its own problems. To be used, the customized version had to be installed and started. Likewise, upon a new Bukkit release, debugging features had be merged into it, recompiled, and redeployed. Given the DRM work-around used by Spigot, these features needed to be applied as patches that did not necessarily migrate from one update to the next.

A better solution was developed last month that comes in the form of a debugging library and a plugin. Instead of patching code, this library can install a decorator around each registered event handler to log events. The plugin is just an interface to the library through which rules can be loaded as to which events are logged. This has eliminated the need for patching code and maintaining two versions of server JARs for each release. This tool allows us to dynamically start and stop event logging to see what plugins may be interfering, abusing, or just plainly wrongly using a particular set of events.

Just after Easter, Mudwog sent me a link to this announcement – Removal of Ebean ORM. My first reaction was to jump for joy because I had championed its removal, or at least an update, in this post about a year ago. For once there was some good news. Since that post, we had relegated ourselves to use asEbean "as is" rather than suffering the complexities of removing/replacing it. The older version still provided excellent ORM, though the new version would add features that we would love to leverage.

My second reaction was to verify that our database support libraries would not be affected. We should be able to have the same version of Ebean added as a dependency and provided by us instead. I spent a few hours creating an Ebean-less version of Spigot to test against. Sadly, the compiler started to bark errors. Some of our support classes relied on something we thought to be provided by Ebean, but instead was provided by Spigot. Fortunately, it was a quick fix to use a corresponding Ebean-provided class.

Thus, the good news, is that we will not be affected by the elimination of Ebean ORM in Spigot. Then again, from what I could tell at that time, The World of Colour Update (Minecraft 1.12) first came to light on March 13 with no official or educated guess as to its release date. As to using the latest version of Ebean ORM, that is something that can wait. Given our redesign, it will be a simple matter of removing a few secondary support classes and updating our database interface. The change should not percolate any modifications into database-dependent plugins.

It appears that I have already started writing the strawman of an essay. The goal was to let everyone know that a lot is being done. Unfortunately, the manner in which it is done is a necessary evil. Obviously, this would not be a sound business practice. But that is exactly the reason why we are spending so much time with this rebuild. We want to commit to having no significant technical debt such that lengthy updates – those that are under our direct control – are a thing of the past. Without this, we may just as well resign ourselves that VeteranCraft is a hobby and will never get better than it is – when properly updated. Some of our past and current members may be happy with this, but I would not be as content.

I have purposefully not mentioned any dates or times. We are too committed to the rebuild once and for all to allow a deadline to have an effect. We have an internal deadline, but I have already scored a trifecta being wrong. There is no sense to potentially add more pain.

I will say this. We understand most members are off elsewhere; after all, they still need to get their fixes. Having taken this long, VC continues to increase the risk that some members may have made another server their home and may not return. We’d love to think that once VC is current that everyone would come back, but that is just a dream. For those, you have my sincerest apologies that I could not do better by you.

We will keep the doors open. We will try our best to transfer all data as it is now to the rebuilt VC and we will not expire anyone’s Shillings, inventory, claims, etc. for at least two months thereafter. Thus, most returning members having joined or built since roughly the end of 2015 will find all their things where they have left them. It should be noted that this does not include unused claims or builds for which specific removal requests were issued and performed since end of 2015.

Best regards,

Frelling

 

Addendum (4/27/17)

Silly me, how could I forget to mention this important part. Another task of the overall VC rebuild is to be more manageable and deployable by a PaaS (Platform as a Service) and IaaS (Infrastructure as a Service) system. Currently, we roll our own pseudo-PaaS with OpenVZ and KVM, which work perfectly well. Although we are acutely aware of the adage “If it is not broke, don’t fix it”, we do need to perform due diligence by examining deployments requirements of stable PaaS/IaaS systems such as OpenStack, CloudStack, or OpenShift; and, potential integration with other services deployed on AWS or Azure. Mind you, most of these are thought experiments and intended to provide fodder for our future plans.

 


* - I should say “I” instead of “we,” since Mudwog hasn’t had any time to devote since February. Unexpected work and family issues have his attention elsewhere. Blame is not being cast; but I do dearly miss him and his absence is quite noticeable. Couple that with my own issues and processes wind up not as effective and efficient as they could have been. I hope to see him return within the next few weeks. However, I will continue with the “we” as LWK is also an integral part, though lacking the coding skills of Mudwog. However, he is eager and chomping at the bit for us to get where we need to be so that he can start making VC once more the great experience we all have come to know.

** - The term suck does not imply non-functional. Competent programmers can write code that works; however, just because it works, does not imply that it is great or of high quality. Lack of testability, high degree of coupling, code that is not self-documenting, lack of cohesion, etc. are attributes of code that sucks.

Human beings, who are almost unique in having the ability to learn from the experiences of others, are also remarkable for their disinclination to do so. - D. Adams
April 25, 2017
8:05 pm
LightWarriorK
Aelfheim, Arda
Moderator
Members


Viceroy


Senior Mod
Forum Posts: 2154
Member Since:
June 1, 2012
sp_UserOfflineSmall Offline
33sp_Permalink sp_Print
0

Thanks for the post, frelling!  Please let us know if we can be of any help!

"Awake, oh man, and be wise." -Thoth
April 26, 2017
1:28 pm
Trip6s6i6x
Member
Members


Knight
Forum Posts: 155
Member Since:
November 3, 2012
sp_UserOfflineSmall Offline
34sp_Permalink sp_Print
0

Seconded on both counts. If there's anything us regulars can do to help test things (once it gets to that point), let us know - there are still a number of us lurking around at the ready to help with whatever we can. And thanks as always for all of your hard work on everything, frelling! 

Don't Panic -Douglas Adams
No permission to create posts
Forum Timezone: America/New_York

Most Users Ever Online: 442

Currently Online:
5 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

Emulated: 3206

ryanpitts: 1300

Dalferes: 747

Pherian: 660

Okarim: 594

Member Stats:

Guest Posters: 10

Members: 14558

Moderators: 3

Admins: 2

Forum Stats:

Groups: 8

Forums: 45

Topics: 6229

Posts: 27412

Newest Members: krissu1, Knvpllnop, hvmzxkmqkel, axpwyfhtety, ezjywjicleb, dianart69, detstvopro, DJkukispift, GeorgeLam, adeledc60, christylv16, DianeMoith, carlakx18, Richardzip, kaylawf4, Angellinavirt, minutewicle, Stevenedusa, RonaldBramy, BillieSit

Moderators: terrorisly: 424, mudwog: 127, LightWarriorK: 2154

Administrators: meatbawllz: 2475, frelling: 3264