HerrBaron

meh; lemme keep looking at this... :(

Ok, I'll bite: have a look; maybe you can see something I'm not. This still always crashes the second time it's run! I'd rip my hair out, if I had any...! (Boy, the code tag here really, really sucks!) ScriptName WSTNHKExceptionListMgrScript ; - ; state machine states ; - short bInitList; short bMoveItems; short bClearList; short HotKeyIndex; int iListIndex; int HotKeyItemCount; int ItemType; int nItems; ref rHKBaseObject; Begin GameMode if ( bInitList ) ;-------- ; This part works every time... ;-------- ; Get a list of weapons assigned to hotkeys; these ; will not be removed. set HotKeyItemCount to 0; set HotKeyIndex to 0; label 100 set HotKeyIndex to HotKeyIndex + 1; if ( HotKeyIndex <= 8 ) set rHKBaseObject to Player.GetHotKeyItem HotKeyIndex; if ( rHKBaseObject ) set ItemType to GetObjectType rHKBaseObject; if ( ItemType == 40 ) printc "Adding %n", rHKBaseObject; AddFormToFormList WSTNHKItemList, rHKBaseObject; set rHKBaseObject to 0; set HotKeyItemCount to HotKeyItemCount + 1; endif endif goto 100; endif ; ( HotKeyIndex <= 8 ) set bInitList to 0; set bMoveItems to 1; elseif ( bMoveItems ) set nItems to Player.GetNumItems; if ( nItems ) ;----- ; I THINK this works every time, but can't be sure, since game CTD's. No way to check the console ;----- if ( HotKeyItemCount ) printc "HKItemCount = %x", HotKeyItemCount; Player.RemoveAllTypedItems StgWeaponsREF, 0, 1, 40, WSTNHKItemList; else ; No hotkeyed weapons, just take 'em. Player.RemoveAllTypedItems StgWeaponsREF, 0, 1, 40; endif ; ( HotKeyItemCount ) endif ;( nItems ) set bMoveItems to 0; set bClearList to 1; elseif ( bClearList ) set HotKeyItemCount to ListGetCount WSTNHKItemList; if ( HotKeyItemCount ) set rHKBaseObject to ListRemoveNthForm WSTNHKItemList, 0; printc "removed %0.f", rHKBaseObject; else StopQuest WSTNHKExceptionListMgrQuest endif ; ( HotKeyItemCount ) endif ; ( bClearList ) End

Hmm - I've never run a Label/Goto Loop inside an event handler block. I don't recall clearly but I may have read that that should not be done. I just use that type of block to set things up for a gamemode or menumode block to follow. I tried a similar test script on an armor token added to the player, with the same results. But generally, I use quest scripts sort of like subroutines, starting and stopping when needed. I like them because I can adjust the quest delay so they don't necessarily have to run every frame, depending on the application. My understanding is that all scripts are run in the same thread, sequentially. So you won't have a case where you have two scripts trying to change the same variable somewhere else at the same time, for example. Thanks. I think the NVSE guys could use some help because from what i've gathered, they are really busy with real-life concerns. Like work ;) That would be really cool if you could do that and they were receptive to it. Ah, guess I wasn't clear; the gamemode block is where I'm doing the clear loop, not in an OnActivate or whatever. That said, I've assumed that gamemode is an event handler of sorts, just called on the basis of being there for each frame. It's GREAT to know that scripts are run on the same thread sequentially; that eliminates a big worry and a great big can of worms debugging-wise... Very good points about quest scripts; I'll build a version of the script I'm having problems with to run as a quest script modelled on your example above; this may be all it takes. Roger on the receptive thing; real life must always trump pro bono stuff. That said, they do include the source code with each download. The NVSE guys are tops in my book; IMHO, they've contributed more to these games with their script extenders than anyone else, by enabling a whole class of high-quality mods that wouldn't have been possible without them. Thanks again, Ricker! Good to have you around! :)

Hey Ricker! :) Thanks for going to the trouble on this. Very revealing, in that you're doing this in a quest rather than in a block handler that's responding to an event. I note that when my script crashes (it CTD's; it doesn't just abort processing), it's always at a particular place in NVSE_1_1.dll. We know that this game engine multithreads, and I'm wondering if maybe we're hitting a threading race condition or infinite loop or a combination of the two. In the next couple of days, I'm going to build a debug version of nvse_1_1.dll, and do some stepping through in the debugger with it. If I find anything, I'll post it here in this thread, and send what I find to the NVSE guys. Maybe it'll save them some time and effort. BTW, you write very nice, clean code! :)

No doubt you've earned it; I suspect it's a very polished mod, and I respect the work that goes into those. Understand how you feel about NVSE, but there are some things you just can't accomplish without it. I resisted modding with it for a long time, myself, but as I got deeper into modding it, I found that there are a whole range of hoops you don't have to jump through with NVSE, and since most folks have it installed, I got over my qualms. My only issue with it, seriously, is that the form list support is so buggy; lists are essential in data processing; they're a natural data structure for a broad range of ComSci issues. They even invented a language once to work with them; it was called LISP. It didn't do much else well, but it did lists superbly...! :)

David, any idea if the TempCloneForm NVSE function has ever actually been there? GECK with GeckPU doesn't seem to know about it...? Thanks for the link; just checked it out. BTW, I'm gonna grab your quest mod as soon as I get back to playing instead of modding... :)

David, You understand perfectly. The reason it's necessary to clear the exclusion list is that if I don't, and the user changes hotkeyed items (weapons in this case), you end up with a continually growing savegame, a no-no! :) I'm just trying to find a workaround for an issue that does not seem to lend itself to easy solution, particularly after not getting responses to emails from the NVSE folks. I've even offered to help; I have all the tools and expertise needed. But even if I were to succeed in fixing the issue here, I certainly couldn't distribute it. As to the necessity of a persistent object reference, what Ricker suggests might work, in that the objects created by PlaceAtMe are, from the point of view of the game engine internals, instantiated objects, not simply types from which instances are created. We'll soon find out! :) I'm not sure how I would programmatically create a new form list? You can't PlaceAtMe with them, I don't think...? By the way, I wasn't disparaging the NVSE guys; I understand they're likely busy working stiffs like me, who out of pure generosity have created a wonderful tool for the community purely pro bono; God bless them! :)

David, You understand perfectly. The reason it's necessary to clear the exclusion list is that if I don't, and the user changes hotkeyed items (weapons in this case), you end up with a continually growing savegame, a no-no! :) I'm just trying to find a workaround for an issue that does not seem to lend itself to easy solution, particularly after not getting responses to emails from the NVSE folks. I've even offered to help; I have all the tools and expertise needed. But even if I were to succeed in fixing the issue here, I certainly couldn't distribute it. As to the necessity of a persistent object reference, what Ricker suggests might work, in that the objects created by PlaceAtMe are, from the point of view of the game engine internals, instantiated objects, not simply types from which instances are created. We'll soon find out! :)

That's a great idea! I'll give that a shot! :smile: I'm so used to being able to new something up in compiled languages, that this has kind of been eluding me. Thanks, Ricker!

:biggrin: Thanks, David; that was my thread. Unfortunately, his approach may have worked in FOSE, but not in NVSE; believe this is a base form / form list issue, and I know that persistent references work just great with form lists...

Ok, here's the thing: I've got a form list I use as an exclusion list for RemoveAllTypedItems. It's a known issue with the form list functions in NVSE that deleting the last item in a form list will crash the game; this is NOT the case with persisten references, so it would appear that the form list issue is centered around base forms in form lists only. I populate the form list using GetHotKeyItem, which returns base forms, not references. Elsewhere in my project, I use form lists to temporarily store persistent references, added and removed all day long without any adverse effects. So here's what I'm thinking; since GetHotKeyItem returns base forms, is there any way you can think of to 'convert' a base form into a reference to an object temporarily, so that the form list methods will work reliably in this instance? I hope I've stated this clearly; any ideas on this? Thanks, guys!

Hey Astymma, Yeah, all the above has been extensively rewritten several times now, finally ending up with the recommendations given by RickerHK, here: BethSoft forums. Turns out that calling rItem.GetObjectType was the problem; it needs to be called like so: set ItemType to GetObjectType rItem; It turns out that there are definite bugs in the formlist methods for removing items, so the recommendation was that I should replace them instead. Unfortunately, this approach doesn't work, either; the code MAY run the first time through, but crashes if you run it again. So I'm stuck, unable to get a nice, custom weapon storage container to work without crashing. Ah, well... Oh, and BTW, I had no idea I could use an alphanumeric name for a label; thought they had to be numeric only, so thank you for that; I find numeric labels to be very basic-like, and they offend my C++/C# sensibilities! :) Best, HB Ahh probably because it needs to be passed as a reference instead of being used as a reference caller since it's a base type. Right. Also, the issue with formlists in NVSE seems to center around baseforms only. I've used formlists elsewhere in the mod with permanent references (followers), and you can add and remove those references all day long. When you try to do the same thing with baseforms, that's when you get the crashes.

Hey Astymma, Yeah, all the above has been extensively rewritten several times now, finally ending up with the recommendations given by RickerHK, here: BethSoft forums. Turns out that calling rItem.GetObjectType was the problem; it needs to be called like so: set ItemType to GetObjectType rItem; It turns out that there are definite bugs in the formlist methods for removing items, so the recommendation was that I should replace them instead. Unfortunately, this approach doesn't work, either; the code MAY run the first time through, but crashes if you run it again. So I'm stuck, unable to get a nice, custom weapon storage container to work without crashing. Ah, well... Oh, and BTW, I had no idea I could use an alphanumeric name for a label; thought they had to be numeric only, so thank you for that; I find numeric labels to be very basic-like, and they offend my C++/C# sensibilities! :) Best, HB

lucky you! heheh! :)

Hi guys, It would appear that GetObjectType and Player.GetNumItems aren't working, always return 0. I'm calling GetObjectType with a reference returned from GetHotKeyItem after checking that it's non-zero, like so: ... set rItem to GetHotKeyItem ListIndex; if ( rItem ) set ObjectType to rItem.GetObjectType; if ( ObjectType == 40 ) ; weapon... ListAddReference WSTNExceptionsList, rItem; endif endif ... I'm cycling through the hotkey items for weapons prior to iterating the player's inventory to removing weapons from him into storage; I don't want to remove hotkey items. In preparation for iterating, I'm calling GetNumItems to determine loop boundaries, like so: set ListIndex to Player.GetNumItems - 1; GetNumItems is always returning 0. Can anyone shed some light on what's going on here? Thanks! P.S. MAN, what's with this EDITOR?? where do you shut off the HTML??

Basically something like that, yes. I'd probably set up an if/else block, so using that given example it would be something like: if DoEnable == 0 myObject.Disable myObject.MoveTo myMarker set DoEnable to 1 Return ;only needed if there is more code after this if/else block elseif DoEnable == 1 myObject.Enable 0 set DoEnable to 2 endif Obviously that may have to be changed around a bit depending on how you're using it, but the idea just not to do both commands in the same script iteration. Thanks! Great stuff. One of the first things I learned when I started to pick up TES scripting is that any resemblance to a "real world" programming or scripting language is purely incidental. Although this does seem to be a form of State Machine, right? I've not done enough TES scripting to have learned the finer points, so this tip is another for my notes! :thumbsup:

Try using this, but create a new door. I am not sure what they mean by Pre-Loaded furnitures. Try it wil This door I know it doesn't fit, but will work for testing. Thanks, Interfero; found something similar on the GECK wiki, but oddly, the door I'm using won't move consistently, only sometimes... pretty odd. Even tried using SetPos instead of MoveTo; no joy. What is meant by "pre-loaded furnitures" are Furniture objects that are placed in the editor. Unless they are created dynamically at run-time (with PlaceAtMe) SetPos and MoveTo have no effect on them. Statics are the same, but I don't think Doors have this problem (EDIT: just checked, and no they don't). To get the havok collision to update properly after moving (fixed) objects, Disabling then Enabling should be enough, but depending on what's going on you may need to wait a frame between those commands. Also, if you use "Enable 0" instead of just "Enable" you should be able to avoid the fade-in effect in most cases. At the risk of jinxing it, doing NVSE checks may get A LOT easier (and work better) relatively soon. Keep your fingers crossed. Hey, HugePinball! Fancy seeing you here; I'm actually getting ready to install the NV version of your Feng Shui; have it sitting in my downloads ready to go! Thank you for the above; didn't know about the 0 flag on the Enable function; I'll have to give it a try. One question, probably a stupid one; when you say "wait a frame", how would you do that in a GameMode block? set a flag and return?

PlaceAtMe should have been MoveTo & GetIsTeammate should have been GetPlayerTeammate. I'll never again post late night after coming from pub. Anyways glad You solved it! alho if I may say how does performance of filling list with all Actors from entire game looks ? - (2048 cells seems like overkill lol - yeah non-persistent references are unloaded, so it's not really that much of overkill) also why did You use "follower" condition in load cycle instead of in fill list cycle ? hahahah! It's the thought that counts! :) Nonononononono! 2048 is the SIZE of the cell, not the number of cells, it's a couple of kilometers, and I rarely get 7-8 actors. the 200 specified is the type of reference (ACTOR) and that limits it pretty effectively. Best to ya buddy! oh, and almost forgot; Merry Christmas! -HB

EzOn3, This update came out majorly sweet! Check your PM's! -HB

It sure would. If you're interested, there's a post floating around by Cipscis which talks about script performance. Where he times different logic to see which is the fastest. He noted that the more operators used, the slower the performance. It was actually faster to use separate conditional statements rather than "this && that && those && these" etc. ; Slower - checks all 5 every time if ( ( rFollower.GetCurrentAIProcedure == 11 ) && ( rFollower.GetPackageTarget == Player ) && ( rFollower.GetDisabled == 0 ) && ( rFollower.GetDead == 0 ) && ( rFollower.GetUnconscious == 0 ) ) ; Do stuff endif ; Faster - could even arrange by which are most likely to be true if ( rFollower.GetCurrentAIProcedure == 11 ) if ( rFollower.GetPackageTarget == Player ) if ( rFollower.GetDisabled == 0 ) if (rFollower.GetDead == 0 ) if ( rFollower.GetUnconscious == 0 ) ; Do stuff endif endif endif endif endif Or if you're dealing with a boolean (true/false), you can leave the operators out completely. It was faster to run an if/else with no operators than an if with. ; Slower - check if equal to 0 every time if ( rFollower.GetDisabled == 0 ) ; Do stuff endif ; Faster - not doing a logical comparison if ( rFollower.GetDisabled ) ; functions like "rFollower.GetDisabled != 0" else ; Do stuff endif So, something like this would theoretically be the fastest: if ( rFollower.GetDead ) else if ( rFollower.GetDisabled ) else if ( rFollower.GetUnconscious ) else if ( rFollower.GetCurrentAIProcedure == 11 ) if ( rFollower.GetPackageTarget == Player ) ; Do stuff endif endif endif endif endif Having it all on one line is nice and neat, but not necessarily the best choice - if you're talking performance. Edit: I think there's a max of around 10 nested if's though. Ez0n3, Good stuff; thanks! I did run across that thread of Cipcis', over at the Bethsoft forums, but admittedly didn't spend more than a few minutes perusing it. I did intend to go back... Anyway, when I'm not focusing on the 'day job' (30 yrs+ as a software engineer), I've been focusing on getting this mod upgrade working, then getting it to work better... :thumbsup: Great suggestions you've made; I'll be using them. I'm very partial to the "If yada" notation; I use it in real life development all the time, but it seemed to me that I had some issues with it in TES script way back, so have kinda stayed away from it. The only thing currently in the quest script for the tent is a one-time Player.AddItem to stick the manual in their inventory, then I call StopQuest on it, since it never needs to execute again, so maybe I'll work that into a global flag, as well, and remove the StopQuest call. Anyway, thanks for all this; I'll be back! Best, -HB

Well, got it working very nicely; gotta test it for a while though. I've attached the Entry code as a .TES file, since the code markers make a mess of the embedded code. All I have to do now is set up the quest code to check for NVSE and warn the user, and test for a good while. I used several of the suggestions from you guys; many thanks for helping me make a better mod than I had before! :) Best! -HB P.S. it sure would be nice if the GECK could process line breaks in long lines of code; not doing so makes it tough to write complex conditional code, because it all has to go on the same line...

thc1234, Working on something like this as we speak; I was trying to stay away from NVSE (Not because I don't like it, NVSE is terrific; I was just hesitant to introduce it into my codebase if I could think of another way to do it...). I'll post back as soon as I get it working, and let you know how it worked out! BTW, isn't PlaceAtMe only useable with form id's, not persistent references, like, say, BooneREF or VeronicaREF? Since there's only one of these each in-game, wouldn't you be creating copies of them, and bloating the game saves? You're right; they are ALL pervs; you should SEE what they get upto in that tent when my back is turned! :P -HB

Try using this, but create a new door. I am not sure what they mean by Pre-Loaded furnitures. Try it wil This door I know it doesn't fit, but will work for testing. Thanks, Interfero; found something similar on the GECK wiki, but oddly, the door I'm using won't move consistently, only sometimes... pretty odd. Even tried using SetPos instead of MoveTo; no joy. -HB

Hey folks, I'm the guy who built HB's Wasteland Tent, and I'm looking to upgrade it to accomodate companions beyond the vanilla ones. These were easy, since they're present in the FalloutNV.esm. The issues and questions revolve around a characteristic of the Havoc door objects; when a door is moved, its' location is not updated by the engine; believe me, I've tried several different ways. Hence, the Wasteland Tent doesn't use a door; just a couple of travel markers and the MoveTo function (for both the player and the vanilla followers subject to some checks to make sure that they're actually following, not waiting and not disabled). In other words, the Tent model itself is an activator. As stated above, I'd like to be able to support other companions, such as Fake Plastic Trees EDE and GurkMeja's Sunny Smiles Companion (and a number of others recently uploaded to Nexus). One of the things I've tried to do in preparation for this is to generalize the code which tests follower/waiting/disabled status before moving a follower into or out of the tent after the player. I did this with a formlist and NVSE to loop over and process it. It doesn't work, even for the vanilla followers, apparently because the engine has no way of knowing that an aliased reference to a reference (set rFollower to ListGetNthForm VanillaFollowerList, index). When you attempt to test variables through rFollower, the engine has no way of knowing that rFollower actually points at a follower with a script which contains variables like Waiting. I've only been able to make it work for vanilla followers by duplicating the same conditional code block for each one. So, if generalizing this code doesnt' work for vanilla followers, it seems to bode ill for others not even in FalloutNV.esm. Anyone have any ideas as to how I might: A) get a door object to actually update its world location if moved, or B) Generalize the entry/exit code in such a way as to make it possible to test both vanilla followers and any others I might add to the list in the course of play? I've been fighting this for weeks, now; if anyone has any workable ideas, I'd be most grateful. Thanks! -HB

Hi folks, I'm the guy who built HB's Wasteland Tent... I'm looking to build a companion compatibility addon for the tent which will need to know if the tent mod itself is loaded, and am looking for the best way to accomplish detection of the tent mod without using NVSE. Nothing against NVSE, I love it and run it; but out of deference to those who don't, it would be best if I didn't have to use its' IsModLoaded function. I've considered using the GetScriptVariable vanilla condition function, but do not know what its' behavior is if the requested variable doesn't exist. Any ideas here? Many thanks! -HB Edit: Nevermind; I'll just use a global variable.