Back to Main Page


This page is about my Players Extended mod, a mod that throws open the world of addon peds, making them accessible and more interactive than ever.

WARNING! This is my therapy mod, this is intended to keep me away from the edge... Content on this page could get feisty on bad days, which are every day. If you want jolly stories about mod development, this probably isn't the page for you.

This hasn't been a free-flowing project like my others, this really is a battle of wills to keep going and I lose that battle a lot. Some days just a couple of lines of code get written, other days see more happening... but it's hard to keep this going, really hard.

I don't expect people to understand just how critical this mod is, I don't expect them to care how critical it is... but this is a make or break mod for me.

Page 1

Page 2

Page 3

Page 4

Page 5

Players Extended - Addon peds at your fingertips


A long while back, I had an ambitious mod plan, called persistent peds. It was something I came up with while I was doing the World Guide mod and was designed to add more life to a selection of peds that existed as more than just toys to play with. Like most of my plans, it had an ambition level of +99 and my ability and motivation scores combined, rarely make it into double figures, so it got sidelined.

Then a short while back, I created a skeleton project called Enhanced Roleplay, that was intended to open up more options when you were using addon peds. It never got any further than that, because I went through a massive dip in my life, one I wasn't sure if I would come out of. The jury is still out on that...

But anyway, a week or so ago, I got the idea to approach this from a different angle. I would start by making a selection of Peds accessible and persistent, like the main characters. I wanted to fix them into the map, so I scoured the map for 4 locations that seemed unused or uninhabited. This involved using Codewalker to search the map, then check for car generators, then check for scenarios. Any locations without both of those were candidates. I found 4 that were ideal, one over in Banham Canyon, that's a definite fixer-upper. One over in Mirror Park, that required a yMap edit to remove a For Sale sign. One in Vespucci Canals and an apartment in West Vinewood. All of them were shown on this Mystery Mod Photos page.

So having found my locations, I needed to implement a system to access these peds. I liked the character wheel, so it made sense to stick with that idea. First hints of that were shown on this Mystery Mod page, along with a prototype video showing the early stages of the system. The wheel and selection process has moved on quite a bit from that, as you can see in the new video below.

I spent tonight trying to get the money system working and it seems the game just doesn't register anything money related for addon peds collecting money pickups. Player.Money doesn't change, Ped.Money doesn't change

What makes it even more annoying, is the money pickups aren't detected by any Entity or Prop detection checks. If you raycast at them, it detects an entity but they don't seem to be registered in any Pools, so you can't detect if they suddenly disappear. I actually wrote a small function that gets all the entities nearby and draws a line to them but it never draws a line to the money pickups. I even created a Pickup and it didn't detect it, so I have no idea how to interact with any money related entities.

That's really frustrating as it means anything that should involve money, is now going to have to be free, which is going to be really immersion breaking. I could just transfer the Player's money to the ped when you switch but having too much money is as pointless as having none. I could give the peds theoretical jobs and give them an amount of money each day but I would have to work on system time as I never save in the game, so it's always the same day. Maybe if I broke a day down into several virtual days based on the time advancement in the game, that might work better. I would need to find out how much faster the game time goes, compared to real time

Ooooh, right on cue, a StackExchange question asking that very thing... the answer, is "A full day in GTA 5 takes 48 minutes real time.", so 2 real seconds for 1 game minute. Wow, that means in the space of one day, you would earn one month's wages, that might be a bit too much, too fast, unless they have really crappy jobs. I can work something out though, until I can find an alternate solution.

Update: A new day, a new idea... looking through the natives and I found DOES_OBJECT_OF_TYPE_EXIST_AT_COORDS, I hadn't thought of looking for objects instead of props. So a new checking process is in place... time to try it.

Okay... so that works, I now have a system that detects dropped money and knows when it has been picked up, which works when dead peds drop cash. What I don't get access to though, is the value of those pickups, so I am going to have to create my own "Assign random cash value" system based on the object type. The main types seem to be money piles and wallets, so I just need something reasonable for those objects... maybe £1 - $20 for money piles and $25 - £100 for wallets. Although in reality, I have no idea if anything other than money piles is dropped. As a main character, you get wallets from recovery missions when someone has been robbed, I don't think those occur as an addon ped... unless I create them that is.

At least this is a start on the Addon Ped money system.

And once again, it gives with one hand and takes away with the other. I have the dilemna of how to display the help text, whilst blocking the help text. I have to block that item, to stop it saying "You don't have enough money for ...." but I need it to display that component, so I can make it say my substituted message. I don't know if it's a scaleform or something else. I can't find anything other that instructional buttons that also allow me to display the input indicators but I don't want messages at the bottom, I want it to look like the normal game messages. This simple thing is probably going to be more difficult than the whole switching system, if I know my luck.

Update: I was going to do an update about money and telescopes, I had forgotten that I had already done money... probably because it happened more than 5 minutes ago.

Anyway, telescopes, an interesting excercise and the source of new discoveries. I wasn't sure how the animation-to-prop syncing was done, I thought it might be prop based but it turns out it isn't, the key is in the animation. There are two very useful natives:

GET_ANIM_INITIAL_OFFSET_POSITION and GET_ANIM_INITIAL_OFFSET_ROTATION

You pass them a position and a rotation respectively and you get back a position and a rotation. The position is where your character needs to stand and the Rotation.Z is the heading you need to be on. So you send the ped to the position, make them face the heading and then start the animation tasks. The result (presuming the ped is the right size), is perfectly synchronised animations and props.

The stumbling block with the telescopes was the actual props themselves and it's the kind of screw up that is so typical on multi-artist projects, when the project has an incompetent producer or art manager. Take a look at this image.

Notice how they are facing in opposite directions? What that means, is when you create the camera to provide the view, with one prop the camera inherits the rotation, on the other prop it needs a 180 degree addition. It's not a problem to do that but there shouldn't have to be that situation, props should be consistent both in direction and placement. The other thing you can see is that one has the origin in the centre of the prop, the other has it at the base, where it should be... it's just careless and that's what the producer and art manager are supposed to prevent happening.

I hadn't noticed the lens side of the Mount Chiliad telescope prop until now, it has twin lenses on the back, that means the single lens scaleform is wrong for that telescope, it should be using the binocular overlay but it can't because the telescope Timecycle modifier has a distortion based on a central lens. It's incredible to think a developer of Rockstar's status can make such elementary cock-ups. Then again, if you notice in that last video, there is a grating that is floating about a foot off the floor near the first telescope I used. Cock-ups are something they seem to excel at.

There were two main items with these props, the animation sequences and the camera view itself. I talked about the animations earlier and the camera view was another place I learned something new. Initially, I had the timecycle modifier working fine, then I added the overlay and the timecycle modifier went away. I tried a few things, none of them worked. So I remembered that the overlay was from the ob_telescope script, so I did some digging. I noticed one small section.

GRAPHICS::_SET_2D_LAYER(1);
GRAPHICS::PUSH_TIMECYCLE_MODIFIER();
GRAPHICS::DRAW_SCALEFORM_MOVIE_FULLSCREEN(iLocal_81, 0, 0, 0, 255, 0);
GRAPHICS::SET_TIMECYCLE_MODIFIER("telescope");

Adding those lines instead of the simple set timecycle modifier line I was using, cured the problem. I now had the scaleform with the timecycle modifier behind it. So I now had telescopes I could use and a money system that let me pay for them. I really need to sort that help text out though, because if I don't, I will need to create sprites for every message related to the things I want to use. I asked a question on GTAF... makes me wonder where that tumbleweed GiF went.

Update: Some small changes to the money position and display functionality, plus I have the exact game colours now. The normal game money display has a thick black edge that I can't replicate, I think that might be the scaleform display.

Update: New things discovered today... IS_ENTITY_IN_ANGLED_AREA. I couldn't sus this out at first and the only information that had been posted about it, was wrong. So I began to investigate and now understand exactly how this works and how powerful it is for area detection.

There are 3 elements to the check, an origin point, an edge point and an angle. This image explains it a bit clearer... Note, I got Point 1 and Point 2 the wrong way round. Point 2 is the Origin and Point 1 is the top of the Edge. In Pythagoras terms, Origin to Edge is the Hypotenuse and Edge is at the top of the Opposite. The whole thing is based on right-angled triangles, which is I presume, where the name came from.

If you use Entity.GetOffsetInWorldCoords(), you can align this check with a prop. This has proved perfect for my telescope detection, as I can now define a narrow window, in just the right place where the player will get detected. You can see in the next (poor quality) video how precise it can be.

Update: Well I have a dilemna again. I had planned on storing outfits and weapons but now I am not so sure. I always play with unlimited weapons/ammo, so I might as well just give them all weapons. I don't understand the weapon setup and the more I look into it, the less I want to know about it anyway. Outfits wise, I am only using good (as in well created, not well behaved) peds with this mod and those are ones that handle random outfits well... like anything from alex189 for instance. I never change the main player's clothes, so I think I might just leave the peds on a random config setting, as it makes them feel a bit less controlled.

I like to imagine that when I switch to a ped, I am really just getting a small snapshot out of their normal daily life, so the less control I exert over that, the more individual they feel.

Continued on Page 2