Josh
-
Posts
23,313 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Josh
-
-
I thought it seemed sort of redundant when you have the member itself to access.
-
That's true.
-
Thanks for making this. I added it to the sync folder.
-
Right.
-
Okay, there is a confirmed bug where the roads don't construct properly when meters per tile is other than the default value. The number 2 is probably hard-coded in the script somewhere, so I will find it.
-
How do I produce this result?
-
-
The world has a list of entities. You can also look for a specific class in the classnametable:
local class=classnametable["light_directional"]
-
Messages with zero delay are sent immediately.
-
Try this:
fw.main.camera:SetMatrix(object.cameraPivot.mat)
-
It looks like the filter needs to be moved to the end of the line, or added in the water shader as well.
-
Not free, but good:
-
This command has been added to the DLL. It is experimental. It will return the lua state used in the engine.
You might be able to import the lua library and perform commands on this variable. I don't know if it is okay to access one lua state with a separately intialized instance of Lua. If it isn't, then eventually we will expose the whole Lua command set through the engine DLL.
-
entity.matis a member where the matrix can be accessed.
Rick, I need more information from you. I don't know if you are running something in the editor, a scripted app, a C++ program, etc.
-
I think NVidia pursues these kind of things to raise their stock price. There is no way they are making a profit with this product, but it gives them something to show off and reinforces the idea that they are the leader innovating new technology. Cuda, PhysX, 3D vision, all of these projects lose money but they make NVidia look better to technically ignorant stockholders. When you see these grand web pages on NVidia's site talking about some new technology, it isn't aimed at the consumer. They are courting stockholders and potential stock buyers. After thinking about it, I really believe the decision to pursue these things was based on the desire to raise stock price even though it lowers profits. It's not really a good or bad thing, but it would be a mistake to get suckered into technology the proprietor themself doesn't even believe in.
-
We already have mostly procedural environments. You can distribute grass and trees based on certain parameters. You don't have to paint every spot of ground because you have parameters for the different layers. You can generate the terrain in L3DT and get a procedural heightmap.
The dream is an infinite world with easy tools to procedurally generate most of it, then go in and adjust the things you specifically need by hand. That's pretty close to what we have now. But the whole streamed infinite world is a developmental nightmare, especially for an open-ended engine not locked to a simple racing genre.
So let's make the most of the mature technology we have now, and everything we develop in the current engine might someday be useful in a version 3.
-
I don't have any such errors with those objects, and Lua is much less prone to hardware differences than graphics are.
-
The Lua command DoFile() simply executes all the code in the specified file. Require() only executes the code if it has not yet been run in the lua state. With a multi-state system this is not much of an issue, but in a single-state system it has a few ramifications. Let's consider the light_directional.lua class script. Pretend we want to make a change in the class.lua script and have this change seen by re-saving the light_directional script. We make our changes to class.lua and save it. Then we re-save the light_directional script. The changes in class.lua will not be apparent, because the light_directional script calls Require(), not DoFile()! The lua state sees that class.lua has already been run, so it doesn't bother re-running it.
There is a way around this. Simply open the integrated script editor and type in "DoFile("Scripts/class.lua")". The script will be re-run. Then you can save light_directional.lua and the changes in class.lua will be apparent.
Re-running a script will re-create any tables that were created in that script, and any values added to them will be lost. So if you were to run a script like core.lua, where the class and object tables are created, the results will be unpredictable.
Hopefully this helped you to understand better how scripts in the engine work. Remember, you can always save and reload the scene if you think you did something bad to the lua state. Live programming is by its very nature a touchy matter, so if you are doing "heavy" coding you might want to stick to the standalone script editor until you have something stable.
-
FileSystem.lua
-
Ah, you are right. I uploaded your fix to the server.
You can probably guess what happened. I used to call the Refresh() function Update(), but then changed it because I didn't want it called each frame.
-
Well, for terrain at least it makes sense. I bought Fuel. What an amazing game. Can you imagine if they had made an FPS with that?
-
What would commented-out code you add to template.lua have to do with the waterplane script?
-
Yes. The environment_atmosphere script uses it.
-
I played this game on the PS3. When the car hits that ramp and knocks over the tower, the ramp has an animation that makes it "fall" on a pivot, but the tower is completely solid. Unless I remember wrong.
I actually bought this game and studied it a bit because someone was interested in having us design something similar, but it didn't work out.
lightimg problem
in General Discussion
Posted
It sounds like perhaps some files got moved around and you are loading an older version of the script? Double click on the class node of the pointlight and see what the script is.