ow.... okay. That's not a good sort of malfunction at all.

I wonder if that nature of the PDA breaks any part of the vanilla game.

I'll toss a message where the hummer's body creators can see it, seeing if its possible to make the sitting-in-hummer position unable to ever back the camera's position out of the hummer.

I don't know if this helps or not . . . but one thing the PDA mod does is RIGHT when you exit the pipboy (i.e. return to gamemode) it unequips and reequips your armor in a single frame. It does this because without 'refreshing' your armor, your pipboy arm will be mostly transparant. Maybe something is activating during that same time frame and causing problems?

We've had issues with PDA mod alongside FWE when trying to do things immediately upon exiting the pipboy. Adding a half-second delay the scripts in question has worked well to avoid this conflict.

EDIT:



Tarrant, what if instead of worrying about the landscape being ugly and such, you just made the weather pattern totally pitch black? Alternatvely, you could add an image modifer when in the travel worldspace with a lot fo blur or depth of field so even if in 3rd person, you wouldn't be able to see much. I dunno, just an idea.

Interesting, but does not sound like it. I happen to have a bunch of delays already built into the thing (its related to follower moves). Sesom said that the problem kicks in right after he gets into the hummer, and that is not done via the pip boy, that's a moveto as a result of hitting an activator and, there was a 20 frame delay between hitting the activator and the moveto being done.

Oh, you can hell bet that is what I tried first. An early version of Demo1 had that in it. I think some of the guts of that effort are still lying around in the .esp.

It looked completely unconvincing. I threw it away for that reason and went for this instead.

Only a idea. What if you check if the pipboy is equipped, before you display the message 'Use your pip-boy to ...'. If it isn't (which can't happen in vanilla) simply equip it on the player. It's the purpose of the car inside to open your pip-boy and choose the travel location.

Not sure what happens with the pda if you leave the car if it was forced equipped.

wow..

more wow..

holy wow..

you win... for ever. :celebration:

hm do you believe that would solve the PDA issue?

That message only plays once btw, but I can check at that point in time repeatedly of course.

Ya, I understood what you were saying. I was just mourning that the standalone wasn't gonna be the right solution.

@Tarrant

Ok, I think I got the solution and tested it with the PDA pipboy. It worked without problems. The player controls are correct after these changes to. No more accidental 3rd person. Sorry I have still no FO3 configuration without pda so further tests should be done. I changed HummerChairVault01LSCRIPT, added a short for checking if the pda is used and checked before/after Disable/Enable Playercontrols which are the critical sections:

..	if PlayerHummerRef.inside == 0		set PlayerHummerREF.inside to 1 ;this is returned to 0 in the hummer quest script should the player fasttravel away		If PlayerRef.getequipped PipBoy != 1 ; check for PDA			PlayerRef.equipitem PipBoy 1    ; equip it			resetPipboyManager                 ; and reset pipboy manager			set pda to 1                              ; make a mark that there is a pda		EndIf		DisablePlayerControls 0 0 0 1 0 0 0; no 3rd person view allowed while in vehicle  	endif...;Wait until standing-up player anim is complete, this also gives necessary time for followers to be moved out.	if waiting == 1		if playerref.getsitting == 0			set waiting to 0				If pda == 1 ; there is a pda				If PlayerRef.getequipped PipBoy == 1  ; player has it still equiped					PlayerRef.unequipitem PipBoy 1   ; so unequip it to keep the esthetic's 					set pda to 0                                ; mark isn't needed any more				EndIf			EndIf			enableplayercontrols...

Hope this helps.

hey thanks, can't ask for better help than that. I'll give it a try here shortly, it does not look harmful in any case.

I guess i have to credit you in the textfile when it comes out now, huh??? huh???

As you like... No need for credits it was only a tiny bit of troubleshooting.
My new slaver weapons for FNNCQ2 are producing a lot more headaches for me in the moment and I assume your follower transport system in the hummer does the same to you. :whistling:

Ahhhhh I think most of the headaches with that thing are solved for me. There is an open question of, very very occasionally, one follower not popping through. I'm going to see if I can pin it down. There may or may not be anything I can do about it in the existing framework - - although there is a way I can mitigate it if it happens to the regular followers whose definitions are originally resident in fallout3.esm.

EDIT: Here is your code as it went in. It required a fix btw.... codeboxes do not work for me on this board so, below looks ugly.. (why'd they change their board anyhow, this one screws my browser and I cannot leave the site sitting here, I have to close it out if I'm not actually looking at it ... it wasn't broken why'd they fix it yuck).

I've been tossing around an idea about how to get portable containers with an easier-to-work-with method of weight limiting.

Technically, NPCs can be containers too.

It was just a thought, but I'd assume it'd be easier (I haven't had time to test out that theory yet) to manage remote inventories like that. Downside I can see is that it would equip wearables onto the dummy actor that the gear is stored in.

It works exactly as you think it would, I'm using it now for the phalanx followers 'carried-only stuff'. I use robots to store the stuff, and the robots are in an inaccessible cell. Cell must never be entered by the player or, the contents of the robots' inventory will insta-empty.

I have not dug real deep into if I can make an NPC have an absolutely huge carry weight capacity. I was expecting not, and I already know that strength 10 is not enough to cause a teammate to be able to carry the large amount of gear I wanted to be able to stick in the trunk.

Well, that makes me feel a lot better about that idea, knowing it works. Though knowing it was already pretty normal stuff makes the subject a little less exciting. xD

Err so is the file in the OP the most up to date? i want to drive around like a bad-a$$

You can directly modify CarryWeight, so I don't see the problem here.

I thought carryweight was a derived sorta function which can't be really messed with directly. I shall certainly give it a try and see what it acts like.

Nilli - - neither .esp is finished, its just a demo of how it's looking as it starts to come together. I have not updated the zipfile itself with anything.

I'll let you know how this is coming along - -

The hummer's had its size changed a bit and some minor texture edits - I think it was an intention of the creators for some time to first have an oversized one but then to size it properly later in the process.

Its been given a whole lot of weight/inerta so that hopefully stuff will not knock it around, but, it seems that Zeta's Drone Cannon has the ability to move any moveable object it bounces against. That sort of thing is not something I care to spend a ton of time on - - i'll have some functions in place to where, if you move your hummer through the world using something such as a drone cannon, when you walk up to it and activate it again, the position will be corrected by my scripts. But it does look kinda funny to bounce the hummer along the terrain, chasing it with drone cannon balls.

In my copy here, 5 total locations are in, now. The locations do not take all that long to make once what I call a "good" spot is found - - good spot is one which limits the visibility enough to be able to do the visuals halfway decently for the sitting-in-car deal.

The transportation system's had some changes, in particular related to follower handling. It now seems that it will never, ever lose a follower, not a single one. The two new things which achieve this are - - never, ever using triggers, and instead always using what they call a "refwalk explosion" to detect their presence, and, never allowing the pathing system (IE: navmesh and linked doors) to assist the moves. Triggers seriously just miss the entry of mobs now and then (we're talking both the player and followers), it is not related to a mob entering and then exiting the trigger within one frame. And, pathing has an issue where, occasionally, mobs can either go into "limbo", or, end up standing at an area somwhat near Springvale High, in the water. It is not uncommon btw for the springvale high water deal to happen to followers during regular fast travel. My experience with those 3 problems while trying to effect follower moves was that it was not worth continuing to use triggers or allow pathing between the 2 move locations - - in particular when the trigger glitch might happen to the same follower as a limbo/springvale-water glitch. So - - follower moves are working great, but what it took to make that work was unexpected.

I'm a little concerned about CTDs. I think that rarely, it CTDs when you go to get into the vehicle. Will have to see over time what that's about and if it really is, I can try to slow down certain operations to see if it helps.

Once enough locations are in to make it able to work, I'll mess with a first version of a random encounter sort of ability.

I'll upload another zip soonish I think, once I get the changes that the newly-resized .nif require done in the .esp.

A little request from me. Please make the 'hummer inside' locations 'no respawn' zones. The reason is that FNNCQ Slaves are transported correctly with the hummer but respawn as soon as they land inside, because my 'respawn safe' transport mechanism is taken over by your scripts and doesn't work. It shouldn't do any harm to your mod or influence any other things.

Sounds like you've been getting your hands real dirty, Tarrant.

How has the trunk feature coming along? I'd like to know more about how you got it to work, if that's okay. I've been trying to come up with things like physical portable storage, so this could be advantageous to me in that respect.

I've put up a demo 4 esp/bsa set. Its got a number of internal differences (fixes/improvements/stuff) and 2 more locations. It lives at http://www.finhosting.fi/~fallout/downloads/development/Hummer-Demo4.zip .

There could be a savegame compatibility issue. If you have a save where you had hummer3 in it, and you try to load hummer4 and it CTDs instead of starting the game, try making a clean save without hummer3 loaded and then load hummer4 into that savegame.

If in practice, anyone seems to think that the items they stuck in the trunk inexplicably disappeared, I would be interested to know about that.



Let me know if demo4.esp fixes that for you. I set the alternate hummer worldspace as having the same encounter zone as wasteland. Here's to hoping that doesn't do more than I realized (heh).



That's like this - - you take a container and stick it somewhere where, either the player has positively been before, or, will never enter. Then, when you want the player to have access to the container, you do like

MyRemoteContainerREF.activate player

you can do that via any sort of script, such as dialogue result script (that's how I do Phalanx followers "Carried Stuff" inventories), or call it from the ONACTIVATE block of another activator (that's how the hummer's currently works).

by the way, if you use a player-only ONACTIVATE in any script, be aware:

do it like this

"begin onactivate

if isactionref player"


Never use "begin onactivate player", it doesn't work right, it's kinda not fair that it compiles.

Nope the new update doesn't help, setting the encounter zone to wasteland enables the respawn (the wasteland !!is!! a respawnable zone). I already tried to set the 'Hummer Wasteland' to 'no encounter' zone but still a respawn of the slaves is happening.

I know that isn't easy to solve because in FNNCQ I use a pretty tricky method to stop the respawn of the enslaved NPCs.

Before the player is fast traveling anywhere they are transported in a respawn free zone. As soon as the player has arrived they are brought back. The respawn happens if the NPC arrives before the player (normal game follower behaviour with fasttravel). If you turn this around the NPC stays the same and isn't respawning. My method is to check if the player opens the pip-boy in data mode and correct timing to get this done.

I am not sure if this is even possible safely with the hummer mod. I think the best way is I make a compatibility esp which saves the slaves before traveling with the hummer and bring them back after the player has arrived.

Btw. I recognized similar troubles with the FWE transport system.

But still you would make my modding live easier if the 'Hummer Wasteland' is a 'no encounter' zone if it is possible.

At the end something completely different. When adding & removing the PDA pipboy to the player add a flag at the end of the command so that is no message is shown for the adding/removing. The adding/removing sound is played anyways but pda pip-boy user should get used to it in the meantime . It happens all the time.

Alright I'll just make the zone its own little norespawn zone, and yeah I'll stick the code in the pda block for nomessage

btw the latest .esp has a ton of identical to master records... I think ... the next one I put up won't have that crap. Teach me to zip up an .esp and forget the cleanup FO3edit portion of the process.

That demo4 .esp turned out to have a nasty script bug in it eh ..... if anyone downloaded it, it would be best to get the fixed .esp.

An updated zip is up at the old Demo4 link, at http://www.finhosting.fi/~fallout/downloads/development/Hummer-Demo4.zip, or, download the .esp only at http://www.finhosting.fi/~fallout/downloads/development/Hummer-Demo4.esp


The interior-hummer worldspace has an encounter zone that should work for uh .... the slavers among us (we'll see what the feedback is), and a nasty script bug is fixed, and, I remembered to remove all the identical to master records this time (GECK sure likes adding those).

I was hoping to get my grippy little fingers on a stripped down copy of Wasteland worldspace living as a new one, because that would make adding locations go quite quick. I think Miaximus is taking a look into it for me. I messed with it a bit myself and have the impression that my PC cannot create such a thing, what with its 2 gigs of memoryt. What I could really use is the heightmap + landscape data for wasteland inserted into my hummer worldspace, and if the statics were there too, that would rule supreme, but I could live without those. Definitely no NPCs and so on, its just for what stuff looks like as you peek out the windows of the hummer.