|
|
New 7.6 Coming Soon?
About Truespace Archives
These pages are a copy of the official truespace forums prior to their removal somewhere around 2011.
They are retained here for archive purposes only.
New 7.6 Coming Soon? // Work in Progress
Post by Steinie // Apr 9, 2008, 1:07am
|
Steinie
Total Posts: 3667
|
Caligari decided to wait supplying bug fixes to users and only give them to Pro Team Members instead. The "Others" (normal users) have to wait build to build. So if I don't purchase the next build I'm stuck with these bugs. Is that fair by any Company? |
Post by W!ZARD // Apr 9, 2008, 1:14am
|
W!ZARD
Total Posts: 2603
|
:D
We discuss round in circles here. We have been at the point of the business model before. Current business model has cost hundrets of users, leaving the remaining ones unsatisfied. I simply cannot say it is a good one.I'm not necessarily saying it's a good one either - I'm trying to say they may well have a perfectly good reason for doing it that way that you and I don't know about.
I make games since years too, and know at least from that angle what i talk about when it comes to bugs and fixing them. And i work alone, make everything by myself :)
Your told case here is more than bug fixing. This is adding new features. Which is a completely different chapter. A tool that is there should work when i click the button for it. And fixing that doesn't mean to add new features.Is one person making a game comparable to to a team of people building a more complex piece of software? I don't know but I have my doubts.
I'm a musician, I've played solo and I've played in bands - believe me playing solo is much less complicated but then, you cannot do as much either.:D
Complex software is not analogous to a box of separate tools as I've said which is where I believe your theories are inappropriate. I mean no offence but I believe your terms of reference to too far from the reality to be applicable. I'm not trying to change your mind or call you wrong, just to point out a different viewpoint.:D |
Post by Tiles // Apr 9, 2008, 1:48am
|
Tiles
Total Posts: 1037
|
Staying with your analogy: A note is a note. No matter if you play solo or in a big band. And you better play the note clean in a big band too.
A wrong pointer is a wrong pointer. A wrong variable is a wrong variable. A bug is simply a bug. No matter if in a Pong clone or in the biggest software ever. And don't underestimate making games. My biggest one took me three years. Don't you think that i have a bit knowledge about the bug issue after years of making games? ;)
I cannot find a single bug in the bugs section that makes it necessary to implement a new feature or to change the manual for that. Show me just one :)
Point is, i know because i did it before, but you just guess. And you don't accept that i know. You think i just guess too. Makes the discussion pretty complicated. |
Post by Jack Edwards // Apr 9, 2008, 1:51am
|
Jack Edwards
Total Posts: 4062
|
Proteam never got any patches before the rest of the users that I ever saw. Last time around we did get eventually get betas to play with, but that didn't happen this time. So this last year the only advantage that proTeam had was the free courses and there were only two courses. So with Caligari now offering free phone support now to all it's customers, it's hard to see the advantage of proTeam. Likely that's why it's no longer offered on the website.
Subscription services are really kind of an odd model anyway in today's world of internet distribution. Like has already been mentioned, if you can make a distribution for a patch why deny it to the rest of your users? I think services likely that date back to the days where updates were mailed out on CDROMs... I used it mainly for the included courses and the guaranteed price on updates.
As to the cost effectiveness of patches, there's a real simple reason why it's more (time) cost effective to release fixes with version upgrades. You don't have to maintain separate code bases (each with their own unique fixes) for each previous version. It also allows for the fix to include re-writing entire sections of the application. Why waste time working on band-aids for tools in old versions when the tool is planned to be replaced or revamped and each new version basically makes the old version obsolete? I'm not necessarily saying that I agree with that approach or that is why/how Caligari chooses to do things the way they do -- it's an example of how releasing fixes with upgrades is more time/cost effective.
Again it all goes back to the whole thing about an application in transition. My guess is that when the core features are fully implemented and model side has been removed (8.0) it will be a lot easier for Caligari to release small updates in the form of maintenance patches. Of course, hopefully by then, we won't need them. ;) |
Post by Steinie // Apr 9, 2008, 2:00am
|
Steinie
Total Posts: 3667
|
Thanks Jack, Caligari must have changed their mind about supplying Pro Team Members with update/patches.
I certainly don't feel that all the bugs be fixed for us before the next release. Just the serious bugs preventing an operation or tool to be performed.
I think Wizard is in a time warp and Tiles is in a Hamster Wheel. At the end of the day what has changed?:) |
Post by Tiles // Apr 9, 2008, 2:08am
|
Tiles
Total Posts: 1037
|
Oh, alot here. Stopping here to discuss doesn't mean to stop life :)
We discuss what has to be discussed because there is need to. Else this thread wouldn't grow this fast ;)
What i hope to change is that Caligari wakes up and changes its marketing strategy when it comes to bugs. May not work. And i may need to change my rendersoftware because of that as others did before. But at least i tried :) |
Post by Jack Edwards // Apr 9, 2008, 2:51am
|
Jack Edwards
Total Posts: 4062
|
:D LOL Stienie!
And you're of course welcome! ;)
Yeah they must have. Last I'd heard on the proTeam forums, 7.5 was supposed to put in place architecture that would've allowed for quick patches and updates for proTeam members. It never materialized and my guess is that the idea was scrapped.
As far as a bug free 7.6 goes, we're gonna give a good go at it. I think the other beta testers feel the same way as well. Prodigy has already mentioned that he's using 7.6 in a production environment and that he won't go back to 7.51, so that should tell you something right there. I agree hoping for perfection would be setting your expectations too high, but there are relatively recent developments that make me very optimistic about this this upcoming version (and no they are not cloth or booleans ;)).
BTW, I know that some have expressed concern that Caligari is "wasting time" working on flashy things like cloth. But I think it would be a mistake to take that simplistic a view. TrueSpace needs to have those "high-level" features to remain competitive at it's current price point. While I have actively argued for a primary focus on usable workflow and making the existing toolset more solid, I also cautioned that we can't ignore the need for new flashy tools that will encourage users to upgrade and help keep TrueSpace competitive with other apps. Much as we hate to admit it marketing considerations *are* important.
But I agree with Tiles, for many users how the bugs shake out will determine if they stay or go especially since they have to decide if staying is worth learning the new interface, or if now is the time to move to a different (possibly more expensive) software. |
Post by Tiles // Apr 9, 2008, 2:58am
|
Tiles
Total Posts: 1037
|
Can i have a dollar for every bug i find in 7.6 please? :D |
Post by Jack Edwards // Apr 9, 2008, 3:00am
|
Jack Edwards
Total Posts: 4062
|
LOL Tiles! Depending on your definition of "bug" and as good as you are at finding them that might be a money losing proposition! :p |
Post by frootee // Apr 9, 2008, 4:24am
|
frootee
Total Posts: 2667
|
Can i have a dollar for every bug i find in 7.6 please? :D
How about you Pay a Dollar for every bug you find? :D
Just kidding! Just kidding! |
Post by kena // Apr 9, 2008, 5:37am
|
kena
Total Posts: 2321
|
Just to be specific... When I got my proteam, I paid lots of money.
What I get for it is "possible" pre-release of new software. "Free" tutorials and upgrades. Nothing else. No bug-fixes unless everyone gets them.
"Free" means that I've already paid a bundle in advance. I MIGHT get my money's worth. I might not. Then again, I might end up having paid less than someone who did not get the ProTeam. It's a gamble. I felt that it was a gamble that was worth taking, so here I am. |
Post by Steinie // Apr 9, 2008, 5:43am
|
Steinie
Total Posts: 3667
|
Just to be specific... When I got my proteam, I paid lots of money.
What I get for it is "possible" pre-release of new software. "Free" tutorials and upgrades. Nothing else.
I thought you guys wore Black Suits and Foster Grants as part of the Membership!...:rolleyes: |
Post by Steinie // Apr 9, 2008, 6:11am
|
Steinie
Total Posts: 3667
|
QUOTE=Jack Edwards
I agree hoping for perfection would be setting your expectations too high, but there are relatively recent developments that make me very optimistic about this this upcoming version (and no they are not cloth or booleans ;)).
The only thing I could think of that would have a huge impact would be a SDK for WorkSpace, Dribble could finally be brought over to have another rendering option with 3Delight. That would be huge news.
Another biggie would be Layers.
I'd still like to see how they want me to bend a pipe, or create the new fluorescent light bulbs in WorkSpace...
Thank goodness we have users here giving us improved light management. |
Post by Igor K Handel // Apr 9, 2008, 7:07am
|
Igor K Handel
Total Posts: 411
|
Wizard.. your debate as always reasoned, but heck did you Ghost Write War & Peace. I mean do you dictate to a roomfull of shorthand typists lol. Don't you ever run out of ink?? Do you sleep... like EVER? :D
Ok so I now live to regret the woodworking tools comparison.. should have seen that coming:rolleyes: But I am sure you have got my point, as Tiles did?
Cunning plan to circumvent Wizard's debating skills.... lol
So I should be comparing a space Shuttle to TS.. AHA get outta that one !!!
(am laughing here)
Hmmm glad I am not on the moon rely on a tool in Ts to get me home. (Still at least I can pass the time using my woodwork tools, that have now become surplus to requirement)
Houston we have a problem...
Come back Ik please report status...
Looks like we won't be coming home a vert has shot off to infinity whilst weight painting.
Yeah IK no-one in Houston forsaw that you might use weight painting to er weight paint.. We have our guys on it now..
Houston what is timeframe for workaround... Muffled background heated voices. IK this is Houston all is in hand just wait for the next upgrade. 3 or 4 months.
Houston we copy that. All is well,, that is perfectably acceptable...
IK continues to whittle his model of a O2 molecule. A subject very dear to his heart. After a bit he decides to have a meal, so he opens the cabinet of the Revamp reverse molecular jiglifier cooker, a cookathon 3000 model ver 7.6. It looks remarkably like a woodworking tools carrycase. Nah must be going space crazy.
Yours in good humour
IK |
Post by Jack Edwards // Apr 9, 2008, 7:49am
|
Jack Edwards
Total Posts: 4062
|
LOL Igor! :D |
Post by Igor K Handel // Apr 9, 2008, 9:28am
|
Igor K Handel
Total Posts: 411
|
2 hours and no reply from Wizard.
YES YES YES He's stumped for words.
Yeehaa I've done it. LOL.
IK |
Post by jayr // Apr 9, 2008, 12:01pm
|
jayr
Total Posts: 1074
|
hate to Say it Igor but he's in New Zealand, he'll probably reply while you're asleep |
Post by spacekdet // Apr 9, 2008, 12:16pm
|
spacekdet
Total Posts: 1360
|
Don't laugh yet, he's still typing. |
Post by kena // Apr 9, 2008, 1:35pm
|
kena
Total Posts: 2321
|
So I should be comparing a space Shuttle to TS.. AHA get outta that one !!!
(am laughing here)
IK
Actually, you could compare TS to a house. You buy a new house, and find that there is a leak in the garage whenever it rains. So you call the builder, and they come out and fix the ceiling... It rains, it leaks, you call - and they come back out and fix the ceiling... It rains, it leaks -
You call Mike Holmes (http://www.holmesonhomes.com/) from Canada, and he takes a look at it and says; "well, it would probably stop leaking if they actually fixed those tiles on the roof that were not nailed in correctly."
First you have to identify the problem
Then you have to identify the cause
THEN, you can fix the problem. ;)
... now on to that knocking sound that comes from the living room every time you flush the toilet... hehehe |
Post by 2much4U // Apr 9, 2008, 3:47pm
|
2much4U
Total Posts: 430
|
Ha, lol! :D
I'm actually quite excited about the features just announced by Roman. When I use TS, I almost always have to render out of the Model side because Workspace lacks the ability to render an alpha channel. If the Workspace were to gain this capability, it would drastically decrease my use of Model. Also, the new cloth tools should help me with my current animation (the untitled), especially with the clothing. I'm mainly excited because these features will be around in tS7.6, which Roman has stated will be a free upgrade to 7.51 users!
:jumpy: |
Post by Steinie // Apr 9, 2008, 3:51pm
|
Steinie
Total Posts: 3667
|
... in tS7.6, which Roman has stated will be a free upgrade to 7.51 users!
:jumpy:
You mind sharing the link to that statement? |
Post by W!ZARD // Apr 9, 2008, 8:08pm
|
W!ZARD
Total Posts: 2603
|
Are you all sitting comfortably?
Friends, Romans(?) and Countrymen, lend me your ears!!
I'll try to keep this short - no promises though.:D
@IKHandel - yeah the War and Peace joke has already been made by Frootee in another thread.:D I started signing my posts as 'Leo Tolstoy' and he got worried I'd taken it to heart - and I can't really object as it's clearly a reasonable comparison!!
Re "I mean do you dictate to a roomfull of shorthand typists lol." I gotta do something while I'm waiting for my animation to render. If we had realtime reflections in Workspace you would hear a lot less from me!
Re "YES YES YES He's stumped for words" - Sorry mate, that hasn't happened since my first date in 1972!:p
Re your Space Shuttle comparison - I like that, I might even share some thoughts on that later;)
@spacekdet - Re "Don't laugh yet, he's still typing" LOL, you'll have to teach me how to say so much with so few words!!.
@Tiles - Re ""you just guess." Yes I do, that is indisputable. The guesses however are (I hope) educated ones. My background (Stienie may be right about me being stuck in a time warp) includes 14 years of working as a telephone technician and repairman. For 5 years I was a faultman in charge of repairing each and every faulty phone in a huge area 300 miles long. Each morning I would receive a handful of newly reported faults. A common fault was NRR - meaning Not Receiving Rings. With that information plus the phone number and the associated cable pair numbers I was expected to go and find and repair that fault. I can easily think of at least a dozen physical causes for an NRR fault even though the phone circuits of the day were very simple and any fault was ultimately either a broken connection, a short circuit or a contact with either the ground or another phone line.
I've seen NRR faults caused by trees in the lines, forest fires burning the overhear wires, cars knocking over poles, drain-layers digging up cables, lightning strikes, and so on and on. I've seen phones that had been shot by a hunting rifle and children hooking their crystal radio sets up to the phone line in the crawl-space under the house.
My point being that it may seem very simple to the phone user - the damn thing is not ringing! But the reality might involve replacing a length of cable under a busy road, or it might involve simply removing the build-up of spider webs from the outside extension bell!
I find it very difficult to believe that bug-fixing a highly complex piece of software is as simple as you say it is tiles. An old-fashioned telephone is a comparatively simple device - the lines suppling that phone may be in perfect order and still the damned thing won't ring! The bell circuit in the phone is very simple, so simple problems like a loose terminal are easy to find. The thing is that the ringing circuit shares common components with the dialing circuit - they both share the same capacitor so a short circuit in the dial can in fact stop the bell ringing.
Fixing a faulty phone or buggy software are quite different things but at the basic level require similar strategic principles. Quality control and error rectification are in principle the same no matter where those principles are applied - even when fixing the Space Shuttle!
Ultimately, it's quite simple to my mind - if it was as simple to fix bugs as you say Tiles why wouldn't they do it that way? If it was more cost effective to release 4 minor upgrades a year rather than 1 big upgrade, as suggested by Tiles, why wouldn't they do it that way?
It's their job and it seems to me that they would most likely want to do it in the best way possible given the circumstances.
Peace Love and Mung Beans
Leo Tolstoy. |
Post by Burnart // Apr 9, 2008, 8:42pm
|
Burnart
Total Posts: 839
|
Say what?
(I got an error saying the message was too short so I added this line.) |
Post by Tiles // Apr 9, 2008, 9:23pm
|
Tiles
Total Posts: 1037
|
I find it very difficult to believe that bug-fixing a highly complex piece of software is as simple as you say it is tiles.
I never said it is easy. I say i made it before and so i know what i am talking about. But you cannot know what you talk about because you haven't made it before. You simply lack the knowledge. I talk about software development, i develop software. You not. See the difference? I know about bugfixing because i did it in the past and still do it.
What i say is that a bug is a bug. No matter if in a small software or in a highly complex one. In both cases you have to find the bug. In both cases you have to find out what causes the bug. And in both cases you finally have to fix it.
That said, and to repeat myself: Fixing a bug doesn't mean to implement new features. Which was my point. And you are simply wrong at that. No clue where you found here that bugfixing is easy.
And to repeat myself at another point: when a customer contacts you that his phone doesn't work. Do you wait a year before you repair it so that it is more cost effective? Or do you repair it immediately? You haven't answered me that question before ;)
If it was more cost effective to release 4 minor upgrades a year rather than 1 big upgrade, as suggested by Tiles, why wouldn't they do it that way?
Errm, it was me who told you the reason why it is cheaper to deliver the bugfixes with the next release. And Jack explained it again a few postings before. So what's this statement about? What's your next question? Why i am against bugfixes every 4 months?
I said, and say it again, that the current strategy of bugfixing, to deliver the fixes with the next version instead deliver bugfixes for the current version is wrong. It has cost hundrets of formerly TS users. It is a bad strategy just to see the short economy not to pay two more people, or to slow down main development for that, so that the needed bugfixes can be delivered.
Make your users happy with working software. Users that have to battle with bugs are not happy users, and not long users at all. The german community is an excellent example for that. It is gone. Quod Erat Demonstrandum. |
Post by W!ZARD // Apr 10, 2008, 12:51am
|
W!ZARD
Total Posts: 2603
|
I never said it is easy. I say i made it before and so i know what i am talking about. But you cannot know what you talk about because you haven't made it before. You simply lack the knowledge. I talk about software development, i develop software. You not. See the difference? I know about bugfixing because i did it in the past and still do it.
So are you saying the principles of repairing glitches in complex systems are different dependant on the system? If that is so then it is not a principle. I have knowledge about complex systems - software is a complex system. Saying that I lack the knowledge about a specific type of complex system does not alter my understanding of the principles involved. Nor does it affect the validity of my metaphors.
What i say is that a bug is a bug. No matter if in a small software or in a highly complex one. In both cases you have to find the bug. In both cases you have to find out what causes the bug. And in both cases you finally have to fix it.Whilst superficially true this surely understates the case. Sure a bug is a bug in the sense that it might be a missed character in a line of code but the context is very important. That missed character in one place may cause a minor bug in a seldom used secondary part of the overall program. That same character missed somewhere else, in the right context and sequence of events could cause a full scale crash. Or does my lack of specific knowledge mean that principle is wrong?
. A bug may also be intermittent, dependant on the environment. A line of code may function perfectly in six of the seven common places it is used but only be problematic in the last place. This would mean some sort of workaround would be required - an exception written, a new piece of code that only operates in the seventh situation - that is NOT adding a new feature, it's writing a solution, which I was trying to demonstrate earlier. So tell me, is this something that occurs when fixing bugs? Or does the developer go right back to scratch and rewrite that common piece of code, perhaps requiring the further rewriting of some or all of the situations where that code segment is used - or have I got that wrong too?
That said, and to repeat myself: Fixing a bug doesn't mean to implement new features. Which was my point. And you are simply wrong at that. No clue where you found here that bug fixing is easy.Not sure what you mean about adding new features - seems to me this is semantics. You have a feature which does not work and you replace it with one that does seems like a new feature to me so arguably every bug fix adds a new feature. But I'm not talking about adding new features I'm talking about adding new code to address certain bugs.
And to repeat myself at another point: when a customer contacts you that his phone doesn't work. Do you wait a year before you repair it so that it is more cost effective? Or do you repair it immediately? You haven't answered me that question before ;)Now that is an excellent question! The answer is yes and no and maybe. Much depends on the circumstances. If it can be quickly easily and safely repaired - well that's an easy one, you just repair it. But suppose you have a 500 pair cable crossing underneath a busy motorway and a handful of those pairs are faulty - do you dig up that cable and replace it, or do you swap the faulty circuits to some spare pairs so that the phones work and just a record of the existing faulty pairs? Obviously you take the most cost effective route and simply swap to spare unfaulty pairs.
Depending on the specific cause of the bugs... er I mean faults a decision is made as to the best way to fix it.
Perhaps a handful of cable pairs were damaged when the cable was laid and no more problems occur in the rest of the cable. No problem, just leave the faults there, move the phone lines to other, unfaulty pairs and everyone is happy.
What if water is slowly getting into the cable? Over time, more and more pairs go faulty, the cable is running out of spare pairs and the costs of ignoring the growing problem reach a point where they are greater than the costs of closing the road and digging a trench for a new cable.
Additionally your question is based on false premises - a complex telephony network is analogous to a complex software system when discussing fault (bug) repairs. A single faulty phone is not analogous. A phone company can fix a faulty phone one at a time but when a software company releases a new bug fix it's the equivalent repairing everyone's phone at once.
Errm, it was me who told you the reason why it is cheaper to deliver the bugfixes with the next release. And Jack explained it again a few postings before. So what's this statement about? What's your next question? Why i am against bugfixes every 4 months?It's not a statement it's a legitimate question - if it's cheaper to release 4 minor patches than it is to release one major one why don't they do it that way? If your answer is that it's actually cheaper to release one major upgrade than 4 little ones then isn't it better that they do it the cheaper way? If they take the more expensive option they have to put up the price of their product. In a competitive market they have to maintain competitive prices or they will lose customers.
So maybe they lost 400 German customers because of slow bug fixes - if they gained 800 new customers because of good pricing then the economics work out. It's sad the Germans left but the company is still viable.
Or are you going to tell me that because I don't write game software I don't know anything about economics?;)
Customer attrition is a fact of life for any company. As long as you are gaining more customers (perhaps by good pricing) than you are loosing (perhaps due to slow bug fixing) your company can still survive and grow - and hopefully one day grow to the point where faster bug fixes become economically viable.
I said, and say it again, that the current strategy of bugfixing, to deliver the fixes with the next version instead deliver bugfixes for the current version is wrong. It has cost hundrets of formerly TS users. It is a bad strategy just to see the short economy not to pay two more people, or to slow down main development for that, so that the needed bugfixes can be delivered.
Make your users happy with working software. Users that have to battle with bugs are not happy users, and not long users at all. The german community is an excellent example for that. It is gone. Quod Erat Demonstrandum.
At the end of the day Tiles it's a fact of life that you can get cheap products and services and you can get highest quality products and services but you can't get products and services that are both cheap and highest quality. Quantus est ut canis obvius fenestra?
Love Leo |
Post by KeithC // Apr 10, 2008, 1:26am
|
KeithC
Total Posts: 467
|
So maybe they lost 400 German customers because of slow bug fixes - if they gained 800 new customers because of good pricing then the economics work out. It's sad the Germans left but the company is still viable.
You forget, Wizard, that 1 lost customer often means you actually lose 2-3 customers....the one who left, and 1 or 2 potential customers who followed the advice of the one and didn't purchase the software on the advice of the other. Word spreads fast on the internet these days.
Just wanted to interject a bit......please don't feel the need to write a verbose passage just for me. ;)
@Tiles: Do you have a link to the games you have worked on? I'd be interested in seeing them. :)
-Keith |
Post by Tiles // Apr 10, 2008, 1:31am
|
Tiles
Total Posts: 1037
|
I have knowledge about complex systems - software is a complex system.
An ape is an animal. But not every animal is an ape. Software is in the first place software. And follows its very own rules.
I have knowledge about making complex software systems, i have knowledge about producing bugs in such complex software systems, i have knowledge about fixing bugs in such complex software systems. I develop software.
You miss that knowledge. But still say you are the one who is right. Perfect argumentation :)
Whilst superficially true this surely understates the case. Sure a bug is a bug in the sense that it might be a missed character in a line of code but the context is very important. That missed character in one place may cause a minor bug in a seldom used secondary part of the overall program. That same character missed somewhere else, in the right context and sequence of events could cause a full scale crash. Or does my lack of specific knowledge mean that principle is wrong?
. A bug may also be intermittent, dependant on the environment. A line of code may function perfectly in six of the seven common places it is used but only be problematic in the last place. This would mean some sort of workaround would be required - an exception written, a new piece of code that only operates in the seventh situation - that is NOT adding a new feature, it's writing a solution, which I was trying to demonstrate earlier. So tell me, is this something that occurs when fixing bugs? Or does the developer go right back to scratch and rewrite that common piece of code, perhaps requiring the further rewriting of some or all of the situations where that code segment is used - or have I got that wrong too?
Could that please somebody translate to me so that i understand what he is talking about? Really, i don't get your point here. Is so mixed that i simply cannot extract what you want to say.
Let's try an answer. You develop a feature until it works as thought. You debug it again and again up to the point where you don't find any bugs anymore. And you may need to rewrite parts or even the whole stuff while the development. That's why it is development.
Once you deliver this feature in your software it obviously is ready developed. It works as thought. Else it wouldn't be in the software.
Now a customer finds a bug. Which makes it necessary to fix it. Development of this tool is finished. That's why it is in the software. So it is just about an overlooked bug here, and fixing it. Not rewriting it. Not adding a new feature. Just fixing this bug.
Not sure what you mean about adding new features - seems to me this is semantics.
Ack, so you forgot your questions two pages before? But that was my answer for that. And you refer to this answer here. You stated that bugfixing always means rewrite and implementing new features. Which is simply completely wrong.
And so my answer was that this is not true. That i know it because i develop software. And that a bug is a bug. That it makes no difference if in one of my games or in trueSpace.
Now that is an excellent question! The answer is yes and no and maybe.
Thanks. I will please not be a customer of your company. I need a working phone :)
At the end of the day Tiles it's a fact of life that you can get cheap products and services and you can get highest quality products and services but you can't get products and services that are both cheap and highest quality. Quantus est ut canis obvius fenestra?
That is not the question. And has nothing to do with the current bugs issue we talk about here. Question is should a company change its marketing strategy when the current strategy leads to the fact that the customers run away?
You can ruin the highest quality tools with bad service.
800 new
Where? Please show me. Really, show me the new 800 members here at the forum. Ah, you cannot. There are no 800 new members :)
I have shown that 400 are missing now though. That is fact. And that is just germany.
What i can also see is that the number of active users here at the board shrinks. And that the number of registered users is nearly the same since years. |
Post by transient // Apr 10, 2008, 1:44am
|
transient
Total Posts: 977
|
You forget, Wizard, that 1 lost customer often means you actually lose 2-3 customers....the one who left, and 1 or 2 potential customers who followed the advice of the one and didn't purchase the software on the advice of the other.
When I was at school this figure was actually put at 25, or more, but this was in a retail environment. It may even be more now, because that was before the digital revolution.
I'd say that trying to argue the economics of Caligari's business practices is somewhat futile, as we don't know how viable they were before the buyout.
I suspect they were doing it tough like others in this industry seem to be, but it's moot, as they have Daddy Warbucks to fund their development now.;) |
Post by Tiles // Apr 10, 2008, 1:51am
|
Tiles
Total Posts: 1037
|
Ah, forgot, my games can be found at my page: http://reinerstileset.4players.de/gamesnappsE.html |
Post by Steinie // Apr 10, 2008, 2:05am
|
Steinie
Total Posts: 3667
|
Pancake Luigi looks like fun!!!, but I think I see a bug....:) |
|
