Without this option, you would have to change the settings in. The third command mcidas -config displays a McIDAS-X Configuration Graphical User Interface GUI window with sliders, checkboxes and text fields that are used to select values that override the settings of the corresponding flags in the. This Configuration GUI is designed to make one-time for the current session only configuration changes easier and less error-prone than other methods like changing flag settings in the.
However, caution should be used with this option because it replaces the current. To make recovery easier, the option first moves the current. Though not recommended because of possible file conflicts, you can run multiple McIDAS-X sessions from the same account. To differentiate between the files used for various sessions, each session stores many of its files in its own.
In the above example, we're using code to refer this block to itself in a dynamic way. As with the code for the [id ID] attribute, this will be explained in a later section. For now, change "tutorialBlockID" to the same value that you chose for the same change made to the ID attribute.
If you want your block to be availabe in Creative Mode, set it to "true". Otherwise, set it to "false". If you set it to false, you can omit the creativeTab attribute entirely. This will be discussed more in depth in a later section. For now, choose a name for a texture file, making sure to include the file extension ". That is, make a block drop something upon being broken. A harvestLevel of 0 will drop an item even when broken with bare hands, while 3 requires diamond tools.
Texturing for Minecraft is much the same as texturing for Minecraft in general. Each tile must be a perfectly square image, saved in the. By default, Minecraft uses images that are 16 x 16 pixels width and height. This is not a hard restriction, however, and any resolution will work as long as it remains perfectly square. Keep in mind, though, that larger images will burden your game and may cause crashes if you run out of memory to hold them.
Widths and Heights that are powers of two 16, 32, 64, etc. As a recommendation, don't go over 64 x 64 for an image size unless you're sure that every computer running it can handle that size. If you're planning to post it on this Wiki, keep your textures to the default 16 x 16 and make higher-resolution versions for yourself if you desire. Textures in Minecraft are no longer in sheets as of Minecraft 1.
If you're a vetran of CS1, you may remember this method. If you have a tile sheet from this era, you'll need to cut it apart into individual tiles in order to get it to work with the most recent versions of Custom Stuff 2. Texture files can have any name, but must be. Also keep in mind that this is only for items and most blocks. Chests have their own texture format, and GUIs will also be different. Read up on how to set out a texture for those things before attempting them. For now, create a 16 x 16 PNG image that you want to use as your texture.
Give it the same file name that is mentioned in your block's. Now that you've settled on the attributes that you want your block to have, you'll need to actually add it to Minecraft. If you look in your project's directory, you'll see a file called "mod. This is the "master" file of a Custom Stuff project. It's the file that actually adds things to the game. While all of the other files decide what a block, item, or what-have-you is , this file takes that and actually puts it into the game.
When Editing this file, I recommend trying to do things in small parts. Add one line and run Minecraft. If it does crash, look at your crash log and try to figure out what went wrong. See debugging for more information on how to look at your crash log, and track down common errors. For your block, you will change "tutorialBlockID" in the first and second lines to the name you gave to your block's ID.
In the third line, "tutorialBlock. The number in the first line should be change to any number between 0 and that does not already have a block assigned to it.
Because each block must have a unique ID number, Custom Stuff itself will reassign this number if you accidentally use one that's already assigned by another mod. In general, it's a good idea to keep this number greater than for blocks. In the last line, note the word "normal" near the end. This is the type of block that you're trying to add to Minecraft.
See Type for a valid list of Block Types. Changing this to another type in this line changes what sort of block it is in-game. For example, if you change "normal" to "stairs", it will be a stairs block.
Know that not every block attribute works for every block type, so it's possible to create a block file that's valid as one type of block, but will crash the game when used as a different type. For example, anything that uses a metadata value above 0 will not work for stair-type blocks, causing an out of bounds error.
Finally, note that every line has a bit of code that uses the word "Block" in it. If you're adding something that isn't a block, you'll use the proper name for that object instead. For example, config. Before we continue, it's essential to understand what is going on with those lines of code that take the place of block IDs in all of these files. The ones that you have, thus far, been told would be explained to you later. Well, now is the time to have those lines explained.
Effectively, this system is set up to make a block or item ID that can be used anywhere in the mod, for any purpose, and be set by the user in a config file rather than having it hard-coded in the files. This make it easier for you to alter your block's and item's IDs to prevent conflicts with other mods, as well as making them simpler for anyone else who would be using your files to adapt them to their own setup.
Here's how it works: It starts in the mod. This does exactly what it says it does - it ads a block ID property to the config file, and gives it a value. If you open it, you'll see a series of lines that show names and numbers. This is file is generated by Custom Stuff, but can be edited by the end user. For example, let's say you assign your block the ID number like in this example.
Later, you download another mod that uses that number. This will cause a block ID conflict since you can't have two blocks that share the same number.
If the other mod is well made, you'll change the block ID number in it's config. Otherwise, you'll have to change it in your project's config. Anywhere you have the line "config. It check the file and goes "Oh, this block is this number. I'll use that number then. This is where this system makes things easy for you. Rather than having to hunt down every instance of "" in all of your files, you can change the one instance in your. You don't even need to change the line above, since it sets the default when the file is created, but will not change what you set manually.
This extends down the line. You can set a variable, which gets it's value from the config file's ID. This then allows you to give your block a unique alias which checks that variable which in turn checks the config file's information.
From there you use the alias in crafting recipes which, though several steps, get the correct ID number from the config file. It may seem like a needlessly complicated system, but this is where some of the power of Custom Stuff flows from: The ability to do things dynamicaly and have information flow freely from one area to the next.
It's a lot of work to get everything working, but this same system will also save you loads of problems down the road as well.
If you've done everything correctly, your block should now be accessible in-game from the creative menu of your choice. That's fine if all you want is a new building block in Creative Mode, but what about making it appear in survival? Well, the most common way to do this is the have your block crafted from materials already in the game. Before you set up a crafting recipe, it's best to set up an Alias for each block you create. The reason for this is explained in the previous section about Understanding Cascading IDs.
Because best practice dictates assigning block IDs in a way that flows from the config file, rather than being hard-coded, we need to continue that practice here. To set up an alias, you must first get the block's ID number from the config file, and make it a variable. This is fairly strait-forward and works by adding a line like this to your mod. This is telling Custom Stuff to create a variable called "tutorialBlockVar", which is always equal to the value for "tutorialBlockID" in the.
If that value changes, this also changes "tutorialBlockVar". Just as with the previous line, this moves the ID number from the config down another level. Changing your ID number in the. A little cumbersome to set up, but far more utilitarian to use!
Now when you want to refer to this block in a recipe, you don't have to use it's ID number which you shouldn't be using anyway , or type any 'get' code into the recipe which won't work anyway. You just use it's new Alias. To set up an actual crafting recipe, open your mod.
You'll be using the mod. For more information, check out the Crafting Recipes. Register Don't have an account? Risugami's Modloader. View source. History Talk 0. Categories Modloaders. Universal Conquest Wiki. This page is a candidate to be moved to ModLoader. Please discuss this move on the talk page.
0コメント