macklebee

no problem... until something better comes along its basically the best solution right now. While it is a pain, I have a hand full of them of various shapes and sizes that so far have suited my needs.

didn't say you didn't have a right to an opinion... i said your POV of the problems and frustration people are having is hindered because you haven't been affected like alot of people that have been here for quite awhile...

Kevin, I know you and alot of people here have basically only been using LE since what 2.30? Your POV is hindered because you haven't been around long enough. The problem alot of people that have actually been here for awhile is changes making previous working code fail is not a new thing. These things keep happening over and over every new release. The previous releases forced people to completely update their projects if they expected to get a bug fix. Hopefully this will not be the case from now on and Josh will fix the current version's bugs before releasing a new version. This way it will be up to the user to decide if he wishes to upgrade his project for whatever the new version has for features or leave their projects in the previous version that is bug free. I think alot of the unhappiness and frustration (at least for me) with LE over the last year or so, could have been avoided if bugs were fixed for the current version instead of forcing people to update to a new release just for bug fixes. Hopefully this will be the path taken going forward.

I vote for GMF2PHY conversion. Having to create an OBJ model file just so I can have a model that reacts to physics is a pain in the arse and seems an unnecessary step for asset creation. yeah, that makes absolutely no difference. Something the size of say a grenade when launched and hits the terrain just right will cause it to fall thru the ground. I know the answer is that this is supposedly a problem with any physics engine, but honestly I cannot recall the last time I played an fps game where this happens. Actually I have about 30 scripts that have to be rewritten because of this. I know your intention is to make things more user friendly but its changes like these that annoy the hell out of people. And they have to upgrade their projects to the next release, because before now we couldn't get bug fixes unless we upgraded. I think the rule going forward should be fix the current bugs before any new releases. This allows people to make the decision to either move their project forward to the newest release or just live with the current version thats bug free for their intentions.

thats good news. Thats actually how these things should have been handled from the get-go: No releases until the current version is stable and bug free. Also helps people that do not want to upgrade their project but have to just to get a bug fix.

so i assume this means the destructable physics/objects will not be implemented? The new PHY format will still require us to change all of our assests' physics files or will there be a method in which this will automatically be done? Or at least a way to minimize the amount of effort and time to do this? How are you going to address issues with objects passing through each other? Hopefully better than what Newton currently does...

if it happens that way... history of how the later versions of 2.2X were handled suggests otherwise... but we will see.

Why should you be able to read the moved position of a model before an UpdateWorld() has occurred? The last time I checked that was one of the purposes of UpdateWorld(): and i still do not see the connection to why these two files are back in the SDK.

forcing people to have to use blender to have this ability is not ideal... i'd prefer for this to be handled inherently inside the editor... if SDK editors for games 7 years ago could do this, there is no reason LE couldn't eventually be able to do this...

we do have this already in a round-about way... see GetEntityAABB in the wiki

yes, i do not see this being fixed until josh implements csg modeling into the editor... seems like that would be the most obvious and easiest method to create triggers of any size...

weird... i cannot reproduce that at all... i get shadows from the crawler/zombie in the editor and from a standalone lua game... and i do not see anything wrong with the zombie either... perhaps it isn't an issue with the zombie but rather the room that you have him... what is the material file for the room cocopino?

I noticed the base and baseclass lua files that were used when we had multi-state lua are back. Is there a particular reason for these files to be used other than the class lua file that was introduced with single-state lua?

I do not use EntityDistance; I just use simple shapes like cube/sphere models then use the collision callback on them. I use the property dialog to set the model's material to make it invisible for gameplay.

require("Scripts/constants/engine_const") RegisterAbstractPath("") Graphics(800,600) fw=CreateFramework() scene=LoadScene("Maps/deserthighway.sbx") PositionEntity(fw.main.camera, Vec3(1140,157,-444)) RotateEntity(fw.main.camera, Vec3(4,83,-8)) while KeyHit(KEY_ESCAPE)==0 do fw:Update() fw:Render() if KeyHit(KEY_F)==1 then fw=CreateFramework() scene=LoadScene("Maps/test.sbx") PositionEntity(fw.main.camera, Vec3(0, 2, 0)) end SetBlend(1) DrawText("Press F key to switch worlds", 0, 20) SetBlend(0) Flip(0) end if you run the above example in 2.31 and 2.32 you will see that 2.31 frees/deletes the previous scene, whereas there is no mention of this in 2.32's log... it appears to give the same result, but now i am not to sure its actually clearing out the scene...

are you sure its ClearWorld() you want? you used to be able to just create a new instance of CreateFramework() and it would automatically free the world and all its objects and let you load a new scene... but since that has changed in 2.32 and of course there is no documentation of it being changed or why it was changed... it appears to still work, except I am not sure everything is being freed since there is no mention in log whether its deleting the instances or freeing the classes anymore...

got it...

I wouldn't load the mesh in the main loop but in the initial setup. Why are you loading the mesh twice? Is it "vwep" that you are trying to hide/show? if so just do: vwep:Hide() and vwep:Show() toggled by if the variable showthing is equal to 0 or 1.

wow... you people refuse to actually read his post. something had been changed and he was asking why and what... Ziored, you havent been here long enough to understand that this is not an uncommon occurrence... once you have to go back and change working code several times over the next few releases then you will understand.

i thought we had a icon for cameras now? can't you check something like helpers in the Editor properties dialog to show these even when they are not clicked on? i do not have access to LE for a couple of more weeks so i cannot confirm personally...

looks good Red

Lumooja, just hush. He is asking a legitimate question and you do not know the answer to it. Your ramblings telling people to use gamelib is not an answer to the question. The only person that can answer his question is Josh. And he is not the only person that has issue with this constant redoing perfectly working code every time a new release comes out. If something like this gets changed on how it functions for no obvious reason, it gets quite annoying to constantly go back and redo code that worked just fine the previous version.

notepad

Do not run object scripts. Only save object scripts then add the object into the world. You can run gamescripts like driver.lua or fpscontroller.lua in the editor. Or you can run standalone scripts like example1.lua from the Script Editor located in the SDK root directory. and by the way, my way is better than Josh's example because it actually sets the properties dialog as well as setting the collision type.