Spectator.lua

[megabyte]

The Spectator.lua script makes any players on yellow team able to passively watch the game without interfering. They wont be visible to the other players and will not be able to block bullets or interfere in anyway. they move using the the turn/look keys(or mouse) and the left and right triggers to move forwards and back. Just remember that all players on yellow team will spectate.

Download Here

[treellama]

Gross.

[megabyte]

How so?

[treellama]

Well, it sets players to invalid positions, which may break some day. It doesn't handle 5D space. Sound is broken. Lua cameras are currently buggy.

For spectating, just killing the player, and rerouting his action key to toggle views with :view_player() would work better, and be much less complicated.

[riserobotrise]

Well, it sets players to invalid positions, which may break some day. It doesn't handle 5D space. Sound is broken. Lua cameras are currently buggy.

For spectating, just killing the player, and rerouting his action key to toggle views with :view_player() would work better, and be much less complicated.

Will it be possible toggle player view with a .lua script, like you could with a saved film? It would be pretty neat if you could do that in elim or survival.

[megabyte]

Well, it sets players to invalid positions, which may break some day. It doesn't handle 5D space. Sound is broken. Lua cameras are currently buggy.

For spectating, just killing the player, and rerouting his action key to toggle views with :view_player() would work better, and be much less complicated.

The invalid player position issue is something i would like to get away from, but I don't have a way to at this moment. It does handle 5D space as far as I've seen. I tested on maps like Sans Serif (SQ version), but could you tell me a case of it not working so I can fix this? I think I may have a fix for the sound that will come in the next release. I will add player toggling in as well. I really haven't noticed any camera issues except when using the open gl shader. Which I really should have mentioned on the download. All of this but the shader issue should be fixed within the next release.

[treellama]

The invalid player position issue is something i would like to get away from, but I don't have a way to at this moment.

Please accept the fact that you cannot do everything you want with Lua. Focus on the things you can do, which are numerous, rather than trying to hack in things you can't.

That said, I mentioned a much cleaner way to achieve the same goal as this script in my previous post.

It does handle 5D space as far as I've seen.

When you move a camera, you set an (x, y, z) and then just take the first polygon you can find that contains it. There could be many polygons containing (x, y, z)! Or, in the case of the level 5D Space (did you really just ask for an example of 5D space, having not tried 5D Space?), just two, which your script (from my reading) will often get wrong.

See the "find_target" re-implementation in Visual Mode.lua for a hint at the correct way to traverse the map.

I really haven't noticed any camera issues except when using the open gl shader.

I am not sure why this is worth mentioning--unless you only intended this script for use on your own system? Why did you post it here, if that's the case?

Or are you saying Aleph One doesn't have camera issues, because you haven't seen any?

[irons]

Trust me when I say that Aleph One has an assload of camera issues.

[Wrkncacnter]

Trust me when I say that Aleph One has an assload of camera issues.

Only if you use them they way they are supposed to be used. Elimination used cameras for quite a while and no one had any problems, other than it just generally sucking.

[Crater Creator]

That said, I mentioned a much cleaner way to achieve the same goal as this script in my previous post.

Not quite. :view_player() limits you to first person views of the players in the game. It sounds like Megabyte's script allows one to wander wherever they like as a free, untethered camera. While that may not have been his goal, specifically, both kinds of camera views have their potential uses.

However,

Please accept the fact that you cannot do everything you want with Lua. Focus on the things you can do, which are numerous, rather than trying to hack in things you can't.

Let's not lose sight of this point. By giving the scripter access to the most basic variables like the player's stats and where things are in the world, Aleph One's lua implementation is already amazingly powerful.

[Kurinn]

Not quite. :view_player() limits you to first person views of the players in the game. It sounds like Megabyte's script allows one to wander wherever they like as a free, untethered camera. While that may not have been his goal, specifically, both kinds of camera views have their potential uses.

However,

Let's not lose sight of this point. By giving the scripter access to the most basic variables like the player's stats and where things are in the world, Aleph One's lua implementation is already amazingly powerful.

Yeah, but can Lua vulcanize my tires while I wait?

[megabyte]

Please accept the fact that you cannot do everything you want with Lua. Focus on the things you can do, which are numerous, rather than trying to hack in things you can't.

Like I said, I'd rather not use invalid player positions but it seems to be the most effective way at the moment.

When you move a camera, you set an (x, y, z) and then just take the first polygon you can find that contains it. There could be many polygons containing (x, y, z)! Or, in the case of the level 5D Space (did you really just ask for an example of 5D space, having not tried 5D Space?), just two, which your script (from my reading) will often get wrong.

See the "find_target" re-implementation in Visual Mode.lua for a hint at the correct way to traverse the map.

I gave that a look and it was quite good, but I settled on using adjacent polys instead and it seems to work rather well (thoroughly tested on 5D Space).

I am not sure why this is worth mentioning--unless you only intended this script for use on your own system? Why did you post it here, if that's the case?

Or are you saying Aleph One doesn't have camera issues, because you haven't seen any?

I was saying that cameras didn't seem buggy from my experience (they work quite well in another project I'm working on). They only thing I noticed is that during the use of the shader things start to act very odd(lots of smearing but this only happens around edges with the newer version) with camera and I should have put a warning to only spectate without using the shader. This warning is on the new release.

But in the newest version I have fixed sounds, 5D space, and a platform issue I found during testing.

Get the newest version here

[treellama]

Like I said, I'd rather not use invalid player positions but it seems to be the most effective way at the moment.

What happens when that bug gets fixed, and Lua doesn't let you set invalid player positions any more?

I gave that a look and it was quite good, but I settled on using adjacent polys instead and it seems to work rather well (thoroughly tested on 5D Space).

What if the source and destination of the camera move are not adjacent polygons?

[megabyte]

What happens when that bug gets fixed, and Lua doesn't let you set invalid player positions any more?

I'm looking into new ways, but I don't have to worry about this right now so I'm going to focus on other bugs first.

What if the source and destination of the camera move are not adjacent polygons?

The camera doesn't move, but I did realize this after I posted the update this morning and I'm going to switch to a method more like the one in VML.

By the way, when using find_line_crossed_leaving, what if the line passes all of the way through? Will it return nil? If not how does it pick which line to return?

I also figured out a way to get cameras out of the script so there are no shader conflicts or camera related bugs.

[treellama]

By the way, when using find_line_crossed_leaving, what if the line passes all of the way through? Will it return nil? If not how does it pick which line to return?

Whatever "passes all the way through" means, if one of the polygon's lines is crossed by the line segment leaving the polygon, it returns it. If not, it returns nil.

I guess the note in the docs could be more specific: "can be nil if the line segment doesn't intersect a polygon line leaving the polygon"

[megabyte]

Whatever "passes all the way through" means, if one of the polygon's lines is crossed by the line segment leaving the polygon, it returns it. If not, it returns nil.

I guess the note in the docs could be more specific: "can be nil if the line segment doesn't intersect a polygon line leaving the polygon"

Sorry for being vague. I meant what happens if the line goes through a poly all the way and crosses two lines. Does it take the one closer to the second set of coordinates, or just first line it detects, how does it pick the line it returns, if it returns any at all?

[treellama]

Polygons are convex, so any line segment can at most cross two polygon lines. The one it crosses on its way out of the polygon is the one that gets returned. Still trying to figure out what you're asking, but maybe this will help: if (x1, y1) (x2, y2) crosses two of polygon P's lines A and B, and A is returned when you call P:find_line_crossed_leaving(x1, y1, x2, y2); then if you call P:find_line_crossed_leaving(x2, y2, x1, y1) instead, B will be returned. In other words, the direction of the line segment (and, of course, the polygon you call the function on) determines which polygon line is returned.

[riserobotrise]

hey megabyte, I found a problem with your script. When reviewing films, one cannot switch views from the original host to any of the players. Maybe it should be a problem that needs to be addresed.