PDA

View Full Version : A Special Conveyor Cog



Daft_Vader
10-29-2005, 09:02 PM
Hello, I was wondering if it was possible to have a conveyor belt cog that scrolls all mat's of the same type at the same velocity and speed? Just like the unviersal animation of a mat, only this time a conveyor cog for a certain mat.

If this is possible, I would appreicate it very much. You will receive credit! :)

zagibu
10-30-2005, 05:55 AM
Try this:


flags=0x240

symbols

material surf_mat

surface surf local

vector dir_vec

flex speed=1

int i local
int j local

message startup

end

code

startup:
// Wait a short while for level initialisation
Sleep(1);
// Normalize the direction vector
dir_vec = VectorNorm(dir_vec);
// Loop through all sectors
for(i = 0; i < GetSectorCount(); i = i + 1)
{
// Loop through all surfaces of current sector
for(j = 0; j < GetNumSectorSurfaces(i); j = j + 1)
{
// Get a direct reference to current surface
surf = GetSectorSurfaceRef(i, j);
// Check if material is of desired type
if(GetSurfaceMat(surf) == surf_mat)
{
// Start conveyor animation for this surface
SlideSurface(surf, dir_vec, speed);
}
}
}
Return;

end

I tested it. Doesn't work with dflt.mat (this issue cost me 20 minutes...damn JK quirks).

Daft_Vader
10-30-2005, 09:10 AM
Thanks zagibu! I'll try it out now. :)

Daft_Vader
10-30-2005, 09:22 AM
Yay, it works! Thank you again, this will be a real time-saver. I'm surprised nobody has suggested this before. Maybe you or I should submit it to the HUB.

zagibu
10-30-2005, 09:36 AM
Already done.

ORJ_JoS
10-30-2005, 03:15 PM
Very cool. :)

May I ask, with this cog, do we still need to provide vectors?

zagibu
10-30-2005, 03:33 PM
Sure, or how else would you specify the direction of the conveyor?

ORJ_JoS
10-30-2005, 06:45 PM
Right.... will this mean all mats with the same name will scroll in the same direction?

Because if you want your conveyorbelt/flowing water (or whatever) to go around a corner, you'd have to use a different texture.

Daft_Vader
10-30-2005, 07:04 PM
Well, you see, in my level all of the conveyed surfaces move at a vector of (0.00/0.00/1.00) or, in other words, straight up. Hence I don't need to worry about a river cog where the vectors change. So yes, I see this cog might not work for everyone. For me, however, it saves a great deal of time. :)

LKOH_SniperWolf
10-30-2005, 08:05 PM
There's a minor problem with this. Doing this same for all mats, in that manner, will mean that they'll be sliding at different speeds. The speed is relative to the provided vector. The vector determines movement relative to the surfaces orientation, and therefore the speed is relative, based on the direction the surface is facing. I've modified my general vector conveyor cog to work on a specific mat file.

zagibu
10-31-2005, 02:42 AM
Isn't this only a problem when the vector is not in the plane of the surface? Also, at times, this "problem" might even be the wanted effect. Maybe an option to toggle the calculation method?

LKOH_SniperWolf
11-01-2005, 11:16 PM
Yes, but for something that works on materials, and not linked surfaces, it really is a problem. Even for what Daft originally stated: all the same velocity, for a material, like an animation. This only works with a directly vertical vector being applied to only vertical surfaces, or a horizontal vector to only horizontal surfaces. However, think from an editors point of view. If you're going to apply this to all surfaces with a material, are you going to want to have to try and figure out how it will translate to a particular surface depending on that surfaces orientation, and calculate it for every surface? I can't think of a case where one would want that 'problem', as it doesn't provide any sort of consistency between surfaces, and wouldn't look good. Take the simple example of a cube sector. Say you want the walls to scroll horizontally. To do it your way, you'd have to use two seperate mats, even if you want all the walls to look the same. If you just put one around the four walls, and used a directly horizontal vector for one of the walls, then two would move the same, and the other two wouldn't move at all. This isn't to say your code is bad zagibu, however, it's just not very useful in most practical applications. It's ok for Daft, because he's doing one of the two cases mentioned above; a vertical vector on only vertical surfaces. However, sliding all with the same 3d vector is more usable when you can individually select the surfaces, which isn't the case with a mat based surface scroller. I didn't mean to write this much, but I wanted to explain why it is a problem.

zagibu
11-02-2005, 02:57 AM
Errr...thanks for the explanation? I'm not that stupid, you know. That's why I proposed to have an option that toggles absolute and relative vector calculation...heck, I'll just show you:


flags=0x240

symbols

material surf_mat

surface surf local

vector dir_vec

flex speed=1

int mode=1
int i local
int j local

message startup

end

code

startup:
// Wait a short while for level initialisation
Sleep(1);
// Normalize the direction vector
dir_vec = VectorNorm(dir_vec);
// Loop through all sectors
for(i = 0; i < GetSectorCount(); i = i + 1)
{
// Loop through all surfaces of current sector
for(j = 0; j < GetNumSectorSurfaces(i); j = j + 1)
{
// Get a direct reference to current surface
surf = GetSectorSurfaceRef(i, j);
// Check if material is of desired type
if(GetSurfaceMat(surf) == surf_mat)
{
// Check which mode is active (absolute or relative vector offset
if(mode)
{
// Start conveyor animation for this surface (absolute mode)
SlideSurface(surf, dir_vec, speed);
}
else
{
// Start conveyor animation for this surface (relative mode)
SlideSurface(surf, fancycalc(dir_vec, GetSurfaceNormal(surf), speed);
}
}
}
}
Return;

end

I can't work out the calculation at the moment (work is pressing), but I'll complete it later. The idea is to base the vector on the surface's normal vector, so that it will nullify the problem you posted. And I can still think of examples where this "problem" could be the desired effect, e.g. when you try to simulate a thick liquid flowing down an uneven wall. It will obviously move slower on less slanted walls, but move down with the general (0/0/-1) vector. An absolute calculation is the solution here.

LKOH_SniperWolf
11-02-2005, 11:02 AM
If you note the cog I posted in the zip, it does the problem 'nullification' as you put it, calculating surface-relative slide vectors. It is based off of the surface normal, if I remember correctly.

As for your current code, there's no need to do sector/sector in surface loops, and then get a reference. Just use GetSurfaceCount(), and use one for loop to go through all surfaces. The reference then would just be i. Also you can detect for DFLT, but you have to be told the mat is dflt (I used another var, isDFLT to handle this). (Straight comparison won't work...) GetSurfaceMat() returns negative values if the mat = dflt.

I have attached a modified version of my previous cog which includes a toggle. As for the case you present, while that would seem logical, in the case of JK and sliding straight textures, it would not be visually appealing.