We've had releases named "extrabiomesxl", "ExtrabiomesXL", "ExtrabiomeXL", etc.

We've had two or three different numbering ideas.

So how about a standard, based on the most current stuff.

ExtrabiomesXL (with the s, lower case b) -universal major.minor.maint.build.

For example: Why do we have 3.1.0c, and not 3.1.3? Granted, it's the third patch -- so a, b, then c -- but why not increment that last number? What is that last number for?

ExtrabiomesXL-universal-3.1.3.98.zip -- does that work?

Ahh. So 310a is the first patch to 310. Fine. Then 311 would be ... which?

Ahh. 311 would be the development release in prep for 320.

So, we have 3.1.0.86, then 3.1.0.a.87, then 3.1.0.b.89, then eventually 3.1.0.c.98.

And, in the meantime, we have something like 3.1.1.91, 3.1.2.95, 3.1.3.101, or something like that. Correct?

(so the numbering forks after a .0 release.)

The variations in "extrabiomesxl" occur when the automated system is down and I have to manually name the file at 3am. I do my best to be consistent, but I tend to make typos at that time of the morning.

Tee hee. I've learned not to do anything that critical that early before my coffee. Or do you mean that late the previous night :-).

I like how it is currently and to me it makes more sense and is less confusing. 3.1 tells me what version it is and the "a, b, c" shows me the patches to that version.

@keybounce - I don't understand why you are wanting to add more numbers. To me that just makes it more confusing. What would the point of adding another set of numbers after the letter?

@keybounce Yep you got it.

@Annysia That last number is the unique build number.

The very last number is added by the build server. If Forge changes, it could trigger a build without updating EBXL's version, so you might have 3.1.0.c.100 and then 3.0.c.101, with no changes except the new version has been compiled against the new release of Forge.

@keybounce You do realize that you are maybe the only person that actually puts the mod in the server jar file? 😁

This does not take into account development versions. Now that development version are public, they need to be distinguishable in logs.

The current system: Every official release the third number is 0. The third number denotes which development version beyond the official release. the letter denotes which patch is applied to the official version.

The variations in "extrabiomesxl" occur when the automated system is down and I have to manually name the file at 3am. I do my best to be consistent, but I tend to make typos at that time of the morning.

How would you use the mods directory?

The idea of "Everything in mods is live if it can be parsed" is the fail.

Apparently, modloader is defined to use a "disable these in this list" system.

Which means, if you have more than one config using a given folder, you have to modify every config each time you add a mod.

Leftover files in the mods folder is the biggest source of issues and problems I see in the modloader thread.

Conclusion: Instead of "Use everything unless it is explicity disabled", the better approach is "Only use those files in the mods folder that are explicitly enabled".

It's not too hard to consider using something like "modsFML" as a folder for this rule. And, FML has two new mod loading schemes, so it might even be reasonable. It's not like "coremods" has to follow the same rules as "mods", right?

Coremods is for mods that alter the byte code of the jar file at run time...a way of editing the jar in memory.

Why not use a symbolic (or hard) link? FML walks subfolders, so you could accomplish a lot with links.

OK, how would you set up a link-based system? Ideas/feedback welcome, seriously.

Right now, I'm pretty much looking at going back to "separate installations for each different server/world", and that's a maintenance nightmare/pain. I did that back in the prerelease days, but since 1.1 I have only used that for the early weeklies, and I haven't touched those old scripts since 125.

I don't put the mod in the server jar.

Here's my script, for your amusement:

#!/bin/bash
# Simple script to assemble the parts of a minecraft server.
# Where the files are located.
# Dated -- this is based on 125 when server and client used different mods.
# As more mods switch to universal, seperate 132smp and 132ssp directories becomes redundant.
ModDir="$HOME"/Documents/Games/Minecraft/Playing/Mods/132smp
JarDir="$HOME"/Documents/Games/Minecraft/Playing/Jars
# For the server, we have two different sets of mods to assemble: Jar mods and Mod-folder mods.
# Jar mods:
TMPDIR=`mktemp -d server.jar.XXX` || exit 1
cd $TMPDIR
unzip "$JarDir"/minecraft_server-132.jar
### unzip "$ModDir"/minecraftforge-universal-4.0.0.247.zip
unzip "$ModDir"/minecraftforge-universal-4.1.1.251.zip
unzip "$ModDir"/FML_BiomeFix.zip
unzip "$ModDir"/mystcraft-uni-1.3.2-0.9.2.01-Forge-4.0.0.247.zip
echo forge compatible
unzip "$ModDir"/ImprovedLogPlacing-132.zip
unzip "$ModDir"/ClaySoil_Server-132.zip
unzip "$ModDir"/FallFix_1_3_2.zip
unzip "$ModDir"/MoreVillageBiomes-V2.1-132-smp.zip
unzip "$ModDir"/Village-Logic-Addon-02-132.zip
unzip "$ModDir"/SuperiorEnchantment-132smp.zip
unzip "$ModDir"/WaterPropogationFix_132.zip
unzip "$ModDir"/larga-isso-enderman-mod-1.0-mc1.3.2-joserobjr.zip
mv ../server-myst-ebxl.jar ../new_server.jar.old
zip -r ../server-myst-ebxl.jar *
cd ..
# Now for the Mod folder. 
# We have to clear the mod folder out all the time -- leftover files there are the biggest cause
# of problems. 
#
# I'd love to just blow away the mods folder completely, but some mods need various resources
# in there, that are meant to be customized by you. So they have to stay around.
#
# Bottom line: We remove the .zip files from the top level of the mods folder, and leave
# everything else -- config files, resource files -- for mods to keep.
TMPMOD=`mktemp -d mods.XXX` || exit 1
mv -f mods/*.zip $TMPMOD
cp "$ModDir"/twilightforest-1.11.10.zip mods
cp "$ModDir"/Ruins-1.3.2.zip mods
cp "$ModDir"/ExtrabiomeXL-universal-3.1.0.c.98.zip mods
cp "$ModDir"/CustomOreGen.1.3.2-v1.Common.zip mods
echo Done, leftover junk in $TMPDIR, old mods in $TMPMOD

I actually hate how the mods folder is used. But when I tried suggesting to Lex/cpw that it was time to reconsider how it is used, the reaction was one of "How dare you, that's how Modloader works, it's a documented published standard, we won't make any changes". I still don't understand what he means by "documented" -- not when Risugami's stance seems to be "Modders: Decompile my code, and read it, to understand how to use it".

Boy, that was a fail. :-)

EDIT: Thank you for fixing the formatting. Now to take a look and see what you did

Answer: HTML tags for "pre". That was un-obviously obvious

Looks fine to me 😉

Wait -- BYTECODE REPLACEMENT????

What the ...

What the heck was CPW thinking? It's FML, right? I'm assuming that means it was cpw's decision.

Please correct me if I'm wrong -- I haven't looked this closely since Java 1.4. The byecode layout was essentially fixed memory locations with references to other bytecode locations very much like assembly language with hardcoded machine addresses.

That only permits patching if your patch is the same length or shorter, fails if there are multiple entry points into the same assembly routine, works best if you are just replacing the entrance with a jump to your own code, etc.

I mean, really -- that's so 1985-ish. That's an old and discarded method of patching. It has zero tolerance for any alterations or the file being a different version; it fails if there are any other files trying to patch that file.

Heck, magic launcher and MCPatcher both basically do transparent class merges by only using replaced routines in the class files, not trying to do byte-level mixing.

Seriously, cpw/lex are not stupid. They had to have had a specific style/useage pattern in mind when they did this. So what were they thinking?

For all of the mods common between configurations, but them in a 'common' folder outside of the game's folder structure. In each configuration that uses those mods, include in the mods folder a symbolic link to the 'common' folder as well as the mods unique to that particular configuration.

Theoretically (meaning I've never tried it) this should allow you to maintain one copy of each mod you use.

You could do something similar with your config files...obviously they must remain in place, but you could use symbolic links to 'share' common config files in a similar way.

The only wrench in this should be mods like Millenaire that still store their config information in the mods directory.

Forge now contains OW2's ASM library. Java bytecode is pretty flexible. And it works very well. It means that I can run many mods that used to go in the jar (like NEI) by putting them in coremods. I understand very little about it,but geniuses like chickenbones are able to use this to great effect.

And, no, it is not just Lex and cpw making the decisions. I know that they have a close relationship with Searge (who is responsible for MCP) and he has helped get these features implemented as well. And there are others...all smarter than me. 😊

And for the record...back in the day I actually had a professor say that writing code that modified itself or other code was morally wrong. 😄

I agree...but isn't it interesting how times change... 😄

I won't say that self modifying code is morally wrong, but you really have to know what you're doing. And, given the move to non-writable text segments, it no longer works on modern processors.

Yes, I've been there, done that, don't do it anymore.

The only wrench in this should be mods like Millenaire that still store their config information in the mods directory.

As does ruins :-).

For all of the mods common between configurations, but them in a 'common' folder outside of the game's folder structure. In each configuration that uses those mods, include in the mods folder a symbolic link to the 'common' folder as well as the mods unique to that particular configuration.

Theoretically (meaning I've never tried it) this should allow you to maintain one copy of each mod you use.

You could do something similar with your config files...obviously they must remain in place, but you could use symbolic links to 'share' common config files in a similar way.

That still means having a separate installation for each world. But it does mean that I could have less maintenance as things update. could -- need to think on that.

In fact, as I think about it, I'm thinking of a test world that updates differently than the main world. On the server side, it has a fully separate set of directories, but on the client side there is one set of directories / mod folders / configs that are supposed to work everywhere, equally -- which is a fail, so I'm back to the whole "everything is separate" full duplication on the client side.

I've just spent about an hour looking over ASM. Looks ... like a smart bytecode interpreter that tracks all that re-organization and length changing concerns. Looks like a third generation tool, in fact :-).

So did we decide to keep it the way it is?

Yea, just try to keep the words in front consistent :-). Looks like all those numbers are needed, and that letter.

And for the record...back in the day I actually had a professor say that writing code that modified itself or other code was morally wrong. 😄

I actually had to write a disk loader at one point. This routine -- back in the days of floppies -- had to deal with timing issues and everything else. The difference between the "read" routine and the "Write" routine was about 4 bytes, and the whole thing was about 250 -- in a machine that had around 16K.

I was quite happy to make it a self modifier -- significant size savings