Forum adverts like this one are shown to any user who is not logged in. Join us by filling out a tiny 3 field form and you will get your own, free, dakka user account which gives a good range of benefits to you: No adverts like this in the forums anymore. Times and dates in your local timezone. Full tracking of what you have read so you can skip to your first unread post, easily see what has changed since you last logged in, and easily see what is new at a glance. Email notifications for threads you want to watch closely. Being a part of the oldest wargaming community on the net. If you are already a member then feel free to login now.

MM hits it on the head.

Seriously, I have stated it over and over again. This is simply put a RAW issue. RAW says no unless you choose to ignore the wording of the rule. As such it is a RAW issue. No matter how you apply logic to the case, RAW says you cannot. This is NOT to say in anyway that RAI shouldn't allow PowerKlaws, but the Maintains stick to a strict RAW standpoint as that is what GW has stated over and over recently that they stick to.

As for the original post on the Maintainer site, I personally sent PMs to the OP there explaining the ruling and advising I would follow-up (which I did). He chose to not respond and instead take his derogatory statements to another website to air his grievances. His Original Post stayed on the Maintainer site until the content clearly devolved into a flame way in which I deleted the posts due to language and content. In hindsight I wish I hadn't so everyone here could see the flame based statements he originally made.

Here he has stated his efforts are simply a few hours work every few months. That of course assumes he starts with the basis the current and past maintainers have provided in base rule sets and existing files. It’s good that he has stated it’s so easy for him to complete his work, and it’s definitely his freedom to do so, but the maintainer site and the main 40k datafiles will remain using a RAW mindset. Again, this isn't a datafile issue, it’s a rules issue and should be brought to GW to fix.

Stelek wrote:

If you really think you can add a razorback to a SM unit over 6 models and get a validated-as-legal list, well, you're off your cookie because you cannot do so.
The list will print out as illegal. So it's working as intended, and so much for that 'argument'.

I can have the option (though it's wrong) and print it out, validation errors and all. That's the point. That's all he wants. You already have datafiles that allow things that aren't 100% RAW. He's just lookin' for some of the same lovin'.

Yeah, and you can do that in the datafiles NOW Ki.

Add a boyz nob to a slugga squad.

Give him a klaw.

Click off the sluggas.

Click on the shootas.

Same points, gives a validation error, and you can print it.

What, no one tried to do this before starting this bitchfest?

Greeeeeeeeeeeat.

KiMonarrez wrote:You already don't have datafiles that allow things that aren't 100% RAW.

Interesting point of view.

If you mean the optional stuff, yes...and it prints out as not legal since it isn't 100% RAW.

So what's the point? That you really don't 'get it'? I think I understand that now.

KiMonarrez wrote:

Stelek wrote:

If you really think you can add a razorback to a SM unit over 6 models and get a validated-as-legal list, well, you're off your cookie because you cannot do so.
The list will print out as illegal. So it's working as intended, and so much for that 'argument'.

I can have the option (though it's wrong) and print it out, validation errors and all. That's the point. That's all he wants. You already don't have datafiles that allow things that aren't 100% RAW. He's just lookin' for some of the same lovin'.

Again, the warning or error isnt a 'you might have an issue' its a YOU HAVE AN ISSUE. It is assumed that you will FIX the issue and if you do not it gets listed on the output. Its just not always possible to fully disallow every silly little thing when its not avaaialbel. The design of AB doesn't allow this very easily and as such we have to code many things on a REACTIVE process instead of a PROACTIVE process. This goes back to one of my previous posts. All because the rror is there when you do something wrong and can print the wrong information doesn't make it a user choice instance. The problem with Klaws are they are disallowed by RAW. You cannot in any way successfully add a Klaw to the Nob without breaking the rule at some point if you have a shooty mob.

Try creating a program that follows the rules as outlines. It will nto work. If you wouldlike more examples(from a programming example) I would be happy to provide later tonight.

jlong05 wrote:MM hits it on the head.

Seriously, I have stated it over and over again. This is simply put a RAW issue. RAW says no unless you choose to ignore the wording of the rule. As such it is a RAW issue. No matter how you apply logic to the case, RAW says you cannot. This is NOT to say in anyway that RAI shouldn't allow PowerKlaws, but the Maintains stick to a strict RAW standpoint as that is what GW has stated over and over recently that they stick to.

And myself and others have repeatedly said that your interpretation is incorrect. The Klaws are not clearly illegal. The RAW is ambigous, and to state otherwise is to do what Stelek repeatedly says AB cannot do: change the rules.

This is the crux of much of the animosity: many, many people disagree with your assertion that the RAW is clear.

I tried to do it in the most logical fashion.

I added a boyz squad.

I clicked off choppa&slugga
I clicked on shootas
I added a nob

I can't add a klaw.

I tried it your way and it works. Guess it's the *shhhh* SOOOOOOPER SECRET method.

If it can be made to work the other way too, I'd shut up.

KiMonarrez wrote:I tried to do it in the most logical fashion.

I added a boyz squad.

I clicked off choppa&slugga
I clicked on shootas
I added a nob

I can't add a klaw.

I tried it your way and it works. Guess it's a sooper secret method.

If it can be made to work the other way too, I'd shut up.

to be fair, the super secret method is the method by which the RAW woudl allow the Klaw. the rules are pretty clear that a Nob must exchange his choppa for a klaw, but it does not say what order to do things in. The method Stelek pointed out is the way it has to be taken.

Edit: I tried it, and it works. Since it does pretty much what I'd like it to (allow the option with a warning), then I'm happy. I wish I or somebody else had discovered this 25 posts ago.

Were I an orks player, and now knew the *shhhhhhh* Soooooooper secret method, I'd be happy with it.

I'll shut up as the only thing that concerned me is available.


And now, by 4 year old son wants to type something.

0oih5`l5r utjr5oi45y6tjr45i4reyurdh7w26y1q2t79683etwqc7534er@fasfdsgf

the next Shakespeare. I know.

Polonius, the RAW isn't clear but the way the 40k maintainers have done things for years IS.

Come down on the 'strictest' not the 'loosest'.

'Strictest' makes for the most legal army lists.

'Loosest' does not.

Stelek that's fair, if that's the policy. I guess I never really encountered it before, but that's probably because there's never been a RAW issue regarding army comp before, with the possible exception of the six dreadnought list.

Since the product does what I asked it to, I'm no longer concerned. My only comment for the future would be to replicate what the mainainers did here: make the option possible, simply illegal. If you read my posts, that's all I've ever asked for. I think there can be some slop between what AB says is legal, and what AB allows as possible. After all, I can build a list without an HQ or 2 Troops with AB. It's not legal, but it's possible.

Once again, Polonius says it FAR more eloquently. What he said.

jlong05 wrote:
As for the original post on the Maintainer site, I personally sent PMs to the OP there explaining the ruling and advising I would follow-up (which I did). He chose to not respond and instead take his derogatory statements to another website to air his grievances. His Original Post stayed on the Maintainer site until the content clearly devolved into a flame way in which I deleted the posts due to language and content. In hindsight I wish I hadn't so everyone here could see the flame based statements he originally made.

I never posted on the thread on the maintainer website, as I saw from how other threads were being locked that it was a waste of time. You never sent me a PM either. You must be confusing me with someone else who feels that the datafiles you are providing don't meet their needs.

Again, this isn't a datafile issue, it’s a rules issue and should be brought to GW to fix.

Of course it is a datafile issue. You are not, to the best of my knowledge, employed by GW. Your collective decision to follow the most conservative interpretation of the rules yields a tool that is less useful than it could be. You gain nothing by sticking with this path, as the number of bugs in the datafiles consistently yield situations where AB allows something that a codex doesn't. AB is not considered a viable authority in any rules discussion that I've ever seen. You can claim "100% legal lists" but in the three years I've used AB, it's never once been 100% legal, and each release fixes some bugs but introduces new ones as well. Since the datafiles cannot be depended on to be 100% correct, why not go with liberal interpretations of the rules so that the tool is useful to the most gamers. Those who want to follow more conservative approaches can restrict themselves.

I'm not trying to berate you for the bugs, either. I develop software for a living, and I know that bugs happen. It's not my aim here to criticise the existence of bugs in the datafiles, but rather to point out that because bugs do exist, and have existed in every single datafile I've used, you're already failing on the 100% legal point.

The crux of the issue though is that the OP (which knew this method was available) had issue with it being flagged 'as an error'. As his view is it is not he changed it and said everyone working on the files is wrong and have giant egos, blah blah blah. I never brought up that you 'could' do as you wanted as I assumed the issue was the same in that it was being flagged as an error as by RAW it is. Here is the logic process I promised.

A = Boyz Mob with Option C(Slugga/choppa)
B = Nob
D = Option for Shootas
E = Option for Klaw

The specific rules state:

Options: Entire Mob(A) may replace sluggas and choppas for shootas.
ie: A(C) - C + D = A(D)
One Boy may be upgraded to a Nob(B)
ie: A(D) - Boy(sub A item) = A(D) + B(D) Nob inherits default weapons at time of upgrade.
Nob may replace his choppa(C) with Klaw(E)
ie: A(D) B(D) ... Wait No choppa(C) available. = No Klaw(E).

Lets try the other method process. (ie. add nob and klaw and then convert)
One Boy may be upgraded to a Nob(B)
ie: A(C) - Boy(sub A item) = A(C) + B(C) Nob inherits default weapons at time of upgrade.
Nob may replace his choppa(C) with Klaw(E)
ie: A(C) B(C) - B(C item) = A(C) B(E)
Options: Entire Mob(A)(B) may replace sluggas and choppas for shootas. You must include the Nob as he is part of the Boys MOB now.
ie: A(C) B(E) - C ... Wait the entire MOB doesn't have a choppa(C) = No shoota(D).

This is the issue with the RAW. From a strict computer step by step process you cannot get a Klaw legally. Now, again, I agree that the RAI says you should, but RAW says you cannot.

Please someone dispute this with a logical FLOW that shows my error and is accurate without breaking the legal process and I will happily jump ship and argue to the Klaws. But as a programmer, I just cannot find it.

Stelek wrote::You can complain all you want, and while Ghaz isn't exactly Mr. Personality until you are willing to put in the hundreds of hours a month the many people at that site do to create the product, you really should be happy you have a working product.

That's just it. As the files currently stand, it isn't a working product. It's broken.

Redbeard wrote:

jlong05 wrote:
As for the original post on the Maintainer site, I personally sent PMs to the OP there explaining the ruling and advising I would follow-up (which I did). He chose to not respond and instead take his derogatory statements to another website to air his grievances. His Original Post stayed on the Maintainer site until the content clearly devolved into a flame way in which I deleted the posts due to language and content. In hindsight I wish I hadn't so everyone here could see the flame based statements he originally made.

I never posted on the thread on the maintainer website, as I saw from how other threads were being locked that it was a waste of time. You never sent me a PM either. You must be confusing me with someone else who feels that the datafiles you are providing don't meet their needs.

My mistake, as your comments almost matched exactly the posts on the maintainer site, I incorrectly assumed you posted there also. I retract my statement stating you are he also.

Redbeard wrote:

jlong05 wrote:
Again, this isn't a datafile issue, it’s a rules issue and should be brought to GW to fix.

Of course it is a datafile issue. You are not, to the best of my knowledge, employed by GW. Your collective decision to follow the most conservative interpretation of the rules yields a tool that is less useful than it could be. You gain nothing by sticking with this path, as the number of bugs in the datafiles consistently yield situations where AB allows something that a codex doesn't. AB is not considered a viable authority in any rules discussion that I've ever seen. You can claim "100% legal lists" but in the three years I've used AB, it's never once been 100% legal, and each release fixes some bugs but introduces new ones as well. Since the datafiles cannot be depended on to be 100% correct, why not go with liberal interpretations of the rules so that the tool is useful to the most gamers. Those who want to follow more conservative approaches can restrict themselves.

I'm not trying to berate you for the bugs, either. I develop software for a living, and I know that bugs happen. It's not my aim here to criticise the existence of bugs in the datafiles, but rather to point out that because bugs do exist, and have existed in every single datafile I've used, you're already failing on the 100% legal point.

The reason I do not agree with the liberal approach is within your very argument. The AIM of the datafiles is to provide a 100% legal list. You are correct that bugs exist, but they are fixed periodically. I disagree with an assessment that NO lists are EVER 100% legal. I am pretty certain that multiple armies have bug free lists, or if bugs are there they are not being identified and stated to the maintainers to be fixed. As an example, I am unaware of any bugs within the Necron datafile that are not clearly marked as Scarabs . All Joking aside, I honestly have no bugs there that have been identified, so lists made with that army are 100% accurate and legal. If not and there is a bug, it has not been identified and listed for me to fix. This is also the same with other armies as well. To complain that the files are full of bugs is honestly an incorrect statement as it is NOT full of bugs. Bugs exist and when found and we are informed of them and they have been confirmed we fix them(generally within a few days to a week of being notified).

If you know of other existing bugs, please, please, please report them so we can fix the files so everyone can benefit.

jlong05 wrote:Seriously, I have stated it over and over again. This is simply put a RAW issue. RAW says no unless you choose to ignore the wording of the rule.

This is a laughable statement. The only possible way to correctly read the rules is to allow powerklaws on every nob, since the order of the application of the rules is _never_ specified. But, since Ghaz is involved with the official files, it's to be expected that the files will break the rules on a regular basis.

Buoyancy wrote:

jlong05 wrote:Seriously, I have stated it over and over again. This is simply put a RAW issue. RAW says no unless you choose to ignore the wording of the rule.

This is a laughable statement. The only possible way to correctly read the rules is to allow powerklaws on every nob, since the order of the application of the rules is _never_ specified. But, since Ghaz is involved with the official files, it's to be expected that the files will break the rules on a regular basis.

Please see my post(4 posts up) which shows the flow. If you are aware of a flow matrix that allows Klaws without ignoring another rule then show it logically.

jlong05 wrote:Please see my post(4 posts up) which shows the flow. If you are aware of a flow matrix that allows Klaws without ignoring another rule then show it logically.

If the nob has a powerklaw, then he has no slugga+choppa to exchange, and thus isn't affected with the rest of the mob. The way it actually works, for anybody who can handle the basic logical concept that A=>B does not mean that B=>A is:

One Boy may be upgraded to a Nob(B)
ie: A(C) - Boy(sub A item) = A(C) + B(C) Nob inherits default weapons at time of upgrade.
Nob may replace his choppa(C) with Klaw(E)
ie: A(C) B(C) - B(C item) = A(C) B(E)
Options: Entire Mob(A)(B) may replace sluggas and choppas for shootas. There is no requirement that Entire Mob(A)(B) has sluggas and choppas for this to succeed, so every Slugga and Choppa is replaced by a Shoota.

Buoyancy wrote:Options: Entire Mob(A)(B) may replace sluggas and choppas for shootas. There is no requirement that Entire Mob(A)(B) has sluggas and choppas for this to succeed, so every Slugga and Choppa is replaced by a Shoota.

But there is. The rules says the ENTIRE mob replaces their Sluggas/Choppas. The Nob is part of the Mob and doesn't have the Choppa to exchange. By your logic, one could argue that they can 'mix' mobs with shoota boys and slugga/choppa boys. This is why it says the ENTIRE mob.

Caps indicated for emphasis(and are mine)

Stelek wrote:

KiMonarrez wrote:You already don't have datafiles that allow things that aren't 100% RAW.

Interesting point of view.

If you mean the optional stuff, yes...and it prints out as not legal since it isn't 100% RAW.

So what's the point? That you really don't 'get it'? I think I understand that now.

Honestly it seems more evident that you don't 'get it'. Ki's point is simply that, because AB already incorporates the capacity to flag options as illegal, it should be very simple to do something similar with the shoota mob PK. Such an argument is entirely valid as it supposes that all instances of potential illegality are similar, and therefore equivalent to a reasonably objective observer. Ki is simply questioning what it is about the shoota PK which makes it any different from his cited examples; thereby legitimating the omission of the option from the file. All you've done in attempting to refute this point is state that you don't agree with it and thus deem it worthy of aggressive belittlement.

Glad SOMEONE was getting it.






Though, *looks left* *looks right*


"Shhhhhhhhhhhhhhhhhhhh. There's a Sooooooper secret way to do it."

Buoyancy is correct. The rule is that the entire Mob may exchange their Sluggas and Choppas for Shootas, not that they must. If any model, such as the Nob, does not have both a Slugga and a Choppa to exchange, then it does not meet the conditions for exchanging those weapons for a Shoota.

So yeah, if you're not representing the modality with the proper notation of course you're going to compute the wrong answer.

Nurglitch wrote:Buoyancy is correct. The rule is that the entire Mob may exchange their Sluggas and Choppas for Shootas, not that they must. If any model, such as the Nob, does not have both a Slugga and a Choppa to exchange, then it does not meet the conditions for exchanging those weapons for a Shoota.

So yeah, if you're not representing the modality with the proper notation of course you're going to compute the wrong answer.

So, your standpoint is that as the rule states the ENTIRE mob may replace their sluggas and choppas for shootas, but the rule does not say the ENTIRE mob MUST replace... then isn't is also valid by your reasoning that a mixed mob is also legal? The problem is that the issue is with the first part of the rule (ENTIRE MOB) so the secondary part is inherent to that (MAY replace...) There is no reason to indicate the ENTIRE MOB MUST, as they are NOT required to replace unless you want to switch the weapons, but if you do want Shootas, then the ENTIRE mob MUST follow suit. As the Nob(which is part of the mob) doesn't have the appropriate weapons then the ENTIRE mob cannot exchange their choppas and sluggas as the ENTIRE mob doesn't have them. Only the REST do. The rule indicates the ENTIRE mob, not the REST of the mob.

The issue that you appear to be clinging to is the wording of 'may replace' as in it is each individual models choice, but that is not the case. It the choice of the player but its an ALL or nothing due to the prior point of ENTIRE Mob.

So your logic flow is flawed.

When following a ruled logic flow, one must strictly adhere ALL rules that are identified, not just the parts one wants to use.

Again, please someone; programmatically identify a proper logic flow that does not break any of the rules or requirements without taking things out of context or assuming the understanding of the rules designers. Unfortunately, I have been over this specific rule more times than I like to count, and I still cannot find a way it’s valid.

jlong05 wrote:
The reason I do not agree with the liberal approach is within your very argument. The AIM of the datafiles is to provide a 100% legal list.

You have set a goal that, to date, you have failed to achieve. Again, I'm not trying to say that there are a lot of bugs, or even that every datafile has bugs. I am stating the fact that, to the best of my knowledge, in the three+ years that I've been using this datafile set, there has never been a set of datafiles that was able to produce 100% correct lists, due to the bugs in the datafiles.

Given that the goal you have set is not being met, maybe it is time to re-evaluate the goal. Rather than strive for something you cannot do, aim to create the most useful set of datafiles.

I disagree with an assessment that NO lists are EVER 100% legal. I am pretty certain that multiple armies have bug free lists

I didn't say that no lists were 100% legal. You can make a lot of 100% legal lists with the current datasets, even in some of the buggy datafiles, as many of the bugs can simply be worked around by users who have read their codexes. I make legal lists all the time. My assertion was not that you cannot make legal lists, it was that it is possible, and has been possible in every set of datafiles I've used to date, to make illegal lists that are not flagged as such. Since the ability to create an illegal list doesn't actually impact the usefulness of the tool as long as all legal options are supported, these bugs are much less likely to be reported.

As for the powerklaw thing, as seen in this thread, even RAW, it's a debatable case. It's not a matter of RAW vs RAI, it's a matter of RAW vs RAW with different ways of applying the logic from the poorly worded rule.

jlong05 wrote:

The issue that you appear to be clinging to is the wording of 'may replace' as in it is each individual models choice, but that is not the case. It the choice of the player but its an ALL or nothing due to the prior point of ENTIRE Mob.

May vs must is not the correct issue here. The real question is what it means to say "the entire mob may replace X with Y"

If I have a group of ten people, five of whom have apples and five of whom have oranges, and I say that the entire group may (or must) replace their apple with a banana, what is the result? Is it that no one does anything because the entire group doesn't have apples, or is it that I end up with a group with five people with oranges and five people with bananas?

The nob buys himself a powerklaw. He no longer has a slugga and choppa.
The mob all exchange their slugga and choppa for shootas. Everyone who has a slugga&choppa makes the trade. Anyone who doesn't have it, doesn't. But that doesn't stop the exchange. There is nothing that says, "If the entire mob has sluggas and choppas, they may exchange..."

That's the logic. It's the application of the concept that I can tell an entire group to trade their apples for bananas and the fact that some of the group have oranges doesn't stop them from making the exchange.

Redbeard wrote:

jlong05 wrote:
The reason I do not agree with the liberal approach is within your very argument. The AIM of the datafiles is to provide a 100% legal list.

You have set a goal that, to date, you have failed to achieve. Again, I'm not trying to say that there are a lot of bugs, or even that every datafile has bugs. I am stating the fact that, to the best of my knowledge, in the three+ years that I've been using this datafile set, there has never been a set of datafiles that was able to produce 100% correct lists, due to the bugs in the datafiles.

Given that the goal you have set is not being met, maybe it is time to re-evaluate the goal. Rather than strive for something you cannot do, aim to create the most useful set of datafiles.

So your view of a process is, that if you fail to achive 100% correctness in a specified frame of time, one should give up???? This just doesn't make sense to me. It's odd that you keep indicating errors that you have found that are still not flagged correctly, but you did not send those in as I have suggested. I appologize, but I cannot accept the conclusion that we should give up because bugs are found. If that was the case, every application, program and computer system developer should just quit now as bugs are part of the business.

I commend you on yoru ability to edit the files we created to resolve your personal issue with the lists, but that still didn't resolve every issue that is ambigious in the rules as has been indicated. It only fixed the one you were concerned with. The effort needed to allow every possible ambigious rule would eliminate the ability for timely updates and honest bug finding as everyone at that point argues that their 'logic' is valid wanting the additional options. This is why we have not continued with that development effort. If you choose to continue your personal subset of our datafiles, that is your choice, For those who wish to have our version , they can continue to get them from our website and the AB tool itself. We will continue to strive for 100% RAW support.

Redbeard wrote:

jlong05 wrote:

The issue that you appear to be clinging to is the wording of 'may replace' as in it is each individual models choice, but that is not the case. It the choice of the player but its an ALL or nothing due to the prior point of ENTIRE Mob.

May vs must is not the correct issue here. The real question is what it means to say "the entire mob may replace X with Y"

If I have a group of ten people, five of whom have apples and five of whom have oranges, and I say that the entire group may (or must) replace their apple with a banana, what is the result? Is it that no one does anything because the entire group doesn't have apples, or is it that I end up with a group with five people with oranges and five people with bananas?

The nob buys himself a powerklaw. He no longer has a slugga and choppa.
The mob all exchange their slugga and choppa for shootas. Everyone who has a slugga&choppa makes the trade. Anyone who doesn't have it, doesn't. But that doesn't stop the exchange. There is nothing that says, "If the entire mob has sluggas and choppas, they may exchange..."

That's the logic. It's the application of the concept that I can tell an entire group to trade their apples for bananas and the fact that some of the group have oranges doesn't stop them from making the exchange.

But your not applying strict logic then. You are applying loose logic. The assumption is that part of the group doesn't have to make the exchange because they don't have the proper items. By applying strict logic you have to do it this way: Imagine a couple of children(Easy for me cause I can use my kids).

I give my daughter an apple.
I give my son an orange.

I then tell them they can trade(they didn't understand the word exchange :( ) their apples for a banana. My Daughter then says cool, but my son immediatly starts to cry because he doesn't have an apple to trade with. Children are great for strict logic because this is what they see. Black and White. Adults however prefer to see Grey in which you see it is obvious to you that the entire mob doesn't HAVE to trade as onlythose with the proper equipment can trade. Those without the equipment would be ignored.

In my family's case, Poor Cyrus(My Son) :(

OT, but I didn't think it warranted a new thread. I'm curious.

Hey Ghaz or anyone else volunteering their time to write AB files (thanks ), I was wondering what made you guys go to v3.x instead of stick with 2. Considering the fact that AB wouldn't be used at all without your guys' writing, why didn't you guys just stick with 2.x, so you wouldn't have to buy a copy?

I have 2 and tried 3 but didn't think things changed enough to warrant a new purchase. I know how much of a pain in the ass it is to modify a list since I had to do a major rehaul when Tau Empires came out.

stonefox wrote:OT, but I didn't think it warranted a new thread. I'm curious.

Hey Ghaz or anyone else volunteering their time to write AB files (thanks ), I was wondering what made you guys go to v3.x instead of stick with 2. Considering the fact that AB wouldn't be used at all without your guys' writing, why didn't you guys just stick with 2.x, so you wouldn't have to buy a copy?

I have 2 and tried 3 but didn't think things changed enough to warrant a new purchase. I know how much of a pain in the ass it is to modify a list since I had to do a major rehaul when Tau Empires came out.

For me its simple. I wanted to support the company that created the software. The 2.x version is old, the files written for it are cumbersome and a pain to support, the way they were developed(due to the 2.x architecture) cause everythign to be slow and crash from time to time, and honestly, no one I knew personally with a copy actually bought it as the license didn't manage properly and allowed for piracy. I know this is a generalization, but I view most everyone that refuses to upgrade as a pirate as I do not understand the reason why you wouldn't want the newer version.

That's just me, and I know not everyone are software pirates, but you asked why and I wanted to answer.

BTW, All my friends have upgraded as well as they see the benefits of the newer version.