 |
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
 Posted: Mon Jun 08, 2009 5:26 pm
3.08 close to Public status
|
According to the bug reports I'm receiving, it looks like 3.08 is working pretty well for most people.
I do have some issues on my high-priority list for the next version:
1) Clicking Map button for additional sessions doesn't allow multiple map windows to be created
2) New/Window in settings editor makes a new style instead of a window
3) %isnumber not working for null values
4) #mapquery crash
5) Save layout when AutoSave is turned off is not working
6) Using #NNN within #IF statements
Other items that would be nice to have:
1) Support multiple keywords in rooms and classes
2) Auto-unwrap lines from MUD
3) Auto-strip MUD prompt with display in status bars
4) Multiple status bars
along with various other minor bugs and issues.
Am I missing anything critical here? Right now I'm planning to wait another week or so before releasing a new version to make sure I have caught all of the important issues from 3.08. My goal is to release a public version for CMUD 3.0x sometime in July and also start marketing TeSSH in July (press releases, etc). |
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: Mon Jun 08, 2009 6:21 pm
|
I was wondering if you are going to address any of these lingering bugs?
http://forums.zuggsoft.com/forums/viewtopic.php?p=145987#145987
I was doing my best to be patient and not mention them again, but if you move this to a public version and move on to mapper work it may be a year or more before you start to address these type of bugs again. Also, old bugs seem to get lost after a while since the, who knows if it's still a bug, uncertainty starts to come into play. |
|
|
|
|
Dwoggurd
Wanderer
Joined: 29 Jan 2008
Posts: 63
|
Posted: Mon Jun 08, 2009 7:16 pm
|
Color/HTML logging issues are included?
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Jun 09, 2009 4:50 pm
|
ReedN, which specific ones on that link are you still looking at. Many of those have already been fixed, so I need some indication of which ones you consider high priority. All of them are still on my bug list. But my bug list has hundreds of issues on it, so I always have to prioritize what gets fixed based upon how many people it effects and how difficult it is to fix.
You are correct that old bugs get lost after a while because uncertainty starts to come into play. I rely on beta testers like you to let me know which of your bugs are still a problem. Note that when you Edit a post, the post date doesn't get changed so it doesn't reappear at the top of the forum where I can see it. When you edit a post like you did recently, also add something like a "bumped this post for 3.08" as a new reply so that it reappears on the top of the forum where I can see it. Otherwise I never see your edits (which were very useful, thanks). But the issues that are remaining in that post seem pretty minor to me.
Dwoggurd: Yes, color/html logging issues are included...I should have put those on my list above. What I have for HTML logging is
1) #PCOL color not saving in HTML output
2) HTML logging not closing SPAN tag
If I missed something else, post a link to the issue. |
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
|
|
|
|
Dwoggurd
Wanderer
Joined: 29 Jan 2008
Posts: 63
|
|
|
|
|
Anaristos
Sorcerer
Joined: 17 Jul 2007
Posts: 821
Location: California
|
Posted: Wed Jun 10, 2009 12:30 am
|
I would like to mention some problems that I have found using the COM object (for which I have posts):
1: If the target of the COM object exposes an overloaded method, CMUD will return an invalid method specification when invoking any variety of the method.
2: If the target of the COM object exposes a method with a variable list (e.g. MethodName(string arg1, params object arg2[])), CMUD will return an invalid method specification when invoking the method.
3: It seems that there is no way to decouple the COM object once created. Setting it to null doesn't seem to clear the reference to the target.
I have sent a few dumps of these problems. |
|
_________________
Sic itur ad astra. |
 |
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Wed Jun 10, 2009 12:52 am
|
Dwoggurd: I didn't see any unresolved issues in that thread that still occur post 3.06 except for the issue with CMUD sometimes not closing a SPAN tag (which is already in my list). If you have a procedure for reproducing other problems with "simple" ANSI codes, please start a new thread for 3.08 with the procedure that you are using so I can try to reproduce it.
Anaristos: I'll take a look at your dumps, but #1 and #2 probably won't be addresses in this public version because those are such rare issues (few people even use COM, and the issues that you mention are very advanced COM issues that most COM users won't even encounter).
Remember that I said I had hundreds of minor issues like that on my list and it would take me years to fix all of them. There just isn't a business case for me to spend a lot of time on really minor issues like this. I've got to get the public version out so I can start marketing TeSSH and get some more income. Nobody (or very few) people are going to make a buy/no-buy decision for CMUD (or TeSSH) based upon those kind of obscure issues. It just doesn't make sense for me to spend all of my time working on stuff that isn't going to generate income, especially with income as critical as it is these days. If I got a good-sized donation to focus on some of these issues or if you got more people to buy CMUD because of it, then it might be different. All software companies have to make business decisions about what bugs they fix or don't fix, and it's the same for me. I wish there was enough time in the world to fix all of these issues, but there isn't and I'm just one person.
#3 sounds more like a bad bug that needs to be fixed. I know CMUD *used* to remove the COM reference when you assigned nil to a variable, so that fact that this doesn't work properly anymore is something that should be easy to fix. #1 and #2 are not easy to fix. |
|
|
|
|
Dwoggurd
Wanderer
Joined: 29 Jan 2008
Posts: 63
|
Posted: Wed Jun 10, 2009 3:18 am
|
http://forums.zuggsoft.com/forums/viewtopic.php?p=147269#147269
This post contains an example with broken coloring on a sreen. I'm not sure if it is exactly the same problem as with a SPAN tag.
Again, not only a html log is mailformed, but also a visual output on my screen contains "unclosed" red color.
This can be reproduced in 3.08 (triggers and a command to invoke are in the post). |
|
|
|
|
Arde
Enchanter
Joined: 09 Sep 2007
Posts: 605
|
|
_________________
My personal bug|wish list:
-Wrong Priority when copy-paste setting
-1 prompt trigger for Mapper, Session and General Options, not 3 different!
-#SECTION can terminate threads
-Buttons can't start threads |
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: Wed Jun 10, 2009 4:52 pm
|
| Zugg wrote: |
Remember that I said I had hundreds of minor issues like that on my list and it would take me years to fix all of them. There just isn't a business case for me to spend a lot of time on really minor issues like this. I've got to get the public version out so I can start marketing TeSSH and get some more income. Nobody (or very few) people are going to make a buy/no-buy decision for CMUD (or TeSSH) based upon those kind of obscure issues. It just doesn't make sense for me to spend all of my time working on stuff that isn't going to generate income, especially with income as critical as it is these days. If I got a good-sized donation to focus on some of these issues or if you got more people to buy CMUD because of it, then it might be different. All software companies have to make business decisions about what bugs they fix or don't fix, and it's the same for me. I wish there was enough time in the world to fix all of these issues, but there isn't and I'm just one person.
|
That is, of course, your prerogative. However, in my opinion, the inevitable result of ignoring bugs considered important to your beta testers will be less bug reports. They probably won't consider it worth their time to spend large amounts of time working on bug reports, only to see their work marginalized and then ignored.
I personally won't mind seeing a smaller feature set, but nearly bug free, rather than a huge feature set where I run into bugs all the time. But perhaps that's just me. If you are feeling overwhelmed by the bugs, perhaps you have overextended yourself in the feature set that you are reasonably able to manage. If you keep adding more features it seems like it is only going to make the situation worse. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Jun 11, 2009 12:38 am
|
| Quote: |
| That is, of course, your prerogative. However, in my opinion, the inevitable result of ignoring bugs considered important to your beta testers will be less bug reports. They probably won't consider it worth their time to spend large amounts of time working on bug reports, only to see their work marginalized and then ignored. |
While that might be true for some people, that hasn't been my experience with most beta testers over the past 12 years. Most beta testers understand that there isn't enough time available for me to fix *everything* and that I need to run a business and make a living from this. They know that I *do* value their work and bug reports and that I never "ignore" them. Those bugs are always still on my list and I still take time away from programming to respond to the reports on these forums.
Adding certain new features attracts new business, which means more sales. Fixing some obscure bug that 99.9% of users don't ever encounter doesn't attract new business. That's the reality. Just because you are encountering the bugs doesn't mean that everyone else is too. In general, beta testers tend to be a lot more advanced than the typical user. So you are exaggerating when you say "I run into bugs all the time". That just isn't true. The number of crashes and bug reports *per user* is significantly less in v3.08 compared to the current 2.37 public version. In many cases there are also workarounds, or, as in several of your reports, the bugs are just annoyances that are easily dealt with. If a bug was stopping someone from using a feature at all, then I consider it serious and it gets fixed. But most of the issues you are reporting are more in the "annoyance" category.
But obviously I *DO* care about this stuff, which is why I haven't release a new public version yet. I wanted to release a public version 6 months ago, but instead I've been fixing bugs. Yes, I still add new features, because I need to make sure that the 3.x version has compelling new features for *all* CMUD users and not just the mapper users. But most of this past 6 months have been spent on bug fixes.
But the bottom line is that I have to do what makes sense for *all* CMUD users (including new potential users of CMUD or TESSH) even if it means that some issues from beta testers get pushed to lower priorities. That's the way I have always worked, on both zMUD and CMUD, for the past 13 years.
| Quote: |
| I personally won't mind seeing a smaller feature set, but nearly bug free, rather than a huge feature set where I run into bugs all the time |
It's a fine opinion to have, but it doesn't match what Zugg Software has ever been about. zMUD and now CMUD have always been the most feature-rich clients. Just because you don't use certain features doesn't mean that there are not hundreds of people who do. This argument is so common when complaining about any software (MS Word, etc). Everyone wants to remove so-called "bloat" and get rid of features they don't use. But the features that are critical to each user are different! The richness of features has always been the trademark of zMUD and CMUD. If you want a "smaller feature set" then there are plenty of "bare-bones" open-source MUD clients you can use. My guess is that most/all of them won't have some of the features that you personally need.
Yes, it's true the one person managing more than 1.5 MILLION lines of code is overwhelming. And it gets worse every day as new features are added. But in many cases, those "new features" are more like improvements (fixes) to old features rather than completely new features. Look at the new mapper...it was rewritten to address many problems (bugs) in the old mapper. Does that make the new mapper a "new feature"? No...it's an "improved feature". But the fact that the code for the mapper was rewritten means that it will take time to debug. Even if it already has fewer bugs than the 2.37 mapper, or even the zMUD mapper.
Sorry for the rant. But none of this is really new...features vs bug fixing has been discussed many times in the past. There are no easy answers. If there were, then it wouldn't be a problem and we wouldn't keep talking about it every year or so. The only solution is to invent a time warp where I have more time to work, or suddenly increase CMUD sales by a factor of 3 to 5 so I'd have the money to hire help. If I stopped adding new features, competitor clients would catch up and people would stop buying CMUD, making the problem even worse, so you'd need to eliminate all competing MUD clients before I could stop adding new features. None of those solutions is likely to happen any time soon. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Jun 11, 2009 9:45 pm
|
Anaristos: I was not able to reproduce your 3rd issue with COM:
| Quote: |
| It seems that there is no way to decouple the COM object once created. Setting it to null doesn't seem to clear the reference to the target. |
Give me the link for this and I'll post it in your main post. But here is what I did:
| Code: |
a = %session
#VAR
a = ""
#VAR |
The %session assignment stores the COM object reference in @A. After assigning the null string to a, the #VAR showed the variable as empty. When I did this in the Delphi debugger, I looked at the internal object reference for the @a variable, and it was "unassigned" which means the COM reference was properly cleared. Maybe you were doing something different, but this method properly clears a COM reference from a variable. So I'd need to see your exact code, so please bump whatever old post you reported this problem in so we can continue the discussion there. |
|
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
