For those interested, here are a couple quick videos of Scripted Collision Detection in action

http://s130.photobucket.com/albums/p276/EZ...ent=SCDvid1.flv
http://s130.photobucket.com/albums/p276/EZ...rent=SCDvid.flv



This is preliminary and there is still some work to be done. I apologize for the quality, or lack thereof. I was in a rush and have never actually used Fraps before. I have made some progress since these videos but this shows something at least.



OK... so it turns out that many people really want to know how to do this. Well, I have been persuaded. Initially, I really didn't want to mension anything further until I had everything working well enough to create my flight mod. Well, I'm pretty close to the point that I can begin working on Spells of Flight, and although I don't have it done, I will go ahead and explain it since so many people have asked so nicely.

Well, here it is. It's actually rather old school and very simple really. The problem is that when you use SetPos the movement is essentially instantaneous. Because of this, the Havoc collision doesn't actually occur because, as far as Havoc is concerned, the actor did not actually move. In fact, the actor simply "teleports" to the new location. So, needless to say, the end result is that you go through ceilings and walls and such.

About the best work-a-round is to only move the actor in the upward direction on the Z coordinate. This will allow Havoc to do it's job in the X and Y directions as well as the Z direction going down. The drawback here is first, you can still go through the ceiling, second, you can only move as fast as you can fall if you are flying in a downward direction, and most impotantly, it does not allow for any type of flight model.

At first, I thought maybe we could "trick" the game into giving up the information. So I tried things like "dropping" items from a height and monitoring their position to see if they fell to the ground, or at least as low as the players position. Trust me, that doesnt work. I tried a few other things as well trying to get the Havoc collision working. It just wasn't happening.

So I changed my thoughts. I decided on a new approach. I figured, if the Havoc collision detection isn't working in this situation, then don't try to use it. So, I started over. Not sure precisely where I should start, I called on some good ole experience. Sure, it wasn't since the grand days of DOS that I did any game programming, but that was all I had to go on.

What was the number one rule then, seems to still apply now. If things are getting complicated then step back and think simple. We often have a tendancy to over complicate things. So that's what I did. And when I tell you the solution, you will think, "Hell, that's simple. Why didn't anyone else do that?"

So, the answer..... can we get a drum roll.... is a bounding box. Yep, that's it. Nothing complicated. All that needs to be done, is to build a bounding box around the character. That was my thought. So then that is just what I did. First, a creature is created. I coppied a dog and removed all of the packages and such and tweaked varios attributes. Then in the script, I created 8 copies of that creature and using SetPos and SetAngle I positioned those dogs in each corner of the box. Then simply test GetLOS between the dogs.

Now, I'm not going to say that is the only thing that I had to do, but it is the primary step. Additionally, there are some other issues to address. Obviosly, it isn't "down to the polygon" collision detection level but it is collision detection, and it does work.... For the most part anyway.

There are some other issues as well. But the larges hurdle has been jumped and the rest are rather small. Some of those problems include what happens when you go through doors. I found a solution to that. Another problem is what happens if you move the actor in a distance that is greater than the size of the bounding box. I've got that one pretty much solved as well. In fact, the solution allowed me to get rid of most of the box and improve performance. And yet another problem is the fact that the ground outside is a heightmap and does not block actor LOS, so if one actor is under the ground and the other is above the ground they can still see each other. It's funny, because all of the objects, like rocks and trees do block actor LOS but the ground itself does not. But, I have a solution for that too, however, there are still some difficulties that I have to work out on that.

Anyway, there it is. A brief academic explaination of how to do Scripted Collision Detection.



Sorry this took me all day to get out. I'm at work and started writing this about 9 hours ago but became so busy I could not finish it until now.

I'm just moving this from another discussion to this (using a simple cut and paste method).






Thats pretty much the sum of it. But there are some additional difficulties that you can run into w/ subdivision, primarily, you have to keep in mind, all of it has to be done each and every frame. Also, it seems you can only call GetLOS on an object from one position for each frame. So, ultimately, when you do it "right" you would end up w/ a very large number of actors that you don't want..... also, it causes crashes. But nonetheless, I've been playing w/ a few things allong the same lines. But I still have to keep in mind, the number of GetLOS calls and the number of actors doing those calls.

Keep plugging. There's even more gotcha's to encounter yet

Of that, I'm well aware. But, in point, the most annoying problem is the fact that the outdoor ground (the texture mapped ground) is see through. But, there are a few things I'm working on there. It seems, as far as indoors goes, the only difficulty that I have is when fly up a hole in the ceiling. Because it really is a hole, there isn't anything to collide w/. At lease, indoor flight, this is what I have found so far. I don't recall precisely where it was, and I wish I had a save game in that area, but there was a wall that Havoc collision detection didn't work and allowed you to walk right through it, however, when you used a GetLOS collision detection it detected the obstruction. Another problem that can arise is w/ the number of actors, and I suspect that the function that automatically causes all actors to assume LOS to be 1 might give a problem as well. But none the less, there is really only one major problem to overcome before I just start flying around everywhere and look for exceptions and problems. Needless to say, I am this ... close and if you have any suggestions, or any thought on what more problems you might expect, please share. Knowledge and foresight is very helpfull. I have a decent flight model in the works, but it will only work w/ full x, y, z control. Oh, and of course, there are some precision problems w/ trees so some clipping issues can occur, however, (mostly) direct collisions do get detected... except w/ leaves.

But to add to the discussion, I wanted to mension, since your moving in a specific direction, you actually only have to test for collision in the direction you are moving... Mostly, sort of anyway. The point being is that you don't have to actually create an entire box per say. At this point, I have the ceiling, floor, walls, and other objects in doors pretty much worked out, w/ the exception of the holes in the cielings which isn't a real big concern right now. The only major obstacle left right now is the out door ground, and I've been working on that w/ mixed results. It is in grasp, but difficult to grip.

Some work I did back for Morrowind sounds like it could be useful for you to look over.

Galsiah, myself and I few others had interest in developing teleport functionality with boundary detection. Go get Short-Range Teleport from my ES homepage. Feel free to use anything there that's useful for you. The Blink spells are the part of the package that involve the teleporting.

Well hopefully you have my Boots of Flying MOD by now and can use this as your base or guide.

LOS is a tricky thing to handle. Here are some things you should know - if you haven't worked them out already.

1) GetLOS only works properly on the player:
a. On actors it functions like GetHeadingAngle w/ an FOV of 70 (+/-35'). E.g., actors will see the player through walls if they are facing the right direction.
b. Actors do not 'see' anything other than other actors or the player (they 'sense' items but do not 'see' them).
c. GetLOS will not work when called on objects other than actors.

2) GetLOS is not buggy but there are problems with it's use with various models. So far I have encountered the following:
a. You can sometimes see behind the surfaces of things, including walls at some angles. In this case you can still actually grab the objects even though they cannot be seen.
b. Sometimes the GetLOS surface is ahead of the drawn object. This is the reverse situaion to (a) - you can see the object but can't pick it up. (Even though you can actually see it GetLOS still returns 0.)
c. Gaps between abutting objects, e.g. doors and windows, can result in GetLOS 'seeing' right through whole buildings.
d. Some models are not completed with GetLOS in mind. For example, there is at least one outdoor building model that lets you fly right through the roof. On ballistrades/castle ramparts there is an LOS plane but this is significantly above where you see the surface. Walking on these is actually like walking 2-feet above the ground.

One general note: GetLOS appears to be the only means to detect static object collision. Trigger zones around the player will only detect items, actors and certain scriptable objects.

BTW: You dont need to use GetLOS to detect ground collision. LTC/BoF uses two techniques - GetLOS is superior in the situations where it does work, e.g. landing on rooftops, boxes, etc.

Yes and no. This is one of the enhancements for LTC 1.6 Levitation effects. To be fully protected would require at least side (and back) bumpers. That is if you use the SetScale technique and programmed key control. (This comes with a whole different set of issues.)

LTC/BoF are based on the z-control technique. These only have xy-clipping issues where the models are not complete (see post above) but is instead complicated by Havoc effects. Because effective Havoc surfaces are typically several feet ahead of the LOS surfaces, this leads to explosive havoc bumping when your feet are off the ground! In the BoF MOD I sent you may be able to pick out the parts that use vector math to dampen explosive havoc effects. Unfortunately, the fix can also cause you to get stuck to surfaces and so there is also code in there to release you from this situation when it occurs.

The "bumpers" that you are talking about is part of what falls into the "mostly, sort of" portion.

Please, tell me more about what you refer to as the "SetScale technique". I wont be able to download anything until probably Friday, when I'm at work. Unfortunately, the boonies and a very unreliable low bandwidth connection doesn't allow much. Sometimes it can take me an hour to download 20k files... IT SUCKS!!!

EDIT: Mark that. I got it. Ill check it out.

Guidobot has pretty much said everything I can think of about the good and the bad of using this technique, I just wanted to say I thought it was funny when you mentioned the dogs. I used the exact same technique for my telekinesis spell against NPCs only I used rats

Heres an example of it in action, every time you see someone get thrown and hasn't been held for more than 5 seconds, its because the player lost LOS with one of the invisible rats that circle the NPC:

http://youtube.com/watch?v=WGvt0m4sMwI

This is the more primative technique that employs the SetScale 1 command on the player (every frame) to prevent all motion and havoc effects.

The disadvantages are primarily that you have no gravity/collison detection at all and freeze out the regular motion/animations for the player. Hence, you can only move forward using the x-hairs as your guide.

The basic technique is easy to improve on using GetLOS in the direction you are moving and employing OBSE to manually control the character movement through simple vector math. However, it is very poor even with OBSE for handling strafing and backwards motion, mainly because you cant use GetLOS at these angles in 1st person. It also permits no direct (fast) solution for detecting the ground. Additionally you lose the ability to cast spells and other player functions, although these could possibly be added back using OBSE (?).

OK, that's similar to using Reset3DState. Too bad, that won't be of any help. I'm still shooting for full x,y,z control. Still making progress. The out door ground is real close, but it's tricky because it is see through everywhere except the objects.

As for the occasional building that is see through and doesn't have havoc data, well, there really isn't much you can do about that. Open Cities is an awesome help there, but ultimately, it comes back to the ole addage "the simplest solution is most often the best solution". In this case it might ultimately be the only solution. Perhaps we can make it a joint project in the future, but let's face it, in the end, if we want it all to work correctly, we are just going to have to replace those structures in a similar fassion that Open Cities has.

I will add one other thing, a lot of the functions have exceptions. I've notices, the dependability and reliability of certain functions is entirely dependant on various situations. Some have more or less reliability in certain types of script and others might be in how they are used. It is unfortunate we do not have some kind of "map key" that tells us what situations and uses result in what. But then, I'm not sure that even the developers are aware of all of that.




I am absolutely positive you can get it to work for a whole lot longer than 5 seconds. In fact, as long as there arent more than about 12 additional actors in your vicinity, you should be able to hold them up indefinately... but the approach you would probably have to take is a little sideways from what you seem to be describing. (I believe it will handle a bit more than 12 but I haven't tested the limit.)

I've found that advanced coding really revolves around understanding out each command works in any given situation. The exceptions can often be exploited to actually effect new functionality!

I'm guessing that the 5 seconds limit is part of PJ's intended scripting. Losing hold before this is due to GetLOS complications.

Well.... I'm afraid I have to take back what I said earlier. A bit more testing and bouncing between systems warrented different results.


I cannot be absolutely certain, but from what I can tell, I suspect that the problem w/ GetLOS is that only so many LOS checks can be ran in a given frame. Again, I'm not sure how I could confirm it, but it seems that you are only alloted so much processor time per frame for LOS checks. Basically its like each actor in line does its checks then the next actor does its checks and if you run out of time before you get to the end of the line, then the rest of the actors GetLOS result would be 0 until the next frame where it continues down the line where it left off. Additionally, I suspect that basically all the GetLOS function "actually" does is check a flag and the line of sight between each actor that is loaded is kept track of cycling down in turn like I described, w/ the player having priority which is why using the player.GetLOS has more reliability. Like I said, I can't really prove it, but that's the way it seems to act. I guess w/ the right tools I could find out for sure, but I don't really want to afford that kind of time. It does appear that GetLOS on the faster computer is not affected as soon as the slower computer so this is why I suspect that it is processor time, it just cant get all of the LOS checks done in a single frame if you have too many actors in the scene, which I suspect is why they have those 4 extra functions for when there are lots of actors and such.

I'm not sure you appreciated my previous post. From my testing, I found GetLOS only works on the player. Actors use FOV with no obstacles. Assuming that this is correct, then GetLOS would take almost no time at all to process for actors. However, I have not explicitly done all the test case scenerios, e.g. actors seeing actors out of a line-up with one infront of the other, etc. My results were based on moving an actor around and reporting GetLOS player, but I know others have found similar results for creature-on-creature action. If you have found GetLOS to work differently for actors please let me know - it would make a great deal of difference to some of my T* scripts.

In general, be careful about the assumptions you make when you're code is not working. I've wasted hours thinking I'd found something out one way or the other only to later discover the result was compromised by some bug in a completely different block or script.

Oh no guido, I absolutely appreciate every bit of information that you provide. However, from what I've been working on the last good bit, I must say, that I don't think that is entirely accurate, but that doesn't mean that your wrong. In testing creature to creature GetLOS I have been having fairly consistant results.

I create 2 creatures and suspend them in mid air with them facing each other and restrained and then call GetLOS. Each time I get the expected results. If one is behind a wall, the expected results are there. If they have clear sight, the expected results. I add another creature and call the GetLOS between them, then I add another, and another, and another. After so many are added, then some of the actors will return 0 on their GetLOS checks, but the following frame, they return 1 and different actors return 0.

There are a few other tests I have considered to confirm whether or not all LOS functions are pre calculated even without calling GetLOS which is what I suspect. In this case, since the player would undoubtedly have priority over creatures, the results of the players GetLOS would then take precedence and as such return the proper and expected answer. Thereby one would come to your conclusion that GetLOS is only reliable for the player. However, reliability is really in how much about the function and the internal processing that one knows. So, if you are aware of the limitations and those limitations are correct, then the function is reliable. Unfortunately, in this case, GetLOS reliably returns 0 when so many actors are in the loaded area. It also reliably returns the proper answer when very few actors are in the area. The question is what precisely determines the percieved reliability or lack thereof? Additionally, I would be curious as to what type of script it is in. I have been working w/ Magic Script. I have found that, at least in some circumstances, when doing some of this stuff in a Quest script, it seems that it can cause additional problems and sometimes stuttering, if it is a time precision reliant task that your trying to accomplish. I am confident, although I do not know for sure, that this is because when Oblivion processes the Quest Script processes other quest data as well in order. The end result being, w/ movement script at high speeds in a quest script if viewing in 3rd person, the scenery jitters where as if used in a magic script as an ability, the player can go a lot faster without the jittering.

So in conclusion, although I'm not sure if I will bother testing further to confirm, I believe that GetLOS simply returns a actor game state value that is already calculated. I believe that each time you add a character to the loaded zone, the number of line of sight calculations increases exponentially whether anything calls GetLOS or not. So if there are 2 actors loaded, there are 2 line of sight calculations, 3 actors is 9 calcs, 4 is 16, 5 is 25... and when I have 10 actors loaded there is 100 line of sight calculations and it doesn't finish with them all, but on the next frame the calculations are continued where they left off. Line of sight it seems defaults to 0, if there is not enough time within the frame to calculate a particular line of sight then it will be 0 by default. This I suspect is why we have SetAllVisible.

Now, the question of the day is, although we know the player has first priority, is there a way we can raise the priority of one actors line of site over another.

But like I said brother, I absolutely do appreciate every bit of information that you provide and I sincerely thank you very much.

When you say "if one is behind a wall, the expected results are there" do you mean the creature stops seeing another creature that is blocked form sight? I tried real hard to get an actor (Imp mostly, but also tried with an NPC) to see me (the player) for allowing throwing items to move independent of player sight. However, even with several walls between me and the imp it always saw me whenever it was looking towards me. I.e. no true LOS, only FOV.

For an actor to track the player they would only need to be able to see directionally towards him and them havoc would guide them around buildings and obstacles. The whole of the OB world is designed to just be seen from one angle. Therefore it makes perfect sense that the only actor that has a true LOS is the player. Why would you code this in any other way? You could easily have 50 different actor perspectives and, without a full rending from each, any LOS function is going to be buggy. Therefore why not just go for the simplest technique possible? For example, if you really need to know when an actor sees you, you can apply the reflection approximation: That is, if you can see them and they are facing you it is fare to assume they can see you. (The obvious exception being if they are blind This is indeed pretty much the only thing you can wrt "pre calculate" when the world only really exists (rendered) from one view point.

For me the only question is if there are some circumstances where GetLOS on an actor does do something different from FOV? E.g. if they were directly on the other side of a wall door. I would very much doubt this because havoc and my own testing.

As for more general issue about script processing per frame you may indeed be noticing some effect here but there are many reasons for this beyond just GetLOS calls. Certainly many GetLOS calls on the player in a cluttered and complicated region could slow your scripts down. But for actors I think it is more a function of how many are being processed rather than what they are doing specifically. I've also found that actors in combat eat up far more processing time and scripts on those actors, e.g. on tokens, definitely do not run reliably every frame. Having lots of scripts running also can lead to unusual effects, probably due to frame syncs. However, mostly it appears that it is a matter of the number and complexity of graphical models that have to be drawn that is the primary processing power hog.

As for jittery effects from quest scripts, I mention this in the README for the Boots of FLying MOD and in other threads. Basically the GameMode in quest scripts IS NOT guarenteed to frame sync. Hence if you set fQuestDelayTime to some very low value this DOES NOT mean your GameMode will get processed every frame (it could even get processed twice?). This means you shouldn't try to use frame-sync'd commands like SetPos in quest scripts to control movement. However, the issue using an ability script is likely to be more to do with crossing cell boundaries, which can force the script to re-initialize. Using the GameMode block of a token is the safest way to go but an ability/spell effect should be ~just as good if implemented with all global variables.

Actually, the number of GetLOS calls increases factorially. I dont really know what to say about your conclusion but I seriously doubt that LOS is pre-calculated for actors. It would kind-of make sense but it is far more likely that actors just know the positions of each other and do not really use LOS to check for obstacles but rather some approximation based on object positions and dimensions (even here there are many options). I would expect that it is the havoc processing that is the cpu hog. IF you assumed someone like yourself was going to do GetLOS calls between all actors in a location then it would make sense to precalculate all the LOS results at the start of the frame. However, do you really think this is the way it is implemented, bearing in mind that combat is not scripted?

What IS actually going on in the complex situation you have created is hard to say. What commands like SetAllVisible and SetNoAvoidence actually do is debatable. But I myself would certainly not implement a full GetLOS check for any actor in the same way as done for the player and I very much doubt BS has done either. For example, it is a fact that when a building is placed in front of you there are no back walls to be seen by an actor standing on the other side.

Anyway, these posts are far too long. Lets try to get back to some more basics. For example, do actors see eachother and/or the player with (1) obstacle/wall or (2) another actor between them?

BTW: I'm 100% sure that GetLOS is not pre-calculated. I have scripts in my T* MOD that would not work if this was the case: I perform several GetLOS commands on a sighting object in one frame. Additionally, most of the time I use GetLOS the sighting objects don't even exist in the player space until the script runs.

Factorially, I stand corrected.

"Pre Calculated" was a forsite guess. And you're correct. Not pre calculated per say, but there is definately a priority issue here.

NEW DISCOVERY... An accident really, but I may have stumbled onto something. Keep in mind, I am working w/ actor to actor GetLOS here, or more precisely, creature to creature. One thing is definate, at least when I am creating the actors w/in a spell script. The GetLOS works between them until there are too many actors in the loaded area. At that point, using GetLOS for the player still seems to work fine. Now, the accident....

I have created dozens upon dozens of different short little spells just for testing purposes. I've probably created nearly a hundred of them. Well, I created this one little test spell, there are 3 or 4 actors in it, using various calls of GetLOS. I initially created it to try to test what the actor limit was before I started getting inaccurate results. But, when I started testing it, something caught my attension. It wasn't working as I expected. In fact it was working completely, regardless of how many actors I put in the loading area. Unlike all of the others, which would start returning 0 when a dozen or so actors were loaded, this particular test spell continued to return the proper and expected results. When one was behind a wall or in a tree it would return 0 as it was supposed to. If there wasn't anything obstructing the view then it returns 1. This boggled me a bit. So, I started creating lots of actors to try and test and push the limits. At well over 150 actors in the imediate area and even though my frame rate was choking and crawling, GetLOS still keeps giving the proper results.

Now, I'm not entirely sure what is different in this particular spell script that is causing this, but if I can decipher it, then I may very well have a way to "increase the priority" of a particular GetLOS call.

Other than that, I don't have much. I haven't really gotten a chance analyze it further since I discovered this oddity. But, rest assured, I will look further into it.

Well good luck with this pioneering work. You do seem to like pushing things to the extremes

I would be surprised if actors do actually see objects between them but if they do then it might not be universally true. For example, trees are a very specific type of static object whereas walls are very different. I would expect them to be at least aware of of other actors blocking their view. I will certainly pay attention to to whatever you post here.

From what I've been experiencing, I don't believe it is that actors see objects between them. It is that the actors just can't see through objects between them. If that makes sense. Basically, if you place the object between them, they can't see the object, but they cant see what is passed the object either.

Also, I am wondering if it has to do w/ some kind of bounding box, because in some cases it seems that the area that actually blocks their LOS is a little larger in the corners than the object.

I haven't even been able to open the CS in over a week so I will look further into a few of these things when I get the oppurtunity.

I'm pretty sure this would come along a lot faster if it werent for the fact that I only get to actually work on it every so often and usually only maybe one to three hours a week if Im lucky, but I'll let you know what I find out.

Oh, and I might have mensioned it already, but the last time I was playing with it, I did discover a way to accurately determine the Z coordinate of the ground at a given X,Y coordinate position. This would be useful for a local site to site type teleport spell I would expect.

I suspect the GetLOS function uses a simple raycast algorithm that casts a ray from each corner of the bounding box of the source object to each corner of the bounding box of the destination object and returns false if a majority of the rays intersect any local meshes other than those of the source and destination objects. ( or some slightly more sophisticated variant of such an algorithm )



You seem to get an amazing amount done with so little time!



How?



Neither: its polynomial ( n * ( n - 1 ) for the number of edges in a complete, directed graph )

Actually, that is basicly, more or less, the same assumption that I've been going off as well. However, there is a field of view issue too. Not only does the other actor have to be in line of site, but that line of site has to be within the field of view according to the direction the actor is currently "looking".


As the ole saying goes, "99% of Creativity is the thought you put into it. 1% is the work. And 100% heart and soul." I don't think it is that I get a lot done per say, but I have a lot of time to think and when I come up with an idea I write very short efficient scripts strictly for testing that are easily attached to spells or objects. It usually takes more time to open the CS than it does to actually write the script. I'll note that this is not the only thing I do, but when I am exploring possibilities and trying to discover a method, this is what I'll do. Then when something works w/ positive results, later, I will go back and test it more thoroughly.


Well, the how isn't real difficult. Now, as I said, it was something I discovered the last time I got to play with the scripting so I haven't been able to thoroughly test it.

One thing I will note is that there are certain exceptions that I expect will have to be accounted for. The primary concern is if you are trying to get the Z coordinate of an X,Y position where a tree is standing. I'm not sure what kind of results will occur there. There is also concern with getting the Z coordinate of the ground directly below a character standing on the ground. Obviously, in the later case, the easiest way to get that particular Z coordinate is to get the Z position of the character standing on the ground, but none the less these things may have to be accounted for. It seems that in the case where there is a rock or that type of structure, then the Z coordinate you get will be on top of the rock which is good and fine because for all intents and purposes that is the top of the ground. I also haven't tested but suspect problems in the case that a building is on the ground and you try to get the Z position there. Will you get the Z position of the ground? Or will you get the Z position of the roof of the building? Either way, it can be worked with and even w/ all of these exceptions, I believe they are all things that can be accounted for and coded for.

Now, you want to know how. Well, the how really is simple like I said. But there is one more thing that has to be kept in mind. You can only get that Z position on the following frame that you set it up to do so. An interesting, though apparently consistent thing occurs when you place an actor below the surface of the ground using SetPos. On the following frame, it's Z position changes to the surface. Now, if I recall (it has been over a week) I was using SetPos Z, -1000. It also seems to me that there were some issues that would occur if you actually placed the actor at an under water level. Again, if I recall, if the actor is placed "in the water" under the ground, then it would still come back to the surface. However, it would be in a swimming state and even though you could see it while you are on top of a mountain, GetPos Z would return -5. And one more "if I recall", you can actually set an actors Z position to be below the water level, which I think is why I changed it to SetPos Z, -1000 because SetPos Z, -10 wasn't working.

So, strictly speaking. First, create a creature and reduce its size and everything to make it undetectable in the game. PlaceAtMe the creature that was created for this. Then immediately set the creature to restrained so he doesn't move. Then set X and Y positions of where you want and then immediately after that set the Z position to -1000 or something along that lines. Then wait till the next frame and get the Z position of the creature and then dispose of the creature.

Obviously, that is a rough explaination, and will result in a one time position, but if you need to continuously get positions, then you would have to use at least 2 creatures and alternate back and forth dunking one under ground and getting the position of the other and flip flop back and forth.

And, just to conclude this, again, I haven't had any oppurtunity to thoroughly test it, so I'm sure there are other little things that can pop up. If you work on it, and discover anything new, please let me know.


OK, So I haven't done any real math in over 10 years and it shows.

Although this is essentially true, I doubt it is s full ray-cast algorithm, which are very complex. Instead I would guess that it is a very simplified form using crude approximations of the meshes that are in view. When a new frame is drawn essentially everything seen is in-view as far as the player is concerned, except for the player model itself. This has to be true because of the way GetLOS works in 3rd person.

I'm a little skeptical because almost everything comes with exceptions. However, I too would really like to know what you find.

Oops, my bad. I was considering all the combinations of taking groups of these items (Cnm). You are correct that the number of pair-wise sightings is n(n-1)/2, which is a geometric increase and less than exponential or factorial.

Yep, OB has a built in safety mechanism for actors when placed in the 'void'. Basically you cannot move too far from a region surrounding the objects placed in your cell. If you go too far below the cell you are automatically transported to the floor of that cell, although I wasn't aware this also applied to exterior cells.

I had the same problem when hiding my shadows when I needed them to be near the player but enabled. If I use a z-offset of -200 then it takes them enough time to 'fall' that you can process what you need over a few frames (about 30 is what I needed but I keep resetting the shadow's zPos to this value to extend its presence). However, if you place them at a large z-offset, e.g. -5000, they will pop back to the surface almost immediately (next frame?).

This is one method for finding the ground's surface. I haven't used it myself this way because I think it only applies to actors (items seem to fall to a minimum z and stop?) and because they have to be enabled for this to work (?). It also requires testing over a few frames and you can use havoc on the player to have them return to the ground (less abruptly). Having said this, it would definitely be worth experimenting to see if a reliable solution to ground detection can be implemented this way. If reliable, it might be superior to the method I use in LTC, which raises you up to the surface gradually should you fly/parachute below it.

The way OB treates the water-level is a bit wierd. I had to debar using Levitation when swimming because SetPos does not seem to function the same way when swimming.

Well, it's been a while since I've actually gotten to do any work on this. I got the chance to play w/ some scripting for about an hour today. I am hoping I'll get a couple hours after all the kids are in bed.

I've decided to go ahead and put the discovery, testing, and research parts of this project on hold. I have started rewriting the flight engine at this point. I did momentarily consider actually writing a more accurate flight sim like engine, but after about 30 seconds of thought and 3 minutes of phantisizing, I decided against that. I'm afraid that the scripting would not handle it if I did. So, instead, I'm going forward w/ an arcade approximation flight model. I'm shooting for "the feel" more than anything else.

Well, one of the boys just pulled a cake out and it is all over the place, so I gotta go. .... The work of a father is never done.

Well best of luck. Once you have a levitation effect that works best for you then adding all the fancy aviation mechanics should be relatively straight forward (i.e. once limitations and gochta's of OB have been handled).

Just figured I'd pop in and say "I'm not quite dead yet."

Unfortunately, until yesterday, I haven't gotten to do anything further with this since the last time I posted. The week of Thanks Giving was rather busy. Go figure. The wife thinks "This is family time" so, other than a slap in the back of the head for turning the computer on, I didn't get anything done then. I thought I would be able to "play" with some scripting after that but the flu swept through my house like the plague and finally knocked me out. So, needless to say, I spent the last week in bed or in the bathroom.

Well, I finally started feeling better, so yesterday, I got to script for a couple hours or so. It can be distracting w/ 4 kids, but I managed to get the majority of the psuedo flight mechanics model coded. At this point I have completed about 90%-95% of the flight model code.

After I finish that last little bit, then I'll get back to investigating that "special" test script I wrote in which it seems GetLOS always works properly. Once I figure out why that one script works consistantly, then I will put the collition detection code into the script. From there, all I will have left is an adventure quest to create and all will be good.

EDIT: Corrected a typo