Any plans to replace this program?

[sir_pudding]

Originally Posted by Armin

I don't *want* people to suffer with crashes. I don't *want* GCA to crash, and to be seen as buggy. I try to catch things and handle them gracefully in the code. But GCA is a bit complex, and there is a lot going on at times, so things slip through. This is compounded by my being one guy, without a QA team (other than my helpful, but small, beta crew).

The only way I can fix crashes is if people tell me what they're doing, so I can try to reproduce the issue. If I can't reproduce it, it can't be fixed. When all people say is "it crashes all the time" it provides no useful information, so whatever might be happening to you can not be fixed.

Otherwise, your only hope is something that will come along extremely rarely: a new code base overhaul like the one I'm doing now.

Armin

I didn't mean it as a criticism. I just meant that if there is a new version I don't really care about speed, or how it handles "locks and hides" as much as I hope that it's more stable.

EDIT: And I'm pretty sure I have reported some of the crashes, it's been awhile since I've bothered, though. Do you really want me to tell you every time the program crashes because I changed a skill level or tried to change the loaded gdfs? I'm basically used to it now. It's not that big of a deal because it rescues pretty reliably.

[Armin]

Originally Posted by sir_pudding

I didn't mean it as a criticism. I just meant that if there is a new version I don't really care about speed, or how it handles "locks and hides" as much as I hope that it's more stable.

Me too, believe me. I believe that some of the issues people see are actually related to underlying issues that I can't directly address. The more modern dev system should address some of that.

Originally Posted by sir_pudding

EDIT: And I'm pretty sure I have reported some of the crashes, it's been awhile since I've bothered, though. Do you really want me to tell you every time the program crashes because I changed a skill level or tried to change the loaded gdfs? I'm basically used to it now. It's not that big of a deal because it rescues pretty reliably.

No, you're right, just reporting every crash doesn't help, because if it's not reproducible, it's not really helpful.

Armin

[sir_pudding]

Originally Posted by Armin

No, you're right, just reporting every crash doesn't help, because if it's not reproducible, it's not really helpful.

Yeah, I can't reproduce the crashes. The only constant is that the program will crash when I tell it to do something eventually, but that something isn't the same thing from one crash to the other. Which is not really much of a bug report.

[panton41]

Originally Posted by Bruno

Just because it's the way you want racial templates to work doesn't mean it should be the default :D In GURPS you're not really supposed to mess around with your racial templates, and they're listed as a single item on your character sheet, not as a list of traits.

Those are great options, I agree, but not acting like the books say really shouldn't be the default.

I'll give a perfect example of when it's annoying - making a member of an "Attractive" race "Beautiful." This requires adding the Disadvantage of "Not Attractive" then turning around and adding back the exact same Advantage that was removed. Let's not get into how difficult it is to add the same trait twice - especially when it's locked and hidden.

Not to mention it's hard to teach new players when they don't know exactly what's happening behind the scenes of their character build. Most all of my players, and myself, want to see this info.

So add me to the list of people who think "Locked" and "Hidden" by default is a bad idea.

[panton41]

I think a major point of instability and random crashes has been more or less:

1) Make change to character.
2) GCA processes the change.
2.5) Make another change to character before the first change's processing is over.
3) Crash

It won't do it 100% of the time, but repeat that procedure enough and it'll happen. Especially on a slow machine where that processing can take a very long time. And especially under WINE, but that's a special case in itself.

[ericbsmith]

Originally Posted by ciaran_skye

I think a major point of instability and random crashes has been more or less:

1) Make change to character.
2) GCA processes the change.
2.5) Make another change to character before the first change's processing is over.
3) Crash

This has been my experience as well. It seems double-expecially-true if you have the Quick View tab open, either because of some slight instability in the Quick View or because the Quick View causes calculations to slow down while it's open.

[Armin]

Originally Posted by ciaran_skye

I'll give a perfect example of when it's annoying - making a member of an "Attractive" race "Beautiful." This requires adding the Disadvantage of "Not Attractive" then turning around and adding back the exact same Advantage that was removed. Let's not get into how difficult it is to add the same trait twice - especially when it's locked and hidden.

Not to mention it's hard to teach new players when they don't know exactly what's happening behind the scenes of their character build. Most all of my players, and myself, want to see this info.

So add me to the list of people who think "Locked" and "Hidden" by default is a bad idea.

Show > Show Components is your friend.

Show Components exists for the very purpose of showing you what parts make up a template (or other compound trait). From there, selecting one and right-clicking to choose Disable Component isn't difficult, and creates the opposing advantage/disadvantage ("No Appearance" or whatever) automatically. It's pretty easy to add the new Appearance then, because the other is disabled, and has "*Disabled*" as part of the name, so there are no duplicate item issues.

Racial templates are basically meta-traits, so the components are supposed ("officially") to not be shown on the sheets. And you're supposed to take the "No whatever" ad/disad when you vary from the norm for the template. So GCA is promoting, and assisting, the user doing that as it's supposed to be done.

If the components aren't locked, then changing the value of the bits will change the value of the template, and that's absolutely not how things are supposed to work, so locking also helps to ensure that things work as expected.

While I understand how many feel about this, and sympathize since I like to see the component bits as well, the hidden and locked behavior is one of the few things that SJGames specifically requested that GCA should do, so it's unlikely to be changed from this default behavior, even though we try give you options to work around it.

If folks have suggestions as to how it can be made more clear to new or novice users as to what's going on, and how they can deal with it, I do love to hear such suggestions. I don't like having things that leave people confused or frustrated.

Armin

[Armin]

Originally Posted by ciaran_skye

I think a major point of instability and random crashes has been more or less:

1) Make change to character.
2) GCA processes the change.
2.5) Make another change to character before the first change's processing is over.
3) Crash

It won't do it 100% of the time, but repeat that procedure enough and it'll happen. Especially on a slow machine where that processing can take a very long time. And especially under WINE, but that's a special case in itself.

Yeah. Trying to work out ways to limit that kind of interference. Doing it while still allowing proper feedback to the user seems a bit vexing.

Armin

[Urban]

I for one would love to get the stuff from the many books/pdf files released the last few year added to the GURPS Character Assistant with a quality stamp on them.

I know you can add it yourself but since my know-how is lacking and my time limited I for one would support a pay for additions scheme similar to the one used for Hero Labs character software. Another benefit of this is more money to pay for upgrades but of course you must balance that against any potential loss of customers that want all future additions to the rules and content for free.

[panton41]

Originally Posted by Armin

Yeah. Trying to work out ways to limit that kind of interference. Doing it while still allowing proper feedback to the user seems a bit vexing.

Armin

Maybe set up a change queue or simply lock the interface to changes while processing occurs. I have a feeling the first option is almost impossible without dramatic changes to the code base and the second option would give the appearance of the program being slow or locking up. Though if processing speed increases sufficiently that second idea might not be too bad.

For what it's worth, is the interface changing dramatically? There's been a subtle push in certain levels of software development away from the "classic" menu-driven WIMP-interface to ones that allow and give more direct visual clues. GCA could easily lose its menu structure in favor of a modal button-driven interface.