Botjoe

Huge fixes, repetition and improved rotation (August 7 2016)http://commandrunnermod.com/2016-07-04_01.03.30.png[/img]. Also a companion mod called BlockDumpMod, a utility to create execute commands or dump the information from blocks to a report.

Hi, Quick notes. 1) First you have no packages in the java source. (e.g package com.mymods.testcommandmod; ) 2) I do the register in server start. @EventHandler public void serverStart(FMLServerStartingEvent event) { MinecraftServer server = event.getServer(); ICommandManager command = server.getCommandManager(); ServerCommandManager manager = (ServerCommandManager) command; ICommand cmd; if (strFiles == null) { cmd = new ExecuteFile(server); manager.registerCommand(cmd); } else { // This sends the directory list of files to the command for tabcompletion of file names. strFiles is loaded in the server once. cmd = new ExecuteFile(server, mydirProperty.getString(), strFiles); manager.registerCommand(cmd); } } 3) By the Way : Do the recommended housekeeping I set up the apache logger and set accepted versions, et al. public static final Logger logger = LogManager.getLogger(MODID); And in the @MOD annotation, I added the maven formatted acceptedVersions; and required-after e.g. public static final String REQUIRED_AFTER = "required-after:Forge@[12.16.0.1887,]";

Is it more correct to implement ICommand rather than extend CommandBase for this type of command? When would one not choose ICommand?

My source is out there for command runner mod. It's procedural (will be) with !for, !wait, and !replacing macros. I currently recursively rotate. It has one command executefile example /executefile File load1.caleb byline rotateplayerfacing cascade cascade causes "cascade rotation" recursion for called files. Couldn't think of a better name late at night. I do need a different approach, in rotating blocks. www.commandrunnermod.com

1.9.4 is Updated for 1.10. fixes command completion. Sample .caleb files below. Trefoil4.caleb (Creates a trefoil). And a sample with command blocks.

I originally developed the mod to have an uppercase command called "ExecuteFile". I had always typed the ExecuteFile command and then used tab completion to add the rest of the command arguments. I discovered recently that the tab completion was not working, so after trying a number of things , I changed the command to lowercase. Causing the problem. 1) Created a command mod with the command name "ExecuteFile". 2) in the command execute coded to get list of matching command strings. then 3) Typed any command starting with e (e.g. /exec) then tabbed. 4) Entry clears to / then 3) Typed the command to /ExecuteF then tabbed. 4) Entry shows /ExecuteFile and works normally then 3) Typed /execute {space} 4) Entry shows /execute and works normally then 3) Typed /execute without a space 4) Entry clears to / This caused the command to clear on the tab until after the F is entered. The user could enter 'execute space' and the string would not reset (deleted to the first /). I don't believe this is a forge behavior. This has the issues. if (args.length <= 0) { List<String> ly = getListOfStringsMatchingLastWord(args, "ExecuteFile","/ExecuteEile"); return ly; } This works fine. if (args.length <= 0) { List<String> ly = getListOfStringsMatchingLastWord(args, "executefile","/executefile"); return ly; } Now typing /e {tab} displays /execute, /entitydata, /effect, /executefile, /enchant and sets the entry to /execute Thank you. I don't think that this is a forge behavior. I failed to use a convention of lower case commands. ----- Opinion ---- To me, it's a workaround, or fail to follow convention. While much of the rest of minecraft is inconsistent on case, commands appear to be lowercase. My reason to view it as a "gotta know" stems from how commands are parsed in terms of case in ordinary minecraft. For example in standard minecraft, as a command, using /kill @e[type=villager] (entity uuid error) will not work, and /kill @e[Type=Villager] will kill everything (matches every entity), only /kill @e[type=Villager] will correctly work. Knowing to type /kill @e[type=Villager] is a "gotta know". That's why I think it's not a forge issue, but modders should know.

Just noticed that commands seem to must be lowercase in the first argument for the tab completion to work (might just be the first character). ExecuteFile and execute interfere with each other (will clear to the first /). But executefile and execute work fine. Nothing different but the name of the command. Easier to change to be consistent and use lowercase than to try to figure it out. (Probably happened in 1.9 versions also.) Just a shoulda known better. So the workaround or correction is always use lowercase for command names.

Appreciated. I considered that in 1.8, but couldn't consistently get non-vanilla blocks in other mods to work as well as TileEntities. I will change the weird bit manipulation, that is hacked from 1.7 into 1.8 and 1.9 code. Mostly, I want to have the everything in a block or tileentity rotate relative to an ordinal direction.

To encourage better behavior (like Java , I'd like to suggest a startup warning for the forge user if the running directory is exactly ".minecraft". "Forge recommends a separate game directory, and a separate profile specifically to each version of forge. Put all the mods that are appropriate to the version in that version's mod game directory. You can set this in the launcher. "

Other modders, forgers, do you always extend an block from existing block type (e.g. BlockStair,BlockSign)? Is there something else I should do, also? Ok, I can easily tell that a Block yourmods_stair is a stair if the yourmod's Block is instanceof BlockStair and get any new IDs from the registry. I need to know what the block type is to rotate the meta. Is there any way to ensure I know the type of object is a "stair" assuming another modder correctly defined it. I prefer not to have more bodgey code than I have now. I need to know from the tags and datavalues to rotate them before I place something.

Closing the thread for now. Rethinking how to make it easier.

It's that the error is displayed and the game stops. I have no big objection to a displayed error, i do object to errors that don't have a clear resolution for the end user.

Not really looking to ignore errors, I prefer the mod to be ignored, in the any unsupported versions. Errors are good, but only when it's obvious what to do next. What I'd have as my use case is ... 1) Loader checks versions. 2) If not in versions, then ignore mod. Not ignore errors, handle errors by not activating. Does the slim class still show up a loaded mod? Yes. A slim class is OK, but is out of common practice. The alternative use case is to be obvious to the user. Either having some better help message saying 'Recommend to have a separate game directory for each forge version's profile', or a help screen available from the ForgeGuiFactory config (About Mods).

Thank you. Currently, my installed Forge 1.9.x (e.g 1887) does not activate some 1.7.10 mods ('sureen') in the same directory, with out error or comment. The 1.7.10 mods are only active (Instantiated) in 1.7.10 forge, and they don't activate in 1.9 forge. OK, I see that fml is no more, so it's supporting a prior behavior. Adding and deleting mods in a directory I'm used to, but not pleased with. Is there a better practice, that I'm missing? since it's not acceptedSaveVersions or anything else. Is there a way to self disable before the loader? I'm looking for a quiet dontLoadMod. Is there another (looking at Loader.java for one, i don't see one) practice, that I am missing?

I'd like my mod to only load on versions I expect (1.9 after 1887 or 1.9.4, and not be attempted to be loaded on forges for MC 1.8.x or 1.7.x, or any 1.10) forge. I have dependencies set, but that's not really what I want, nor is accepted version. I am used to maven version strings, but I just want to know, how do I get forge to not generate an error on any newer or later version of anything. I'd like it to skip my mod correctly. Most mod seem to use dependencies="" @Mod(modid = CommandRunnerMod.MODID, version = CommandRunnerMod.VERSION, acceptedMinecraftVersions = CommandRunnerMod.ACCEPTED_VERSIONS,dependencies=CommandRunnerMod.REQUIRED_AFTER) public class CommandRunnerMod { public static final String MODID = "CommandRunnerMod"; public static final String VERSION = "1.9.4"; public static final String REQUIRED_AFTER = "required-after:Forge@[12.16.0.1887,]"; String [] strFiles; public static final String ACCEPTED_VERSIONS = "1.9,1.9.4";

Some advice... 1) Read the source code docs. It's harder to get to them now than the javadoc link. I think I'll change my mod's gradle "build.gradle" to have a javadoc task for generating javadoc of the forge and deobf minecraft libs. 2) Where the annotations are (e.g. @Mod) is the magic, so use the code completion in eclipse to see options like acceptedMinecraftVersions. These necessary aren't automatically in the example nor are they populated. If it's an annotation, you have to (or should) read about it and read the code. Understanding the annotations is the first step. @Mod(modid = YourMod.MODID, version = YourMod.VERSION, acceptedMinecraftVersions = YourMod.ACCEPTEDVERSIONS) Yes, accepted versions should be a static string of (Maven) version strings. (e.g. public static final String YourMod.ACCEPTEDVERSIONS="1.9,1.9.4" BTW: The forge example and the MCCreator generator should possibly include a note on this in the example, since the forge developer team says PLEASE use this in CAPITAL LETTERS. 3) Assume you are going to code it wrong the first time. Decide if you are OK with that. You are probably not going to write using the best choices. This is a principle of architectural recoverability. (Design code so that refactoring from mistakes is easy.) There is probably a method that you won't find as a newbie that would do something for you, you'll code a kludge for. Unless you have a version control system, clean up code late. Even from 1.8 to 1.9, there is refactoring (e.g. my major mod difference from 1.8 to 1.9 is getting the server from event.getServer() instead of MineCraftServer.getServer()). Write one to throw away. Your first mod will probably not work well. Copy to a new forge version. CommandRunnerMod is still in the one to throw away stage. Useful but not perfect. 4) You might start with a Block Mod. (Where I should have started). Things become clearer with a Block Mod behind you. My biggest error in command runner mod was not starting in forge with a block mod. I looked for a rotation type (e.g. that would tell me how a block will rotate directions in datavalues and NBT tags (e.g. I'm still looking for a Orientation_Type = STAIR_ROTATION) and it's probably there somewhere, but I haven't found how to use it. So I reused code from old libraries for schematic editors. I'd have probably done better starting with a block mod. Not a great idea but livable for vanilla blocks. I'm redoing a block mod for that reason for the CommandRunnerMod. 5) Release early and often. Evolve in small steps. Fix early and often.

Updated for 1.9.4 forge, but a set of function to return the types of rotation for datavalues and tags would be useful. My source is there, anyway. I'll think about hardening it to a set of functions.

I am thinking that this type of code should be in rolled into the forge. The ability to execute a command file as a script is a core feature of flexible modding.

I am thinking that this type of code should be in rolled into the forge. The ability to execute a command file as a script is a core feature of flexible modding.

I did not take that approach, I took cues from part of the world edit logic as recommended by grey ghost. https://github.com/sk89q/WorldEdit/blob/master/worldedit-core/src/main/java/com/sk89q/worldedit/blocks/BlockData.java My problem is that forge blocks aren't in the current set of rotations. I plan to parse block names and allow the user to create new rotations in a config file. very nice.

I considered using another language similar to your approach, and I just downloaded your mod. Neither approach invalidates the other, as there exists the need for both. Scripting structures by command language has some advantages but it's hard to visualize. Once I have iterators by x y z, the scripting becomes more powerful. I'll look. Thanks for the posting. I'm not focusing on a mod as my end state, but to develop the concept for a vanilla minecraft suggestion, along with an eventgen command. Very appreciated.

Right now, I am still working out a lot and I have a number of kludges in the code. Thinking about it.

New version - Thanks to grey ghost now supporting stairs, and vanilla command language datavalue rotation. File arrow.caleb http://www.commandrunnermod.com/2015-01-27_19.22.24.png[/img]

BIG Thank you Grey Ghost that's got it for now. Just vanilla, but enough for the moment. --------------------------- This is how it looks says the happy modder.... !!! /ExecuteFile File arrow.caleb byline rotateNorth ... now rotates most commands and datavalues. The full side (North) on the stairs step up. All the arrows are from the same arrow.caleb file. Should have used netherrack stairs. http://www.commandrunnermod.com/2015-01-27_19.22.24.png[/img]

Ghost, I looked at https://github.com/sk89q/WorldEdit/blob/master/worldedit-core/src/main/java/com/sk89q/worldedit/blocks/BlockData.java. I'll probably extend the code differently and hook it to a generic type. It's close, but it's not configurable for any other custom mod's blockdata. I realized on reading it, I would need to allow modders with custom commands to add to the command types of rotation for my mod. No reason to do the same hard coding as blockdata.java. BlockId's aren't stable across mods, so more thinking is required. --------------------------------------------------------------------- I'm not clear on how mods should communicate capabilities to other mods in forge. I'm using the following for now.