TylerH

I am in 100% agreement. Though I think the way the community can spearhead this, if not done by Josh (whom seems interested ), is to go ahead and start making some of these objects. You made a 3rd Person Camera; if someone makes a First Person Camera, then someone else can make a First <-> Third person camera that you can switch between and change elevation angle via mouse wheel, and the list just goes on from there...

Because I made the modified base.lua 3 days before I made math_counter, in an attempt to expand the base of the framework to support a Hammer-Like Input/Output system. Ofcourse.

No problem. I have to leave, computer class is over, I shall return when I get home

"works", as in I tested it and it seemed to work? I didn't doing anything extensive, I just played around with different ways until I got a combination that basically made my entity editor interactable, but not game-interactable.

You don't really need the custom base.lua file, you can just move the implementation of entity:RelayMessage into the math_counter.lua script itself.

invisible=1 in the .mat file is always helpful. Using a Null mesh also works. Collision type of -1 works too.

Someone wrote a shader that let you do this, but just not in the editor.

Bump. Feedback please?

I can definitely do that for you then Just chat with me on MSN again, and I can set up your script to have the properties grid and proper settings for the animation.

I tried starting this, but no one has commented on my math_counter object, and almost no one has downloaded it. I know how to fix the problem you are talking about with the models too, but also, no one has spoken to me about it since I mentioned heading up this project. So PM Me, talk to me on MSN, or respond in my math_counter thread, and I will shed some light on it.

Yeah, I use LinePick extensively in Weaponwerks, for obvious reasons. You simple create assign a variable to the return value of LinePick, it will be a table with the following values: local pick = LinePick(...) pick.entity (TEntity) pick.surface (TSurface) pick.position (vec3) pick.normal (vec3) pick.triangle (number)

Could you possibly share how you did it? I would like to add explosives to Weaponwerks as a native projectile type

I think you can easily use CreatePlane to make a smaller waterplane, just not sure if it will work or not.

Screen Space Depth Occlusion? ... Dynamic Occlusion? ... hmm.

Yep, I was able to push that up to 120 bullets on screen, running bullet logic, keeping 60 FPS. I also made the gun shoot a non-tracer bullet by default, and will be implementing some logic for either every nth bullet being a tracer, or a tracer is fired to let you know you have n bullets remaining (i.e. either every 4 rounds, or say when you have 5 rounds left in the current clip). I also implemented colored tracers, so if you want crazy looking tracers, they will be as easy as setting weapon.TracerColor

It was fun to remove the ricochet count and angle checks, and just have 12 bullets flying around making ricochets forever. With 12 on screen, I got about 30 FPS, down from 60 FPS, which is believable, for the amount of math I am doing per bullet. Needless to say, I already know about 5 ways to optimize what I have currently, I already made a few changes and gained loads of frames I didn't know had ever been lost

I have successfully implemented hierarchical bullet ricochet, skimming, and skewing. Right now, the system will use this little bit of code: -- Process ricochets if they should still occur if (bullet.ricochetcount < 3) then local I = bullet.velocity--Subtract3(pick.position,bullet.origin) local N = pick.normal--:Normalize() local angle = 180 - math.deg(math.acos(Dot3(I,N)/(I:Length()*N:Length()))) if (angle < (60)) then return end local R = Subtract3(I,N:Scale(2 * Dot3(I,N)))--:Scale(bullet.velocity:Length()*HOST_TIMESCALE) local ricochet = CreateBullet(pick.position, R, Vec3(0.0,0.0,0.0), ricochets) ricochet.ricochetcount = bullet.ricochetcount + 1 end Which grabs the bullet velocity (our incident vector), the normal of the surface we hit (the normal), calculates the angle between these two (which will be obtuse, so we subtract from 180 to get an acute angle that is easier to run comparisons on relative the bullet and player). Presently it is hardcoded to ignore impacts for ricochet if the incident angle is less than 60 degrees. To explain, when you think of a protractor, where the far right flat line is 0, as you move up towards the top is goes from 0 to 90 , this is backwards of how the system works. The Normal is 0 degrees, and as the bullet angle towards the impact point gets close to parallel with the surface that the normal is from, it gets closer to 90. It is checking to see the angle between the normal plane of the object you hit, and the bullet velocity. This has worked and given realistic results (minus that I didn't add friction, velocity fall off, etc. physical effects), and appears to be how this would work in real life. The next thing I want to work on is bullet penetration through surfaces, but I am not entirely sure how this is done, and wouldn't mind some suggestions or ideas on how to do this.

Lumooja has the right point here. I knew of GetBodyOmega, which is just angular velocity. GetBodyTorque should be implemented such as he said.

I think Enabling swept collision should fix, if not simply aide those problems.

I think GetBodyTorque?

Thanks, I had forgotten the TFormVector to make sure the forces are local. Falloff as well, as that makes it more realistic. I do the same thing with the bullets in the Weaponwerks library.

In regards to the kinematic thing, you want to make the player not be affected, but affect other things?

You need to do a ForEachEntityInAABBDo on the mine, and run the a function to add massive amounts of force in vectors equivalent to the entity's position minus the mine position. Basically: for each entity in the bounding box (radius or whatever) of the mine forcevector = entity.position - mineposition AddBodyForce(entity, forcevector*500) // 500 is your force scalar or whatever repeat

Nevermind, I read the list of how it works, and that seems to be how it works. This sounds good.

Well, what I mean is, I didn't mean physics exactly. Is the animation actually MOVING the mesh and the entity's position in terms of what Leadwerks interacts with? Because if not, it is pointless.