[SendMessage timing]

You can code your own system in Lua that works instantly. If I can assume that if I grab an instance of ANOTHER script in a given entity's script, can I access the members defined in the OTHER script? Or does this multi-state setup prevent that currently?

 

The single-state would clearly let you setup a global message system simply in Lua using an Input/Output structure like in Hammer.

 

function entity:FireOutput(output,value)
	for k,v in pairs(self.targets) do
	v:FireInput(output,value)
	end
end

 

The above would be instantaneous, because you are directly calling a function of the receiver from the sender's script. Hammer/Source engine does this EXACTLY in this way, except via C++ functors/callbacks, not Lua.

[base lua file proposal for Josh]

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...

[math_counter (Test Entity)]

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.

[logical entities and their "models"]

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

[logical entities and their "models"]

"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.

[math_counter (Test Entity)]

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.

[logical entities and their "models"]

invisible=1 in the .mat file is always helpful.

 

Using a Null mesh also works.

 

Collision type of -1 works too.

[Vertex painting in editor]

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

[math_counter (Test Entity)]

Bump.

 

Feedback please?

[Need one or two .lua scripts]

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.

[logical entities and their "models"]

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.

[LinePick]

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)

[Simulating a shockwave with Newton]

Could you possibly share how you did it?

 

I would like to add explosives to Weaponwerks as a native projectile type

[more arch-vis, more questions ;)]

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

[What makes this terrain look good?]

Screen Space Depth Occlusion?

... Dynamic Occlusion?

... hmm.

[[WIP] Lua Weaponwerks (Now with video!)]

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 n^th 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

[[WIP] Lua Weaponwerks (Now with video!)]

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

[[WIP] Lua Weaponwerks (Now with video!)]

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.

[Calculating torque in LE?]

Lumooja has the right point here.

 

I knew of GetBodyOmega, which is just angular velocity. GetBodyTorque should be implemented such as he said.

[Animation driven character movement]

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

[Calculating torque in LE?]

I think GetBodyTorque?

[Simulating a shockwave with Newton]

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.

[Animation driven character movement]

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

[Simulating a shockwave with Newton]

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

[Animation driven character movement]

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

 

This sounds good.