In the past month I have released two new mods (OK, a mod and a half) and demonstrated parts of a third. I can no longer arrange myself as if I am the author of only one Minecraft mod; I now have many.
This means that some areas of my site need to reorganize, particularly treating the site as the home of Me and Mystcraft. Now it needs to be my home, where we can discuss all of the things I’m working on, not just the oldest mod I have.
I’ve already rearranged the forums here, setting things up into a more categorized setup. The layout might change some depending on feedback, but the addition of the categories and space for other mod discussions should be very helpful. The blog and overall site layout will be changing in the near future. I have awesome people who are working on that for me.
I still need to rearrange the wiki, but… that’s more than slightly daunting and also feels like wasted effort. It’s a waste because I plan on killing the wiki.

Now I don’t plan on killing the wiki without a replacement, so don’t worry there.
A long time ago, when creating the wiki for Mystcraft here, I sat down with the other people in the community and we chose DokuWiki. Doku has served well enough, but I regret the choice.
At this point I wish we’d selected MediaWiki. MediaWiki supports much more advanced templating and macros right out of the box. SillyBits wrote a plugin for Doku at one point to add more to it, but it never got added in for various reasons.
At any rate, lots of things are going on in the back here and at some point I’ll swap the wiki out. Depending on how and when we might keep the existing wiki around to help with populating the new wiki, but one of the problems with the existing wiki is that it’s written really badly. More like a forum board or reference manual than a wiki.
Before I let people at the next wiki I intend to specify how it will work and layout some macros, templates, and standards first. I didn’t touch the existing wiki much, intending to allow it to evolve naturally. Natural evolution can end badly, though, is a good lesson here.
I do appreciate the people who have put information into the wiki. They have been really helpful to the community at large. It’s just that the wiki lacks a definite structure and newcomers to it often have difficulty finding anything in it. I want to fix that with the reboot.

This is an upcoming thing, though, and the site redesign is ongoing, so hang on to your chairs and we’ll try to keep you off the ceiling.
Cheers, and I look forward to where this is going. 🙂
-XComp, author of a bunch of things

If you’ve not already seen LookingGlass, you should probably check it out.

I’m releasing the first public API for LookingGlass. The source code will go open source very soon, now, but I want to make sure it’s clean first.

Mystcraft got some really cool features this week as well, particularly age recycling. Check out the change log for more information.

Note that all existing versions of LookingGlass will be effectively useless moving forward, as they didn’t have the API done. The versions of Mystcraft built at the time will only be able to use those versions of LookingGlass as well, so to be able to use the newer LookingGlass builds (with Mystcraft) you’ll need to update Mystcraft. From this point forward the API should remain fairly stable; no loss of existing functionality.

So I missed a line of code in Mystcraft and we’ve probably been suffering issues from that for like 8 versions now. Fixed it now, though.
I also added a little more sanity checking to things and cleaned up the released API jar.

I have had something every night this week, most of them deadlines and/or very late running activities. While, for the most part, I’ve really enjoyed these things, this has cut into my dev time.
Normally I’d recover on the weekend, but this weekend is similarly busy; events all day, everyday. I won’t even be home until Sunday night.

So, the purpose of this post is a forewarning to a probable lack of builds this weekend. I know everyone is eagerly awaiting the LookingGlass API, but it’s no use to anyone if I release it half baked. Particularly without enough javadoc.

I *might* be able to push builds early next week (Monday or Tues), but I’ll probably just hold off until next weekend, effectively skipping this week.

Sorry for the gap. I hope to not make a habit of this. I’ve managed pretty well thus far, since starting my weekly release schedule.
Cheers!

For a long time I’ve used Bazaar as my version control system. I’m sure that people have lots of opinions on this, but let me present why I chose this:

I wanted to be able to put empty folders in the repo.

I particularly liked the automatic rename detection in Bazaar. It does better than most other VC systems in that regard.

It was simple to use.

It’s fast.

There were probably other reasons, but those are the main ones in terms of practical reasons.
However, the main reason I chose it was I didn’t want to choose the other options.

The other options I considered were, of course, Git and Mercurial.
I didn’t want to choose one because I didn’t want to be seen as taking a side. Amongst a number of people you’ll find some interesting arguments over which one is better. I always find “my tool is better” arguments to be rather silly, so I opted out of them by opting for a different tool entirely.

Let’s discuss them a bit, before I get to my main point.

I’ve read a post about how Git is MacGyver and Mercurial is James Bond. I found the analogy quite apt (especially since they are both prone to making things go boom, so it’s fair).
Particularly, Git is complex; everything has it’s own tool or command and it’s a ridiculous Swiss army knife of gizmos which you pretty much have to be an expert to work with consistently. However, if you CAN work with it well then it’s really powerful.
Mercurial, on the other hand, takes a more monolithic approach; it’s got some nice gadgets for when you really need the laser watch, but it doesn’t expect you to use the laser watch on a daily basis. Instead, it gives you the core set of tools which will generally keep things running smoothly. It’s slick, fast, and likes its drinks simple.

This is as it should be, really. This is how they were designed.
Git was designed by an expert for experts. The expert in question didn’t think much of non-experts, so he didn’t care that it was complex.
Mercurial was designed to be fast and smooth. Nailed it. Mostly, anyway.

Bazaar… is just kind of there. I’m not sure what their main motivation was for creating it, but maybe Canonical just wanted their own version control system. Microsoft made one too, so it’s not unprecedented, but at least Bazaar works.

At any rate, back when I was choosing a version control system to graduate to (from SVN… *shudders*), I did my research… and while I found the above analogy good, I was completely disillusioned with either Git or Mercurial due to all the online arguments. I chose Bazaar.
By most comparisons, the three are nearly identical for basic use. They diff, they branch, they are distributed, and they are pretty much the same speed for most operations.

Now, years later, I’ve used both Bazaar and Git first hand. I have some new opinions on the matter.

This past week I was in Italy for a code camp with my colleagues (from various countries), and it turned out I was the Git expert. I found this funny, because I know Git from working on Forge.
However, I was also pushed into the role of fixing the repos and getting everyone working happily on their branches. This included some interesting and serious stuff that I hadn’t had a lot of practice with. I knew how to do it, roughly, but I’d not done it everyday for a week before.
I’m now pretty confident that I AM a Git expert…

And I like Git, suddenly.

Previously, when working on Forge changes, I’d always find Git slightly painful. It worked, but, in terms of version control systems, it’s the most likely to break. Or do something weird. Or eat stuff. Or produce nasal daemons (look that one up; you won’t be disappointed).

So, now I’m considering moving my personal repos from Bazaar to Git. The biggest thing is I’ve taken to certain features such as the branching mechanics of Git (especially the visualization and rebasing). The visualization features actually make it really rewarding (to me) to make branches. I know, I’m weird, but what can one do?

However, one of my original gripes with Git still exists: You cannot put an empty folder into the repo. This is because Git has no concept of file hierarchy; the names of the files include the hierarchy implicitly. This means renaming a folder actually is renaming all of its contained files individually. There are tricks to force a folder into the repo, but it requires creating dummy files, which is against my rules for repos, and it still doesn’t solve the renaming.
Git’s concept of a file is also a bit different, as Git considers changes, not snapshots or files or folders. This is where the limitation comes from. I admit that the tradeoff is pretty worth it for the underlying mechanics, though.

Some of my projects are going to need to migrate anyway, so I’ll do those and see how that goes. Bazaar includes systems for conversion to and from other version control systems, so that’ll make it easy. Now that I think about it, that option was one of my original reasons for selecting it.

Long post for something most people won’t care to read about, but I hope you enjoyed it. Let me know what you think! 🙂

This build focused on getting more API stuff in place, wrapping up some of the unfinished parts
I did a few other little things at the same time, to round out the build so it’s not just ‘inpotentia’ content. 😛

New API! Cool!
I know that this makes for a slightly underwhelming build to the average user, in that there’s little immediate direct gain, but ultimately a robust and powerful API will enable better mod interactions and plugins.

I also fixed a bug with the grammar system while I was there and improved the general handling of a few things, which resulted in better symbol attribution. 🙂

The API system is also getting applied to the new project, so there’s progress there, too. I’d hoped to be closer to making it public by now, but there simply has not been time. It’s getting there, though.

EDIT: I’ve pushed 0.11.6.01 to fix a problem with old vs new API resolution. This caused any mods using the old Mystcraft API to cause crashes in class loading.

EDIT AGAIN: I’ve pushed 0.11.6.02 to fix a problem I introduced in .6.01 (which was originally a single line change…). Due to casing issues, “API” wasn’t possible to send as an IMC message. 😛 Should work fine now.

Fixed some bugs and things.
Biggest new feature is rotatable Ink Mixers, Link Modifiers, and Book Binders.
Bit of API stuff. The API is beginning to ramp up some more, so I’ll hopefully get the API public again in the near future.

Things are happening in the background as well. My secret project is coming closer. 😀

Categories

Meta

This website stores some user agent data. This data is used to provide a more personalized experience and to track your whereabouts around our website in compliance with the European General Data Protection Regulation. If you decide to opt-out of any future tracking, a cookie will be set up in your browser to remember this choice for one year.I Agree, Deny