Bugs in pris on mass?

K

KANUSO

New member
Maybe I did something wrong, but if it is so, than think about a better documentation...

After dig out the error with the pris/modeler/move
(I have reported this with the Feedback Agent)

I run into the next strange Situation....
pris/modeler/boundingbox
this seems to return {[0.0, 0.0, 0.0], [0.0, 0.0, 0.0]} allways
no matter if there is geometry or not,
no matter if something is selected or not

please NT do better tests with your python stuff, if you want us to use python insted of LScript.
The many tests you made (or not) seems not to evaluate the results, they only check if the call Ends up with a bad Status

Do you really want us to act as beta-testers? Who does paying us for the wasted time?

Maybe I did something wrong, but this only Shows how "good" your docs with that stuff are.

If you want us to use python, than please give us the Information we Need in a form we Need it and please... test your stuff before you release it

LW is such a great product, why do you Smash it down with such weak docs?
Yes, if you are searching for hours, than you "may" be able to find something... Here in the Forum, or in the Internet or somewhere else, but why not in your docs?

I dont Need docs, that are more or less variations of the python help-command.
It is ok, that you are proud of your work, but if you want us to use it, than you should even Show us how.

At the Moment it seems that it does not really make sense to develope further with pris/modeler

Please do the docs as good as LW

Regards,
KANUSO
 
lwsdk.LWStateQueryFuncs().bbox(lwsdk.OPSEL_USER)

to get the bbox of what you got in modeler. (and that IS documented in the docs)
 
Hi oliverhotz,

thank you for answering. And thank you for showing a function, that does the same.
But as the thread says I am talking about the lwsdk.pris.modeler and you give me indirect right, you want me to use something else than pris. Don't missunderstood me, I am really thankful about your help. Give it a try, write a simple test script which is using lwsdk.pris.modeler.move and lwsdk.pris.modeler.boundingbox (which both are very Basic functions for modeling) and you will see what I am talking about. Nobody can tell me that one of These both functions are testet. And that what I am talking about... We, the users did test (we are the beta testers). And that costs our working time and so even our money. And give the pris documentation a closer look please. It is more or less the Output of the python help changed to html.

Again thank you for helping me out.
As I wrote this thread, I was boiling about this Situation (maybe especially mine). For me it is the first contact with python (and I don't really find this language fine). The main hurdles of python I have mastered.
And than I found many, many, many files where I have to gather Information to the python stuff of the lwsdk. Even the C-includes must be used to find something out (wich don't fit at all circumstances).
And than I started to use the pris, becaus this seems to be something, that is not looking so much strange in coding (and thats the reason why it is developed from NT)
Than even Basic stuff doesn't function. As a new user to python I thought of course it is all my fault. And after hours of searching for Information and doing try an error (i did not expect, that such rough mistakes are done in that module, so I thought it is all a fault of mine)
But I have learned about this. If I get an error in a script in the future, than I will first look at the code of the deliverd python stuff. Yes, even if I am new in python, because the bugs are that clear to see, that I can not doubt that this is really tested.

And now I am thank you again for helping me out, but I hope you understand why I wrote this here in the Forum. Maybe I does help someone to NOT spending hours in developing in pris to simply notice, that there are bugs in the delivered code, and even Basic things did not work.

In this sense and with a lot of thank you
Regards
KANUSO
 
Last edited:
Kanuso, I understand your issues.. was just trying to get you a head start..

Rule #1.. dont use pris... its just AGAIN, an abstraction layer like lscript.. DONT use it... just a word of advice, might as well stick to lscript if you do.
 
oliverhotz, I can't understand your rule #1 because this is exactly what I want. I do not want to fumble with the internas of LW. This Job should be the responsibility of NT. And exactly that is the reason why they developed pris. What is wrong on doing the Job that easy? They want us to Switch over from LScript to python. They now want to give us a simpler way to use python. Why should we say: no, we want the complicated way? With pris (if it is with no bugs) we get a way to do the things much faster.

And by the way, I really wish they don't let LScript die, because that is a really fast way to write scripts for any Job inside LW. From my Point of view python is good for doing Jobs that comunicate to other applications, but for Jobs inside LW is LScript much, much easyer to handle.

Please, if you want me to notice this as advice, than give me a hint of why I should do it more complex than I need to do. I think you have a reason, because you want me to use this as advice and it Looks like you are experienced in python with LW.

To do the job with more fumbling on internas does mean to much more search for Information. And this in many files. Even the search for the right file for gathering Information could be frustrating. And if the LW gods give us the possibility to use such an abstraction layer, why should we went away and don't use it?

Please don't missunderstand me, I am really thankful on your help and advice.

Regards,
KANUSO
 
Sorry, I have no interest in getting into a shouting match about why and what and how.

regarding your initial report on boundingbox, I looked at the pris code, and noticed that it works with selected points only. Select points, issue the command, and you get the correct info.

Again, not disagreeing with you that it a) should be fixed, b) should be better documented... and those are all things that the lw3dg is aware of, trust me, its been brought up. I just bug it, and tend to help myself until it can be fixed by the devs. To me, this is nothing out of the ordinary with any other app i use. I also never saw mentioned, that lscript is going to die, but of course I could have missed that announcement. However, if there wasnt one, pure speculation then, which, does not help anyone.

I am perfectly happy with using vanilla SDK, and i dont find it in any ways "slowing me down, or more cumbersome".. i just get used to it. It also allows me to focus on bugs with the actual sdk versus bugs in the translation layer (the later, you can actually fix yourself by adjusting the pris code - again, of course it should be fixed by the devs, just saying, until then, you can)

Its all what you are used to, and in the end, its great that we have that many options, so that everyone can use what they want. Anyways, I've rambled on longer then I wanted to, and wrote more than I wanted to.

Best of luck,
Oliver
 
Please read the following in a relaxed informative tone. I love lightwave 2018 and get great results with it.

The PRIS modules were released without enough testing. The most basic 'move' function throws an unknown error code in version 2018.0.7. I have just reported two bugs. One for selhide (selection hide), and another for boundingbox. It is (feels like) such a waste of time for each of us to find and report the same bugs.

There is a file named common_test_pris_ss.py in the plugin scripts folders that tests some common functions but there is no corresponding tests for the modeler or layout functions. Newtek, please complete the test suite. Please use the PRIS modules to write plugins for regular use. If not, Why not?

Respectfully,
John
 
my adivse.. DONT USE PRIS... just really dont.... you can use the pris.py files to learn from them.. but DONT USE PRIS... you are limiting yourself there and making your life a lot harder in the long run... use the raw api (and again, learn from the pris files if you need)

just my 2 cents.
 
oliverhotz said:
my adivse.. DONT USE PRIS... just really dont.... you can use the pris.py files to learn from them.. but DONT USE PRIS... you are limiting yourself there and making your life a lot harder in the long run... use the raw api (and again, learn from the pris files if you need)
Click to expand...

I definitely agree with you there, but regardless, Newtek either needs to fix the PRIS APIs or remove them. Leaving broken APIs in the SDK just causes frustration, and can have a seriously discouraging impact on devs who lack experience to quickly recognize the LW APIs are the problem versus their own code.

If the PRIS APIs shouldn't be used by third-party LW devs, and are broken as well, then there's NO valid reason to keep them around -- if the APIs are broken, the "existing dependencies" argument is moot at best, and an active liability at worst.
 
Last edited:
I think that Oliver is right, from his Point of view and that you are more freed from chains by using the vanilla api....

BUT: The PRIS SDK is a way to let the users (what are in fact we) step away from the internas of LW and have not to fumble with the internas. And that is why it is developed. The nuArchitect python Version uses PRIS and it is running.
OK, there are bugs in it, but there I full agree with Oliver. I just bug it and tendet to help myself as he did. Thank you Oliver for pointing my nose in the right direction.

To work with the PRIS, you have to do workarounds. I did so and nuArchitect works...

Here the workarounds named:
move
boundingbox
selhide
selpolypoints

I think that the name PRIS is stop some users from using it.
Python Reduced Instruction Set
Yes it is reduced, but you are not bound to use the PRIS stand alone. Use it as Extension to the vanilla SDK. Therefore it should be named
Python Instruction Set Extender
To Show it in the Name, that this can help you to do things with some more distance from the internas.

No, I do not wish that it will be renamed. The name is choosen... And NT had for sure a reason to Name it so.
And it will be good for users coming from LScript (because there are things that they are used of)

Again: I agree with Oliver. But I would say: DONT USE PRIS ONLY, USE IT COMBINED WITH VANILLA

Regards,
Kanuso
 
Whether its my viewpoint or not.. it is really pretty simple.... you can take Jwiede's stance and say that those errors shouldnt exist, and blah blah blah, and... (i am going to give you a shortcut outlook here:), thats not going to change anything. Its an utopian idea, that world doesnt exist.

you can also use pris, or the vanilla api, and as you find bugs, submit the living crap out of them, so that they can be fixed. the more people that are doing python scripting, the more of those bugs will be found AND resolved. I have logged 100's, if not multitudes of that in terms of python scripting, and they are being fixed. however, if noone else is using it and reporting it, there's nothing to report.

So, I am going to make a suggestion here.. UNLESS you actually do python scripting with lightwave, pris or not, and unless you do report these bugs.. please... lets refrain from the idea that everything SHOULD be perfect. It is not, and it will never be perfect or optimal, or whatever other word you want to choose
... oh... and, that goes for ANY package.

Some people will use pris to do simple things, others will not.. I've probably written the most python stuff that exists for lw, I have no used pris, a very conscious decision.

Fact is.. python in lightwave is VERY powerful, VERY capable, and yes it has bugs.. and yes... they are being fixed.
 
in case you are wondering how I would have found such information, you can find a pretty thorough example in: support\plugins\scripts\Python\Common\FileRequester

those were added after I asked for it myself.
 
You must log in or register to reply here.
Back
Top