[RELz] DLL - Dynamic Leveled Lists : IV - Oblivion

» Wed Mar 30, 2011 7:45 am

Any ideas?

The only thing that comes to mind would be if the LLs didn't have "process all levels <= character level" turned on. I could see that causing more multiple spawns, since the lower-level critters would (presumably) be a higher-level selection when in groups, but it really seems like a long shot as an explanation for the numbers I'm getting in-game.

What level is your character, btw, ndervish?

Ten.

If you want to try the DLLsixport on your own.. you'll have to take the DLL.esp out of the mods to omit exceptions folder and run the exe again. Then do your backup/update and then run "startquest DLLsixport"

The only file in my "Mods to Omit Entirely" is DynamicLeveledLists.esp.txt, which is empty, so I renamed it to DynamicLeveledLists.off.esp.txt; is that (effectively) what you meant? Then re-ran the exe and turned on DLLProcessBackupImmediately, started the game, waited for the backup, and ran the startquest. The resulting DynamicLLSingleExport.ini contains:

Spoiler

[-----------------------------------------2900457C]
10Name--------=Imp
10LeveltoSpawn=10
10Count-------=4
11Name--------=Imp
11LeveltoSpawn=10
11Count-------=3
12Name--------=Imp
12LeveltoSpawn=10
12Count-------=2
13Name--------=Imp
13LeveltoSpawn=10
13Count-------=2
14Name--------=Imp
14LeveltoSpawn=10
14Count-------=1
15Name--------=Imp
15LeveltoSpawn=10
15Count-------=1
16Name--------=Imp
16LeveltoSpawn=10
16Count-------=1
17Name--------=Imp
17LeveltoSpawn=10
17Count-------=1
18Name--------=Imp
18LeveltoSpawn=10
18Count-------=1
19Name--------=Imp
19LeveltoSpawn=10
19Count-------=1
110Name--------=Imp
110LeveltoSpawn=10
110Count-------=1
111Name--------=Imp
111LeveltoSpawn=10
111Count-------=1
112Name--------=Imp
112LeveltoSpawn=10
112Count-------=1
113Name--------=Imp
113LeveltoSpawn=10
113Count-------=1
114Name--------=Imp
114LeveltoSpawn=10
114Count-------=1
115Name--------=Imp
115LeveltoSpawn=10
115Count-------=1
116Name--------=Imp
116LeveltoSpawn=10
116Count-------=1
117Name--------=Minotaur
117LeveltoSpawn=10
117Count-------=4
118Name--------=Minotaur
118LeveltoSpawn=10
118Count-------=3
119Name--------=Minotaur
119LeveltoSpawn=10
119Count-------=3
120Name--------=Minotaur
120LeveltoSpawn=10
120Count-------=2
121Name--------=Minotaur
121LeveltoSpawn=10
121Count-------=2
122Name--------=Minotaur
122LeveltoSpawn=10
122Count-------=2
123Name--------=Minotaur
123LeveltoSpawn=10
123Count-------=1
124Name--------=Minotaur
124LeveltoSpawn=10
124Count-------=1
125Name--------=Minotaur
125LeveltoSpawn=10
125Count-------=1
126Name--------=Minotaur
126LeveltoSpawn=10
126Count-------=1
127Name--------=Minotaur
127LeveltoSpawn=10
127Count-------=1
128Name--------=Minotaur
128LeveltoSpawn=10
128Count-------=1
129Name--------=Minotaur
129LeveltoSpawn=10
129Count-------=1
130Name--------=Minotaur
130LeveltoSpawn=10
130Count-------=1
131Name--------=Minotaur
131LeveltoSpawn=10
131Count-------=1
132Name--------=Minotaur
132LeveltoSpawn=10
132Count-------=1
133Name--------=Minotaur
133LeveltoSpawn=10
133Count-------=1
134Name--------=Minotaur
134LeveltoSpawn=10
134Count-------=1
135Name--------=Minotaur
135LeveltoSpawn=10
135Count-------=1
136Name--------=Minotaur
136LeveltoSpawn=10
136Count-------=1
137Name--------=Minotaur
137LeveltoSpawn=10
137Count-------=1
138Name--------=Minotaur
138LeveltoSpawn=10
138Count-------=1
139Name--------=Minotaur
139LeveltoSpawn=10
139Count-------=1
140Name--------=Will-o-the-Wisp
140LeveltoSpawn=10
140Count-------=4
141Name--------=Will-o-the-Wisp
141LeveltoSpawn=10
141Count-------=3
142Name--------=Will-o-the-Wisp
142LeveltoSpawn=10
142Count-------=3
143Name--------=Will-o-the-Wisp
143LeveltoSpawn=10
143Count-------=3
144Name--------=Will-o-the-Wisp
144LeveltoSpawn=10
144Count-------=2
145Name--------=Will-o-the-Wisp
145LeveltoSpawn=10
145Count-------=2
146Name--------=Will-o-the-Wisp
146LeveltoSpawn=10
146Count-------=2
147Name--------=Will-o-the-Wisp
147LeveltoSpawn=10
147Count-------=2
148Name--------=Will-o-the-Wisp
148LeveltoSpawn=10
148Count-------=1
149Name--------=Will-o-the-Wisp
149LeveltoSpawn=10
149Count-------=1
150Name--------=Will-o-the-Wisp
150LeveltoSpawn=10
150Count-------=1
151Name--------=Will-o-the-Wisp
151LeveltoSpawn=10
151Count-------=1
152Name--------=Will-o-the-Wisp
152LeveltoSpawn=10
152Count-------=1
153Name--------=Will-o-the-Wisp
153LeveltoSpawn=10
153Count-------=1
154Name--------=Will-o-the-Wisp
154LeveltoSpawn=10
154Count-------=1
155Name--------=Will-o-the-Wisp
155LeveltoSpawn=10
155Count-------=1
156Name--------=Will-o-the-Wisp
156LeveltoSpawn=10
156Count-------=1
157Name--------=Will-o-the-Wisp
157LeveltoSpawn=10
157Count-------=1
158Name--------=Will-o-the-Wisp
158LeveltoSpawn=10
158Count-------=1
159Name--------=Will-o-the-Wisp
159LeveltoSpawn=10
159Count-------=1
160Name--------=Will-o-the-Wisp
160LeveltoSpawn=10
160Count-------=1
161Name--------=Will-o-the-Wisp
161LeveltoSpawn=10
161Count-------=1
162Name--------=Will-o-the-Wisp
162LeveltoSpawn=10
162Count-------=1
163Name--------=Will-o-the-Wisp
163LeveltoSpawn=10
163Count-------=1
164Name--------=Will-o-the-Wisp
164LeveltoSpawn=10
164Count-------=1
165Name--------=Will-o-the-Wisp
165LeveltoSpawn=10
165Count-------=1
166Name--------=Will-o-the-Wisp
166LeveltoSpawn=10
166Count-------=1
167Name--------=Will-o-the-Wisp
167LeveltoSpawn=10
167Count-------=1
168Name--------=Will-o-the-Wisp
168LeveltoSpawn=10
168Count-------=1
169Name--------=Will-o-the-Wisp
169LeveltoSpawn=10
169Count-------=1
170Name--------=Will-o-the-Wisp
170LeveltoSpawn=10
170Count-------=1
171Name--------=Will-o-the-Wisp
171LeveltoSpawn=10
171Count-------=1
172Name--------=Wolf
172LeveltoSpawn=10
172Count-------=3
173Name--------=Wolf
173LeveltoSpawn=10
173Count-------=2
174Name--------=Wolf
174LeveltoSpawn=10
174Count-------=2
175Name--------=Wolf
175LeveltoSpawn=10
175Count-------=1
176Name--------=Wolf
176LeveltoSpawn=10
176Count-------=1
177Name--------=Wolf
177LeveltoSpawn=10
177Count-------=1
178Name--------=Wolf
178LeveltoSpawn=10
178Count-------=1
179Name--------=Wolf
179LeveltoSpawn=10
179Count-------=1
180Name--------=Wolf
180LeveltoSpawn=10
180Count-------=1
181Name--------=Wolf
181LeveltoSpawn=10
181Count-------=1
182Name--------=Wolf
182LeveltoSpawn=10
182Count-------=1
183Name--------=Wolf
183LeveltoSpawn=10
183Count-------=1
184Name--------=Wolf
184LeveltoSpawn=10
184Count-------=1
185LeveltoSpawn=10
185Count-------=4
186LeveltoSpawn=10
186Count-------=3
187LeveltoSpawn=10
187Count-------=3
188LeveltoSpawn=10
188Count-------=2
189LeveltoSpawn=10
189Count-------=2
190LeveltoSpawn=10
190Count-------=2
191LeveltoSpawn=10
191Count-------=1
192LeveltoSpawn=10
192Count-------=1
193LeveltoSpawn=10
193Count-------=1
194LeveltoSpawn=10
194Count-------=1
195LeveltoSpawn=10
195Count-------=1
196LeveltoSpawn=10
196Count-------=1
197LeveltoSpawn=10
197Count-------=1
198LeveltoSpawn=10
198Count-------=1
199LeveltoSpawn=10
199Count-------=1
1100LeveltoSpawn=10
1100Count-------=1
1101LeveltoSpawn=10
1101Count-------=1
1102LeveltoSpawn=10
1102Count-------=1
1103LeveltoSpawn=10
1103Count-------=1
1104LeveltoSpawn=10
1104Count-------=1
1105LeveltoSpawn=10
1105Count-------=1
1106LeveltoSpawn=10
1106Count-------=1
1107LeveltoSpawn=10
1107Count-------=1
1108Name--------=Sheep
1108LeveltoSpawn=10
1108Count-------=3
1109Name--------=Sheep
1109LeveltoSpawn=10
1109Count-------=2
1110Name--------=Sheep
1110LeveltoSpawn=10
1110Count-------=2
1111Name--------=Sheep
1111LeveltoSpawn=10
1111Count-------=1
1112Name--------=Sheep
1112LeveltoSpawn=10
1112Count-------=1
1113Name--------=Sheep
1113LeveltoSpawn=10
1113Count-------=1
1114Name--------=Sheep
1114LeveltoSpawn=10
1114Count-------=1
1115Name--------=Sheep
1115LeveltoSpawn=10
1115Count-------=1
1116Name--------=Sheep
1116LeveltoSpawn=10
1116Count-------=1
1117Name--------=Sheep
1117LeveltoSpawn=10
1117Count-------=1
1118Name--------=Sheep
1118LeveltoSpawn=10
1118Count-------=1
1119Name--------=Sheep
1119LeveltoSpawn=10
1119Count-------=1
1120Name--------=Sheep
1120LeveltoSpawn=10
1120Count-------=1
1121LeveltoSpawn=10
1121Count-------=4
1122LeveltoSpawn=10
1122Count-------=3
1123LeveltoSpawn=10
1123Count-------=3
1124LeveltoSpawn=10
1124Count-------=2
1125LeveltoSpawn=10
1125Count-------=2
1126LeveltoSpawn=10
1126Count-------=2
1127LeveltoSpawn=10
1127Count-------=1
1128LeveltoSpawn=10
1128Count-------=1
1129LeveltoSpawn=10
1129Count-------=1
1130LeveltoSpawn=10
1130Count-------=1
1131LeveltoSpawn=10
1131Count-------=1
1132LeveltoSpawn=10
1132Count-------=1
1133LeveltoSpawn=10
1133Count-------=1
1134LeveltoSpawn=10
1134Count-------=1
1135LeveltoSpawn=10
1135Count-------=1
1136LeveltoSpawn=10
1136Count-------=1
1137LeveltoSpawn=10
1137Count-------=1
1138LeveltoSpawn=10
1138Count-------=1
1139LeveltoSpawn=10
1139Count-------=1
1140LeveltoSpawn=10
1140Count-------=1
1141LeveltoSpawn=10
1141Count-------=1
1142LeveltoSpawn=10
1142Count-------=1
1143LeveltoSpawn=10
1143Count-------=1
1144LeveltoSpawn=10
1144Count-------=1
1145Name--------=Stunted Scamp
1145LeveltoSpawn=10
1145Count-------=3
1146Name--------=Stunted Scamp
1146LeveltoSpawn=10
1146Count-------=2
1147Name--------=Stunted Scamp
1147LeveltoSpawn=10
1147Count-------=2
1148Name--------=Stunted Scamp
1148LeveltoSpawn=10
1148Count-------=1
1149Name--------=Stunted Scamp
1149LeveltoSpawn=10
1149Count-------=1
1150Name--------=Stunted Scamp
1150LeveltoSpawn=10
1150Count-------=1
1151Name--------=Stunted Scamp
1151LeveltoSpawn=10
1151Count-------=1
1152Name--------=Stunted Scamp
1152LeveltoSpawn=10
1152Count-------=1
1153Name--------=Stunted Scamp
1153LeveltoSpawn=10
1153Count-------=1
1154Name--------=Stunted Scamp
1154LeveltoSpawn=10
1154Count-------=1
1155Name--------=Stunted Scamp
1155LeveltoSpawn=10
1155Count-------=1
1156Name--------=Stunted Scamp
1156LeveltoSpawn=10
1156Count-------=1
1157Name--------=Stunted Scamp
1157LeveltoSpawn=10
1157Count-------=1
1158Name--------=Stunted Scamp
1158LeveltoSpawn=10
1158Count-------=1
1159Name--------=Stunted Scamp
1159LeveltoSpawn=10
1159Count-------=1

I'm not quite sure how that relates to the actual LEVCs that get used in-game, but I don't see any listings there for flame atronachs, clannfears, or any of Fran's added creatures; scamps/stunted scamps are the only things I've been fighting since upgrading to 2.03 which appear by name in that data. But that observation did spark a connection... I think that scamps may be spawning in correct numbers, as are flame atronachs, and I've only run across single dremoras. It's been rock golems, hernes, and maybe elder scamps (hard to tell when there are normal scamps also running around) that are almost always spawning in fours. But it's not just a vanilla vs. Fran's distinction, because silver golems also seem to be spawning in proper quantities. (Edit: Perhaps I spoke too soon. After posting this, I went to play and promptly entered a bedroom in Castle Kvatch to find it packed full of a roiling mass of enemies. With a little tgm and tcl action, I was able to count one scamp, one elder scamp, three hernes, and eleven silver golems.)

I dunno. Could just be coincidence, but it's a potential starting point.

I'm going to try to get the Pluggy file backup system working. Not only will that make saving better, but it'll also make it super easy to see the state of all your LLists. No exporting.. just open up your backup pluggy file!

Sweet! Any idea when it should be ready?

» Tue Mar 29, 2011 11:55 pm

One: I found a small bug that could explain why -some- epic creatures are spawning "more often", as if they're in Normal Tier. But it wouldn't explain why they're spawning in large groups. I had fixed this earlier, but it somehow got reintroduced. >8(

So, get the patch to fix that issue. But the spawning mobs issue might still be there.
Try turning on "DLLMoreAccurateCounts" and see what happens.

--------------

Hehe, I'll be working on it, but can't give an eta really. Finals week is upon us! *hiss*

» Wed Mar 30, 2011 6:45 am

Can't really contribute much to the technical side of things, but the SGL concept and Pluggy system sounds good.

Anyway, wow another patch. *grabs* Little report based on a quick run with v2.03. Journeyed south from Harcane Grove all the way to Leyawiin, found very little spawns but that may just be a coincidence. Still came across lowbies like a level 12 jaguar (or was it a lion?), level 16 spider daedra and a level 32 ogre. My DLLlowTierCutLine is at 10 so shouldn't be seeing those I think.

Then came across a whole pack of http://i51.tinypic.com/2ir18hf.jpg, 9 of them in all. Nasty. Can't tell how many spawn points there are. A bit further on I saw 1 level 64 Ottfried, then at another spot a trio of them, nothing too bad. The crazy mass spawn happened near a bridge, http://i52.tinypic.com/2m4dd93.jpg type. Did a check in the CS, loading up all the main FCOM mods, there're only http://i55.tinypic.com/5mhagj.jpg at that location. One is LL1RoadBandit35 and the other LL1RoadBandit65. The mobs were clustered at those two spots so it's not very likely there're more spawn points added from another mod. Further down the road was another LL1RoadBandit65 with 5 spawns. It seems the spawn count settings are producing high spawns more often than not. Ended the trip in an Ayleid dungeon, Arpenia. There were no mass spawns inside, just some level 1 giant rats, level 21-22 Ravager archers and level 31-32 Warlords.

So, lots of inexplicable weirdness.

Could it be something to do with how the lists were set up? No clue here. Will test the new version soon.

» Wed Mar 30, 2011 4:50 am

OH! Explanation for the mobs that are lower than your cutoff:
[DLLReviveEmptyLLists]

If a LList won't spawn anything due to your DLL settings and current level (cuz you're an ungodly huge level), then it'll randomly spawn anything that's a lower level than you.

Essentially it revives the LList to spawn SOMETHING, even if it's pansy. Perhaps you're running into wilderness spawnpoints that don't have pc offset creatures, and they're dead lists being revived.

----------------------------------

Damn, that is so weird. I don't even know how it's possible for DLL to spawn 8-9 bandits at a single spawnpoint.
Unless: DLLSpawnForceButton = 0? I highly doubt you turned that off, though.

It's almost like the game is spawning the spawnpoint multiple times on area load.

I'll see if I can make a DLLsixport that you can type a custom target LList for. That way you could do an export of LL1RoadBandit65 to see if it's DLL screwing up the LList, or the game doing multiple spawnpoint triggers.

*shakes head* We'll get it, but seriously.. creepy weird.

» Wed Mar 30, 2011 12:24 pm

Essentially it revives the LList to spawn SOMETHING, even if it's pansy. Perhaps you're running into wilderness spawnpoints that don't have pc offset creatures, and they're dead lists being revived.

I see, that's good to know.

Is it possible for DLL to make it spawn creatures that are around the same level as the character in these cases? One of the main reason I installed DLL in the first place, thought it might help with low level spawns in dungeons that I can wipe out in a few minutes.

Damn, that is so weird. I don't even know how it's possible for DLL to spawn 8-9 bandits at a single spawnpoint.
Unless: DLLSpawnForceButton = 0? I highly doubt you turned that off, though.

It's almost like the game is spawning the spawnpoint multiple times on area load.

Yep, odd. And yes DLLSpawnForceButton is at 1.

» Wed Mar 30, 2011 5:59 am

I see, that's good to know.

Is it possible for DLL to make it spawn creatures that are around the same level as the character in these cases? One of the main reason I installed DLL in the first place, thought it might help with low level spawns in dungeons that I can wipe out in a few minutes.

Well, that's the thing, those LLists we're talking about don't have anything near your character level. I have it set to equally roll between any creature lower than you, but I suppose it could -always- spawn the highest level creature on the list, but I feel like that might lead to some strange repetitive spawns in the wrong circumstances.

I hear that you don't want a dungeon full of lowbies. The best DLL could do is just spawn the highest level creature, which would mean that dungeon would just end up being ONLY that creature since it would spawn every time.. and even then the dungeon could STILL be easily wiped since it's so low as to be below your Low Tier Cut Line.

If that were to happen, it would just be the fault of the level/LList designer for not putting any PC-offset creatures in. DLL can't force one onto the list.

--------------------------

So, since it HAS to be an easily wiped creature.. and you're gonna kill it easy whether it's 25 or 2 (since you're 65 bajillion), I'd rather have the variety in spawns then always spawning the level 25 creature.

Just my thoughts. 8) It's definitely do-able to always spawn the creature closest to your level, though.

» Wed Mar 30, 2011 3:51 am

Well, that's the thing, those LLists we're talking about don't have anything near your character level. I have it set to equally roll between any creature lower than you, but I suppose it could -always- spawn the highest level creature on the list, but I feel like that might lead to some strange repetitive spawns in the wrong circumstances.

I hear that you don't want a dungeon full of lowbies. The best DLL could do is just spawn the highest level creature, which would mean that dungeon would just end up being ONLY that creature since it would spawn every time.. and even then the dungeon could STILL be easily wiped since it's so low as to be below your Low Tier Cut Line.

If that were to happen, it would just be the fault of the level/LList designer for not putting any PC-offset creatures in. DLL can't force one onto the list.

--------------------------

So, since it HAS to be an easily wiped creature.. and you're gonna kill it easy whether it's 25 or 2 (since you're 65 bajillion), I'd rather have the variety in spawns then always spawning the level 25 creature.

Just my thoughts. 8) It's definitely do-able to always spawn the creature closest to your level, though.

Yep, odd. And yes DLLSpawnForceButton is at 1.

Let me get to that exporting function and Pluggy file backup then. 8) We'll see what happens once we get the means to investigate further

» Tue Mar 29, 2011 11:12 pm

So, since it HAS to be an easily wiped creature.. and you're gonna kill it easy whether it's 25 or 2 (since you're 65 bajillion), I'd rather have the variety in spawns then always spawning the level 25 creature.

Just my thoughts. 8) It's definitely do-able to always spawn the creature closest to your level, though.

Double post. o.o Is it possible to replace the LList for something suitable? Then again, would be tough to figure out what to replace with even if it's possible, and probably out of the scope of DLL. No, I agree with your argument, better leave it as is for the moment. At least things are much better than before, now I can actually get surprised by tough spawns and use some of the nifty powerful spells from Midas. ^_^

» Wed Mar 30, 2011 10:16 am

It would be pretty subjective. I'd have to make some system that polls the lists, finds which creatures are grouped together.
Something like.. Scamp -> usually on a llist with clannfear, fire elementals, etc ...
put that on the backup file

Then when a LList was empty, it would put the top few PC-offset creatures from that list onto the dead LList?
Seems like a bit o' work (and a lot of backup data) for something that I feel would happen rarely... but if I get everything else on the list done for DLL, why not?

Speaking of Midas.. it looks sweet, but from the videos it seems to just dump a load of god-spells on you. Cast and loot, haha.

How balanced is it, in your opinion?
Who knows? A time may come when I need another mod to merge into my setup and balance to keep me from actually playing.. XP

-------------------

Made the process for creating a save file associated with your character, yeehaw! Progress

» Wed Mar 30, 2011 1:38 pm

Midas' spells, you have to work to actually get the spells. Gather all the ingredients then make them, but some of the stuff aren't difficult to find and the spells do have skill requirements. Unbalanced or not, it's no problem as long as you show some restraints, the spells are far more fun than vanilla. Imagine calling down an Ion Beam on one of those crazy mass spawns, very satisfying. ^_^

» Wed Mar 30, 2011 10:50 am

Try turning on "DLLMoreAccurateCounts" and see what happens.

OK, I'll give that a shot when I get home tonight.

Hehe, I'll be working on it, but can't give an eta really. Finals week is upon us! *hiss*

Wow... I work at a university, yet I somehow completely missed that it's that time of year. (But, then, I have an excuse: I don't interact with students or instructors.)

Well, that's the thing, those LLists we're talking about don't have anything near your character level. I have it set to equally roll between any creature lower than you, but I suppose it could -always- spawn the highest level creature on the list, but I feel like that might lead to some strange repetitive spawns in the wrong circumstances.

I hear that you don't want a dungeon full of lowbies. The best DLL could do is just spawn the highest level creature, which would mean that dungeon would just end up being ONLY that creature since it would spawn every time.. and even then the dungeon could STILL be easily wiped since it's so low as to be below your Low Tier Cut Line.

An easy option would be to do 'fake' SGL spawns and, e.g., for a level 65 character getting a LEVC with only level 8, 12, and 25 mobs on it, spawn 8 of the lvl 8s, 5 of the 12s, or 3 of the 25s instead of just one (and then multiply from those numbers if Increased Spawn Button comes up). Although, really, if you're lvl 65 with some good AoEs (especially good Midas AoEs...), there's a strong chance you'd one-shot a group of 25s just as easily as a single 25, so it may not help that much anyhow.

It would be pretty subjective. I'd have to make some system that polls the lists, finds which creatures are grouped together.
Something like.. Scamp -> usually on a llist with clannfear, fire elementals, etc ...
put that on the backup file

Then when a LList was empty, it would put the top few PC-offset creatures from that list onto the dead LList?
Seems like a bit o' work (and a lot of backup data) for something that I feel would happen rarely... but if I get everything else on the list done for DLL, why not?

Definitely a bit of work to code up, but you could easily avoid the excess backup data by not doing that processing (or generating that data) until the player starts to outlevel their LEVCs.

Speaking of Midas.. it looks sweet, but from the videos it seems to just dump a load of god-spells on you. Cast and loot, haha.

How balanced is it, in your opinion?
Who knows? A time may come when I need another mod to merge into my setup and balance to keep me from actually playing.. XP

I used to use Midas back in my original Oblivion install and some of the spells were pretty interesting (if rather situational), but I chose not to install it this time around because I found the process of getting them to be a bit of a PITA. On the one hand, it's a cool concept to get the spells by going out adventuring to find certain components to create them is pretty cool. On the other, though, it quickly turned into having to keep a list of "DO NOT SELL THESE ITEMS!!!" beside me and remember to check it every time I visited a merchant (and, more often than not, forgetting to check it, selling the components I'd collected, and not noticing until the next time I got back to the IC and Midas' shop, by which point I didn't remember where I'd sold them and, even if I did, I wouldn't want to go back to a save that old).

I think it would be a lot better if he'd created all-new items to use for making the spells so that you could immediately see "I have a Midas Essence of Flame; I shouldn't sell that" instead of having to go look and see "Do I need this broomstick for a spell? What about that ruby? I think I've already finished collecting my five silver daggers..."

It also didn't help that I'm the author of Arrows of Channeling, which (I'm pretty sure) was the first of the mods which would let you cast your currently-selected spell by hitting with your weapon; with AoC, you shoot something with one of my arrows, and they take the effect of your current spell in addition to the arrow hit. Unfortunately, Midas' spells are all very heavily scripted and often do things like moving an activator to the player and casting effects from that, which makes them thoroughly incompatible with AoC, since the spell effect should emanate from the arrow's impact point rather than from the player. I seem to recall that a couple spells were also a 100% CTD if "cast" via arrow instead of normally. Since I used those arrows very heavily back then, I tended to be a little reluctant to use Midas spells even after I got them because of the problems it could cause if I fired an arrow without remembering to switch to a more normal offensive spell first.

» Wed Mar 30, 2011 11:47 am

One: I found a small bug that could explain why -some- epic creatures are spawning "more often", as if they're in Normal Tier. But it wouldn't explain why they're spawning in large groups. I had fixed this earlier, but it somehow got reintroduced. >8(

So, get the patch to fix that issue. But the spawning mobs issue might still be there.
Try turning on "DLLMoreAccurateCounts" and see what happens.

2.04 seems to have improved this greatly, if not completely fixed it. Working from a save made just before entering the Castle Kvatch Sleeping Quarters, here's what I found when opening the door:

No-DLL (making clean save):
- 2 flame atronachs, 1 scamp

2.04, DLLMoreAccurateCounts = 1
- 1 flame atronach, 1 silver golem, 4 hernes
- 1 flame atronach, 1 silver golem
- 2 flame atronachs, 1 silver golem

2.04, DLLMoreAccurateCounts = 0
- 3 elder scamps
- 1 flame atronach
- 1 scamp, 2 flame atronachs, 8 hernes

For each of the 2.04 variations, I turned on DLLProcessBackupImmediately, waited for it to finish processing, and quicksaved before entering the cell the first time, then quickloaded for the second and third trials. Given the no-DLL result, the other numbers seem reasonable.

The remaining odd bit is that I checked in the CS and that cell only contains one spawn point, so something else is apparently already intercepting spawn events and producing multiple LEVC rolls from a single spawn point. My best guess is that it would be Fran's doing this (I don't have MMM, Adrenaline Oblivion, or anything else like that installed), but I configured Fran's to not give a chance of increased spawns, since I was already planning to have DLL take care of that.

» Wed Mar 30, 2011 1:23 am

The remaining odd bit is that I checked in the CS and that cell only contains one spawn point, so something else is apparently already intercepting spawn events and producing multiple LEVC rolls from a single spawn point. My best guess is that it would be Fran's doing this (I don't have MMM, Adrenaline Oblivion, or anything else like that installed), but I configured Fran's to not give a chance of increased spawns, since I was already planning to have DLL take care of that.

Hmm the only Fran's plugin that seems likely is Optional Chance of More Enemies but it only contains LLists. The other plugins don't seem to have any script that does that either. Curious. Maybe it's an inherent engine thing instead of mod related, hard to determine.

» Wed Mar 30, 2011 6:10 am

I just installed version 2.04 and found a minor typo in the first message, but it might confuse some people i guess so i mention it here.

http://i176.photobucket.com/albums/w172/Illius_photos/Mod%20Problems/ScreenShot96.jpg

» Wed Mar 30, 2011 11:03 am

I seem to have hit an issue with 2.04... After running my earlier tests on that Kvatch spawn, I turned DLL off (for quicker saves), then flipped it back on after delivering Martin to Cloud Ruler Temple via fast travel. Going through the Bruma shops, about half an hour of play time after re-enabling DLL, I started getting multi-second freezes with sub-second periods of responsive time separating them - the behavior was very similar to the periodic updates I saw when I had turned on DLLProcessBackupImmediately for the Kvatch spawn count tests, except that a: it wasn't right after I started the game, b: there was no "I'm about to freeze your game by processing the hell out of your leveled lists" messagebox, and c: DLLProcessBackupImmediately is turned off in my .ini.

I turned on DLLPrintUpdateStatus and tdt to see what was going on and the console messages showed typically a dozen or so lists being processed during each of the brief playable intervals, then it would hit one (apparently difficult) list and stop on that one for the entire frozen period, although I suppose this could also be the result of output buffering, with the dozen lists that fly past having been processed in the previous freeze, but the messages not getting displayed until the game starts responding again.

I also noticed that a number would occasionally appear twice (e.g., "407 of 2776", "408 of 2776", "408 of 2776", "409 of 2776"), but I haven't turned DLLPrintUpdateStatus on before, so I don't know whether that's normal or not.

» Wed Mar 30, 2011 9:16 am

The .exe is also reporting as 2.03, and the readme too. Both minor and nobody reads the changelog except me anyway. o.o Lev, think you altered LL1VampireMagic100 for testing and forgot to change it back.

I also noticed that a number would occasionally appear twice (e.g., "407 of 2776", "408 of 2776", "408 of 2776", "409 of 2776"), but I haven't turned DLLPrintUpdateStatus on before, so I don't know whether that's normal or not.

Lev explained it to me a few posts back, basically it's normal.

» Wed Mar 30, 2011 2:23 am

Just got back from a scheduled 3 => actual 6 hour long final *gassp*

That's pretty strange

The strangest part is that the status numbers are close together. To me, since I understand/wrote the code, it means the main while loop is exiting after the normal amount of flops. As opposed to when you activate Immediate Backup, the while loop doesnt exit until 2000 flops have been processed. When you have immediate backup on, you see the output print message have status numbers that are widely apart 132, then 546, then 1025 or something. So, I know that it isn't a mess up with the Immediate Backup setting. If it were, the messages would not have been close, as you reported they were.

What that means to me is that a single flop's function (a single part of the update process, like, update levels, average LLists, calc entry counts, revive empty LLists) is causing so much CPU strain that your game is freezing up. That's... not supposed to happen. All of these functions are supposed to be quick short things.

I don't really know how to investigate this further without more information. Perhaps I'll put in a better debug printing system in the next patch.

-------------------------------------------------

If you do run into this issue again, here's what you could try to do to get me a better idea of what's going on:

save and quit the first chance you get.

Turn [ProcessTimer] to something like 5 (seconds)

Turn [ProcessSpeed] to 1, so it will only process one function of the update section at once.

Run the game and load that save. You'll see once every 5 seconds, a print message will come out like "Update process at X of 2043"

5 seconds later, another will come "Update process at X of 2043", it will be the same number, as it's still processing LList #X, but it's at the second function of the update process.

5 seconds later, another

another

at some point, you should experience that "freeze", open up the console and remember me how many "Update process at X of 2043" messages there were

If there's 3, then I know it was the Calculate Entry Counts function

4 would be the Revive Empty LLists one, etc

Try and do that for a few freezes. We'll see if any patterns emerge. Does it happen at EVERY llist? Does it happen on seemingly random LLists?

---------------------------------------

I'm going to try and put in a timestamp debug setup in my next patch. Probably would print out what function just ran, and the timestamp. That would help me figure it out for sure.

» Wed Mar 30, 2011 12:16 am

So another short run using 2.04, with DLLMoreAccurateCounts turned on. Decided to go over to Fort Doublecross, FPS dropped noticeably when I got close and thought that's a bad sign. Went into sneak to get closer, sure enough there was a huge horde at the entrance. Counted around 30 or so dead bodies after the fight, lost count. Inside the fort also had the mass spawns. Well at least the level range was ok, no lowbies. End of the run, total body count outside and inside was probably at 70-80, no exaggeration.

Pretty satisfied with DLL at this point, just need to figure out the mass spawn phenomenon and it'd be perfect.

» Wed Mar 30, 2011 4:30 am

EDIT:
Scrapped the "quickly" implementing the pluggy backup system idea. It's going to take longer than I first thought.

Going to run around some more and try and recreate mass-army syndrome. That needs to be bugsquashed asap

old post

Spoiler

Working on the pluggy backup system, as that will do two things:
1) Make you guys happy by cutting save times down to nil. It'll be as if DLL wasn't installed again. 8D
2) It'll help debug that damn army of creatures problem, since we'll all easily be able to see what DLL has for any LList without needing to do a 30m cond export

Sheesh though.. it's gonna take a lot longer to process, as I'll have to add a lot more flops

Just to get a creature reference I have to:
1) set a few pluggy strings
2) load from file the modname
3) load from file the creature formID
4) do a FindFormFromMod function to correct the creature formID for if the user changed loadorder

That'll need a flop of it's own.. XD

» Wed Mar 30, 2011 8:19 am

To me, since I understand/wrote the code,

You can't fool me... I know full well that having written the code doesn't necessarily mean you understand it.

What that means to me is that a single flop's function (a single part of the update process, like, update levels, average LLists, calc entry counts, revive empty LLists) is causing so much CPU strain that your game is freezing up.

That's pretty much what I suspected as well.

Side question: What led you to call your basic operations "flops"? Every time I see that, I have to remind myself that you're not talking about FLoating-point Operations Per Second...

If you do run into this issue again, here's what you could try to do to get me a better idea of what's going on:
...
Try and do that for a few freezes. We'll see if any patterns emerge. Does it happen at EVERY llist? Does it happen on seemingly random LLists?

My current quicksave is from while the freezes were happening, at about 300/2776. I'll change those settings, reload the quicksave, and report on the results after work tonight.

Edit: OK, I lied. I had about 5 minutes extra before leaving for work, so I gave it a quick try, just casting a Detect Life spell and watching the duration countdown to see when it froze. In the time available, I was able to see it completely process three lists (318-320) and start on a fourth. Each of the completed lists took seven passes to finish (i.e., it logged 318 seven times, 319 seven times, and 320 seven times). There was a brief hiccup on the third or fourth section of 319, but I didn't notice any prolonged freezes like I was getting last night.

I'll poke at it more extensively tonight and see if I can get you some better data.

Working on the pluggy backup system, as that will do two things:
1) Make you guys happy by cutting save times down to nil. It'll be as if DLL wasn't installed again. 8D
2) It'll help debug that damn army of creatures problem, since we'll all easily be able to see what DLL has for any LList without needing to do a 30m cond export

Yay!

» Wed Mar 30, 2011 1:17 pm

You can't fool me... I know full well that having written the code doesn't necessarily mean you understand it.

Haha, I didn't mean it in a schnotty know-it-all way.. I know the devious naughty ways code likes to sneak out of its room and party when it's grounded. XD

Side question: What led you to call your basic operations "flops"? Every time I see that, I have to remind myself that you're not talking about FLoating-point Operations Per Second...

Eh, I'm in school to be a computer engineer, dealing with digital logic gates we delt with transistor hardware flip/flops, which gives rise to multi-state hardware used for counters and other such things. First thing I thought of when I was writing the code. haha

Now if I could just drop the hardware part of my degree... Zzzz

I did some testing both of the army bug and the freezing bug.
I worked off of a vanilla setup with DLL only moderating Oblivions LLists. I roamed around a few dungeons, some of them a few times, and I didn't seem to notice anything army-like. I ran into four level seven atronarchs (or however you spell that odd variation of elemental) on my level 1 test character the first dungeon i entered. But, after further testing of the same dungeon that seemed to just be bad luck. I didn't run into many more of them, and most of the counts seemed normal.

I did come to the conclusion that my default count values may be sliightly on the high end to my taste, but whatever, haha. So, no conclusive findings on that issue from me 8\

----------------------

As for the freeze bug... I encountered it while processing my FULL setup to do the above test with mods. Ran into the same freeze at the same location twice. s'good because now I can investigate it properly. Looking into it in the morning

----------------------

As for the pluggy backup... the more I work on it, the more complex it looks to be.

In the current version, the creature refs in the array are automatically updated to the new modindex when the load order is changed. Not so with the file backup concept.

Instead of just referencing an array for the creature ref, I've gotta access file I/O, change some pluggy strings to get to the right section and LList, also grab the modname associated with the LList/Entry in addition to the formID, and then convert creature FormID to an OBSE string, do a cross reference to make sure the mod index hasn't changed since what was last recorded in the file. FINALLY, a creature ref... haha

I also can't really figure out a way to do quick replace, since the quick replace would need to access file I/O, it can't be done "quickly"... It would have to be normal speed, which means a longer period of vanilla LLists when people start up Oblivion. 8\

Ah well, I'm sure things will come together in my head the more I work on it. All in all, even if it does turn out to be this complex and everything has to take longer to process because of it, it's probably still better than the extended save times

» Wed Mar 30, 2011 12:36 pm

I worked off of a vanilla setup with DLL only moderating Oblivions LLists. I roamed around a few dungeons, some of them a few times, and I didn't seem to notice anything army-like. I ran into four level seven atronarchs (or however you spell that odd variation of elemental) on my level 1 test character the first dungeon i entered. But, after further testing of the same dungeon that seemed to just be bad luck. I didn't run into many more of them, and most of the counts seemed normal.

Did you happen to notice whether the number of LEVC picks you were getting seemed to correspond to the number of spawn points present? Might be worth playing with load orders a bit to determine whether the "pull multiple LEVC rolls for a single physical spawn point" behavior I saw last night was part of vanilla, coming from Fran's, or if it was another mod doing it. The mob armies may just be a result of that interacting with DLL's increased spawns - if two spawn points result in half a dozen LEVC rolls (due to Fran's/whatever) and DLL triggers increased spawns on a couple of those rolls, you could easily hit a dozen or more creatures total. If the source triggering the extra LEVC rolls scales itself up as you level, that would also explain why I'm seeing armies of around a dozen mobs, while Om is getting 30+ at a time.

As for the freeze bug... I encountered it while processing my FULL setup to do the above test with mods. Ran into the same freeze at the same location twice. s'good because now I can investigate it properly. Looking into it in the morning

Good to hear it's not just me! Since you'll be able to poke at it yourself, will you still need me to do any further testing/data collection?

Instead of just referencing an array for the creature ref, I've gotta access file I/O, change some pluggy strings to get to the right section and LList, also grab the modname associated with the LList/Entry in addition to the formID, and then convert creature FormID to an OBSE string, do a cross reference to make sure the mod index hasn't changed since what was last recorded in the file. FINALLY, a creature ref... haha

Yeesh... Would it simplify things any to do an up-front check when the game starts up to see whether the load order has changed? It sounds like you might be able to skip a lot of the extra steps if you know that the FormIDs will still be the same.

All in all, even if it does turn out to be this complex and everything has to take longer to process because of it, it's probably still better than the extended save times

Agreed. I know that I save a lot more often than I load, so I'd be a lot happier with a one-time delay of, say, 20-30 seconds, or even a minute, after loading (or, ideally, only on game-start, since that's the only time load order can change) while DLL rebuilds all of its internal data structures than with a delay of 5-10 seconds every time the game saves. (Especially since I have streamline doing auto-saves after each combat...) I expect that to be true for pretty much everyone else, too.

» Wed Mar 30, 2011 7:51 am

Did you happen to notice whether the number of LEVC picks you were getting seemed to correspond to the number of spawn points present? Might be worth playing with load orders a bit to determine whether the "pull multiple LEVC rolls for a single physical spawn point" behavior I saw last night was part of vanilla, coming from Fran's, or if it was another mod doing it.

My testing suggests that with vanilla + DLL, the army issue doesn't exist, one spawnpoint seems to be rolling once. I never saw more than 4 of any creature in my adventures. I ran through the same dungeon multiple times, and nothing I saw suggested any spawnpoints were rolling twice. I do believe it's a mod we're all using + DLL, and I'll probably confirm it when I do the same test with all my mods running.

Good to hear it's not just me! Since you'll be able to poke at it yourself, will you still need me to do any further testing/data collection?

Nope! I should be good on that one. thanks 8) Although, there's probably a lot of DLL users out there screaming at me with their games frozen.. 8\

I really need to clean up my code and make it more abstract and compartmentalized... I can just tell this pluggy backup transition is just going to introduce a new generation of minibugs. I'll probably keep it as a beta for quite a while, just to make sure it's solid

Yeesh... Would it simplify things any to do an up-front check when the game starts up to see whether the load order has changed? It sounds like you might be able to skip a lot of the extra steps if you know that the FormIDs will still be the same.

Hehe, sounds like a good idea! 8) A lot more if statements, but it'll save some CPU.
Brainstorming ftw! I could maybe even do it on the fly. Keep an array of modnames/indexes, check which have changed, mark them as "unsafe". If I load up a creature FormID that matches an unsafe index, then grab the modname and do the correction. That way, I wouldn't even have to redo every FormID, just the ones that could potentially be wrong.

It would probably be part of the "quick-not-so-quick-anymore" replacement, as that iterates through every creature formid to replace the LLists after every restart, it could do the corrections there. That way, I wouldn't have to put any of the correction code in the rest of the DLL scripts, woot

Haha, I'm starting to spew my thoughts on the forums more with you around.. XD

» Wed Mar 30, 2011 8:56 am

My testing suggests that with vanilla + DLL, the army issue doesn't exist, one spawnpoint seems to be rolling once. I never saw more than 4 of any creature in my adventures. I ran through the same dungeon multiple times, and nothing I saw suggested any spawnpoints were rolling twice. I do believe it's a mod we're all using + DLL, and I'll probably confirm it when I do the same test with all my mods running.

That's what I expected, but Om had questioned whether the multiple-rolls-per-spawn-point feature might have been present in vanilla, so it seemed like a good idea to first establish that it's mod-added.

Looking at his docs, I'm fairly certain that it's Fran's. http://francesco823.tripod.com/index.html#EnemiesMore documents his increased spawn chance feature, and it even has the "number of spawns per spawn point increases at higher levels" characteristic which my last post theorized might be happening. (On reflection, I suspect that I installed Fran's with "Increased Spawns - Normal", thinking it meant "normal spawns" (i.e., not increased), rather than without any Fran's Increased Spawns.)

If that's what's really going on, this may need to be relegated to a documentation issue - "don't use both Fran's Increased Spawns and the DLL Increased Spawn Button at the same time unless you want to fight armies on a regular basis". But, OTOH, Fran's code for increased spawns should be a great guide for coding SGL-style spawns...

» Wed Mar 30, 2011 12:44 am

Look like we found DLL's first incompatibility! 8X

We gotta do some testing to confirm for sure, though, before I start wildly posting

----------------

I think I found the freeze bug you were running into. It had to do with how LLists were getting their levels averaged.
Details:

Spoiler

When DLL averages a LList, it does it, and then if DLL is tracking the mod.. it saves the average level to an array
If DLL needs the average to that LList again, it "shortcuts" and gets the level from the array instead of redoing the calculations.

When it happens to run into a LList that it isn't tracking, it doesnt store it anywhere. If DLL needs to get the average for that LList again, it has to do the calcs again.
It works fine when there's a few LLists DLL isn't tracking.. but:

If you've run DLL's exe with the majority of your mods deactivated, when you reactivate all those mods.. you've got a @$%# ton of LLists DLL isn't moderating and has to recalc every time. This can actually chain and become quite CPU heavy, freezing up your game.

Moral of the story: rerun your exe so DLL is tracking the majority of your mods (minus any exceptions)

I'm releasing a patch that limits the number of these redundant calcs, and also warns the user about what's happening so they can rerun the exe.

I believe this is what you ran into ndervish. But, let me know if you install the patch 2.04.1 and keep experiencing it.