Josh
-
Posts
23,217 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Josh
-
-
Agreed. What have you been hiding?
-
But to be a little off-top, I keep seeing the misconception that hammers and feathers fall at the same rate in a vacuum. Which would be true if the objects didn't have mass. But a Hammer or Piano has a substantially greater gravitational field than a feather. They would actually fall faster, just not on a scale you would notice. But it's important if you plan on throwing large objects at nearby planets.
More force does not mean greater speed. More force is exerted, but because the heavier object has more mass, more force is required to move it. Barring air resistance, a heavy object and a light object fall at the exact same speed. When you consider air resistance, the shape and mass of an object become factors. For example, a person wearing a parachute is much heavier than a brick, but the brick will fall faster.
-
I'm not sure I understand this. Maybe you should consider logic entities, where you are basic dragging an If statement into the scene.
-
It's the same in 2.28.
-
Nilium does know a lot more about Lua than I do.
I'm not sure if Lua can pass a pointer to a table back to the main program. Everything I have searched for and read indicates otherwise. Maybe there is a way, but I couldn't figure it out. In the end, the way I ended up associating a table with a BMX object was to put them both into a Lua table. That's why every function starts with a lookup in the entitytable to retrieve the table associated with a model.
-
-
Sorry for the delay, I didn't have access to the this forum. Recast is NOT my work, I've intergrated the library with Leadwerks. Recast is the work of chap who did the AI for crysis, so fairly good pedagree.
This game?:
Sorry, couldn't resist. This looks really interesting. Maybe I can integrate it into the engine.
-
Default gravity in the engine is -9.8 units/s^2.0. Gravity on Earth at sea level is -9.8 meters/s^2.0.
Since you can change the gravity value, it's all relative, but I recommend using 1 unit = 1 meter. However, you should understand there is no such thing as real units in a computer program. One spatial unit could be an inch, a meter, a mile, or a light year. One weight unit could be a gram, a pound, or a ton. It's all relative.
Gravity affects all objects the same regardless of their mass. A piano and a feather will fall at the same speed in a vacuum.
-
Good point.
-
The jury has spoken.
-
Aye I did see that in the Wiki. Though I worries me a bit that there is in fact just an on/off switch. How does one modify the features? For example, bloom/HDR appear to be a little too over-bright by default. I understand the idea is to simplify the whole process, but I do think I'll require at least a little customization.
That's why you have the source.
How do you see things evolving though Josh? Do you have a 'perfect world' design paradigm or have you included LUA primarily as another language to use such as BlitzMax or C++?Lua is just another language to access all the same commands with as you do in C++, C#, or any of the other supported languages. However, it is a free easy to use popular language, so supporting it gains me a lot of new fans. It can also be used with other languages on a per-entity basis.
If you're comfortable with C, you've got everything you need already to make a game. A problem we found is that people can get through the tutorials and understand everything, but still don't know how to structure a game. And my response has always been that I can't write their game for them. With Lua, yeah, to a degree I am writing your game for you. But everyone is writing functionality, and it's easy to mix and match components.
So it depends on your skill level. Some people use C++ and make games. Some people use BlitzMax and make games. Some people say they want to use C++, but they have trouble making anything with it, and are better off with Lua. Some people just like Lua because it is fun. My personal preference is BlitzMax, but I am finding Lua to be a lot of fun.
-
Framewerk handles all the effects. You can implement them yourself one at a time, but it is difficult, even for me, to get all of them working together. So most people just use Framewerk instead of struggling with basic rendering effects. It handles DOF, water, bloom, HDR, god rays, SSAO, and a bunch of other stuff, with simple on/off behavior.
Lua is quite new, and the integration with C++ is something we have to explore further. This will evolve, but I would not start writing a large amount of code in Lua just yet. I think it is possible to expose all your own C++ classes to Lua and call engine and C++ functions from the script, but we still need to work it out.
-
This is presently not supported, but rest assured it will be soon.
-
Hooks
in Programming
It just means you can turn functionality on and off with a single include file.
-
I think you will find the results are not as good when you try to apply a texture to fade them along the length, when a cylinder is used.
-
Hooks
in Programming
You can add update loops to the main loop while keeping all the code contained in one file.
Let's say you include a script that has to update something every frame. Instead of adding extra code in the main loop, you can add a hook in the included script, and that way you only have to include a single file. It just makes it easier to mix and match components.
-
Hooks
in Programming
What do you think?:
AddHook(hookname,function)
RunHooks(hookname)
Example:
AddHook("UpdateHook", UpdateBullets() )
AddHook("UpdateHook", UpdatePlayers() )
Then somewhere in the main Lua loop:
RunHooks("UpdateHook")
This can be coded entirely in Lua. Does gmod do anything fancier than this?
-
I would. Load it from a file so it is instanced. Or you could create a mesh manually and copy it for each tracer. I don't think you will ever have more than 10-20 onscreen at a time, so performance isn't a concern.
In the final version, I would have a cache of tracer mesh instances you just hide and show as they are needed, instead of creating things dynamically, but there's no need to worry about that until the basic version is working. Oh hey, here's one example where a single lua state helps, because the tracer cache can be shared across multiple guns.
I think your hook suggestion from gmod is a good one, too.
-
Why would you want the particles facing up? If you looked at the particle from the side it would become invisible. You want it to face the camera, and be aligned in the direction of travel.
Is there any particular reason you want to use a particle emitter for tracers? It seems like an individual mesh would be easier to control.
-
I'm all for this, but is it really that simple? Won't you run into other issues with how lua scripts are currently used? entitytable for example will now be global and all entities loaded will be in it not just the entities local to one class model. Plus all scripts currently need to dofile() to base to use constants and stuff. That won't be needed because it'll only needed to be called once to load all that stuff.
The base file can be called once by the main program, or can be placed in the start folder. The entity table would be global, but it's easy to iterate through all instances of a model. Undoubtedly some small changes will have to be made to the model scripts, but we're still in the stage where that is acceptable.
I don't want this to happen. My vote is no.Can you elaborate why?
The biggest disadvantage of the multistate system is when you have tables that have to be shared, it is impossible. We might be able to get around that for a long time, but I have a feeling it is going to come back and bite us in the future. For example, if I want to tell if a vehicle's wheel is on the road, I would want to be able to call a function from all nearby road entities that would be written in the road script. That's where it gets ugly, and I am afraid we will run into more cases like that as we make more complicated games.
I won't do anything to the official release until I am sure this is a good idea. If I pursue this, it will start by posting some test versions of the interpreter so we can play around with the idea.
Like I said, I don't like making changes, but if we are going to, it should be done now while it won't hurt anything.
-
Well you have two vectors to think about. One is the direction of the bullet. The other is the direction the camera is facing. You might want to solve this on the CPU, because it is a rather tricky problem to get right. You should be able to point the tracer in the direction the bullet is moving. Let's say the z axis of the tracer mesh is aligned to the bullet's velocity. Then find the camera xy position relative to the tracer and align another axis of the tracer to this vector. Fortunately the AlignToVector command lets you align any axis. Make sure you fill in all the parameters of this command, because they will all be 0 if you don't supply an argument.
-
I can see already Lua is being very well-received, and it looks like some serious work is going to be done with it. I did not plan on making any revision to the system, but if we are going to make any changes, it should be done now, not later.
I do know a way I can use a single state and still have our same function name conventions. Internally, the engine can just do this string before loading a new class script:
Spawn=nil InitDialog=nil Update=nil ReceiveMessage=nil
Then let's say light_directional.lua is run. After that, this code can be run silently by the engine:
light_directional_Spawn=Spawn light_directional_InitDialog=InitDialog light_directional_Update=Update light_directional_ReceiveMessage=ReceiveMessage
The engine would then call the functions prefixed with the model name, like light_directional_Update() instead of Update(). You could still call the functions the same thing in each class script, but the engine would be able to differentiate between them.
Consequences:
-You can access lua functions across scripts.
-You can't call Update(), etc. yourself because the functions are internally renamed.
-You have to clean up everything in the Cleanup() function since the state won't be deleted when all instances are cleared.
-The Lua virtual machine will get bigger and bigger as more model classes are loaded. Maybe I can set all the class functions to nil when the class is deleted.
I initially thought Lua would be good for tinkering around with and making some cute demos, but it looks like people like it and are very capable of using it. A single-state system might be better in the long run, and it's not that big of a revision.
-
Use TFormPoint and TFormVector to transform the position and force from local to global space.
-
Extra is a BlitzMax object, which includes strings. It cannot be an integer (unless it is converted to a string) or a Lua table.
2.3 DrawLine
in Programming
Posted
The speed of drawing a line is not a bottleneck. The command you wrote is the same thing the engine does internally.