[SCRIPT] [RELEASED] On-Foot Cinematic Cam
-
@Elope Just an update on the planes situation, I have now categorised them into four groups, Low, High, Front and Rear. Low allows for views from anywhere, but is height restricted to stay below the wings. This is for Mammatus and Dodo. High is similar but height is restricted to stay above the wings, Vestra, Velum and Velum 5-Seater. Front is for front entry planes, P-996 LAZER, Hydra and Besra and anything else gets the rear view, Duster etc...
The big planes are a real problem, because they just don't follow the same entry/exit process. They're going to have to be special-special cases. My concern is any add-on planes, as you can imagine, I have no way to cater for those... unless I really expand what the ini file is capable of dealing with.
-
@LeeC2202 Perfect!thanks for your hard work : D
From your words,so the planes are actually specially defined in the script and those add-ons needs the difinition as well,otherwise they'd still have the camera angle problem,right?Ah that kinda sucks : (
And how's the eject camera going?I'm not sure if it's a bug or you didnt set it...as I mentioned you dont get the cinematic view when jumping off a vehicle when it's speeding.But a cinematic view for ejecting from fighter jets is something you cant really miss ; )
-
@Elope Yeah, any addons would need to find a way of registering themselves with the mod.I can't even choose a default view that would work for all of them. But as I say, I could make it so that there were sections in the ini file, [HIGH] [LOW] etc... and people could add them in there and the script would pick them up and use the correct view. It's just a bit more work for me and a bit more work for the users.
I thought the native IS_PED_JUMPING_OUT_OF_VEHICLE might have caught the jumping off a vehicle, but I can't seem to get any response from it. It is definitely something different though, because the normal vehicle exit check doesn't pick them up. I'll get it working, it's just going to take a bit of time. It is on my todo list as I want to get it working.
Boats are another weird one, when you get up from driving a boat, you are classed as not being in a vehicle, yet you're stood in the boat... very odd some things in this game.
-
@LeeC2202 Anything is strange about the game lol,anyway,an ini file to type in the vehicles ourselves is a nice way to do so,thanks for the hard work!
-
@Elope Ini file changes are now working, I will preload it with the default planes that are part of the normal game to give people an idea of how it needs to be done.
As for the special case planes, I have discovered that there are a couple that I just cannot cater for. The Cargo Plane and the Jet seem to use a warp and obviously, I can't put a cinematic camera on a warp. That also means that any other plane that you have to warp into, won't work.
The others, like the Luxor, Nimbus etc... I can detect that you're getting into a flying vehicle, which means I can get the name of the vehicle. That means I can create a special case for those vehicles. So as well as the camera sections in the ini file, I might also have to add a [SPECIAL] section where problem planes can be stored.
On a positive note... I jumped out of a plane tonight and it kicked in a cinematic camera. It was completely wrong mind you but at least it means I am now detecting that action and can deal with it.
And on a negative note, I have discovered that a vehicle not on its wheels, screws up the camera placement... sigh Two steps forward, one step back.
-
@LeeC2202 Well there's the solution: Get a custom launcher. I mean, as I said before, some custom launchers allow the player to select "Offline Mode". Why not look one up? It will definitely put a stop to those problems.
-
@Hyper-Droid I do have one of those on my other OS install... I run two versions, my normal retail version that runs on my development OS (Windows 7) and my modified version that I run in Windows 10 (I dual boot both OSs on my PC, I bought a cheap, but legal OEM Win7 license and used that on the Win10 installation)).
I only have a modified launcher for an older version of the game though... I'll have to look into it further, because while it's inconvenient to stop you playing, it's more than that when you're trying to test a mod.
-
Grrrrr, it's the little things that you trip over most. Part of the way this works relies on scenarios completing in a clean fashion. So that means that if you exit a vehicle, it relies on you either standing on your feet, or the camera timer expiring. I have just discovered that if you begin the "getting into a vehicle" scenario, but just before you are fully inside, you are dragged back out, it doesn't finish cleanly because it expects you to be in a car to finish. As such, it cannot go through the full "getting out of a car" to put you back into a default "on foot" mode. So that's a must-fix issue.
I'm also going to be re-writing the camera placement code to try and cater for the camera probe system I am also writing. At the moment, the camera is placed into designated zones and what I plan to do, is to be able to place them on designated sectors of an orbital ellipse instead. That should be more flexible and give me greater results in how they work and how it looks.
I plan to release a version tonight that has the fixes and ini changes in for the aircraft. That will give people a chance to get used to how the ini file is now used to control where the cameras are placed.
-
lee, you can make commandline.txt file in gta root directory and use a command line parameter to force game to launch in online only without social club, or use the launcher as hyper says. See that you have two game directories now.
Bummer they wont let you launch in singleplayer offline mode.... damn. silly
Maybe the camera can trigger on one of the natives for enter/exit, and just expire after a timer and return to previous camera view if no secondary native forces the return.
-
@turtlevan said in [SCRIPT] [RELEASED] On-Foot Cinematic Cam:
Maybe the camera can trigger on one of the natives for enter/exit, and just expire after a timer and return to previous camera view if no secondary native forces the return.
That's how it does work, but being jacked on the way to getting into a car, means that the camera system should be starting a new scenario of "being jacked", but the "getting into car" one hasn't finished. So you can't allow the first event to expire, or it cuts the second one off.
Normally, you can't interrupt a sequence, like you can't press the exit button to get out of a car, before you have got in and started the engine, or visa versa This is just one of those odd curveballs I hadn't considered and that's the perils of working with a system full of unknowns... it keeps you on your toes for sure.
They won't allow you to play completely offline, because then it means they can't push their money grabbing promotions at you. If you play one of the non-social-club versions, the loading sequence is free of all that "20% off this, 30% off that... please buy it all" type stuff that gets shown during loading... it's much better.
-
Version 1.5 has now been submitted which includes the changes I have been working on for the planes. I was all ready to upload one earlier, when it suddenly occurred to me that the same problem might happen with helicopters... and I was right. So I have added all the required info for them to work as well.
So what you basically have in the ini file now, is sections marked as [HIGH_CAM], [LOW_CAM] etc... There is an image in the zip file that shows where these zones are on the vehicles. The [EXTRA_CAM] is for any plane/helicopter that has the entry point a long way from the centre of the vehicle, like the Miljet aircraft, or the Skylift helicopter.
So for example, you have this, which places the camera in a high-central position, but limits how low it can go, so as to avoid the view being blocked by the low wings.
[HIGH_CAM]
FLYING = "Vestra"
FLYING = "Velum"
FLYING = "Velum 5-Seater"If you add any planes/helicopters to your game, simply add them in the section that you think will work best for them. Any vehicle not listed will get a generic central view.
I know things probably look like they're going really slow at the moment, and to be honest, they are. I do have personal issues and that means that whilst I can go three days and really get things done, I can equally go three days and get nothing done. At the moment, I have just moved into one of those low-points and it can make things hard work. So I hope you can bear with me until things improve a bit and I can get a bit more productive.
It's like the bug that caused the camera to shut off immediately when trying to enter planes like the Nimbus or Luxor. I spent ages trying to work out what was getting triggered, why I wasn't detecting them etc... then it occurred to me, I have a function that I use for if you try and jack a car but the driver manages to drive off. That cancels the camera when the car gets a certain distance away. Well it turns out that the distance from the centre point on the aircraft to the door, was further than my checking distance... and that is why the camera shut off. When I'm in a worse place than I am normally, I can miss such simple and stupid things.
Edit: And just to make things worse... the version I uploaded has lots of debug info visible... could this day get any worse?
-
@LeeC2202 Just chill ,man,have a rest when things are too complicated : D
-
Why don't you let the user set the timescale other than 10, 25, 50, 75 or 100? It would be very easy.
float tempScale = (float)ModSettings.GetValue<int>("SPEED", "SPEED", 75) / 100f;
if (tempScale < 0f) fTimeScale = 0f;
else if (tempScale > 1.0f) fTimeScale = 1.0f;
else fTimeScale = tempScale;
-
@Jitnaught Because in my code I have an array of those values and when you have it set so that you can adjust the speed, it uses an index to choose the next or previous one in the array when you press left or right. Had I allowed people to change that value to anything, the minute they turned on the setting that allows them to change it during playback, that value would have to get modified to fit in with my values anyway.
I also don't think there is any need for values between those as the difference would be so small it wouldn't be noticeable to any extent. So this was to allow users to adjust in game but to also allow them to choose one of the values as a permanent setting.
So yes it would be easy, but it wouldn't fit with how I designed it. Everything is a balance between functionality and usability, I believe that this caters for both. Think of it this way, with the cinematic view for vehicles already in the game, you have normal speed or slow speed, so at least you have more options here than that gives you.
I hope that doesn't sound too dismissive... I'm trying to balance stress levels with helpful communication, so I apologise if it does.
Here's a handy line for you as well, while we're offering up code:
float fTimeScale = Math.Max(Math.Min(fTempScale, 1), 0);
That constrains any number between the two values at the end, 1 being the highest, 0 being the lowest. Saves all that if (x < y) x = 0, else if (x > z) x = 1, else... stuff.
I use it a lot for boundary checking moving windows across tile maps, or constraining crop rectangles in image applications.
-
@LeeC2202 Alright. I just thought that maybe in-game you could have it so it goes 10-25-50-75-100, and then in the INI file you could have it any custom value from 0 to 1.
Cool use of Math.Min+Max, thanks.
-
@Jitnaught I could have the ini file like that, but the minute you changed the value in-game, it would write one of the preset values back anyway. I do understand what you're saying though and in a different situation, I wouldn't have imposed such restrictions. I'm trying to accommodate as many features as are possible, especially requested ones but this one has to stick I'm afraid.
-
I just want people to be aware of something I have just discovered about the game writing settings back to an ini file. If you remember how I said that each camera entry was stored in the ini file like this:
[HIGH_CAM]
FLYING = "Vestra"
FLYING = "Velum"
FLYING = "Velum 5-Seater"Well it turns out that when the game re-writes those values, it could end up looking like this:
[HIGH_CAM]
FLYING = Vestra
FLYING//1 = Velum
FLYING//2 = Velum 5-SeaterIt appears to strip all the quotes off the values and then for each value with the same name, it appends // and a number after it... the first one has no // and number. This is repeated in each section, starting from just the name in each one.
So be aware, if you cause the game to save the ini file, by changing the playback speed, this is how it will look. So you must make sure that any additional planes/helicopters follow the number sequence.
I had no idea it was going to do that...
-
Having a nightmare with inconsistent delegates at the moment. It took me ages to understand the damned things and now they just hack me off. Two almost identical classes, two absolutely identical delegates but when one is called, it sees a List<int> contents correctly, when the other is called, it sees that same List as being empty... frustrating to say the least. As for what this is for...
This is a preliminary test for my camera probe system, this video shows a fair amount of glitching but I have advanced the system since then. It is basically the cinematic camera working whilst walking. I had concerns over the control inconsistencies but now that I have this system working, those concerns didn't prove to be true. Once you are walking in a direction, no matter where the camera cuts to, the controls remain the same. . However, this video test is all done with floating cameras pointed at the player, I have yet to test this with a camera dropped in a fixed location.
What this system allows me to do, is have probe configurations/formations that can be changed easily. Probes can be either orbiting around a target on a variable X and Y radius, so either a circle or an ellipse. That elliptical orbit can also rotate around that fixed point, at its own speed. Height, speed, radius and orbit are all individual to each probe. They also have the ability to either inherit the target's rotation, or remain independent.
Here is another video showing the system in action from the normal game camera perspective. You can see how the formations change depending on what the player is doing. It also switches off while you are in a vehicle.
Green lines represent clear probes, red are blocked and the purple would be the one the cinematic camera woud use. You can see how the probes orbit, track and move differently. The default walk set has a high orbiting probe that is independent of the player's position. A lower orbiting probe that tracks the player and then more fixed probes that track the player's rotation.
-
can you have probes above & below for if the player is falling, flying or swimming?
Great work so far, this is my favorite topic on this site.
-
@LeeC2202 huh i didnt think this would manage to get made after seeing the original threads info lol well done
-
@turtlevan In theory, they can be absolutely anywhere, they can be adjusted in real time with regards to speed, length and direction. Or I could just create another ProbeList and apply that if the ground was more than a certain distance below the player, or simply switch direction of a probe that points directly upwards based on your direction of travel..
I've just actually discovered something really fricken frustrating while writing the "checking for a free clear probe to assign the camera to" code. The game calculates the player heading in an anti-clockwise direction and all the probes are created based on a clockwise direction. I have never seen a system where +90 degrees is to your left... It's no wonder my calculations weren't working.
I hope my rambling isn't too boring... I get concerned that people might think "Oh he's gone quiet, he must have abandoned it or something", so I like to post even small things so it's clear things are still happening. Every now and again I get chance to post a video, so that's helpful to show progress.
-
@AuthorSaulAlan Neither did I, I was convinced that a lot of things weren't possible but the more I have learned about the game and what it makes available, the more I find is possible after all... and thank you.
-
You know when you sit looking at something and you have this constant nagging feeling that something doesn't look right? Well I've just been sat here having a chill with the game, watching things going on and every time a cinematic kicked in, I was thinking "I must stop that minimap from spinning round when you move the controls".
Then it occurred to me, you shouldn't even be able to see that minimap, or any other part of the hud. I used to have a call to SET_WIDESCREEN_BORDERS which actually seems to do very little other than hide the hud and it had completely gone from the code. If you look at the early screenshots, it was working there, there is no hud visible. I originally hoped it would have done what it says, and created a widescreen cinematic view but it seems it did the same thing in GTAIV, just hides the hud.
So now I've put that back in and the cameras are free from any obstructions, which I think makes them much better... no idea where it went though.
Ahhh, I wonder if it was tied in with my original targeting code when you had to be in stealth mode + targeting a ped for all this to work!?! That seems so long ago now... and so horrible to have to do that... what was I thinking???
Damnit!!! I've just discovered a type of vehicle where the player gets off on both sides but it's a central seat so I can't tell. The Off-Road Blazers... damn that's annoying.
-
Just a small version update today (v1.52) that puts back the hud-off code and makes a small tweak to the LOW_CAM. In some instances the small rising motion that happens resulted in the camera going through the wing of the Dodo. So I've lowered the max height to hopefully compensate for that.
As for my clockwise/anti-clockwise issues mentioned above, I now have that sorted, so probes and game are in perfect harmony... bloody Sin and Cos sat in the wrong seats.
I probably won't release a new version now until this on-foot thing is working properly. Hopefully that will be in and working soon, in an ideal world today, in the real world, probably sometime this week.
Oh yeah, and I really need to sort out the fallen over bike problem and the moving vehicle cam thing... rare occurrences but they need fixing nonetheless.
-
@LeeC2202 Looking forward to the on-foot update. sohcahtoa. This mod seems to require a lot of skills & effort...
I thought it could be as simple as just assigning the vehicle cinematic camera to the player... lol. wish i knew how to create thesethings