[SCRIPT] [RELEASED] On-Foot Cinematic Cam

@Elope I have just put 2.51 back into my game and added the seemingly troublesome Hurrican LP610 addon and everything worked as per usual. My Windows 10 install has several addons and that's always worked fine.

It could be a conflict, so if there's a particular car that causes it, let me know and I'll try it here. Other than that it could be a mod conflict... so if you have any vehicle or ped related mods, let me know what they are.

You're definitely up to date on all the essentials, ScriptHookV v1.0.791.2 and ScriptHookVDotNet v2.9.2 along with v2.51 of this mod?

Re the camera... I'll have to look at GTAIV to see how it works... the problem is my GTAIV has started running like absolute crap for no reason, so I need to find a time when I can put up with the juddering and pausing and stuttering to find out.

Elope

@LeeC2202 I do have everything up to date....

Elope

@LeeC2202 you have a old version?before onfoot cam is implented?

@Elope Yep, here's version 1.52. https://drive.google.com/file/d/0B7LFvItVrwd0bzhEeWNZWHgwOEE/view?usp=sharing

I was going to write a whole load of spiel about how giving old versions is no help to me to find bugs but I'm too tired. I can only help people, with help from those people. So I'll leave you with that old version and I think I will get a couple of hours sleep before I get back to it.

Elope

@LeeC2202 gr8, thanks

I've been a bit distracted tonight... not by something else, but by tweaking camera distances and FOV values. I was sat tinkering with values and suddenly thought "Now I have a better working visibility checking, I can push the camera back and the FOV in", which should create a better DOF.

What it also created, is a lot more interest in the shot, because more normally out-of-shot items suddenly made it into the shot as foreground objects.. the first screenshot being a prime example. It also seems to give a far more photographic kind of look than before... to me anyway. So I grabbed a couple of screenshots for a change.

alt text

Those are uncropped, grabbed-as-they-happened shots.

Well here we are again at 4am+... Just found a really annoying glitch that I have to deal with later. It is one of those single frame glitches that causes a flash of something not right and I've just discovered it's a result of my distance/FOV calculations.

The first time through, the FOV isn't set properly, so for just a single frame, it's zoomed far out (so lots of sky) and then next frame, when it's been calculated, it's right in close (so lot's of not sky). I spent ages trying to find it then hit on a solution... Bandicam it happening, play it back a frame at a time and see what the cause is, instant winner!

So hopefully, a bit more than three hours sleep tonight and some positive things to fix later. I know people probably can't see what I'm seeing from the screenshots and video I posted but I tried the old version on my machine today and the new version just seems far closer to what my vision is of this.

With some of the shots coming from the revised vehicle camera settings, it almost feels like a covert documentary at times, with the camera shooting from behind cars, or round corners. I ended up with one shot coming from inside a nearby shop, through the glass window... that looked pretty cool.

DazRave

@LeeC2202 Epic shots. You're quite right too. It looks like really good in game photography!

Would have loved to have seen the shot from within the window!

Ugly camera glitch... banished!!

I am discovering some disturbing issues with the raycasting and I'm not sure why. WHen I am in debug mode, I can see al the rays being cast and their status, blocked, clear, selected. On more than one occasions I have seen rays passing through the corner of buildings but not being blocked... which is worrying, because any that are not marked as blocked, get used as valid camera locations.

I am going to run a fairly drastic test solution on this and that is to cast the ray in both directions and only mark it clear if it passes both tests. This is something that will only happen as you enter and exit vehicles or start a melee attack, so any performance impact should go unnoticed. If it doesn't, then it will get removed.

And in one fell swoop I lose the whole afternoon's work because I have broken something and have no idea what I did to break it... not sure how many more times I can deal with this.

And now I have to find the camera glitch again...

turtlevan

I was able to get on foot cinematic mod to work simultaneously with many other scripts adding luas visualv Mxao reshade and add on vehicles with trainer slow motion custom traffic and a lot more

Sometimes the game crashes on startup screen or when in game when pressing insert to reload scripts. If crash on startup, I run game a admin again and it works great

stillhere

You can do it @LeeC2202 ! I enjoy reading your commentary, it's interesting and insightful. Keep up the good work!

Okay, so back after an interlude, a crappy tea and a very unrewarding session on No Man's Sky... they so fucked up the PS4 version of that.

I think I've travelled about 1% of the distance to the centre of the galaxy and have run out of things to collect. The reward balancing is so messed up for a game with such a potential lifespan, it's incredible. In GTAV terms, it would be like the 5th mission giving you enough money to buy any business and every car. My exosuit is maxed out, my mini-tool is maxed out and I've only been to 12 systems.

It tries to force you to trade because buying spaceships costs so much but the trading side of it is shit... so you have no desire to trade. But the only other way of getting a new spaceship, is to keep visiting one particular type of the boring, repetitive building and hope you get a distress signal. Then you have to hope that the crashed ship sending it, is actually better than the one you've got but 90% of the time, it isn't.

Anyway, in a better state of mind, I managed to find the camera glitch as quickly as I did this afternoon, so that was a good start.

I just want to add before I get back to it... I do sincerely apologise for making posts like I did... it's just so frustrating at times when the only thing you can vent at, is a screen... living in isolation has its perks but it comes at a cost sometimes.

@turtlevan LOL, I feel like I'm missing out when I see how many mods other people are using... I did try to run ENB and in all honesty, it's not too bad capped at 30fps. And luckily, I know how to code for variable frame rates so this mod works identically no matter what FPS it's running at. I'm just not quite sure whether I'm setting the ENB vsync right and how the in-game vsync should be set so they work together properly. If you have any hints/tips/suggestions, that would be great.

Reshade I give up with because they all just look like... I was going to say something I criticised someone else for saying, so I'll just say, I don't like them on my monitors. Colour accurate monitors + Reshade = bad, very bad. Some look great in still screenshots but when they move.... ugh!

@stillhere Thanks, I fear my commentary puts a lot of people off at times... I tend to lose it quite often.

Bah! A Friday afternoon bug and it's not even Friday... sounds about right for the way today's gone.

Edit: Even though GTAV is being horrible today, I'm going to be kind in return. Windows 10 is sat in a honking great partition on my SSD and it really doesn't deserve all that space. So Windows 10 can now have 100GB instead of 275GB and GTAV can have a whole partition just to itself on a shiny, speedy SSD... not quite as much as Windows 7 gets, but close.

Because of how much I write to the scripts folder and how small the scripts are, I'm going to keep that folder elsewhere and symlink it into the GTAV directory. That should make things much nicer than my shi... ahem, not very good WD drive that it's currently on.

Double Edit: Well that was painless and simple... copy directory, change registry, drop symlink, job done.

Today's progress = a big fat zero!

My brain seems to be flitting from subject to subject, can't get focused at all. Not sure I dare attempt to find my Friday afternoon bug... I could end up with the Friday night catastrophe instead. Best make a backup just in case...

Edit: Deciding to try and test for the conditions that cause the bug, I found it... doing a melee attack while the onfoot camera is on, is the source of the problem.

One of the more frustrating things about rewriting core systems, is they often break all the things that used to work perfectly well. The OnFoot and Melee/Vehicle cameras used to effectively be separate entities, but know they use the same core system and sometimes, switching that system from one mode to the other, can leave it in a state of flux and it falls over.

On a slightly different note, after some heroic work by @turtlevan guiding me through some ENB settings and Nvidia Inspector, I now have a nicer looking (but not quite as smooth) version of GTAV running in my Windows 10 install. Night time was a very different affair with the lights going further off into the distance at brighter levels. It also gave me a chance to play with some lighting and reflection settings on the glass, just minor tweaks, not the massive overhauls that I don't like. It's a bit like one of those desk toys you could buy for your office. Something to play with to pass a bit of time.

Double Edit: Seems like it's the Melee camera in general that is throwing a wobbler... but it's a really rare and random wobbler, which is going to be a right biatch to catch.

So I went to bed at 3am, all ready to get up today and tackle my erratic bug and instead, woke at 6:30am to the realisation that no matter how hard I try, my system will fail... regularly. I think it was a realisation born from watching the Rockstar vehicle cinematic camera fail in epic ways yesterday that caused it. I had views from behind fences, behind trees and at one point I had no idea where the camera was, because all I could see was blackness. And this wasn't like a momentary glitch of blackness, it was six or seven seconds, like the behind the tree incident.

I think the problem stems from trying to check an infinite number of places to get a clear view from, in a finite amount of time. At some point, the system has to say "Hey, we've taken long enough, change the damned camera already will ya?", so it does and you get whatever gets drawn out of the hat at that point, good or bad.

The other thing that made me realise I might have a problem, was after I had added the (what I thought were) guaranteed clear view probes to the exit and enter vehicle cameras. Indeed they do guarantee that when you step out of a vehicle in a garage, you are doing so in a clear camera... but then it has to switch to the on-foot probes, and they're not guaranteed to be clear, simply because of how they have to work.

So I'm sure a potential solution jumps out right there... stick with the clear viewpoint, until the onfoot system gets a clear view of its own. But what if that temporary view gets blocked, on top of the onfoot views being blocked? All that has done, is delayed the inevitable failing by one view change. All it takes is one angry ped bent on vengeance to follow you to the garage and the only clear view is now blocked... and it will then want to kick in a melee camera if you choose to fight... which will also fail.

I do have an alternate possibility and that's one based on where the raycasting is done from and to. At the moment, it is done from the probe position to the player's origin point, which is a node at the pelvis. I am thinking about what might happen if I change that focal point to just above the player's head, or even directly at the player's eyes. The camera will still be placed where it is now, but the visibility check will be done from a position that might be clearer more often. It might solve nothing, it might solve everything, it might turn this into the complete opposite of where I thought I was almost at... and that would be my main concern.

I know this is a huge wall of text but I thought it might help people to appreciate the amount of thought I am having to give, to what probably seems like a very simple system. There may be more of these during the day, so pleas bear with me while I try and talk myself into the solution.

Edit: I'm going to add this on the bottom so that people don't think I keep posting to keep my topic at the top of the list.

One of the other options I had considered trying, was a kind of regressive IntersectOptions system. By default, OnFoot cameras check for IntersectOptions.Mission_Entities | IntersectOptions.Map | IntersectOptions.Objects. So what I could do, is if the first run through fails, I could remove say IntersectOptions.Objects. If that fails, I could remove IntersectOptions.Mission_Entities... that last one sounds confusing and it is, because that's what I have to use to detect vehicles. But at this point, after two fails, it will only be checking for actual map, which means a much better chance of getting a clear view. The downside would be a camera that could be placed behind anything that those would normally check for. It could be a small car... it could be a bus, so you can see the problem.

turtlevan

@LeeC2202

why not have the camera postion move forward towards the focal point along the probe when the view is blocked by trees or fences

@turtlevan The problem with that, is what happens if the item blocking the probe is directly next to the player? You can't tell what size the item is that you've hit, just that you've hit something. You can split the detection types into individual routines to try and identify it, but then you're tripling the amount of time you have to spend checking.

So you might have hit a bus, but it might be the end of a bus that is facing away from, or towards you, so you have the full length of the bus to check against. That means you have to sit in a loop, moving the probe slightly forward doing an "Are we clear yet?" check. If it does all that and then finds that it still can't get a clear view, you have to do the same thing with the next probe. You could probably do it the reverse direction, going from player to probe but you could end up moving just a fraction and hitting something again. Then you've got a camera literally in your face.

What has just intrigued me though, was I did some checks by cutting the IntersectOptions down to just Map and it was all fine, which kinda reinforced the fact that it is a case of no clear views causing the problem because it's trying to find a gap in the middle of too many things. So that spawned another idea... at that time, I was doing double direction checks on six probes... so I thought, "I know... I'll do single direction checks on twelve probes" and put a timing check around the function to see how much time it was taking. It was registering as zero, so maybe I am overestimating how much processing time raycasting is taking. Maybe my concerns when you walk through vegetation, are not caused by the raycasting but by the simple fact that walking through vegetation causes a performance hit anyway.

I also wasn't allowing the system to re-use the same probe, to try and keep the variety up but that meant that if the only one that was clear, was the one it was using, it would fail. So I have removed that check as well. I will replace that restriction with one that says "If the only clear probe, is the one you are currently using, choose it again... if not, choose a different one". It's sort of the same thing but in a way that allows the system a bit more freedom to work. If I add in another factor that says "If you're going to use the same one again, then halve the time so it's not the same one for as long", that will help. The direction is reversed on probes as they are used, so it would never carry on in the same direction... it also randomises the height again too, so that's another change.

I am guessing based on the regularity of the Vehicle cinematic camera, they use a similar kind of system, they're just not restricted by having to do everything close in, surrounded by people, vehicles, objects and the map. If you pull into a parking spot with a car either side, you'll notice that you get very few different angles used. What they possibly also do is fire of a random one every frame and if that gets a clear view, they could store it as a fallback... something else I could do.

@turtlevan That wasn't supposed to come across like a "fobbing you off" type post but it probably does. Sorry if that's the case...

I'm just a bit hyper and anxious at the thought of this all coming to a screeching halt... and waking up at 6:30am with code solutions running round your head doesn't help.

So...

Twelve active probes for the melee camera... check!
Remove Peds and objects from raycast intersection test... check!
Walk around as the dead hooker for 90 minutes starting as many fights in as many places as possible... check!
Allow the system to use the previous probe straight after it expires, if and only if, it is the only clear probe available... check!
Crash the game... no!

So in 90 minutes of walking the city streets, the system stayed intact. That was with the OnFoot camera on as well, so it was switching from onfoot to melee to onfoot to vehicles to onfoot etc... and it survived. I like to use the city streets as there is far more chance of being in amongst things that could cause problems. I am getting cases where the camera is inside a building and that really shouldn't happen... not quite sure why yet though, unless it's something to do with the object detection.

So I'm going to add objects back into the checking mix and see if that causes any problems (or cures any). I'm also contemplating my block-timer again. The idea behind that, is that if you walk past a lamp post, it says "We're blocked but just hang on a minute to see if we're clear again as it might just be something thin we're blocked by".

That's going to be a fine balancing act between how long it allows for, so you don't stay genuinely blocked for too long. If that works, it should cut down on the number of unnecessary changes in the city... which I think will improve things quite a bit.

Edit: Handy tip for fist-fight lovers... freeroam as a female character. When I actually found people that would stand and fight, it was taking up to fifteen hits to put them down. Female characters don't seem to inflict anywhere near the same amount of damage as male characters.

Turns out the block-timer idea was a definite must-have feature. Here's a short video showing the impact of not having it... and having it. The downside is the ability for the camera to now drift into objects... so it needs some refining. I think it has to stay though, the benefits far outweigh the negatives.

You'll have to excuse the quality switch for the second half, Bandicam is being a real shit with only occasional videos working in Vegas without glitching.

Oh and you'll have to forgive my failures when trying to get the view blocked at the start... when you want it to happen, it doesn't.

Edit: Yay... doing a RaycastResult.DitHitEntity first, causes it to switch instantly when it hits an entity matching the Intersection checks. So because I check for Vehicles when on foot, it switches straight away when it hits one... no more in-car camera.

I've also just found a better codec for Bandicam which seems to give far higher quality... it should do mind you, it's saving videos at over 300Mb/s. So basically 5 minutes video = 12GB... and that's at half-size of 960x600.

Double Edit: Note to self... stay out of the Need Help and Troubleshooting sections. I can't help but try and assist people with problems and it just causes me to get distracted. Old habits...

Triple Edit: A slight hiccup... turns out it wasn't distinguishing between what it was hitting, so it was switching instantly on Props too (i.e. all entities that matched the IntersectOptions). But a quick check with if (_hitEntity.GetType() == typeof(Vehicle)) and we're away again. It now ignores Props, but detects Vehicles.

turtlevan

@LeeC2202

Can the block timer have a user-defined setting similar to the camera change timer?

@turtlevan It could... but it might not.... not sure yet.

It depends on how critical I discover the timing to be. If I find it needs to be fairly precise to cover certain situations properly, then it won't. If I discover it not being that important, then it will.

I am going to be doing a lot of testing on a variety of props and map objects to ensure that it works at an optimum value. What I hope, is that I will get it so right, that it will appear as a transparent value... i.e. it will look as though it is behaving normally with a set value. In that instance, the level of user control will remain with how long the camera is active during a completely unobscured phase.

Think of it like the speed the cameras move at, or the height they are placed at...

I'm not saying a definite no but not a definite yes either. It's that new I'm still in the excited phase... it's my preciousssssssss.

This is tricky... one of the problem objects is a tree in Vinewood, in fact there are two.

alt text

The one on the right is a real problem, because at moderate distance from the camera, it takes about 700ms to walk past it at normal walking pace. If the tree is right at the front of the view, it takes longer. The one on the left is just about passable on 500ms. So I'm going to leave it at 500ms for a while and see if that is okay. Half a second isn't a long time to be behind something bigger, so you're not out of sight for too long a time.

At this point, it's 4:25am so I'm going to attempt some sleep and get back to testing tomorrow... sorry, today. Overall though, this feels like a successful 24 hours in the life of this mod... and that makes a pleasant change. This is one more key feature implemented off the list, I can't complain at that.