[SCRIPT] MenuV Pick your Ped!

ReNNie

Ah phew

@ReNNie I have a set of debug classes for writing logs and displaying an output window on screen and I've left the reference for it in the script... it's on its way shortly, sorry about that.

We now have a working infopane and images for the categories.

Didn't get round to moving the customise options onto the main menu and I still have a non-functional menu item I need to decide what to do with... decisions, decisions...

I was going to post some images but it would be just PYR with different images and info text, so couldn't see much value there. I know I displayed the menu system already but the triple linked system was a step-up from the simple paired system in PYR.

But it's progress and progress of any kind is good.

ReNNie

alt text

Filled the csv with 224 entries and saw I was lacking in logic.
So I'll re-arrange some categories this evening.

Have had one crash where the log said the script simply stopped working.
It crashed while I was navigating through the drawable categories on this character.

As said, big step up from Meth0d's script and the trainer.
A wish would be to introduce the 'randomize' option from sjaak's Trainer.
For lazy users (like me) this lets the character's appearance over to chance on the press of a button...

@ReNNie said in [SCRIPT] MenuV Pick your Ped!:

It crashed while I was navigating through the drawable categories on this character.

I still have problems in that area and I'm not completely sure what causes it just yet. I'll download that character and test with it... can you remember what component you had selected at the time?

@ReNNie said in [SCRIPT] MenuV Pick your Ped!:

A wish would be to introduce the 'randomize' option from sjaak's Trainer.

That would rely on perfectly compatible sets of components and variations in all peds and from the peds I have seen, that isn't the case. It isn't even the case with the in-game peds.

Take those two you showed me the other day, they have three drawable components but only one is valid. If the drawables are valid, the variations might not be, causing sections to go invisible.

Randomisation of unreliable data is a recipe for disaster.

ReNNie

@LeeC2202 said in [SCRIPT] MenuV Pick your Ped!:

Randomisation of unreliable data is a recipe for disaster

I try to deal with this on a daily basis in my work as a policy advisor

Hmmm, I've tried the randomization on carface80's Sherry Birkin and a Momiji and thought it could an easy fix.

@ReNNie That Storm mod is a classic case of the extents of this problem. If you go onto Torso, there are 32 Drawables and 16 variants... but only 1 of them works. Considering a worst case scenario, that's a possible 512 combinations, of which only 1 is valid.

Imagine those odds in a Randomise function.

ReNNie

I see that. Think that's also why the script crashed .. the author used some ped from the game, morphed it, but didn't delete everything that wasn't used, hence false data inside

@ReNNie I haven't managed to crash it yet but I've only had a short time with it. I have turned on my debug info so I can get a better idea of what's happening... which I must remember to turn off again.

So progress so far today... zero. Potential progress tonight, also probably zero.

A combination of a nauseating vertigo attack and an increasing feeling that what I am making and what people want, are increasingly incompatible, is proving to be too great a distraction.

Maybe this is best used as a downtime day to just re-evaluate everything... more updates tomorrow perhaps.

Slowly easing my way back into this after what was a moderately pleasant day off.

First order of the day was to see what kind of mess was involved with a screw-up ped causing a crash and the results were truly staggering. If I didn't need to test this ped, I wouldn't have it anywhere near my PC... dreadful.

I mean, to give an example, here's my log output from a reasonably well-made addon ped:

[21:06:07] --->> Head : 1 : 3
[21:06:07] --->> Beard : 1 : 0
[21:06:07] --->> Hair : 3 : 3
[21:06:07] --->> Hair : 3 : 3
[21:06:07] --->> Hair : 3 : 3
[21:06:07] --->> Torso : 3 : 3
[21:06:07] --->> Torso : 3 : 2
[21:06:07] --->> Torso : 3 : 3
[21:06:07] --->> Legs : 3 : 2
[21:06:07] --->> Legs : 3 : 3
[21:06:07] --->> Legs : 3 : 3
[21:06:07] --->> Hands : 1 : 0
[21:06:07] --->> Feet : 1 : 0
[21:06:07] --->> Misc : 1 : 0
[21:06:07] --->> Accessories 1 : 2 : 1
[21:06:07] --->> Accessories 1 : 2 : 2
[21:06:07] --->> Accessories 2 : 1 : 0

The first number is the number of drawables, the second number is the amount of variations. Now as you can see, that's 17 lines long, which is fine for an addon ped.

The screw-up ped is so long, it would be crazy of me to post it... but as a hint, the Torso section has 32 (that's thirty two), drawables, several of which have 16 variants.

Now you're probably thinking "Well hey... that's pretty cool having all those options in an addon, what's the problem?". The problem is that out of those thirty-two drawables, only one of them isn't invisible... just one. And out of those sixteen variants, only two of them are different.

The log section for that ped is... wait for it... 144 lines long.

Now then... this is starting to get a bit more interesting... remember that 144 line log file I mentioned? How's about this for a haircut.

[23:10:34] --->> Head : 1 : 1
[23:10:34] --->> Beard : 1 : 1
[23:10:34] --->> Hair : 1 : 1
[23:10:34] --->> Torso : 1 : 2
[23:10:34] --->> Legs : 1 : 1
[23:10:34] --->> Hands : 1 : 1
[23:10:34] --->> Feet : 1 : 1
[23:10:34] --->> Misc : 1 : 1
[23:10:34] --->> Accessories 1 : 1 : 1
[23:10:34] --->> Accessories 2 : 1 : 1

That's every piece of extraneous drawable/variant removed and the only remaining variant, is the valid one on the jacket... now that's more like it.

Edit: Damnit.. these peds are really starting to p*ss me off with their crappy construction. Does anybody do these damned things properly? I mean I go into one Ped, select the head in OpenIV and what I get on screen is a pair of hands and the eyeballs. WTH is that all about?

Double-edit: Well, this turned very rapidly into a complete crock. Turns out that the meta-toolkit may, or may not, completely screw up an unrelated part of the model when you change something. In fact, simply decrypting and encrypting without any changes whatsoever, can screw up part of the model.

If that software worked, removing the invalid parts would be a piece of cake but out of two models, I have one success and one total failure. A 50% success rate is anything but inspiring. Right about now, this is turning out to have been a not very bright idea of mine.

ReNNie

Well at least I can have a future as a monkey-tester

'Storm' is a pretty good example of the mess that can be found, yes.

In the end crashes on those freakshow peds aren't a result of your scripting quality and perhaps you'll do best to just ignore it completely? As long as peds by authors like alex189, carface80 and MAESTRE work a-okay...

@ReNNie The daft thing is, Storm is the one I managed to fix, it seems to work fine now it is edited. It's one of those two from the other day that I am having the major problems with. They actually have drawables missing... completely.

I am going to do some more testing on that meta-toolkit today. I am going to try and decrypt a file, encrypt it, then decrypt it again, then compare the two sets of xml data to see if anything has changed.

If I can get an idea of what has changed, it might help... maybe it's the missing pieces that are the problem, not sure. Not a fun way to spend an afternoon but the only way I can cater for bad data, is to know exactly what causes it and what the end results are.

Shaezbreizh

@LeeC2202 sorry it's out topic but can we chat ? ( it's locked xS)
It's just for a little question

Well I did a test on the meta-toolkit and my worst fears... the two test files were identical.

I know that should sound like the best answer and in one sense it is but in another, it leaves a gaping unanswered question. If the two files are identical, why does a simple decrypt - re-encrypt - replace, break a ped model?

I also tried to add the customise options to the main menu last night and I didn't like how it looked. The options looked completely out of context with what was already there, so I think the double-menu is going to stay.

At the very worst, it creates an extra keypress to close down the menus.... I can live with that. I think the navigation aspect saves so many keypresses, it's a compromise worth accepting.

Well I seem to have discovered tonight that I can almost crash this at will in the customising menu. Something is obviously very wrong with my code for that section, so it's time to rip it apart and redo it... or just rip it apart.

The cup of motivation is well and truly empty today, not a drop in sight.

Edit: Well, the motivation might be gone but the inspiration seems marginally intact... I now can't crash it no matter how hard I try. One simple check (and adjustment) of a value was all that it was.

Okay, so what is probably the final post on this mod as far as updates go... I have removed the Change Player Model from the menu completely and moved the validation status into the menu footer. I think that's an important piece of info but having a menu entry just to display it was rather pointless. I had forgotten that the menu footer had a text property, so this solved the problem nicely.

This is how the menu looks in the final state.

alt text

The whole purpose of this mod and Pick Your Ride, was to allow access to addon content in a quick and easy fashion, allowing for large collections and rapid navigation. For me, they both do exactly that and I am happy with their final states.

Do they do everything a menu like this could possibly include? No, they don't if truth be told. But given that I am tired of jumping through hoops, to code round incomplete or broken data, they do about as much as I can bear under those circumstances.

So what does the future hold now this is complete?... In all honesty, probably nothing. I think this will be my last public mod, maybe even my last mod altogether. I might turn my attention to trying to convert at least one model to a ped addon while I still can.

What that unfortunately means, is that these mods and my menu system won't be going public. My chat is currently locked but I will change that in a few days. If anyone does want to have access to these mods (PYR & PYP) at that point, drop me a PM. It will be on the understanding that beyond bug fixes caused by the programme itself, no changes will be made beyond it's current condition. No features will be added or changed, it will be a WYSIWYG situation.

And on that note, I shall put the final packages together and spend the afternoon doing very little.

ReNNie

@LeeC2202 said in [SCRIPT] MenuV Pick your Ped!:

beyond bug fixes caused by the programme itself, no changes will be made beyond it's current condition

I'm beyond gratitude for this script as you may be well aware of.

Do have a small issue where upon 'wasted' I get an infinite loading screen.
Meth0d had this worked-around in his pedselector script by quickly changing to player_zero etc when you die.
Maybe you feel like implementing something like that one day? Or not...

//edit: Then again, you'd miss the wasted-animation from the add-on ped. Unsure.

@ReNNie I'm trying to do something with this idea but the problem is, I can't even bear to run the game at the moment. I ran it to make sure it updated correctly but I have zero motivation to run it again.

What happens if you have the pedselector script installed, does that take over the model reverting and prevent the game hanging.

ReNNie

Oh nice idea. I'll try that! And make sure you get some off time then. Take care!

I actually managed to drag some enthusiasm from somewhere today and thought I had come up with a good idea... and it was, until it didn't work as I had planned and had a gaping flaw in it. Yay Me!!

I added the facility to store and retrieve complete Ped configurations, the idea being that when the game first runs, or if you use the character switch wheel, the current player is stored as a "Player" config. Then if you use PYP, the ped you choose is stored as a "CurrentPed" config. The idea was, to wait until you had died and the screen started to fade, perform a quick switch to the stored Player config, wait until the screen started to fade back in and then restore the saved CurrentPed config. So you would effectively remain in the character you had changed into.

However, there are several issues with this system, one of the game's doing and some as a by-product of how the script system works.

If you change character and the game runs through a scripted playback sequence, like you walking out of the medical centre in the desert after you have died for instance, the spawned ped doesn't seem to be able to be used in that scripted sequence properly. I ended up stuck in the walls, falling through the floor etc... so that idea was (or might be) busted.

The only other solution I haven't tried to deal with this, is to detect when the screen is fading in, initiate a timer that waits half a second or so, then trigger the switch... just in case it is the initial positioning that is the cause of the problem. It does work where I wait until the player is under your control and then switches back but that is a seriously fugly solution.

If you reset the scripts after you have changed into a spawned ped, the script presumes that whatever model you are wearing, is the default player model, so stores that as the Player config. So when you die, it changes you into the character you already are, that is incompatible with that death sequence... black screen time. If you use PYP to change into another character, you then have two invalid configs stored, both of which will cause the black screen problem.

The other problem with this second one, is the script has no idea who you should be or who you were when you reset the script. You might be in the desert but that doesn't mean you should be Trevor etc... so I can't use location to decide. The "Let's just change into a predetermined character with no regard for who you should be", is a hack at best and as there is already a script that does that hack, I'm not going to duplicate it... I hate writing hack solutions.

There is another solution but to be honest, it's getting into territory so messy, I really don't like the idea. That would be to write out a temporary data file that holds the name of the character that was under your control after the game finished loading.

But on the face of it, I've probably spent some hours writing a whole bunch of code that is up there with chocolate fireguards on the useful scale. Not the best way to boost a flagging motivation problem.

aimless

@LeeC2202 If you havent you should. Set a bool to check if your mod changed the skin. It could be bad if another mod changed it. And both are doing changes.

Issues 1.
You can add a couple of steps so you sont see the change.
1 Check if dead or being arrested and if your mod changed skin.
2 Get model (optional)compenents, props, weapons.
3 Wait until screen has faded.
4 Switch to Michael.
5 Wait for is screen fading in.
6 Fade screen out.
7 Wait for player control.
8 Set model, (optional)compenents, props, weapons.
9 Fade in.

I know you like to do stuff yourself. Just an idea.

Actually ignore that if you read it, it's late, I'm tired and my get up and go has got up and gone...

@aimless Sorry if you read my post last night, I really wasn't thinking straight.

So just to go back to what you said, I usually have bool flags coming out of my ears with mods, so most state changes are flagged and monitored, so I am already doing that.

Number 2. in your list did highlight a wrong thought process I was having, with the fact I was trying to store the original Player's state. I wanted to give the player the ability to revert to whatever state the game loaded them in, hence my double config. If I reject that option, I only need to collect the state upon death or arrest, as you said. The fact that you can reset the scripts nullifying that initial state makes it a redundant process anyway. I over-think most problems and often create solutions far more complex than the problem requires.

What I won't do though is opt for the "Change to a Michael every time" option, if I can't solve the problem with keeping the spawned player change in effect... if you started playing as Trevor, it should revert you to Trevor. If I can't solve that problem, then I might as well just leave it to the existing mods to handle death and arrest changes.

The black screen issue is as I said last night though. It is way too long for two reasons. Firstly, the game would kick in the infinite loading screen after a few seconds, which requires a script reset to get out of. The second one being the length of time between the camera appearing after death and the time before you gain control of the player. In the desert, the camera appears a distance away looking directly downwards, then transitions to a position near the doorway, then watches the player walk down the steps... it's a long process.

I think there are enough potential negatives in there to make this a hopeless case. I could however use the configuration store/restore functions to maybe add custom outfit saving and loading... maybe.

Thank you for providing the steps though, it made me realise my error and reinforce my concerns, so it was very helpful.