First step of solving the prerequirement loop problem
The prereq works fine until some spells can prereq each other.
For example, take 3 Water Spells, with two of them requiring 2 other Water Spells. If you add only the basic one and one of the other two, the latter will be shown red, because its requirement is not fulfilled. If we add the third, suddenly all three spells are black, because each of the two advanced spells has its two water spells prerequirement fulfilled. However, this is agains the GURPS rules.
This happens because the GCS doesn't acknowledge time of learning. Because I think adding this would be too much trouble, I tried something else, basically a loop detection by depth first search. I added marker lists to spells, one for each type of spell requirement: name, any, college and college count. The example described above can be applied to all these cases, although with names one would have to use at least "contains" instead of "is". In fact I excluded this case from the changes for GUI reasons (if only the prereq of a prereq is not fulfilled, the prereq will be shown red, but the spell of the prereq black, which seems intended). Now when a spell prereq is being checked if satisfied, it itself checks the satisfication of its prereq spells. Only satisfied spells will be taken into consideration to see if this spell is satisfied and loops will not occur.

What's the improvement: Satisfaction by use of loops (as described in the example) will no longer occur and spells who fell under this will occur red from now on. This loop situation is not common, but can happen from time to time. This should also work with "equal" and "less than" and "doesn't have", if you see spells not meeting their requirements as basically not being there. Except for the "whose name is", as I wrote earlier. So e.g. if I have three spells, the second (order is not important here or above) requires the third not to be here (never seen that) and the third requires two any spells. Then... Okay, wait, that's a loophole. Good, another thing for...
What's the downside: This is basically a draft. These last hours I worked on the code I saw this concept can be extended to all dependencies, although I never noticed it outside of spells; furthermore I don't know how to clever implement the different marker lists except by just listing them all up. Oh wait, a map to lists would probably do. Next thing is, I don't know what would happen with deeply nested prereqs, as the spell it comes from is marked all the time. This could cause problems, but I can currently not think of any examples. And last, I haven't tested the code, sorry!
Didn't seperated this from the other, the important commit. Still getting used to committing...
Added check rolls for staying conscious and alive
(the numbers to roll against), so Hard to kill, Hard to subdue, fit and other features can manifest with numbers in the sheet.
I created the two checks by copying the fright checks, added it to the other FP/HP stuff and opted it by copying including kicking. I think I got all instances. Untested.
Made the number of decimals changeable.
The numbers variable has to be changed in SheetPreferences because in contrast to other preferences this value isn't explicit asked for when it's neededbecause it lies deeper in the code. An alternative would have been to add precision as a parameter to different functions but I thought that would have been in direct contrast to what happens in Number.java.
Untested.
Forgot that file for the Death Checks.
AttributeModes visually-wise added and the enum, but it does not change anything yet.
Note for Acting added.
It's important to know the modifier for IQ differences.
Corrected some typos.
Corrected some typos.
Merge pull request #8 from Ayutac/attributes

Corrected some typos.
First part of debugging.
Forgot to pull to local after pulling into master.
Merge pull request #9 from Ayutac/master

2nd Pull test
Corrected method name.
Corrected method name.
Another little bug.
Updated .gitignore
Tested and corrected lots of stuff
Decimals corrected
new Checks corrected (
Divider extracted only from HitPointsPanel, should be extracted from all
 Decided not to show the new checks optionally because it seems a little bit to different to me to get it clean right now. One reason is that the component creation of DropPanel and friends isn't thought to be hidden sometimes and the second one is that I'm not quite used to the notifications.)
Second part of fixes and the attribute modes!
As written earlier I decided against hiding elements because doing that is non-trivial in the given toolkit-environment. If someone enables better hding of components, I may make some things invisible on command.
Merge pull request #10 from Ayutac/attributes

Attributes