Prowildfire 2.0

Not possible while maintaining the parametrics.

STEP or IGES the solid out. Pro/E neutral file format.

Software piracy has nothing to do with file interoperability. Software piracy hurts the user because the vendors are writing code into their products to make it easier to detect an illegal license.

As for backward compatibility, name 1 CAD vendor who has full compatibility between version N and N-1.

How many history / feature based systems do you know of that do? Translating back when all that's involved is data structures is pretty trivial, but how do you translate back functions. The best you'd get is something like the better feature recognition / translation (20K US?) programs that place an unparametric surface when a function can't be plugged into the build tree. Suppose they could do the same, but doubt they could expect much return on the development investment.

Even between WF-1 and WF-2 ? Aw poop.

Ya know, it's not that hard to get 'free' PTC software. If companies make using their own products *too* obnoxious then they only have themselves to blame when the 'piracy' rate skyrockets.

Right off the top of my head, there's Cadkey. And even AutoCrap allows you to save in a prior format so that you aren't stuck changing *everyone* to the latest level at the same time. In fact, now that I think about it, how many CAD vendors do NOT allow you to save in an older format ? Besides the pricks at PTC, that is ?

(You added the word "full" to the question, by the way. And the OP didn't want file compatibility between Pro/E version 5 and Wildfire, he was asking to use Wildfire 2 models in Wildfire 1. What huge earth-shaking improvements and new features did PTC add to WF-2 to make such a difference that one *couldn't* open the average WF-2 model in WF-1 ? None. Not shit, there's your answer. It's a trick done on purpose to force customers to buy something they don't need. It's the crappy high-handed bullshit style of behaviour that makes PTC so well beloved of everyone. No wonder all the mags shit on Pro/E all the time.)

Unless said code is very crappy, explain to me how this hurts a user who has paid for his license ? In this case I'd have to go along with the "if you don't have anything to hide ...." folks.

Haven't given it much thought, but pattern features come to mind at the prompt. Their reference setup is different than WF (which is the extent of my history with Pro/E).

That's one way of looking at it and may be accurate. I tend to think it's simply a matter of cost; return on the investment needed to insure backward compatibility and they are in line with the majority, if not all, of their competitors in this respect. The absence of backward compatibility is the current "standard" or "state" of the industry, at least to the extent of my knowledge. They may even be a small step in front of the pack with ATB functions (? don't know; something I've read about, not sure I understand and don't know if it might be of some potential worth to me). Something that definitely puts them ahead of some (lower end, anyway) is continued support for older versions; e.g. they are still releasing new builds of

Obviously, this isn't something that sticks in my craw. I have wondered in passing along similar lines, though, and never asked; I'm an independent, my initial purchase of Pro/E was WF, I have a maint contract: If I should have the need for compatibility will PTC (or any other developer for that matter) furnish me with a copy of a superceded version?

... and a prosperous new year to all. 8~)

I also left off out a word - Parametric. Since you didn't like the question, let's try this question.

Name 1 major parametric-based CAD system vendor who has model compatibility between version NO and NO-1?

Now my question limits your answers to Catia, Pro/E, Unigraphics, SolidWorks, SolideEdge and Inventor. The answer is none.

Despite your subsequent post about what differences there are in WF1 and WF2, look at the underlying data structures involved. I will admit that I have more experience with UG, 17 years, than I do with Pro/E, 3 years.

UG V17 had very little to offer the user in terms of the need to upgrade from V16. However, from UGS' standpoint they need V17 to get a new database structure implemented to support user changes that were coming in V18. We jumped from V16 to V18, with no problems and UG was able to open all older files. My point is that there are technological reasons that the user doesn't see that make changes that prevent the newer file from being opened in the older version.

Let's put this in the context the original question. Exactly how is Wildfire 2 so remarkably different from Wildfire 1 that *most* WF-2 models couldn't be read in WF-1 ? Obviously one can't make programs forward-compatible but these kinds of tricks are pure bullshit. There is absolutely no reason that one shouldn't be able to at least run a trail file in similar versions of Pro/E. I'll have to go try it out before I make a blanket statement but I *seriously* doubt that you can't run the same key presses in WF1 as WF2 and get the same model for most parts. So even if direct use of the model is not practical for some strange reason, they have *no* logical excuse to not allow you to even try to run a trail file. Except blackmailing customers for more money, which I guess you could look at as a practical reason. That does make the customer hate the vendor, however, which is not usually a good situation.

While we're on the subject of PTC screwups, anyone have an idea why the browser plugin to *view* pro/e models is strictly 64-bit on Irix ? What kind of dumbass trick is that ? I can see it for modelling, but for viewing ? Who's going to be looking at 2 gigabyte models over the 'net ?