Just enabled objects Invisible after fast travel

[oc3]

Cool. Not too often I get to ninja the big dog to a solution ... woohoo!!

 

Oops, I spoke to soon. Sorry to say that it appears that it was a one time deal. I'll post a follow up, if you don't mind taking another look.

 

Thanks Striker.

[oc3]

Excellent.

 

Nice :ninja:, Striker.

 

:biggrin:

 

 

Oops, I spoke to soon. Sorry to say that it appears that it was a one time deal. I'll post a follow up, if you don't mind taking another look.

 

Thanks Hickory.

[oc3]

OK, I tried Striker's idea to start a new game, so I coc'd to my camp to add a fast travel marker, coc'd to three sisters inn, let the dialogue set the stage to 20, fast traveled back to camp, and all the camp objects were visible. However, I tried it again later and still having the same weird results.

 

 

I'm thinking it shouldn't be possible for another mod to be causing this since my objects all have unique base object names. Is that correct?

 

Anyway, I went looking for another cause. I had all of the camp objects with Ref editor IDs. I decided that was wrong so created anew objects with unique base object names, but no ref editor ID.

Except for the enable parent of course. Am I correct that you can only enable an object via script if it has a ref editor ID?

 

Anyway, after doing this, I am now having random results, regardless of which save I use. Sometimes all objects render fully, sometimes only a few of them. But almost always some will render. And at all times the collision is there for everything.

 

Is it possible that it is the way I am enabling them. I know I had to stop setting quest stages in the topic results because the log entry window would not display. Could it be something similar?

 

I hope I'm not being a bother. You guys have already earned credits, by the way.

 

OC3

[Striker879]

Oh great, so I'm back to Striker 0 Hickory 999. What's a guy got to do to get ahead in this world (just kidding).

 

Any time I've created a copy of a vanilla object by giving it a unique editor ID I've never created a unique reference ID (that field is always blank if I select Edit from the right click menu on the object shown in the Cell View window list). Hickory will know far more about whether or not a unigue refID needs to be assigned for scripts to reference (I'm no scripter) but I looked in the CS for an vanilla example.

 

The rats in Arvena Thelas basement for the Fighter Guild quest have a script attached to the base object shown in the Object window list (FGC01RatScript). When I look at the rats in her basement (AnvilArvenaThelasBasement cell) none of them show anything in the Reference Editor ID field (Base Object shown as 3571f). Like I say, Hickory will know far more than I can guess at.

[oc3]

Oh great, so I'm back to Striker 0 Hickory 999. What's a guy got to do to get ahead in this world (just kidding).

 

Any time I've created a copy of a vanilla object by giving it a unique editor ID I've never created a unique reference ID (that field is always blank if I select Edit from the right click menu on the object shown in the Cell View window list). Hickory will know far more about whether or not a unigue refID needs to be assigned for scripts to reference (I'm no scripter) but I looked in the CS for an vanilla example.

 

The rats in Arvena Thelas basement for the Fighter Guild quest have a script attached to the base object shown in the Object window list (FGC01RatScript). When I look at the rats in her basement (AnvilArvenaThelasBasement cell) none of them show anything in the Reference Editor ID field (Base Object shown as 3571f). Like I say, Hickory will know far more than I can guess at.

 

 

Hickory's pretty tough to beat. You almost had one there! Seriously, thanks for the help

[Hickory]

None of the camp objects need 'Persistent References' (if that is what you are talking about) other than the hidden parent that is called from the script. The parent 'must' have a persistent reference, because it is called from a global (quest) script, and won't be recognised otherwise. What you *must* do with each and every disabled camp object is to set their parent to the hidden object with the persistent reference. If you are not doing this, that is why objects are not showing up. When you enable the parent, all of the child objects assigned to it will 'appear' once it is enabled, any that have not had their parent set, will not. That is if I am understanding you correctly.

[oc3]

None of the camp objects need 'Persistent References' (if that is what you are talking about) other than the hidden parent that is called from the script. The parent 'must' have a persistent reference, because it is called from a global (quest) script, and won't be recognised otherwise. What you *must* do with each and every disabled camp object is to set their parent to the hidden object with the persistent reference. If you are not doing this, that is why objects are not showing up. When you enable the parent, all of the child objects assigned to it will 'appear' once it is enabled, any that have not had their parent set, will not. That is if I am understanding you correctly.

 

RIght, I completely agree and understand that concept. Not talking about the persistant ref check box, but the very top field when you double click an object in the CS. It's labeled as the reference editor ID. For an object to be enabled via script i.e saxCampParent. Enable, saxCampParent would need to be in that field, Right? or not. That is how BravilHouse's wall hangings parent is set up. I am using the exact same scheme and getting these results.:wallbash:

 

Right now, I have removed all parent references and am starting over just trying to get a single object to enable when it should. It's a tent with that exact ref editor ID (saxcampparent). I can't even get it to enable. At all. It's not invisible this time, it's just not enabled at all. Iv'e checked to make sure the quest is at stage 20, and it is. I'm using a quest stage result to enable it via 'saxcampparent. Enable'.

 

Starting to think I'm crazy.....

 

Oh, I forgot to say I abandoned making the parent hidden, since the vanilla Bravil House Quest used an initially disabled tapestry as its parent. Why not get rid of an unneeded object? The parent object is now the main tent itself.

[Hickory]

RIght, I completely agree and understand that concept. Not talking about the persistant ref check box, but the very top field when you double click an object in the CS. It's labeled as the reference editor ID. For an object to be enabled via script i.e saxCampParent. Enable, saxCampParent would need to be in that field, Right? or not. That is how BravilHouse's wall hangings parent is set up. I am using the exact same scheme and getting these results.:wallbash:

 

Right now, I have removed all parent references and am starting over just trying to get a single object to enable when it should. It's a tent with that exact ref editor ID (saxcampparent). I can't even get it to enable. At all. It's not invisible this time, it's just not enabled at all. Iv'e checked to make sure the quest is at stage 20, and it is. I'm using a quest stage result to enable it via 'saxcampparent. Enable'.

 

Starting to think I'm crazy.....

 

Oh, I forgot to say I abandoned making the parent hidden, since the vanilla Bravil House Quest used an initially disabled tapestry as its parent. Why not get rid of an unneeded object? The parent object is now the main tent itself.

 

Hang on... so you're saying that all of your objects have no editor IDs? They must. All objects in the game must have an editor ID. :confused:

 

As for removing the 'unnecessary' object... it's *not* unnecessary. It is there so that you do not use an object that may be used elsewhere. To do that would make every object with that ID disabled. Always use a bogus hidden (as in not in-game, and moved way down below, or to the side in the CS) parent object.

[oc3]

Hang on... so you're saying that all of your objects have no editor IDs? They must. All objects in the game must have an editor ID. :confused:

 

As for removing the 'unnecessary' object... it's *not* unnecessary. It is there so that you do not use an object that may be used elsewhere. To do that would make every object with that ID disabled. Always use a bogus hidden (as in not in-game, and moved way down below, or to the side in the CS) parent object.

 

They have editor IDs, the hex string number in the object window. I'm refering to Reference Editor IDs, (see pic below, courtesy of TES Alliance). It's the very top field.

 

http://i244.photobucket.com/albums/gg21/Darkrder/Tutorials/CSBasics/12.jpg

 

 

I just now ran across an article in the CS wiki saying that a persistant reference needs to have that top block filled in, and that is the name that you would use to enable/disable via a script. Does that sound right to you?

 

I created all new base objects for almost everything in my mod, to eliminate conficts and unwanted results, also.

 

I get what you are saying about the hidden parent, but If my parent is a unique base object and not used elsewhere, I should be OK, right? I'll probably switch back to the hidden parent just to be on the safe side anyway.

 

I finally decided at the end of the night to move the enable command from the quest result script, to the main quest script. The tent, which is curently the parent, did enable, but was still invisible.

 

I'm starting to think this is some sort of weird memory handling thing or something in the inner workings of the game engine itself. It's like everything but the texture gets loaded. The fact that all works well after coc to that location, not after fast travel has to be a clue. The game must handle loading the new location differently in those cases.

 

Thanks, for all the time. this has been a long one. If you tired of messing with it, I understand.

 

OC3

[Hickory]

I see nothing in your spoiler, nor the prior one with the script, so I'm still unaware of how you are implementing this. Same with Firefox and IE -- I don't know what's going on there.

 

A persistent reference is the name given to a 'placed' object in the render window, and it's name is 'Reference Editor ID'. The editor ID itself, which all objects must have, is the name in the 'Object' window called simply 'ID'. For instance, Pork Chop, the arena boar, has the editor ID of 'ArenaBoar', and a render window persistent reference of 'ArenaBoarRef'.

 

Yes, if your parent is unique, then you are fine there.

 

It is really odd, and I will admit that I'm having a difficult time getting my head around the idea that an object is enabling but staying invisible -- I've never seen that before. Without having the mod at hand I'm at a bit of a disadvantage, unfortunately.