topic Re: Become a registered object developer in Libraries & objects

Become a registered object developer

Anonymous — Wed, 25 Nov 2009 19:46:46 GMT

This is a spin off of the topic Custom GDL objects for FREE.

ztaskai wrote:

Master wrote:

Zsolt: no problem, I think it is better that GS takes care of its own library, than there is more time for developing ArchiCAD. I do think though, that a little more stimulation for independent object developers would be good for ArchiCAD. You need to understand that objects and GDL are one of the most powerful assets of ArchiCAD. There are a lot of topics on this forum, demanding more action on the GDL front, like this one on Updating the Object Depository.
Maybe this might be a good idea: A reward for the best object uploaded to the Object depository each month (picked at random or by vote), it could fill up the depository rapidly. Or the possibility to become a registered object developer (I know you can become a registered API developer), would make it saver for ArchiCAD users to approach developers.
I like your ideas a lot. Renewing Object Depository into something more social is one of my favorite topics. Unfortunately, I don't have the momentum to set up such a multidisciplinary project like that - yet. I will try harder next year.

Then is a good time to discuss what we can do about it. Updating the Object Depository discussion here.
I have got some more ideas. When you make object developers register, GS can enforce rules about how to set up objects. For instance every object must have Parameters for Listing, or a detail level. It can give more constency to objects.

But are object developers interested in becoming registered?

Re: Become a registered object developer

owen — Wed, 25 Nov 2009 23:43:03 GMT

GDL is broken. I'm pretty handy with it myself but my god it is painful and 99% of architects rightly would want nothing to do with it.

Graphisoft would be much better off putting whatever resources they can into completely overhauling ArchiCAD's scripting interface - something along the lines of Grasshopper is where they should be looking. Again and again, until they get it.

Here are some quick videos illustrating how easy it is and how applicable it is to real-world architecture (not just that 1% like Zaha):

Figuring out the triangulation on a complex 3D curved roof

Parametrically defining the storey spacing and rotation of tower floorplates

Re: Become a registered object developer

Anonymous — Thu, 26 Nov 2009 08:11:39 GMT

Hi Owen,

You are missing the point here. Although Grasshopper looks impressive and I agree GDL can have a overhaul, I don't see architects doing any of this, not in Grasshopper, not in ArchiCAD.

An object is a small piece in a large building. As an architect you do not want to spend your time reading through manuals and fiddling around for days. Making an parametric object for each of the infinite amount of elements in architecture. An architect wants to create buildings. The software is just a necessary tool.
That where the parametric and visual qualities of GDL come into play. An architect just has to open an object, put in his values (preferably in an nice UserInterface) and done.
Now these objects can be made by object developers. I feel that architects are reluctant to buy objects from developers and I want to make it easier and saver for architects to call in their help. That why I see a necessity for registering ArchiCAD object developer.
Ofcourse when making objects is easier, prices can be lowered.

Re: Become a registered object developer

owen — Thu, 26 Nov 2009 10:54:23 GMT

Master wrote:
That where the parametric and visual qualities of GDL come into play. An architect just has to open an object, put in his values (preferably in an nice UserInterface) and done.
Now these objects can be made by object developers. I feel that architects are reluctant to buy objects from developers and I want to make it easier and saver for architects to call in their help. That why I see a necessity for registering ArchiCAD object developer.

I wasn't missing your point ... i just chose to address what i think is the bigger problem with GDL and that is its user-friendliness.

I do support what you are trying to do - increase the number of quality GDL objects out there, and provide a central point of availability - but the sticking point is 'Registered Developer' with Graphisoft. This just sounds like another revenue stream for Graphisoft that will not necessarily have many real benefits - e.g there would need to be a major improvement in the tools, training and documentation for GDL. Just look at the Graphisoft Registered Consultants program .. not exactly a shining beacon of success and for good reason - no value for money.

Master wrote:
Ofcourse when making objects is easier, prices can be lowered.

This is what i was getting at. Graphisoft needs to make object creation more accessible, i.e easier. Doing so will massively widen the pool of people able to and interested in creating objects. Document some robust object creation standards (Graphisofts Lib Dev guide is lacking) and decent training material for different levels of user.

Once this happens you can then worry about enacting some sort of quality control on a central object repository. Until then i think you are just further reducing the developer pool - it is already small enough.

Graphisoft doesn't seem to understand that custom objects (and better parametrics at all project scales) are of major importance to ArchiCAD's future. They do not have the resources to create everything anyone could ever need and so they need to provide the easy-to-use tools to open it up to the wider community.

One last thing, slightly OT but related to ease-of-use - the thing i like about Grasshopper is its drag 'n drop modular nature. All those functions you can string together are available in the text-based RhinoScript (GDL) but with Grasshopper they are self contained packages of working code. You do not need to type out several lines and make sure the formatting, punctuation, etc are all correct. No stupid typos or formatting errors will bring your entire GDL script to a standstill. You simply plug in your input values and they work. No input and they just sit there and let the rest of the working script function (unlike GDL where you have to comment them out or it breaks your script).

cheers,

os

Re: Become a registered object developer

Anonymous — Thu, 26 Nov 2009 12:10:27 GMT

owen wrote:
increase the number of quality GDL objects out there, and provide a central point of availability

That is exactly my main objective.

owen wrote:
Document some robust object creation standards (Graphisofts Lib Dev guide is lacking) and decent training material for different levels of user.

True, GS documentation skills are inadequate.

owen wrote:
Once this happens you can then worry about enacting some sort of quality control on a central object repository. Until then i think you are just further reducing the developer pool - it is already small enough.

Another good point, but I am trying to make the best of it right nów. I am sure GS does acknowledge the necessity of improving GDL, but I do not want to wait on that.

owen wrote:
They do not have the resources to create everything anyone could ever need and so they need to provide the easy-to-use tools to open it up to the wider community.

That is why we need to make creating objects popular.

Re: Become a registered object developer

owen — Thu, 26 Nov 2009 12:58:09 GMT

Master wrote:
owen wrote:
Once this happens you can then worry about enacting some sort of quality control on a central object repository. Until then i think you are just further reducing the developer pool - it is already small enough.
Another good point, but I am trying to make the best of it right nów. I am sure GS does acknowledge the necessity of improving GDL, but I do not want to wait on that.

Fair enough ... we have already been waiting a long time, and quite some more to do yet i fear

Master wrote:
owen wrote:
They do not have the resources to create everything anyone could ever need and so they need to provide the easy-to-use tools to open it up to the wider community.
That is why we need to make creating objects popular.

Which also unfortunately means returning to point 1 - making it accessible, perhaps 'fun' even .. not like current state of extracting teeth without the anaesthetic.

Who knows, maybe if they did have a registered GDL developer program they could use the fees to fund resourcing the overhaul of the scripting interface? I would sign-up in a minute if i knew this would get it delivered in the next 18-24 months (and be part of a testing program of course )

Re: Become a registered object developer

Anonymous — Thu, 26 Nov 2009 15:56:06 GMT

Hi Folks,

All these matters have been fully discussed many times in the near past...

I guess that we can all assume that a Graphical GDL Editor is essential for the future of the GDL itself...

Grasshopper seems to point to a good direction, and I'm pretty sure that GS is aware of that.

From what I've seen from GS products (TW2, MEP, VBE, etc...), I refuse to think that at this right moment, at GS headquarters, there is no task force group trying to achieve this.

Right now... All we (community) can do is promote what we have, which is a not-perfect but effective 2d/3d parametric language...
and as Master Script think and act, we don't have the luxury of just sit, wait and complain...
We have to promote what we have now... If not, even a hypothetical up coming graphical GDL editor would not live to see its release.

My 2cents.

Re: Become a registered object developer

owen — Thu, 26 Nov 2009 16:24:57 GMT

Braza

You're right ... this subject has been done to death. I just can't help biting everytime it is thrown out there though

Anyway i agree we have to make do with what we have today and not keep holding out for the next version ... and so i support any activities to improve the amount (and standard) of GDL content out there.

They must not however distract Graphisoft from the pressing need for a better GDL editor - that is the only real thing that will make any big difference to the application of GDL in the community.

Braza wrote:
From what I've seen from GS products (TW2, MEP, VBE, etc...), I refuse to think that at this right moment, at GS headquarters, there is no task force group trying to achieve this.

Unfortunately i think the opposite .. they are spread very thin at the moment with all these new tools (which noone was really asking for BTW). There are no resources left for the not-insignificant task of overhauling GDL. All their new tools appear to be bypassing GDL entirely (Curtain Wall, Complex Profiles, etc). Not encouraging really

Re: Become a registered object developer

Anonymous — Thu, 26 Nov 2009 17:56:49 GMT

owen wrote:
All their new tools appear to be bypassing GDL entirely (Curtain Wall, Complex Profiles, etc).

Exactly!... If you look through a different perspective... Perhaps this is a good sign.

Re: Become a registered object developer

owen — Fri, 27 Nov 2009 13:16:11 GMT

Braza wrote:
owen wrote:
All their new tools appear to be bypassing GDL entirely (Curtain Wall, Complex Profiles, etc).
Exactly!... If you look through a different perspective... Perhaps this is a good sign.

not really if it means relying even more on what tools Graphisoft choose to develop. A better scripting language that can hook into any tool or geometrical function in ArchiCAD will allow users to create parametric tools when they find something is not there or not working in what Graphisoft provides.

The way they are headed seems more a case of providing easy-to-use but really 'dumb' interfaces like the Profile Manager (non-parametric fills) and then relying on programmers to build complex functions as AddOns via the API. If GDL is bad enough C/C++ is not stepping in the right direction to encourage content creation!

Anyway .. OT again and i agree this has been done to death many times before so I will finish by saying the current state of affairs is not at all encouraging to prospective developers who can see GDL seems to be dying on the vine due to lack of development from GS (and no sign of change). Why invest time (i.e money) in a stagnant system whose support seems to be dying in even on its home turf.

Having a 'Registered Developer Program' will (IMO) mean absolutely nothing if it does not coincide with some real concrete signs from Graphisoft that scripting for ArchiCAD (not via the API) is going to be made much, much easier and provide the ability to really extend what people can do in the program. It will just be preaching to the converted otherwise.

I do not think there is a lack of trust in the abilities of object developers out there. There is however a lack of understanding of what GDL can actually provide due to its opaqueness, a lack of 'wow look what it can do' examples and the fact that it really is lagging years behind where it should be - leading to a lack of trust in Graphisofts continuing support and development.

Re: Become a registered object developer

ztaskai — Fri, 27 Nov 2009 14:27:33 GMT

I'll post 2 answers to all which has been written in this topic before me. This one is about graphical GDL scripting (which is slightly off-topic here).

I just tell you how I see this topic. My point of view can change - you may change it 😉

Let's start from the target groups: there are architects (A) and developers (B).

(A) For architects, a graphical GDL interface is an overkill. As Master Script already wrote they need efficient parametric objects and some good custom content creation. The first one should be suitable for generic recurring jobs. The second one would stand mainly for project specific objects. Of course, it could be parametric too - sure it would be useful. Consequently, I truly doubt that Rhino is a good tool for architectural purposes. Furthermore, ArchiCAD isn't a modeling tool - it's for architectural design and it can use the models generated by modeling software (3DS, Sketchup, Autocad, etc.).

(B) For programmers & content developers a graphical interface is pain. In the first 1 minute I was amazed by the Grasshopper videos but then my stomach started to hurt watching the struggle of the demo person (just like watching a Ben Stiller movie). All those repetitions, hovering, mousing aren't the attributes of an efficient development tool. GDL should develop into a programming language producing better maintainable scripts and GS could provide a better text/script editor for it. A real programming language will always outperform graphical interfaces in professional usage and well-scripted objects will outperform generated content.

A few words about Graphisoft priorities - at least the public part. GDL integration and customizability is a priority for us. You mentioned curtain wall which can contain custom GDL elements for each component - brilliant example. All ongoing developments aim for about the same level of integration with GDL. Unfortunately, custom profiles are a good example for the opposite - I can see that. There are plans to take custom profiles to the next level but all ideas have to fit into "the big plan" 🙂

Re: Become a registered object developer

ztaskai — Fri, 27 Nov 2009 15:25:13 GMT

Now I get to the actual topic 🙂

I don't really believe in the "registered" part either. I don't think anyone can tell that a specific developer follows GS recommendations unless they work together. We could test whether the developer knows the methods but I don't think we should waste resources on that.

I believe more in a tightly organized community which can rate products and providers. Naturally, I want to display some technical quality information too which is set by GS or by GS tools. I don't even see how it should work theoretically let alone in practice.

This could be the forum where we discuss how a correct rating system should work.

What do you think?

Regards,

Re: Become a registered object developer

Erich — Fri, 27 Nov 2009 16:03:09 GMT

Zsolt, I really appreciate your frequent presence on the forum recently. It is nice to get a Graphisoft perspective on things.

I don't completely agree with your point A above (For architects, a graphical GDL interface is an overkill). I think is it nearly impossible for Graphisoft, or anyone else for that matter, to provide content appropriate to all conditions. In fact this is the very reason I first learned GDL. But similarly I would hazard a guess that most architects will not even attempt the most basic GDL because it is outside of their comfort zone and realm of experience. By providing a graphic interface you would be speaking to your clientele in a language they better understand. I have done some GDL instruction for my local users group and by and large everyone's face goes kind of glossy when looking at pages of code in a scripting window. That said, I would hate to loose the scripted interface we have now as I do agree that is is more effective once understood.

I think the idea of registering GDL developers, while perhaps providing better content, will almost certainly reduce the amount of content available which will not be beneficial to the community. We do not yet seem to have the issues seen in the Revit community where junk content abounds. Right now I think we need to get more of the community involved in content creation.

The idea of a community driven rating system might help control the quality. The problem I see with rating systems is that when a user first acquires an object, you have not idea if it is good or not. Therefore any rating the user may provide initially can not be based on any real criteria. By the time a user has used a part and formed an opinion based on that experience he/she is probably nowhere near the forum and has no means to submit a rating. Then when on the forum later, the object is long forgotten and while the opportunity for providing a rating might existing the inclination is gone. Perhaps such a rating system could be tied into the Archicad interface so such ratings could be provided from within the program. But if so it would need to be elegantly done so as not to affect the daily use.

Re: Become a registered object developer

owen — Fri, 27 Nov 2009 18:06:44 GMT

ztaskai wrote:
I'll post 2 answers to all which has been written in this topic before me. This one is about graphical GDL scripting (which is slightly off-topic here).

Apologies for that Masterscript .. a necessary diversion IMO but we're getting back on track.

ztaskai wrote:
Let's start from the target groups: there are architects (A) and developers (B).

(A) For architects, a graphical GDL interface is an overkill. As Master Script already wrote they need efficient parametric objects and some good custom content creation. The first one should be suitable for generic recurring jobs. The second one would stand mainly for project specific objects. Of course, it could be parametric too - sure it would be useful.

This conception of who GDL should be geared towards is where our disagreement over its interface lies. I actually think Parametric Scripting (GDL in this instance) should be viewed as part of the design tools available to Architects working in ArchiCAD just like the Wall tool is. Now in theory it is now, but due to implementation it essentially gets ignored by most design architects.

I am an architect who also happens to be a bit techy. 6+ years back working for a big firm we could see the benefit of making our own custom objects - both general office standards and project-specific. However no-one really knew how to do it .. not even a handful. We (the design team) wanted to apply a series of modular facade panels to a series of 'spline' planform facades. Given the alignments etc were still in flux, as were the proportions of facade panels, we wanted to do it parametrically so we did not have to manually replace/resize each panel whenever we wanted to test things out. So I bit off a bit more than i could chew and threw myself in the deep end - the GDL Cookbook and these forums were the only help you could get. It was rewarding but extremely frustrating at times. We got about 80% of what we wanted - parametric modular panels all good, but couldn't get an array of different panels along a spline which was editable. Could probably do it now but that was the first real GDL i had done so ..

Now GDL is not that difficult if you are that way inclined, but for someone who has no programming background (or desire to) it is totally off-putting. After 5 years of working for the same firm there was still only a handfull of us who could do any GDL. Even creating the simplest of objects were beyond 95% of the office because no-one wanted to 'program' in a text editor. Fair enough, we are architects.

Now i know for a fact if there was some sort of 3D graphical interface - even in combination with a 2D editor window - we would have learnt faster and there would have been more than just a handful of us. Architects love to design systems based on relationships, proportions etc and we love do it graphically. Yeah let people dig into the code under the graphical interface, or in parallel - but let us design parametric systems in 3D. Its how we work, and why many of us love working in ArchiCAD versus AutoCAD (efficiencies aside).

We do not however want to manually type lines of code in a text editor, check it for typos, hope we understood the sometimes cryptic GDL Manual explanations, etc, etc

From an architects perspective (and we are your target, not programmers) drawing two cubes in 3D, dimensioning between their faces and saying 'make this Parameter A' beats writing:


CPRISM_ mat, mat, mat,
    n, h, 
    x1, y1, 15,
    x2, y2, 15,
    x3, y3, 15,
    x4, y4, 15,
    x1, y1, -1

ADDX ParamA

CPRISM_ mat, mat, mat,
    n, h, 
    x1, y1, 15,
    x2, y2, 15,
    x3, y3, 15,
    x4, y4, 15,
    x1, y1, -1

DEL 1

ztaskai wrote:
Consequently, I truly doubt that Rhino is a good tool for architectural purposes.

There are many that would disagree. I think it has its place for design, but to actually produce ConDocs you would most probably go with ArchiCAD. They are working on their documentation side of things though, and with digital models driving fabrication who knows how long the status quo will remain. ArchiCAD is very much geared towards production of traditional 'paper' drawings (something it does very well too).

ztaskai wrote:
Furthermore, ArchiCAD isn't a modeling tool - it's for architectural design and it can use the models generated by modeling software (3DS, Sketchup, Autocad, etc.).

Agreed - modelling is just one part of the design process, but a very important part. I just think there are a lot of features of 'generic' modellers which could be applied to the modelling side of ArchiCAD, still with all the other architectural specific functions on top. As for the 'can use models..' bit - yes and no. Technically true but there are a lot of issues and often the results leave a lot to be desired. If it were possible to model complex forms in other applications and get them into ArchiCAD in a usable way then perhaps this whole subject would be redundant.

ztaskai wrote:
(B) For programmers & content developers a graphical interface is pain. In the first 1 minute I was amazed by the Grasshopper videos but then my stomach started to hurt watching the struggle of the demo person (just like watching a Ben Stiller movie). All those repetitions, hovering, mousing aren't the attributes of an efficient development tool.

Assume you're refering to the second 'high-rise' video? There were a few hiccups but this was a recording of a live webcast tutorial AFAIK. It was a pretty simple exercise which should probably have been covered much quicker but for all the talking (and the small 'how does this work' bit at the end ...)

The first video showed the extremely rapid construction of a triangulated complex curve structure - 7 minutes which i'm sure would have been quicker if it wasn't being paced so people could actually comprehend what was going on. Can anyone seriously tell me they could code that form in GDL in 7 minutes? I don't even think it is actually possible given the current GDL functions available - and you would certainly need a maths degree.

I don't know .. maybe you need to be an architect to see how much better that method (draw in 3D as well as drag 'n drop preformed code snippets) looks to the current GDL.

ztaskai wrote:
GDL should develop into a programming language producing better maintainable scripts and GS could provide a better text/script editor for it. A real programming language will always outperform graphical interfaces in professional usage and well-scripted objects will outperform generated content.

I agree Graphisoft should at the very least provide a much better script editor - there have been many suggestions going back well over 5 years now. I also agree that for programmers a text-based interface is probably far more efficient. However why does it have to be one or the other. Can the programmers not just code directly, while others can draw in 3D or code as they feel comfortable? Its similar in Rhino ... the programmers can stick with RhinoScript if they want but now there is a GUI wrapper (Grasshopper) providing a designer-friendly interface to it. This is the reason it is really starting to take off both in schools and practice.

I would propose is actually a side-by-side GDL editor option where you could see both code and 3D, along with the effects of editing each on the other.

ztaskai wrote:
A few words about Graphisoft priorities - at least the public part. GDL integration and customizability is a priority for us. You mentioned curtain wall which can contain custom GDL elements for each component - brilliant example. All ongoing developments aim for about the same level of integration with GDL. Unfortunately, custom profiles are a good example for the opposite - I can see that. There are plans to take custom profiles to the next level but all ideas have to fit into "the big plan"

Yes the Curtain Wall tool is a good start - you can create your own custom components to call into the system. Good stuff.

However I am talking about being able to create your own systems such as this via scripting - such as define a plane, deform it, subdivide and extrude profiles along joints, infil panels etc - similar to the video i was talking about. I do realise this then gets into issues of how you represent these things in plan when the plan view is not a 'real' 3D cut view like Sections/Elevations, etc.

That is a can of worms that has been opened before so better leave it there.

glad we can exchange perspectives

Re: Become a registered object developer

owen — Fri, 27 Nov 2009 18:34:49 GMT

Whoa ... that was longer than i thought

ztaskai wrote:
Now I get to the actual topic

quite

I think some sort of quality assurance of developers by Graphisoft (which is what a registered developer program would imply to many) would be unworkable from Graphisofts perspective ... its just too big a job. I certainly don't want their GDL dept spending time on it.

What they can do is provide better resources for developers - and anyone who uses ArchiCAD can be a developer. Some quick things that come to mind:

- Better GDL Manual - its not terrible, but it is hard to understand how things work in places which is why books like the GDL Cookbook and GDL Handbook are so important.

- Better training material - including guidelines on how to structure objects, common parameter names (maybe this ties into the documentation of Graphisofts own Library standards)

- Better ArchiCAD Library + Standards Documentation - anyone who has opened up one the incredibly complicated GS objects will understand. It is often quicker to start your own from scratch than modify something that almost does what you want due to the fact it is so damn hard to find your way around.

- A code library / exchange - people could share all kinds of code snippets, just drop it in your script and correct the parameter names as required. Graphisoft could even include their library of code components to kick things off .. that would be really useful if documented.

Re: Become a registered object developer

Erich — Fri, 27 Nov 2009 18:48:19 GMT

owen wrote:
A code library / exchange - people could share all kinds of code snippets, just drop it in your script and correct the parameter names as required. Graphisoft could even include their library of code components to kick things off .. that would be really useful if documented.

This is an interesting idea, if the snippets can be kept simple enough to be useful. I am working on setting up a personal database in Filemaker currently for just this purpose for my own coding. If this idea could effectively be broadened and shared it could spur better code development and more complete solutions.

Re: Become a registered object developer

Anonymous — Fri, 27 Nov 2009 21:10:15 GMT

I don't mind being off-topic here

I think there are some pretty good ideas:
-Better GDL Manual
-we love do it graphically
-code snippets (examples!!)

Rating system:
-What about combining a few ideas here. One developer does an upload in the depository, somebody (an architect 😉 ) likes it but needs some adjusting. He/she can post a question if somebody can modify it. Somebody does it and posts an update.
Pitfalls: the code has to be clear, readable and made by standard, because otherwise you are spending more time reading and understanding than coding. This requires an update of GDL script.
Pitfalls: I think ArchiCAD has a strong community, but . . . money makes the world go round.

GDL interface
I think there is a wide range between the GDL editor now and a graphical editor. Some examples to tighten the gap.
-I think everybody in ArchiCAD has made his own objects by using Save 3D model as. Lets make this just a little better. There are already some small examples: Like using Wallhole in the ID to create a custom wallhole, or General as Material to make the material parametric.
-The code that the autoscripting creates must be more pure code and less baggage.
-Special elements just for autoscripting. For instance an element that defines Parameter A. Something similair is already in the complex profiles (horizontal stretch/vertical stretch)
-Autocompleting code, just like visual basic, you begin to type an element and the GDL editor completes it or gives possible other commands.
-Better error handling: OK, I have an error in the POLY or PRISM, but where!!!
-Colorcoding, hyperlinks to go to GOSUBs, expanding and contracting bits of code, etcetera.
-Visual Userinterface creation, dragging fields and pull-down menus, resizing images.

Re: Become a registered object developer

Anonymous — Fri, 27 Nov 2009 22:00:21 GMT

Words from a newbie.
As a absolute newbie to a tiny, tiny bit of playing with the simplest of simplest aspects of a simple object, I'd like to second the comment that Erich
has made:
"..most architects will not even attempt the most basic GDL because it is outside of their comfort zone and realm of experience. By providing a graphic interface you would be speaking to your clientele in a language they better understand."

Architects are in my opinion are; visualizers first, structural minded second and programing code minded last.

I especially like the general concept presented that a duel GDL Object opportunity makes far more sense, than going either way on it's own.

Anyway, now back to listening to the masters speak.

More on how a graphical and code based connection might work?
How would a simple version of this begin/look?
lec

Re: Become a registered object developer

Erich — Sat, 28 Nov 2009 05:39:37 GMT

Masterscript,

You missed a big one. The ability to copy/paste parameters in the parameter table! It wouldn't hurt to be able to have a newly added parameter added to the line above/below the currently selected parameter. It is such a pain in the *** to have to drag parameters to a logical position in the table when dealing with a complex object with lots of parameters. While this will not help the masses it sure would make object making less painful.

Re: Become a registered object developer

Rod Jurich — Sat, 28 Nov 2009 10:43:09 GMT

Erich wrote:
You missed a big one. The ability to copy/paste parameters in the parameter table!/.

Erich, I am with you on this one.
With parts becoming more complex, this wish would really help if GS obliged.