@Lunex - I agree totally. A proper status and error handling system is on my todo list, but I want to get the core functionality done before I start polishing. Fixed in v0.97.
@Everyone else - I got save and load 95% working last night. There's still an issue with detecting when structure tabs are added/gain/lose focus and how that triggers the enable/disable of the Save menu item that I need to address. I also need to include a texture override to allow you to save the 'standard' (i.e. not freeform) structures using a specific texture. Both of those should be done tonight, so I'm aiming to release version 0.96 with save/load functionality then.
OK, you begged, you cajoled, you angrily waved pitchforks and flaming torches... version 0.96 has just been released, and includes the following updates:
[*:6tzleo7h]Save and Load: Save and load any of your created structures. Format is XML based, making it simple to manipulate or display the data using XSL.
[*:6tzleo7h]Freeform Scaling: Similar to the Layer Scaling, this allows you to change the size of the Freeform Design panel. Now actually scales the textures correctly!
[*:6tzleo7h]New Textures: Added Water and Lava for your delectation.
As I said, because it allows you to use a lot of different tools to display the data in many different ways, including things like Style Sheets which could potentially display the layers in a web format.
If I were writing a high performance messaging layer for a trading system then I'd use a byte based optimized format. If I'm writing a flexible save format for a non real-time application whose most complex saves are only going to amount to a few hundred kilobytes, and whose formatted contents will in all likelihood be changing in future releases, and I want to maintain guaranteed backward compatibility with those earlier releases, then I choose an XML based format.
As I said, because it allows you to use a lot of different tools to display the data in many different ways, including things like Style Sheets which could potentially display the layers in a web format.
None of the current XML based tools would be able to display your saves in any meaningful way. Especially considering that they will be reading them in a specific way (Looking for certain properties). Style Sheets don't use XML format.
For exporting to a HTML based display you would have to write custom code to generate the HTML and CSS anyway so for that there is no advantage having saves in XML.
Quote from LankyBrit »
If I'm writing a flexible save format for a non real-time application whose most complex saves are only going to amount to a few hundred kilobytes, and whose formatted contents will in all likelihood be changing in future releases, and I want to maintain guaranteed backward compatibility with those earlier releases, then I choose an XML based format.
Simple Formats offer exactly the same. There just as flexible and backwards compatible.
Ultimately its your choice, but i still don't see any good reason for using a format that has more disadvantages than a simpler custom format(Simple Format also has the advantage that its easier for other people to parse).
The Meaning of Life, the Universe, and Everything.
Location:
Pacific Northwest
Join Date:
10/18/2010
Posts:
61
Minecraft:
Drakmyth
Member Details
Quote from Stucuk »
Simple Formats offer exactly the same. There just as flexible and backwards compatible.
Ultimately its your choice, but i still don't see any good reason for using a format that has more disadvantages than a simpler custom format(Simple Format also has the advantage that its easier for other people to parse).
Not sure I agree with these points. While custom formats are definitely flexible, having used them a few times on my own projects, I have been bitten by backwards compatibility issues after adding a new keyword or section or something. Was my format well designed? Probably not, but using a simple format doesn't instantly mean backwards compatibility. (Of course, the argument could be made that certain changes to an XML format would cause the same problem.)
I do have to disagree with being easier to parse though. Unless you release your own parser, grabbing an existing XML parser library, or using one native to whatever language/framework you're using, is likely both easier and faster than writing a parser from scratch, especially as you will have to update that parser any time the format changes (which is far more likely to happen with a custom format).
I've seen perfectly valid uses for both styles, and in the end does it really matter (Edit: for this project)? Unless you're making schematics equating to megabytes of data, that could be significantly reduced in size by using a custom format I don't really see any difference.
Edit: Forgot to say, amazing job with this application. I planned one of my latest houses with it and it turned out exactly like I planned it. I'm super excited about the save/load functionality.
Load the save file into a text editor. Replace the word 'Cobblestone' with 'Stone'. Hey, I've just applied a mass change to my design.
I don't understand. With both formats you can do that. Both formats are text based not binary.
Quote from Drakmyth »
but using a simple format doesn't instantly mean backwards compatibility.
Thats why i said its just as backwards compatible rather than its more backwards compatible. Its not more or less backwards compatible than XML.
Quote from Drakmyth »
I do have to disagree with being easier to parse though. Unless you release your own parser, grabbing an existing XML parser library, or using one native to whatever language/framework you're using, is likely both easier and faster than writing a parser from scratch
Different XML Parsers read them differently. Some may not read the file correctly. If you take a look at COLLADA, different model editors parse it differently, some won't understand the other model editors implementations. Thats why complex formats are bad as you can't garentee that all parsers made for it will be able to handle every situation.
Quote from Drakmyth »
especially as you will have to update that parser any time the format changes (which is far more likely to happen with a custom format).
No you don't. You don't need to edit the XML parser just to write a value, so why would you need to for any other format. Both formats hold Objects, Parameters and have children. You don't ever need to update the parser when the data is changed.
Quote from Drakmyth »
in the end does it really matter
Depends on if other people are interested in making an importer for there application so that it can load the Structure Planners files into it. If so then making it as easy as possible for them to load it(With the least amount of possible errors) would be a good idea.
Look, there are going to be two formats supported by this application. One is the XML based one, and one will be an NBT export. You clearly don't like anything XML based, and that's your right and opinion. A large group of people agree with you, and a large group of people disagree with you.
This will be my last post on the subject. For the record i don't dislike XML, i just believe people should pick formats based on whats best for what they are doing rather than just because everyone else uses a format.
@Kataris: I normally reference the Reddit thread for installation instructions, just because there were so many good troubleshooting discussions there. You can find the Reddit thread here.
If you're just looking for a straight download link then you can get the JAR file from MediaFire. I normally direct people to Minecraft Workbench but it appears that they haven't approved the 0.96 update for posting to the main site yet. It'll turn up there eventually :smile.gif:
@knoffelstokkie: Click on the 'Structures' menu at the top of the screen. When you select one of those structure types a design tab for that structure will open in the vast grey wasteland below the menu bar. You should recognise the rest from the screenshots posted earlier.
Hmmm - probably throwing an exception then. Go to the Reddit thread and try running the application from the command line (instructions are in the thread.) I'm guessing that your Java3D install is FUBAR'd; don't worry though, there are also instructions for fixing that in the Reddit thread.
@Everyone who's having issues with the Java3D / 3D view panel. Please go to the MediaFire link and download version 0.97.1. I've just added a whole bunch of error tracking and reporting code that should at the very least let us know what's going on with the application on your respective machine/environment.
Either screenshot any error dialog that shows up, or copy/paste the stack trace from the dialog and send it on. Should give me a better idea of what's happening with your installation.
I'm having the same troubles as knoffelstokkie I think. When I open up the program I get the white screen and nothing happens when I click on any of the things in the Structure tab. I've moved over the java3d jar files also.
@franx12 - Not ignoring you, I'm just insanely busy at work this week. I'll post detailed step-by-step debugging instructions, with pictures, as soon as I get the time to put it together.
@Everyone else - I got save and load 95% working last night. There's still an issue with detecting when structure tabs are added/gain/lose focus and how that triggers the enable/disable of the Save menu item that I need to address. I also need to include a texture override to allow you to save the 'standard' (i.e. not freeform) structures using a specific texture. Both of those should be done tonight, so I'm aiming to release version 0.96 with save/load functionality then.
Home of the Minecraft Structure Planner application.
[*:6tzleo7h]Save and Load: Save and load any of your created structures. Format is XML based, making it simple to manipulate or display the data using XSL.
[*:6tzleo7h]Freeform Scaling: Similar to the Layer Scaling, this allows you to change the size of the Freeform Design panel. Now actually scales the textures correctly!
[*:6tzleo7h]New Textures: Added Water and Lava for your delectation.
Enjoy!
Home of the Minecraft Structure Planner application.
Why do people pick XML? Its an over the top format with loads of wastage. You can easily code a simple format thats flexible in about 10-20 minutes.
Writing a parser for the above is simple in any case.
Minecraft Info - Game Requirements - Minecraft Screensaver - MCI Craft
If I were writing a high performance messaging layer for a trading system then I'd use a byte based optimized format. If I'm writing a flexible save format for a non real-time application whose most complex saves are only going to amount to a few hundred kilobytes, and whose formatted contents will in all likelihood be changing in future releases, and I want to maintain guaranteed backward compatibility with those earlier releases, then I choose an XML based format.
Home of the Minecraft Structure Planner application.
None of the current XML based tools would be able to display your saves in any meaningful way. Especially considering that they will be reading them in a specific way (Looking for certain properties). Style Sheets don't use XML format.
For exporting to a HTML based display you would have to write custom code to generate the HTML and CSS anyway so for that there is no advantage having saves in XML.
Simple Formats offer exactly the same. There just as flexible and backwards compatible.
Ultimately its your choice, but i still don't see any good reason for using a format that has more disadvantages than a simpler custom format(Simple Format also has the advantage that its easier for other people to parse).
Minecraft Info - Game Requirements - Minecraft Screensaver - MCI Craft
Home of the Minecraft Structure Planner application.
Not sure I agree with these points. While custom formats are definitely flexible, having used them a few times on my own projects, I have been bitten by backwards compatibility issues after adding a new keyword or section or something. Was my format well designed? Probably not, but using a simple format doesn't instantly mean backwards compatibility. (Of course, the argument could be made that certain changes to an XML format would cause the same problem.)
I do have to disagree with being easier to parse though. Unless you release your own parser, grabbing an existing XML parser library, or using one native to whatever language/framework you're using, is likely both easier and faster than writing a parser from scratch, especially as you will have to update that parser any time the format changes (which is far more likely to happen with a custom format).
I've seen perfectly valid uses for both styles, and in the end does it really matter (Edit: for this project)? Unless you're making schematics equating to megabytes of data, that could be significantly reduced in size by using a custom format I don't really see any difference.
Edit: Forgot to say, amazing job with this application. I planned one of my latest houses with it and it turned out exactly like I planned it. I'm super excited about the save/load functionality.
I don't understand. With both formats you can do that. Both formats are text based not binary.
Thats why i said its just as backwards compatible rather than its more backwards compatible. Its not more or less backwards compatible than XML.
Different XML Parsers read them differently. Some may not read the file correctly. If you take a look at COLLADA, different model editors parse it differently, some won't understand the other model editors implementations. Thats why complex formats are bad as you can't garentee that all parsers made for it will be able to handle every situation.
No you don't. You don't need to edit the XML parser just to write a value, so why would you need to for any other format. Both formats hold Objects, Parameters and have children. You don't ever need to update the parser when the data is changed.
Depends on if other people are interested in making an importer for there application so that it can load the Structure Planners files into it. If so then making it as easy as possible for them to load it(With the least amount of possible errors) would be a good idea.
Minecraft Info - Game Requirements - Minecraft Screensaver - MCI Craft
Let's move on.
Home of the Minecraft Structure Planner application.
Minecraft Info - Game Requirements - Minecraft Screensaver - MCI Craft
This looks awesome, and I'd like to use it.
I know I'm probably missing something very obvious but when I load the app I get this
is there anything I should load for it to look like the example pic?
Regards
Me
If you're just looking for a straight download link then you can get the JAR file from MediaFire. I normally direct people to Minecraft Workbench but it appears that they haven't approved the 0.96 update for posting to the main site yet. It'll turn up there eventually :smile.gif:
Home of the Minecraft Structure Planner application.
Home of the Minecraft Structure Planner application.
Cheers,
LankyBrit.
Home of the Minecraft Structure Planner application.
Either screenshot any error dialog that shows up, or copy/paste the stack trace from the dialog and send it on. Should give me a better idea of what's happening with your installation.
Cheers,
LankyBrit.
Home of the Minecraft Structure Planner application.
Thanks for your patience,
LankyBrit.
Home of the Minecraft Structure Planner application.