2.32 and pickfilter problems

[ZioRed]

I have to admit that Lumooja's posted code does seem to offer a safer way of determining that the entity returned is indeed the top level model.

I agree and I must admit that Gamelib contains some very helpful functions, I think to use it for my C++ games and write a C# wrapper or porting for my current project.

 

there should still be a check for a NULL Entity prior to supplying it to any function

Well, I think that it should be a must for safe programming in any language.

[Guest Red Ocktober]

there should still be a check for a NULL Entity prior to supplying it to any function

 

Well, I think that it should be a must for safe programming in any language.

 

don't ya think that this checking logic should be part of the function itself... and not be left to the caller...

 

i mean, in order to provide the system with a level of robustness that would reasonably be expected... wouldn't that seem to be the way to provide the function to the developer...

 

as shown in the previous back and forth on this topic, conditions could easily present themselves where a NULL Entity could inadvertantly be passed to the function...

 

 

--Mike

[Pixel Perfect]

don't ya think that this checking logic should be part of the function itself... and not be left to the caller...

Well to be honest the caller must always check the return value of a function as a function must always return something and if it can't return something valid it has no choice but return something else.

 

I prefer to code functions which always return a boolean result which is true if the function has succeeded and false if not. The actual required value being assigned to a variable passed by reference. This way the user gets used to always having to provide code to check the return value is true before using the updated variable. In this way the checking is actually done in the function itself and the callers return value check is consistent across all function calls. It just strikes me as a better way of encapsulating code which is what Mike, I think, was suggesting.

 

But either way, a check by the caller always has to follow the call to the function unless the return value is known to always be valid.

[Josh]

The filter would never be called with a null entity.

 

I am not clear on whether this problem is resolved for you. Did my fix help you?

[Marleys Ghost]

hi Josh, as I said I had a quick try with the new .dll but after an hour I had the error notify sorted but as the light_directional_1 is the first picked item the filter it bypasses the extra "if's". Which it would do when using a null check (If entity.parent <> Null). But I have decided on a new route for my project and wont be debugging this further as I have since archived LE at this current time.

[Josh]

Sorry to hear that.

[Joh]

I know he already choose but i wanna tell mine too:

This engine is ever in upgrade and i am happy to this, you don't even know how is bad having an engine full of bug with a slow updating.

I saw in my "little" experience that when there is multiple calling command (as for example a linepick) it should be better have one function called from most of the part of the code, so with a little modification you are able to fix the problem (as for example in bmax i did a Math class where there was stored all the math calculation i needed).

I saw too that 2.32 seem to have many "issue" and as my project is actually in a good step, i choose (you can read it in the topic) to w8 till the version seem stable.

Leadwerks is cheap, because Josh didn't need to pay many testers or programmer (i think he is still alone) so he simply can't find any bugs any time he make some changes, we should help him on this, also as i know he asked for money just only for the big update from 2.28 to 2.30, many other engine will ask for money EVERY big update they did.

In past i was complain for the few of FPS this engine had so i dropped it, few months ago i come back and i am happy to see the engine is faster then before (also i didn't test 2.32 where Josh said is even faster in some cases), so i'll suggest you to think twice before dropping a project, Leadwerks is a nice tool.

[Marleys Ghost]

so i'll suggest you to think twice before dropping a project

 

 

The project is not dropped, just not being developed in LE. This has been based on the last seven months and not just on this one particular issue.

[Joh]

Ok you know your needed. Good luck!

[Guest Red Ocktober]

i think you might be missing the point that Marley's trying to make here J...

 

it's not so much of a matter of Leadwerks being in constant state of upgrade, we're all kind of aware that this would be the case for a while until LW had matured a bit more...

 

and, it's not so much a matter of Leadwerks being cheap... not to harp on semantics, but i'd prefer to call it inexpensive as opposed to cheap...

 

and the fact that bugs weren't all resolved prior to release isn't the issue either... a certain number of bugs are to be expected with any release...

 

i think what he is trying to point out, and i have to agree with him on this... is that we've had to track down faults in existing code that worked prior to a new version release, only to find that it is the result of an arbitrary, non announced change in the core LW code for almost every update as far back as i can remember...

 

now, while this was totally understandable in the early stages of the game, it is getting to the point now where some pretty mature projects are being developed... and this sorta thing becomes more and more 'distracting' for anyone who has a serious LW project being worked...

 

not only has existing code been invalidated... physics resources had to be regened... editor functionality gets changed without warning...

 

and finally, as far as this entitypick issue is concerned... allowing a function to accept an invalid argument, and not returning usefull infomation if it does... well, if i was in the habit of doing that when i was employed as a paid coder, i doubt if i would've been around for very long...

 

 

when an issue is brought up... i think it should be taken seriously... not passed off or disregarded as beeing a 'real' issue... new testimonials are nice and all, but that's not what's gonna help at this stage...

 

i love the scenes that we can create with LW... puts me right up there with the likes of devs who use UDK, Crysis, and other AAA tools... but the bottom line is that there has to be some sorta consistency from update to update... having to spend days, and in some cases weeks redoing assets that worked in previous releases is something that is going to become increasingly intolerable...

 

 

--Mike

[Joh]

As i understood Josh didn't change any documented code.. So you can't complain.

You should use only documented command, if you don't be ready to modify your code.

I would agree with you if some documented command changed, i was when animate command was changed.

[Guest Red Ocktober]

As i understood Josh didn't change any documented code.. So you can't complain.

You should use only documented command, if you don't be ready to modify your code.

I would agree with you if some documented command changed, i was when animate command was changed.

 

then you'd better look again J... lua object.render() function was arbitrarily changed to object.draw()...

 

and saying i should only use documented commands is all sweet and rosey... and i'd love to... if you could just show me where this archive of up to date documented stuff resides...

 

 

--Mike

[Joh]

then you'd better look again J... lua object.render() function was arbitrarily changed to object.draw()...

Didn't see this and i agree with you this shouldn't be changed.

 

and saying i should only use documented commands is all sweet and rosey... and i'd love to... if you could just show me where this archive of up to date documented stuff resides...

As far as i know there is a wiki where command are written. http://www.leadwerks.com/wiki/index.php?title=Main_Page

I find there almost any command i search.

[Guest Red Ocktober]

well... if you're gonna be using the wiki as your definitive source for documented functions, and to determine which ones are undocumented... pleasse explain to me how you can consider Marley's issues as referring to undocumented functions...

 

i mean... all the functions he referred to above seem to be 'documented' in the wiki...

 

i think you're missing the poibnt here... it has nothing to do with documented or undocumented... code that is working perfectly is suddenly invalidated=something has changed...

 

plain and simple...

 

and i think that's what he was trying to say...

 

and i think he was correct...

 

 

--Mike

[Joh]

Entity.parent is undocumented and this is the cause of his issue.

[Guest Red Ocktober]

i dunno where you're looking J... but do you want me to post a screenshot of the page i'm looking at...

 

http://www.leadwerks.com/wiki/index.php?title=Entities#Classes

 

and entity.parent refers to a property, and not to a function... so referring to it as an undocumented command isn't quite right either... would you agree...

 

 

--Mike

[Joh]

mmm you get the point.

It's documented.

[Guest Red Ocktober]

that's what i've been trying to tell you all along... it IS documented...

 

so what did you mean when you said...

 

Entity.parent is undocumented and this is the cause of his issue.

 

 

--Mike

[Joh]

Well that's all i simply didn't seen that part of the page, so "Entity.parent is undocumented and this is the cause of his issue" it's wrong.

[Guest Red Ocktober]

Well that's all i simply didn't seen that part of the page, so "Entity.parent is undocumented and this is the cause of his issue" it's wrong.

 

well... now that you do see that part of the page... and i'm gonna assume that you've read and understand what it says...

 

can you conclude that it didn't seem to be wrong in 2.31... i mean, it was working quite well back then... wasn't it...

 

so looking at it now... from an objective perspective, the cause of his issues isn't the fact that 'it is wrong'... but that 'it has been changed'... or that something has been changed...

 

which seems to be exactly what he was saying... right...

 

 

--Mike

[Joh]

My sentence was wrong.. I am telling that i haven't seen that page so what i was telling about undocumented commands is wrong.

[Guest Red Ocktober]

so... in other words... Marley's complaint appears to be a valid one then... right...

 

 

--Mike

[Josh]

so... in other words... Marley's complaint appears to be a valid one then... right...

 

 

--Mike

Not completely. Although he did point out the filter was being called on entities that weren't pickable, he just happened not to run into any problems with version 2.31, the way he was using it. A single mesh in the scene with no parent and the right collision type could have caused a crash in his program. It's a good idea to always check if a parent exists before using it.

 

So there was some small error on both sides, and now it's fixed.

[Guest Red Ocktober]

Not completely. Although he did point out the filter was being called on entities that weren't pickable, he just happened not to run into any problems with version 2.31, the way he was using it.

 

that may be true Josh... but the exact same code that was being used in 2.31 caused the problem to fault out in 2.32r, which means that something internally was changed... that's the point i think he was trying to make...

 

what he might've done... what he could've done... both are irrelevant...

 

what he did do, and what others will do... is use existing code and assets that they've had working before... with the reasonable expectations that it's gonna still work...

 

trying to pass this off as something that didn't happen is wrong... especially since this guy is out there trying to help with the transition to the new release...

 

to be purely objective... i must agree with the issue he raised... and i also wonder...

 

first of all... how are you gonna completely invalidate a function call that's being used... wouldn't it have been better to merely deprecate the old function and add the new one... maybe having the old one call the newer one...

 

second... the call itself should return something to indicate that this sorta logic fault occured... don't ya think...

 

 

even if he wasn't 200% completely... the point he raised was 150% valid...

 

come on man...

 

 

--Mike

[Joh]

I understood your point (after a "few" posts) and i can agree with you.

But in the same way i agree i need to understand Josh.

Take for example the animate command, i was complain for the change but he change it to improve it.

The render to draw (lua) it was done probably to improve the visual languages.

Probably this change was made to improve the engine itself and as i see neither him was knowing this, so how could him tell us of the change if he doesn't know it?

I have more or less 32 files of code (probably more then 15k lines) for my project i know i'll probably need to check the whole code to seek some bugs that there wasn't before, but i assume Josh have more lines then me and he obviously doing his best to don't change anything. Some time simply you can't.

 

Told this i am out of discussion, this is my thought please accept it as i accepted your.