Jump to content
  • 0

Unlock the built in PIO's.


brudgers

Question

  • Answers 56
  • Created
  • Last Reply

Top Posters For This Question

Recommended Posts

  • 0

Unless I'm mistaken, weren't the "open" scripts primarily tools and commands?)

All the vectorscript (or minipascal) plugins were open before VW was sold as different design packages/modules (version 7 and 8 if I remember well). That is why I wish I could help you guys with the stair PIO but since I own Landmark I do not even have access to it.

Can someone explain what benefit is there in linking to an external database. I see this wish posted before but I have worked 25 years on CAD systems and never had the need for it. And perhaps nobody has developed the feature because there is not enough market to justify the investment.

Link to comment
  • 0

Linking to an external database allows all sorts of existing data to be linked to cad objects rather than having to recreate and validate the data inside vectorworks.

A casual example would be existing office equipment and a space plan or manufacturer's data and an assembly drawing.

More sophisticated applications include linking to a digital document database.

For example, linking the communications regarding a change order to the affected sheets, or a manufacturer's cut sheets to a detail.

Unlike the case with the Plants database in Landmark, ODBC would allow the user to determine what the relevant data is, how to organize the external database, and to which drawing objects it is attached.

Currently, I can create a record and attach it to a vectorworks object, but I cannot populate it's fields automatically with data nor can I update the fields based on changes to an external source such as a spreadsheet or relational database.

Link to comment
  • 0

Version 8 had unlocked Plug-in Objects. Together with the tools and menus these were indeed invaluable for learning vScript.

Maybe they locked them down to prevent people from easily making a different stair tool (for eg) that could be used in Fundamentals, and selling it for less than the cost of the up-grade to Architect, or giving it away for free. I think Miguel is correct that the encryption started with the introduction of different tiers, which is also right around the time Nemetscheck bought Diehl Graphsoft.

This is pretty much the only way that I can see that open plug-ins could possibly hurt Nemetscheck, but I doubt there'd be much damage.

ODBC is also wanted by folks who like the presentation capabilities of Excel. (I'd like to make it clear that I'm not one of them).

Writing from an outside source to attached records is totally do-able with vScript, but you have to export a delimited text file from the source every time you need to update something. Same with going the other direction.

It seems that two-way worksheets satisfied some of the clamor for ODBC.

It'll happen one day....mac included. The plant tool might be a case in point. There's been a few people who'd like to customize that database, and one at least that spent what appears to be a large amount of time trying to do with script something that'd be easily done with ODBC.

Link to comment
  • 0

Comma delimited files and two way worksheets are just ways of recreating data in vectorworks.

Neither is dynamic and neither is relational.

The plant database is illustrative of how MSDOS like the resultant workflow is.

But given that RDBMS's aren't really a core part of Apple's business, it's probably the best that can be done for the Mac.

Edited by brudgers
Link to comment
  • 0

There is always a trade off even when a dynamic link is available. You still have to put the time to setup the connection and make sure the data goes where it is supposed to. When you do your own scripts to import the data, you know exactly where the data goes and program it accordingly and best of all, you can change the script for unusual situations if you need to. And if the added feature, in this case ODBC, does not satisfy the requirements of some users, you will still hear complaints.

Case in point, VW can now import shape files but I do not use it because it does not meet my needs. It imports the graphics as polygons without any attributes and all the fields (20+) in the database attached to each graphic. I would have to spend the time to change the attributes for each graphic and remove all the unwanted fields from the record definition. The workflow I developed even before the feature was added to VW consisted in an extension I created for Arcview which exported the area in the window view with all the attributes and selected fields into a vectorscript file. I would then import the vectorscript into a VW layer and I had an exact replica of the Arcview window with only the necessary fields.

So the point is that even if you get what you ask for, it may not necessarily meet the needs of all users.

Link to comment
  • 0

You're conflating "importing" with "linking."

Importing a file is converting it to vectorworks entities...for the purpose of doing the things that one does in Vectorworks.

This works reaonably well for something like a .dwg since the purposes for which one creates a dwg are similar to the purposes for which one creates a whatever-a-vectorworks-file-is-called-this-year.

But importing an Arcview shape file into vectorworks is a whole 'nother matter. You wind up with a cad object (not a GIS object) and no high level tools for manipulating the attached data.

With ODBC you could attach data from Arcview to a Vectorworks object. The data would live in it's native habitat, growing, multiplying, and dying according to it's own life cycle. And it's management would be done with the well developed tools Arcview offers.

Meanwhile your vectorworks drawing wouldn't contain some computer programmer's arbitrary guess as to the purposes to people put arcview data.

Connectivity is better than conversion, even though it's not the magic pill to meet all user needs.

Link to comment
  • 0

You keep missing the meaning of my reply. In plain words, even if ODBC was available I would have no use for it because I can always device better workflows than what is provided. You may benefit from having it but not all users will. Sometimes, certain technology is forced on us because it is the belief of someone that it is the only way to do a task. We need to think outside the box, analyse the task at hand, and come up with more efficient solutions if what is available does not satisfy our needs.

You wind up with a cad object (not a GIS object) and no high level tools for manipulating the attached data.

A GIS object is no more than a graphic or cad object (point,line,or polyline) with a record attached to it. I am not suggesting that VW has the same functionality as a GIS program. One purpose of the GIS is to perform queries on the database and present the results in a graphical form. In my case, the manipulation of the data is done in arcview and the result is then imported into VW.

With ODBC you could attach data from Arcview to a Vectorworks object. The data would live in it's native habitat, growing, multiplying, and dying according to it's own life cycle. And it's management would be done with the well developed tools Arcview offers
If I had hundred of objects, it would be a lot of work to attach the data to each object. The parcels that I bring into VW already have the data attached and have no need for the live link because the data is not going to change in the time I design a road. The benefit I get from doing it my way is that the objects look exactly the same in VW as they do in ArcView without having to edit the objects. It only takes 3 clicks for me to do the whole operation.
Link to comment
  • 0

Let me put it another way.

With ODBC I could link a drawng object to a record in a document management data base which contains a PDF of the manufacturer's installation requirements (and link it to whatever else I wish or have wished or could wish).

I'm not denying that it is possible to do things statically.

Nor am I proposing that doing so is somehow wrong.

And of course I'm not suggesting the ODBC is the answer to everyone's issues.

But if you look at threads in the SDK forum from the last six months, it may give you an appreciation as to the general appeal of the current approach.

Link to comment
  • 0
Apple's approach has gained them a 2% world wide market share

I realise this is a rather late and now quite off-topic response, but this point needs addressing.

People seem to forget that whilst Apple does have quite a small total market share, they account for 91% of all PC sales above $1000. Their approach got them where they want to be.

Link to comment
  • 0

OK, I can't hold out any longer. I think there must be a middle ground.

I think NNA should pick about a dozen tools, commands and object types (they can be simple ones) from the Fundamentals package and unlock them. Let everyone see the source code as a way of learning about VS.

It could be licensed as open source or just as free, but probably licensed without any promise of support. If they only advertise them as open in the VS manual, most people would never know.

My fear is that the reason they don't do this is that the code is either so badly structured and poorly commented that they would not be good to learn from. Either that or they have some super nifty in-house routines that are included in every script they don't want to let us know about.

Opening up does not have to be an all or nothing scenario.

Link to comment
  • 0
I think NNA should pick ... tools, commands and object types (they can be simple ones) from the Fundamentals package and unlock them.

Nice thought, but I wouldn't go for just the simple ones. If product differentiation is the issue here then there should be no problem opening up everything in Fundamentals.

Are the window and stair tools part of Fundamentals?

Link to comment
  • 0

I had the same thought recently.

But I don't think it is a solution to the bigger issue of making much needed improvements to the built in PIO's.

Pretty much the only people programming for Vectorworks are those with another connection to it, either as users, vendors, or former NNA employees.

A few more code examples is not going to spur a great wave of third party development. A few hundred thousand seats of Vectorworks isn't a very attractive market compared to millions upon millions of iPhones and PC's.

What's needed by typical users is improved PIO's -- not more knowledge of Vectorscript or the SDK. Releasing the code will only have a meaningful impact if it brings widespread functional improvements.

In my opinion, telling users, "if you don't like the bugs in the built in tools, write your own" isn't exactly the best marketing strategy a software company can take.

Edited by brudgers
Link to comment
  • 0
A few more code examples is not going to spur a great wave of third party development. A few hundred thousand seats of Vectorworks isn't a very attractive market compared to millions upon millions of iPhones and PC's.

I'm not hoping for a great wave of third party development, just improvements that NNA can fold into the tools they ship.

In my opinion, telling users, "if you don't like the bugs in the built in tools, write your own" isn't exactly the best marketing strategy a software company can take.

Telling them they can't is worse I would have thought.

Link to comment
  • 0

Telling them they can't is worse I would have thought.

I meant telling users to write their own PIO's from scratch. I'm not denying that there are worse options.

Back in the early 80's, "write your own code" was a reasonable approach given the demographic using desktop computers and the simplicity of many unaddressed tasks.

It's relatively easy to write a macro to draw a rectangle with two diagonals to represent lumber in section, but that sort of low hanging fruit is long gone.

Writing a robust railing PIO for stair attachment is way beyond what users should be asked to do and well beyond the practical limitations of the vast majority of users.

Link to comment
  • 0

I know what you meant. I'm saying I'd rather the code was open than closed (hence, "Telling them they can't is worse"), so that code improvements from others besides NNA developers could be folded into the PIOs. i.e. writing PIOs from scratch is not the only reason to open up the code for PIO improvement, as implied in this post:

http://techboard.vectorworks.net/ubbthreads/ubbthreads.php?ubb=showflat&Number=126692#Post126692

Link to comment
  • 0

A few more comments:

1) The more I think about it, the more the idea of some of the Fundamentals tools being opened has appeal. That would, at least at some level, serve both those who want to learn and those who want to modify. I know the folks in Columbia are slammed, but it would be interesting for one of the powers-that-be to chime in on this.

2) Though VW should include a healthy set of tools, I don't believe that, in every case, it is a wrong expectation or asking too much for users to develop tools. Yes, there is some effort involved, but users would then end up with tools to their spec.

3) I believe that scripting is far more in-reach than a lot of VW users perceive. Yes, things can quickly get complicated (no question of that), but a lot of VW users are much more capable in this area than they allow themselves credit.

4) There are some incredibly talented scripters in the VW community who, if they could get some return on their investment of time and effort, might be interested in creating tools.

Back to work...

Link to comment
  • 0

While lay persons can write their own code, it's analogous to lay people constructing their own buildings in many ways. It's one thing to provide the means for doing so, it's another to expect it to be typical customer behaviour, and quite another to expect customers to resolve substantial issues on their own.

The market for vectorworks scripts is limited both quantitatively and qualitatively.

While the quantitative limits are rather obvious, the qualitative limits are less so.

Price was an important purchase criterion for a large (and likely growing) portion of the current vectorworks user base. A $20 utility probably doesn't compare well on in terms of perceived value/cost to $1000 (or $1500) cad package.

As for more expensive packages like windoor, let's just say that its superiority doesn't foster a perception of value regarding vectorworks architect.

One of the resources that NNA has is the high level of commitment that many Vectorworks users have to it's improvement and success. Opening the PIO's is a way of leveraging that energy toward improving the product.

Link to comment
  • 0

While the Open Source idea sounds good, I don't think it would work.

1. The current scripting community is very small. In the Vectorscript share portion of the Community board, only 5 people have shared anything. I think the active scripting community is probably less than 100 people. So by asking to go open source, you are in reality asking those 100 people to subsidize your use of VW. Or are you willing to open your wallet and pay for work done by those people?

2. At least some of the scripts have proprietary information. There are algorithms and routines that are used that could easily be translated to a different package and provide them with a market advantage.

3. The best open source projects have a strong leader who determines what goes in and what is left out. For this project that would still have to be NNA. So you are still left with the package that NNA wants to ship.

4. If the NNA code is an open source project does that not mean that all development should be open source? And if that is true, then what happens to the developers such as Matt Panzer (Camera Match), Raymond Mullins (Reshaper), Sam Jones (Autoplot Tools for Spotlight). They are all making some money on their scripts right now, but if they have to go open source (because that is what the community expects/demands) how long to you think they will keep up these great products?

Vectorworks is what it is, not what you want/hope it is. Keep submitting your wishes and bugs and it will (hopefully) get better. We as a community gain very little by trying to redefine NNA's business model and strategy.

Link to comment
  • 0

If there are only 100 active scripters, that represents only 0.025% of the 400,000 vectorworks seats. And I suspect only a very few of them are making their living from the practice.

Opening up the PIO's lowers the barrier to meaningful scripting and offers the potential for more "free stuff." But it doesn't obligate anyone to do anything they're not inclined to do. I pointed at the lack of contributers earlier as a symptom of the problems with the status quo.

There are plenty of tools available to protect whatever important NNA intellectual property exists within the PIO's. These range from well established licensing models to modular encryption. Perhaps in ignorance, I don't think there's a large cache of cutting edge algorithms in the PIO's. But I'm sure there's plenty of examples of competent and cleaver programming.

As far as I can see, there's no reason a third party would have be open source for a product developed in the way the existing scheme requires. CameraMatch, etc. were presumably built from scratch and not using code made available through a non-commercial or similar license.

Finally, in an important sense Vectorworks ain't what it is. It's different from what it was a year ago, and in a few months will probably be meaningfully different from what it is today.

There are things that I think it does really realy well and I believe that it has huge untapped potential. In my opinion the primary barriers to achieving that potential are ideology, intertia, and overhead - not economics.

Link to comment
  • 0

Most of the Open Source licenses require that anything derived from them to also be open source. So, if you use any (even one line) of code that you have seen in the samples, your SHOULD license your code as open also.

It is also likely that people would latch onto the open source idea and expect (ie not be willing to pay for) anything as it is "supposed" to be open.

This is getting much deeper than I intended. I think I will say that some PIOs/Scripts open as freeware for learning purposes is much different than making everything an open source project.

Link to comment
  • 0

Unlocking the PIOs is unlikely to happen.

There is a need though for:

- Better Vectorscript documentation that explains the logic of how PIO code should be structured and why.

- More Vectorscript examples that show uses of the various PIO types and the correct programming structure.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements


×
×
  • Create New...