Jump to content

Phoenix update - explanation needed


You are about to reply to a thread that has been inactive for 4720 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I have been using the Phoenix viewer for a long time. Occasionally, there is an update. Today, there is an update, but I don't have a clue what's going on. Could someone translate the following into English for normal humans?

http://www.phoenixviewer.com/

Alternatively, tell me if the solution is simply to install Firestorm and bypass the issue altogether.

Link to comment
Share on other sites

Hi, the short version --

You can use the new bouncy avatar physics wearables from viewer 2.6.3, they put the code in the enable them. This is a bonus to encourage upgrades.

The real fixes are to make sure that you can see avatars running newer viewers correctly when they change their outfits, and to prevent crashes from malicious inworld sound clips.

Adding -- Firestorm will have the same crash bug unless there has been a new build in the last week.

 

Link to comment
Share on other sites

You mean that Phoenix has to add a fix to enable breast physics added to V2 that Phoenix already had years ago? Rolls eyes.

Yet now I understand why my neighbor and I disagreed about his gender. He swore he had a male avi and I had to take a photo and send it to him to prove he was a female avi. He was not pleased - not pleased at all - to discover that everyone saw him as female.

I must admit, I have never liked V2, but I'm appalled it has caused so many problems.

Link to comment
Share on other sites

Or to put it another way ...

I have never liked Phoenix and am appalled that it did things the wrong way.

(Since V2 physics is how others see you and Phoenix's wasn't and, in any case, wasn't officially supported how can you possibly call this 'causing problems'!  rolls eyes)

Link to comment
Share on other sites

I'm not saying it is Phoenix's fault.  I'm pointing out how ridiculous it is to say it's V2 causing problems.  It's a new feature, just like the others LL have added.  You're right, V1 is not the cause of the issue - there was no avatar physics.  V2 has now introduced physics.  My point is that because LL didn't do it the way Phoenix did it doesn't make it a problem, since LL have no backward-compatibility issue to face.

The big thing is that TPVs are not official viewers and their unique features are not official features.  The price you pay for the benefits of using TPVs is that at any time LL might decide to implement those features in their own way.  It's a pretty strange attitude, I think, that not only fails to see that but *blames* LL for adding new features.

Link to comment
Share on other sites

I'm not blaming LL for adding features, I'm blaming them for not notifying TPVs when they found out about this specific issue, so that way they could take the steps to correct it before things went wrong in the first place.

And LL does, indeed, have backward compatibility issues. LL's own 1.23 viewer will never render avatar physics correctly and that will never be fixed. Phoenix, on the other hand, just put out their latest release which does fix the issue.

Oh and another price you pay for the benefits of using a TPV is that you can actually get decent support when things do go wrong.

...Dres

Link to comment
Share on other sites

If the Phoenix devs, or rather the Emerald devs, had not implemented breast physics in the past, LL would have never realized how popular this feature is and decided to implement their own version. Alas, they did a rather poor job. I like the additional buttocks and belly physics, but the way that the breast and belly mesh is distorted in v2 looks quite unrealistic and ridiculous imho. Of course it depends on the settings, but it seems to be impossible to come up with values that look as natural and bouncy as the original Emerald breast physics.

Link to comment
Share on other sites


Dresden Ceriano wrote:

I'm not blaming LL for adding features, I'm blaming them for not notifying TPVs when they found out about this specific issue, so that way they could take the steps to correct it before things went wrong in the first place.

 

LL did notify TPVs as soon as they found out, but this is not a problem with v2, it's a bug in v1. A bug that that LL fixed in v2 way back in 2009. It had been so long that they'd forgotten about it. You can blame LL all you want, but don't forget to blame the TPVs either, 'cause the fix for this issue has been out or over a year.

Link to comment
Share on other sites


leliel Mirihi wrote:

LL did notify TPVs as soon as they found out, but this is not a problem with v2, it's a bug in v1. A bug that that LL fixed in v2 way back in 2009. It had been so long that they'd forgotten about it. You can blame LL all you want, but don't forget to blame the TPVs either, 'cause the fix for this issue has been out or over a year.

That is not a bug. In V1 was agreed upon a different way to handle incoming avatar parameter data, namely aborting if unknown parameter have been received, assuming the data was broken. For V2 they changed the way how parameter data is handled in a way that unknown parameters are just ignored. Both are valid methods of handling unknown parameter data. The problem only arised as LL changed the avatar model, thus new parameters have been created. As this happened long time after V1 has been released, it doesn't render V1's method a bug. LL was either unaware of this when implementing the model changes or too lazy to implement the changes in a way they don't break existing old protocols. The correct way of implementing this feature would be letting a physics compatible viewer signal that capability to the server and the server has to take care that viewers get data in a protocol format they can handle!

Link to comment
Share on other sites


Ansariel Hiller wrote:

That is not a bug. In V1 was agreed upon a different way to handle incoming avatar parameter data, namely aborting if unknown parameter have been received, assuming the data was broken. 

V1 ignores all parameters if just one is unknown and never bothers to request the data again.


LL was either unaware of this when implementing the model changes or too lazy to implement the changes in a way they don't break existing old protocols. The correct way of implementing this feature would be letting a physics compatible viewer signal that capability to the server and the server has to take care that viewers get data in a protocol format they can handle!

The correct way is to implement a hack on the server to work around the brain damage of a viewer that's about to be end of lifed? There's a limit to backwards compatibility and I think we've reached it.

 

Link to comment
Share on other sites


leliel Mirihi wrote:


Ansariel Hiller wrote:

That is not a bug. In V1 was agreed upon a different way to handle incoming avatar parameter data, namely aborting if unknown parameter have been received, assuming the data was broken. 

V1 ignores all parameters if just one is unknown and never bothers to request the data again.

LL was either unaware of this when implementing the model changes or too lazy to implement the changes in a way they don't break existing old protocols. The correct way of implementing this feature would be letting a physics compatible viewer signal that capability to the server and the server has to take care that viewers get data in a protocol format they can handle!

The correct way is to implement a hack on the server to work around the brain damage of a viewer that's about to be end of lifed? There's a limit to backwards compatibility and I think we've reached it.

 

 V1 doesn't ignore all parameters, it just stops processing parameters as soon as it detects an unknown one. Concerning the "hack" as you call it: It is not a hack to let the client signal it's capabilities to the server. In contrast, this is really smart because it allows using different protocol versions at the same time without breaking functionality on existing clients. Concerning the backward compatbility: As long as there is no official statement about EOL of V1 (protocols) there is no need of even thinking about discussing about compatibility - what you personally think doesn't matter.

BTW: V2 is a brain damage of a viewer nevertheless! Underlying code is to a very high degree still the old V1 code. LL only plugged some new stuff on it and replaced some GUI components - and that even bad! There's still no MVC separation, many data is still stored in GUI components. It's no real improvement, it's just old wine in new skins!

Link to comment
Share on other sites


Ishtara Rothschild wrote:

If the Phoenix devs, or rather the Emerald devs, had not implemented breast physics in the past, LL would have never realized how popular this feature is and decided to implement their own version. Alas, they did a rather poor job. I like the additional buttocks and belly physics, but the way that the breast and belly mesh is distorted in v2 looks quite unrealistic and ridiculous imho. Of course it depends on the settings, but it seems to be impossible to come up with values that look as natural and bouncy as the original Emerald breast physics.

Long before the viewer code was even open-sourced, LL had a much anticipated project, "Physical Avatar" which was to give us on-the-fly ragdoll animations (aka "Expressive Puppeteering") among other wonders.  When the Emerald developers chose to implement breast physics, I don't know if they decided it was the easiest feature to do without server-side changes (such as it was), or if they just had a bewb fetish and rightly judged that there were many such enthusiasts.  They may not even have been aware of the intended extent of the then-tabled Physical Avatar project.

I agree that the range of settings available for LL's avatar physics is pretty overwhelming.  Figuring out which value to adjust to get which effect takes more practice than I've been motivated to invest myself, but starting with the Phoenix team distributing their own settings on Marketplace, I'm guessing that enterprising sorts will make a good business from this wearable, eventually.

Link to comment
Share on other sites


Ansariel Hiller wrote:

Concerning the backward compatbility: As long as there is no official statement about EOL of V1 (protocols) there is no need of even thinking about discussing about compatibility - what you personally think doesn't matter.

I'm expressing my opinion as to whether I think LL should spend time and money extending support for a viewer that they have already stated in no uncertain terms that they will not update or support forever. Keep in mind we're only talking about 1.23 here, the TPVs are already fixing this bug. So after a month or so there won't be a whole lot of users affected by this. In other words this whole argument boils down to how much money should LL spend to keep a minority of users happy.


BTW: V2 is a brain damage of a viewer nevertheless! Underlying code is to a very high degree still the old V1 code. LL only plugged some new stuff on it and replaced some GUI components - and that even bad! There's still no MVC separation, many data is still stored in GUI components. It's no real improvement, it's just old wine in new skins!

In other words v2 is a more polished turd than v1. No big surprise there, but that still means it's better (in some ways).

 

Link to comment
Share on other sites


leliel Mirihi wrote:

In other words v2 is a more polished turd than v1. No big surprise there, but that still means it's better (in some ways).


That's a thing of personal preference. But according to the adoption rate, many people don't agree with you as Viewer 2 is being used by only roundabout 20% of all residents - more than a year after it's release and despite all the new features.

Link to comment
Share on other sites

You miss the point that having only the unknown parameters ignored actually makes it easier for future backward compatibility. The old protocol HAD to be broken so it could be reworked properly, without adding more stress to the server. The new method ensures that any future new parameters WON'T cause these same compatibility issues again, and it certainly does seem that these physics won't be the last new AV parameters introduced. Regardless of preference, LL made the right call on this one. You fix the core issue, not put band-aids on it, not make concessions for it which will only complicate things, and not engineer efforts that are counterproductive to your project goals.

Link to comment
Share on other sites


Ansariel Hiller wrote:


leliel Mirihi wrote:

In other words v2 is a more polished turd than v1. No big surprise there, but that still means it's better (in some ways).


That's a thing of personal preference. But according to the adoption rate, many people don't agree with you as Viewer 2 is being used by only roundabout 20% of all residents - more than a year after it's release and despite all the new features.

I added the in some ways part in the hopes of avoiding the usual flame war over the UI in v2. I was specifically referring to the improvement under the hood.

Link to comment
Share on other sites

Sorry, but you miss the point that you can't actually change a protocol that breaks current clients only in favor of future extensions. Well, you can from a technical point of view, but not from the overall scope. You either have to take care you don't break any existing clients or you have to make a cut at a pre-defined point in time so everyone knows when the switch is gonna happen.

What LL did is just the same as if today there would be made changes to IPv6 that will suddenly break IPv4 in some way and then claiming "Hey, you all know that IPv4 is reaching EOL soon, so who cares?".

Link to comment
Share on other sites

General thread reply follows:

To say that phoenix did it wrong to begin with is silly, they did it the only way it could be legitimately done. LL's solution was a change to the inventory system, as well as the viewer, something no TPV could have accomplished in that manner... it was the same story with multiple attach points.

LL did not do it wrong either, although a bit of cross testing on their own v1 download would have made the problem obvious and a patch might have been generated sooner.

v2 itself was NOT the problem, but changes to it DID cause problems not only for TPV's but also their own unsupported (but not abandoned) v1 version.

 

summary of phoenix changes:
V2 physics wearables fully supported + additional bug/crash fixes.

Link to comment
Share on other sites


Ansariel Hiller wrote:

Sorry, but you miss the point that you can't actually change a protocol that breaks current clients only in favor of future extensions. Well, you can from a technical point of view, but not from the overall scope. You either have to take care you don't break any existing clients or you have to make a cut at a pre-defined point in time so everyone knows when the switch is gonna happen.

 

I think you miss the point that this was originally an unintentional breakage. The fact that LL has done nothing to fix it nor made a statement that they will do something is a pretty good indicator of how they feel about the future of 1.23.

LL already told the TPVs months ago that they were going to cut off v1 search real soon now. We know mesh is coming real soon now. We sort of know that other things are coming possibly real soon now. We know LL will not update v1. Put them all together and what do you see in store for v1 in the coming months?

Link to comment
Share on other sites

It is not the problem that it will be "real soon". Unless there is no official statement that from day X V1 will not work anymore, you can expect it to work whether the breakage was unintentional or not!

Need another example? You buy a car and the manufacturer announces a new updated version of that car that is available soon, your version won't be produced from that day on anymore and since the production will soon end you won't get any support or spare parts for your car today anymore!

Link to comment
Share on other sites

"What I find amusing is that LL emphasize this is a PG-rated area but when their standard viewer was updated to provide the bouncy breast option plus more, they did all they could do to market it (youtube vids, blog post, etc).  /me laughs"

---------------------------------------------------

http://www.bbc.co.uk/news/business-13416598

Link to comment
Share on other sites


Ansariel Hiller wrote:

It is not the problem that it will be "real soon". Unless there is no official statement that from day X V1 will not work anymore, you can expect it to work whether the breakage was unintentional or not!

You keep saying that as if LL has some kind of moral obligation to inform it's users that it will no longer be supporting a viewer the majority of them stopped using ages ago. You do know we're talking about the same company that dropped support for OSX 10.4 eight months ago without saying a word. It took them 6 months to update the minimum system requirements too.


Need another example? You buy a car and the manufacturer announces a new updated version of that car that is available soon, your version won't be produced from that day on anymore and since the production will soon end you won't get any support or spare parts for your car today anymore!

Yes actually, since your first one didn't work. Hint: if IPv6 was backwards compatible with IPv4 the internet would have switched over a long time ago. And your example has happened before, with cars as well as many other things.

 

 

Link to comment
Share on other sites

  1. The majority hasn't stopped using V1 based viewers. Get your figures right!
  2. The reason why OSX 10.4 support was dropped because of issues with the gcc compiler.
  3. Guess who provided the initial fix for the physics issue: Seraphim Linden. You may also guess why they provided the fix!
  4. You know that IPv4 packets are already routed via IPv6 in the backbones? Guess what will happen if a change suddenly would break IPv4 piggybacking and somebody says "Your fault! You know IPv4 reaches EOL!" instead of providing a fix?
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4720 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...