macklebee

yeah the heathaze issue with water is a known issue... its in the bug tracker... basically don't mix emitters with water... my problem was i was getting that with no water in my scene... i am trying to do a clean install in hopes that it magically fixes the issue

ok... so maybe something got corrupt today with all of my sync's... hmmm... ok I will try a clean install and see if that fixes it... friggin bizarre

The heat haze doesn't render correctly. I am using the new framewOrk + lua-gluefunctions.bmx. This worked fine before this last update. Here's the program with model/materials/whatnot zipped up. HeatHazeIssue Also note that there is a corona to the left of the firepit that doesn't render either. Haven't looked into that issue yet, just thought i would throw it in there because that is new too as of today...

yep, i will post something in one second...

also now, the heat haze from the firepit doesn't appear to be rendering correctly in bmax. Looks fine in the editor but wrong in the program... edit--- the forum won't allow me to attach a 15kb pic...

you are not a bmax user so it doesn't really affect you concerning the framewErk module... People are just asking why all of sudden did something as arbitrary as wErk get changed? Something other than its not cute anymore as an answer. Its frustrating and annoying when your code wErks just fine one day then the next day it crashes because of some minor update. I don't think its too much that people ask why it was changed.

? did Josh put the framewErk into the 2.28 DLL? I think its only in the 2.3 dll...

why does your SetKey and GetKey functions have three parameters? return self.super:SetKey(model,key,value) return self.super:GetKey(model,key,value) shouldn't it only be two parameters, key and value?

i don't think josh was wondering what osx implied i think he was asking how this change would effect any future plans for osx...

that looks familiar! also did you fix the vector.lua script as well? also, the RestoreDefaults function for the visibility is wrong... you are still calling a Vec2? ok.. i think i see whats happening... you are setting values that have to two components as Vec2's but the framewOrk items that used to use Vec2's are now using floats? wait... what?

oh please... you were just complaining in another thread that Josh needed to add a key in a INI file for you...

ok... so apparently there are differences between framewOrk and framewErk. I have no problems with the change except the fact that it wasn't announced. And it seems pointless now to use the framewErk module, since its not going to be updated.

well, before 2.3 you had the key "classname" inside the INI files... now its not there or the INI file doesn't exist for all entities... but yes, exactly... its just a key. Also, whats going on with Vec2's? they seem to be different as of last night's sync.

nice. well no reason to sync atm... something is screwy right now... well more than usual

not disagreeing with you one bit... it should be optional. I was just curious on how you were handling the fact that the Editor uses scripts to handle stuff and your program does not... So I assume that you do not even bother with putting entities like the atmosphere, emitters, waterplanes, in your editor scene then? Since all of those things you are saying that you are going to control by your code... I am just curious on how you handle it... because at the moment, I am getting tired of the lua only working in the editor as well.

if you look at the old 2.2X LE, the standard entities all had the classname keys inside them. This is not the case for 2.3. So add it to the friggin INI file yourself! I don't understand why you expect Josh to do that for you... yes, it would have been nice if it already came like that... but sheesh, Josh has alot of more important things to work on than to add one line to a text file for you...

no problem... i didn't realize you did not understand my post above... i see that you had asked about it, but i missed it.

so add it to the ini file for that entity if you cannot be bothered to change one line in your code and if you are not going to use lua at all, then are you going to delete the lua scripts for all of the standard entities from your game? how do you rectify working in the editor versus what is in your game? use scripts in the editor but not in your game? seems like that would be difficult to do... or at the very least it removes the WYSIWYG feature of the editor...

Found the issue... for some reason the scripts/math/vector.lua script was screwed up... In the StringToVec2 function, this line: return Vec2(x,y,z) needs to be changed to this: return Vec2(x,y) and this allows the underwater to be seen correctly in the editor... still working on what the issue is outside of the editor ok... along with that, it still seems something is amiss with Vec2's in LE. I ran some old bmax code that actually set the water properties and it started failing at the framewOrk Vec2's... This code worked just fine the last time I ran it. To get this to work again, I had to use the components of the Vec2... Also, even with the above change to the vector.lua script, I forgot that I had to also change the waterplane script. Inside the Refresh function, this line: fw.renderer:SetWaterVisibility(self.visibility) needs to be changed to this: fw.renderer:SetWaterVisibility(self.visibility.x, self.visibility.y) Whats going on with the VEC2's in LE?

And my point is that there is no difference between getting the child of scene by finding a particular classname key as compared to finding a unique key for that child... if you are that hung up on some arbitrary keyname, then just add it to the INI file for each entity that you wish to parse in the SBX file... but in any case, if the lua scripts worked correctly you shouldn't have to parse anything in the SBX

how is using another key other than classname a hack? classname was just another key given to a an entity... in any case though, i agree the lua scripts need to be fixed to actually work outside of the editor correctly.

when is the last time you sync'ed Michael? because I sync'ed last night and I have the same problem as MG

thats why i told you above that the position of a pick is pick.position with pick.position.x, pick.position.y, and pick.position.z as its components... there is no pick.x. pick.z...

i don't think anyone thought you meant that... at least i didn't.

I could be wrong but I think he wants each drawer model's origin/pivot to be its rear center. And then the desk model will have 6 pivots located where the drawers origins would be if they were closed in the desk.