is it possible to use player->additem "leveled item id" in the results of a dialog and get the player to receive the items contained in the leveled list designated rather than a blank item with the leveled item id?

i'd rather avoid having to script the chances for these items, so would placing a container and then adding the leveled item to that work?

and on a side note, does nolore happen to block forcegreeting?

Nothing blocks ForceGreeting as such, but nolore can cause no results to be available.

Leveled lists seem to be resolved when the game loads, so adding them to NPCs or the player will result in an item or items being chosen and added instead.

so then, what i would need to do is to make containers that contain my leveled items, through scripts, place them by the NPC, and remove it with another script, after the PC is done claiming the reward.

or i guess i could bite the bullet and script individual item chances in a "reward giver" script.

Just give the NPC or PC a leveled list (via dialog results). It'll automagically resolve when it enters the game. It's done quite often, like with almost every NPC ever.

that's the problem. instead of the leveled items getting resolved, i get one no icon item with the same name as the leveled item id i was using.

for example, instead of giving any gold at all, when i player->additem "RAK_Ransom_Gold" (a leveled item only containing gold) i get the cross-barred smiley, mousing over reveals it to be "RAK_Ransom_Gold"

Are there valid objects in the list? The original devs used a lot of leveled lists all around, and as you probably have seen (by not noticing), they do work like that. It sounds more like a bug with that list. Try using a stock list, if that works, troubleshoot just your list.

hrm. a bethesda default leveled entry "random_book_dunmer" still returned a null item. i'll try having the dialog start a script that uses additem "leveled list"

also, it seems the dialog result is not wanting to set "glabal_script_name".variable_name to integer. in this case, "RAK_tg_jobscript".status to 40. as "status == 40" is the "reset status" resetting variables to default and self-terminating the script, i think i'll switch to getitemcount "RAK_tg_jobmarker" < 1 as the conditional for resetting. RAK_tg_jobmarker is a "blank" item the player should never see, but is conditional to the greeting that uses the additem.

oh, i also think i figured out the forcegreeting issue. i have another "player"->getdistance check, and it seems that morrowind does not like checking the same variable unless its in one big elseif block.

i'll try the changes i mentioned, and get back.

edit, checked with script, rather than dialog. still got a null item. i guess i'll have to script individual item chances.

You shouldn't call GetDistance twice like that anyway, for speed. Use a float variable to cache the results, you may see an FPS boost. be careful with if/elseif sizes.

I don't know what's wrong with the leveled lists though, they're used a lot and I've never seen that happen.

i had thought that using two getdistance checks would not be that bad if they were cordoned off from each other like -

if ( status == 10 )    if ( ( GetDistance, "player" ) < 200 )        ;do stuff    endifendifif ( status == 20 )     if ( ( GetDistance, "player" ) < 150 )        ;do other stuff    endifendif

as to the leveled lists, i saw a thread about something similar happening with one specific added entry, but i could get neither normal or custom entries to give the appropriate items. only the "null" item.

it's probably for the best, anyway. scripting the rewards the way i did adds for a bit more flexibility in what you get.

now i've just got to figure out why

if ( random100 < ( variable1 + varable2 + variable3 == 98 )

returned false two times in a row.

I've never been able to make leveled lists put in player inventory work, scripted ifs with random is the way to go.

begin exampleshort i1set i1 to Random 1001; testing descending valuesif ( i1 > 900 )	player->AddItem "gold_001" 900elseif ( i1 > 800 )	player->AddItem "gold_001" 800; ....else	player->AddItem "gold_001" 100endifset i1 to Random 10001; testing ascending valuesif ( i1 < 1000 )	player->AddItem "gold_001" 100elseif ( i1 < 2000 )	player->AddItem "gold_001" 200; ....else	player->AddItem "gold_001" 900endifend

I don't know if this can help, but Random100 is a global short updated in the Main script when not in MenuMode, so until you exit dialog it is not updated.

yea, i ended up scripting the additem commands separately, using random100 and three other variables set to random 100 when the script initializes.

No, that's not bad at all then. If you know it will be called, you can still precache the results, just for code simplicity. But as long as you're not actually calling it twice, it won't be too slow.




Because that's epically invalid. And nobody has any idea how the MW VM will process it. It should, in theory, test if variable 3 == 98, then add that to 1 and 2, then check if that's greater than random100. But, there's no reason to believe it will. That should be split into at least 3 lines, using variables to store the data while you're working with it.


But it works for NPCs and containers... I wonder if a work-around would be to force-activate a container that has had the list added to it. I may also bring this up in the code patch thread, see if Hrnchamd can make lists resolve for the player.

i havent tried containers, but they do work when plugging them into NPC inventory in CS.

the 1 + 2 + 3 == 98 is for your convieniance, it's really a variable with 50, a variable with 48 and a variable with zero so that

( random100 < ( v1 + v2 + v3 ) )

think it would be less wonkey if did the equation before comparing it to random100 and stored it in a different variable, so that

set total to ( v1 + v2 + v3 )if ( random100 < total )    ;do stuffendif

also, if the leveled list thing can be solved with MCP in the future, i will be a happy RAK indeed.

You should, as a general rule, always do as little as possible in a conditional. The script engine has particular trouble handling that. Putting it in a variable ahead of time can avoid some crashes you might otherwise run into.

You might try force-activating a container with the list somehow. I know most vanilla loot containers use leveled lists, so that should work, as long as you can make sure the player activates it. Alternatively, add it to an invisible NPC or a creature (which might be easier) who has companion share, and use ForceGreeting then instruct the player to grab the item(s) they want. Either should be a work-around for the moment.

thanks for the tip about conditionals, i shall modify my scripts accordingly.

what i'm doing is a variation of my "send any fighters guild member out to find work". a dialog result starts a targeted script that disables the NPC untill a timer is greater than a time limit variable. the NPC is then re-enabled, and when the PC is within "speaking distance", the NPC forcegreets and adds items to the PC.

to me, it is important that the "item added" messages show up in the dialog, and that the dialog indicates you are talking to the correct NPC. what gets to me is that the script to do this is built from the original "fighters guild find work" script, yet there are important differences. for one, in the fighter script, i control the correct greeting by use of an item that transparently is added and removed from the PC's inventory. in this script, it is not removed transparently (itemx was removed from your inventory message in dialog)

regardless, i'm somewhat satisfied with the current version, where i scripted the random items, and changed the dialog marker item's name to something "discreet".