llSetPrimitiveParams flex parameters inconsistent with GUI

Why isn't the flex llSetPrimitiveParams parameter ordering the same as in the object editor? Inconsistent...

The GUI lists flex parameters as:

1. enabled
   
2. softness
   
3. tension
   
4. drag (friction)
   
5. gravity
   
6. wind

Steps to reproduce the bug: Open the object editor and look at the "Features" tab's "Flexible Path" settings and compare to llSetPrimitiveParam's PRIM_FLEXIBLE parameters.

Observed results:
GUI: enabled, softness, tension, drag, gravity, wind.
llSetPrimitiveParams PRIM_FLEXIBLE: enabled, softness, gravity, friction, wind, tension, force (not in GUI!)

Expected results: Both parameter sets should match and be in the same order.

Shouldn't this be three or four threads instead of just one?

Sarcasm?

This implies to be fixed in SL 1.9.1.14:
But it's not. Note: light parameters weren't inconsistent with UI; only PRIM_FLEXIBLE was/is.

Despite what SL 1.9.1.14's release notes say, this is still no the case.

Steps to reproduce the bug: Compare "Features" object editor tab's flex parameter order: softness, tension, drag, gravity, and wind with llSetPrimitiveParams' PRIM_FLEXIBLE parameters: on, softness, gravity, friction (drag--rename consistently!), wind, tension, force (still not in UI!)

Observed results: See above and /290/80/101731/1.html

Expected results: consistent parameters and UI fields (+ names)

I think there may be a communication problem here.

Do you mean that the displayed order and the order in the list are different, or do you mean the names and the order in the list are wrong.

The former isn't a big deal, really.

If you mean the latter, that may explain the problem I have been having - what I read through the API doesn't reflect what's displayed in the GUI, and vice versa. There seemed to be two problems. First: changes in the GUI don't always get reflected in the API. Second: the values don't seem consistent with each other.

If I call set a prim up in the GUI, call llGetPrimitiveParams, modify it, and llSetPrimitiveParams... I don't get just the modifications I asked for. I had assumed that I didn't understand the scaling that was going on and just fiddled with the parameters in llSetPrimitiveParams until things seemed right.

Or is there something deeper going on?

None of the PRIM_TYPE_* are in order, why should LL start now?

Why SHOULDN'T LL start now? Sheesh. Why not remain consistent between UI and function? Just makes it easier for everyone. Also, there's no way to enter a force in the UI for flex prims.

Am I writing in Greek or something? Seems fairly obvious to me what the problem is...

Both, actually. "drag" in the UI is "friction" in the function. There is no "force" field in the UI.

It is when you're trying to change something in the UI and find it's not in the same order as the function (or vice versa--considering the UI came first, I'd say the function order needs to change to match the UI).

Yup.

Dunno; never had a problem with the other *PrimitiveParams function parameters, aside from them being overly complex and unintuitive to work with--OK, so I HAVE had a problem with them; just not the same as you.

LL should keep LSL *PrimitiveParams function parameter orders consistent with the UI prim parameter orders.

Cuneiform, possibly.
The other way around, since the UI has to change anyway to accomodate "force" and you'll mess up everone testing PRIM_FLEXIBLE in the Preview grid if you cange the API... the GUI might as well do all the heavy lifting.

Also, you seem to have misunderstood my comment about the values not matching up. When I match them up after accounting for the name and order differences I don't get consistent results. That is, I'm not mixing gravity and tension, I'm getting results like: enable in the GUI, change "drag"; call llGetPrimitiveParams and get 0 for "Enabled" and the default for Friction. Change the parameters in the API to double Friction and enable it, call llSetprimitiveParams, and values in the GUI other than Friction are changed.
Neither have I, other than this one.

I say this because the UI order was first, THEN came the function parameter order. People know more about the UI order than they do the function parameter order. Besides, nothing from the preview grid will remain in our inventories once we go back to the main grid anyway so it really doesn't matter if the function order changes...

Well, I didn't misunderstand your comment since I have yet to use llGetPrimitiveParams with a flex prim.

The UI arder in the preview grid has already moved half the tabs and completely reorganised the texture tab. Changing it again is far less likely to cause problems than breaking programs that people are using to test the grid. Do you want to flood the Lindens with extra bug reports?
All my scripts from the preview grid are already in my inventory on the main grid. You don't make backups of your work?

Um, do you even think before you type (troll), Argent? It is a trivial task to simply reorder the flexible fields.

Current order:

1. Softness
   
2. Tension
   
3. Drag
   
4. Gravity
   
5. Wind

New order:

1. Softness
   
2. Gravity
   
3. Friction (renamed from "drag"
   
4. Wind
   
5. Tension
   
6. Force
   1. X
      
   2. Y
      
   3. Z

There's PLENTY of room on that tab to add the force vector fields. I'd rather have the parameters alphabetical...

I will right before the preview grid goes down after LL gets it right before main grid release.

The hardest thing in the world is to change an API. Even if the API's only been out for a couple of days, if there's people other than yourself using it, you only make incompatible changes if you absolutely have to. Why? Because every change means you're going to spend hours dealing with bug reports that aren't really bugs. Even if they're undocumented (which this isn't, but even if it were) it's MUCH easier to go to enormous lengths to keep the old API intact.

There's design flaws in C - acknowedged as such by Dennis Ritchie - that are still there because they didn't want to break the code of the maybe 30 people in the world outside Bell Labs who were using the language at the time.

There's code in Windows, right now, to detect whether certain 20 year old applications are running and return slightly different error codes for those apps.

Changing the order of a user interface - especially when you're going to have to make other changes to it before release - is much easier.

[Edit: And you seem to be agreeing with me, now, or am I missing something]

@_@ alphabetical order
I... I... I...
I've never seen anyone ever asking for parameters in alphabetical order. Parameters are parameters, they are in the order they are in because the programer thought they should be in that order in thier infinite wisdom. It is not our place to question thier reasoning. It's like someone they need to re-arranging their furniture. If there is something horribly wrong with it, like a fire hazard it's ok, but if it's asthetics... You just don't do it... ever. On the other hand it's ok to suggest they build new wings to thier house or suggest they need a sauna or a hot tub.

*twitch twitch twitch*

It's like asking the Department of Motor Vehicals to mandate that we should drive on the opposite side of the road.

Having the gui mirror the API, i can support that, but changing the API, is just wrong. In computers you don't change things, you just add new ones. When LL created the ring shape, and added new attributes to all the shapes. Did they change PRIM_TYPE_* paramaters? No they changed the value of PRIM_TYPE and created another arm to the API. You can still use the old API (really useful in prim torture).

LL not documenting things (and lagging in documenting them in the current build's release notes) is another issue and could reduce how much LL has to deal with unnecessary bug reports. I must've filed around 10 bug reports during SL 1.9.1 preview so far that were already known issues because LL didn't either have the release notes updated or didn't make it aware to testers what bugs they already knew about (only until AFTER a duplicate bug report was submitted and responded to by, in my case, Milo Linden).

This is just piss-poor bug management to me and even prompted Karen Linden to request SL preview build #s in posts, which isn't addressing the actual problem of not having a central depository where testers can compare bugs, add more info to bugs, etc. As it is now, I try to reply to my own bug report posts with info from bug report email replies and it's a pain in the ass trying to keep it all updated!

I am referring to the user interface--I don't care WHICH gets changed so long as they're consistent. It'd be nice if BOTH were changed to be alphabetical but I'd be content with just the UI fields being in the same order as the function parameters.

This kind of thinking is what lets developers think they are holier than thou and can do anything they want. Sorry, but developers aren't gods and need to be kept in check like everyone else. That's what quality ASSURANCE is--assuring quality, not mindlessly letting whatever the developer says go by without questioning it. This is why QA exists: to keep developers in check and always on their toes so they don't slack off and become lazy (too late, unfortunately, but tougher QA could reduce that).

Actually this is probably my fault, i've done my best to answer every single report, and to give people the most information as quickly as possible, and considering thats about 550+ reports its quite a job.

When a new release is built it includes issues that are known at the time prior to that build, it wont have any issues included for that build as well obviously its new and you get it virtually as we do.

When a new bug report comes in its verified that we can reproduce it, search the internal system for an already excisiting bug if not a new entry is made, a developer is most likely assigned and then optionally i decided to email back saying thanks bug entered etc

If a bug is already in the system, then i thought its at least nice to get a reply that we know about it and that user isnt seeing things etc. so i would try and send a nice quick reply, although that seems to anger some that its not in certain lists here or there so its probably better i just close the ticket and if the issue isn't resolved in the next build it will get added to the known issues list.

I'd like to say i think karen is doing an amazing job having to co-ordinate such a large team, and then even come in here and try and check up on peoples problems, the reason she would of asked for build numbers is that so she could check it against her issue fixed list and see if the problem wasnt really fixed, is due to be fixed or has been completely missed as i know she only wants the best results from all of us.

Milo.

I appreciate your bug report replies, Milo--don't get me wrong. I just don't understand how a build's known issues does not actually have all the current known issues listed. The known issues list explicitly states that the listed known issues are for THAT particular build so why would it not INCLUDE ALL known issues FOR that particular build? It boggles the mind.

One way to fix this would be to simply open up the bug database to preview testers so we can see what's TRULY known and add more info accordingly (where it can be edited/reformatted by Linden QA accordingly). Kind of like how the Feature Vote system has so many duplicates because it hasn't been edited, the public bug database would have to be edited to prevent this from happening. Imagine how much easier your and Karen's jobs would be if you only had to worry about the bug database instead of replying to emails, posting in this forum and trying to weed out duplicates from multiple fronts vs. a single unified front: the bug database.

Yes Milo, please do continue with your replying. I find it very helpful, even 2 word email with Known Issue or Bug Entered is enough to know, yes you read it, and the view point on it.

Say WHAT?

The only people for whom this kind of detail in the API matters in the first place... are developers. If it matters to you, then you're one of the developers you're railing against. Pay attention to the comments made by developers who have more experience with API design and changes in API design than you.

Breaking an API, even one that's only been in existence for a short time, is not something that should be undertaken unless there's a very good reason.

Making the order of parameters match the order of parameters in a GUI that's itself subject to change isn't a good reason. In fact, it's a lousy reason... what happens if it becomes desirable to change the GUI in the future? Would you break the API then? No, you wouldn't... because it would break too much code. Which means that you can't in general depend on the API matching the GUI at this level of detail, so there's no point in establishing expectations that it should... you'll get holier-than-thou developers railing about changes in the GUI breaing some code they wrote that takes a screen-shot of the GUI and runs it through an OCR and feeds that into a prim through a key macro...

You think I'm kidding? I'm not kidding. I'm not even making this example up... just translating from another system.

Then why did you object when I suggested that the GUI should change, and explain why?Personally, I'd prefer the API fields had been ordered based on the observed frequency in which they were changed from the default value between the time the GUI was introduced and the time the API was introduced. Why? Because it would more often allow efficient code for tighter storage of saved parameter lists in applications.

If the developers had designed the GUI-function parameter interface better initially, this wouldn't be an issue...

Stupid example.

Um, I didn't--in fact, I specifically outlined how the GUI COULD change. Stop trolling and start reading. I tire of dealing with you...

Why don't you read your own words? When I said that the GUI should change if a change was needed, you wrote the following objection:

If a re-arrange is so important, then I'd re-arrange the UI as it's the "top level" of the feature. Though personally I don't care so long as the options are all there, grouped together logically (ie all under flexible path) and are named the same so I'm not completely confused
If the numbers are different then that's a big issue, otherwise there's no reason to argue so much about re-arranging the text-boxes