BAPACop

I had a long response queued up, but I decided to shorten it to this. There's clearly been a miscommunication somewhere, because this is not and has never been my position.

Again, I don't want MO to try to compare "old" to "initial version" and determine which is newer. This is not a feature I need and I know perfectly well that it's not possible. All I want is "old" to not change to "0.0old" when I type it in. I'm sure it can't tell the difference between "0.0old" and "0.0initial release" any easier, so why mess around with the values? In fact, why does MO even need to determine which is newer? Is it at all likely that the release version will somehow be older than the user's version? Unless the user is the modder, in which case I'm sure they'd have update alerts disabled for that mod, or a time traveler, in which case I'm sure they have more important things to do, no it's not. So why does MO even need to determine which is newer? Why doesn't it just check to see if they're the same? I'm sure it wouldn't end up 100% accurate either, but at least inaccurate update alerts can be turned off. Unlike 0.0old.

That's a fairly good explanation as to why an "Update Available" alert might be inaccurate, but I'm not asking for MO to compare "old" and "0.1" and return "mod is up-to-date". I just want it to not change "old" to "0.0old".

Actually, Windows has sorted numbers properly (or at least had the option to do so) since Windows XP.

It was unknown at the time of posting whether there was a bug or an option in the program that I could not locate. When it became clear that there was no way to resolve the problem on the user's end, I posted a bug report. Considering my request for clarification was dismissed with, and I quote, "deal with it", perhaps you can understand why my tone became rather annoyed over time.

Which I did. :) That just means that changing 2.40.4 to 2.4.4 would be equally wrong, since we're dealing with strings and not numbers. Incidentally, MO actually displays 2.40.4 properly as 2.40.4.

Um... no. You can't drop leading zeroes for anything after a decimal. Type 2.4 - 2.04 into a calculator. You won't get 0. They're not the same. 2.4 and 2.40 are the same, but not 2.4 and 2.04. And that's ignoring the fact that you don't ever have two decimals in math. It can easily account for all possible version systems by simply displaying them as entered instead of changing them. There is no need for MO to be trying to "translate" the numbers it is given. It introduces issues like this and accomplishes nothing but the confusion of the user, whereas leaving them unaltered would allow both MO and the user to compare version numbers with no problems. I have not posted multiple threads regarding this issue on this site.

This forum is listed as the "official support forum" for MO. I had an issue that required support. There was every point to coming here.

Really? It's entitlement to expect something to work properly? And since when do you have to know how to do something to be able to criticize it?

[sarcasm]Oh, it's free? Well then! I guess that means it's absolutely immune from criticism.[/sarcasm] It doesn't matter if it's free. It doesn't matter if it only has one person working on it. If it doesn't work right, it doesn't work right.

The last time I posted an issue here no one responded. You'll forgive me for posting in multiple locations to ensure someone actually gets around to talking to me about it. I don't link to Nexus mods. I put mods in myself and I type the version numbers in myself. I need to be able to compare the version numbers in MO to the version numbers available for download. Why do I have to "deal with it"? Why can't an obviously broken feature be fixed? I typed 1.1.3a. I didn't type 1.1.3alpha. Why would MO displaying anything other than what I typed in ever be proper behavior? When I type in "2.04.4" it spits out "2.4.4". How are those numbers the same? When I type in "new" it spits out "0.0.0ew". How are those the same? And it doesn't store them the same and just display them different. No, it stores them as "2.4.4.0" and "n0.0.0ew". So no, MO doesn't still read it as the correct version. Not even close.

I don't need MO to read it as the correct version, I need to read it as the correct version and I can't do that if it doesn't properly reflect what I type in.

How do I make it not do that?

Mod Organizer is doing a weird thing where the version number I type in isn't the number it displays. For example, 1.1.3a turns into 1.1.3alpha. 2.0b turns into 2.0beta. And when trying to enter versions in a date format, there's not enough room for characters in the box. You can't enter 12.12.2012d into the box because it won't accept the "d" at the end. You have to edit the meta.ini file directly instead.

If I try to launch the GECK through MO with mods active in the load order, it crashes. I haven't bothered to troubleshoot it since the GECK works just fine if no mods are set to load, but it's bizarre since the GECK should only care about the order the mods are in, not whether or not they're active. I've had a similar issue launching FNV itself, but I narrowed it down to JIP Companions Command & Control. If that mod is set to active in the load order FNV will close itself immediately after launching. However, if I uncheck it from the load order and instead check a dummy plugin with C&C as a master, FNV loads up fine and C&C is loaded since the dummy plugin forces it on even though it's not in the load order. So it can be present and loaded into the game, it just can't be in the active load order for some reason?