Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Rafal99]

One more thing:
Lifevis frequently suddenly closes without any warning or anything.
error.txt contains several lines of this:

Modification of non-creatable array value attempted, subscript -16 at Lifevis/Viewer.pm line 1348.

[Rose]

@Rafal99, the 20 seconds you are seeing isn't the drawing, it's the geometry generation and the map reading, there's a difference.

[Mithaldu]

[snip]
Many useful :words:.
[snip]

Ok, wow, thanks a lot for the feedback. I thought i was going insane here!

What's going on is this: For each 16x16 blocks you're seeing, it is getting the data for 16x16xZ-Levels tiles from the DF process and caching it into one OpenGL Display List for each Z-Level. The first time this happens it is fairly slow, because it has to do that for literally every 16x16 slice. On later runs it can go a lot faster since it only grabs the memory data, compares it against cached data and only needs to do further processing if it changed. As well, you set the view range to a level that i'd call "ridiculously large" for the moment. So, if you'd wait out the initial load, it should become a good bit faster.

The Calls-Time you're seeing is very reasonable as well. It means that it only takes 0.02 seconds to render what you see on screen, with another 0.01 secs spent on rendering creatures, items and buildings, and 0.01 secs more for occlusion analysis (which i should probably drop as i don't even know if it works anymore). That, with some extra work, combines to 0.06 seconds render time for a frame, which is pretty decent actually.

However, something i've seen on my rig, and which i'm unsure about whether you're seeing it: Sometimes the Calls time just soars for a while, hovers at 200ms and randomly drops down later again. This is without any big change in the data being rendered and i'm very sure that it is caused by using Display Lists, which present the gfx card with cache sorting issues. Display lists are also likely the source of slowness in loading in the data. If you look at the Landscape-Data/3D-Tasks counters, you'll see that the Data tasks run much faster than the 3D tasks and the 3D tasks are where Display Lists are created.

So yeah, that's definitely the next big thing i'll tackle, after these two things:

Thanks for the suggestion of suspending refresh updates while DF is talked. I looked around and i can do some things with cur_year_tick to avoid rechecking stale data.

Also, thanks for reporting that bug. I'll look into what causes it.

[Dadamh]

Use of uninitialized value in numeric gt (>) at Lifevis/Viewer.pm line 917.

I get this on attempting to run lifevis.  It gets so far as rendering a couple of... I guess in minecraft you'd call them chunks.  A few large tiles of play area, and then closes and puts that line into error.txt.

Just reporting a bug.  Version 34.11

[Mithaldu]

Use of uninitialized value in numeric gt (>) at Lifevis/Viewer.pm line 917.

I get this on attempting to run lifevis.  It gets so far as rendering a couple of... I guess in minecraft you'd call them chunks.  A few large tiles of play area, and then closes and puts that line into error.txt.

Just reporting a bug.  Version 34.11

Wow, that's weird and should literally not be able to happen. I've uploaded a bandaid release: https://github.com/downloads/wchristian/lifevis/Lifevis%20v0.258_006.zip

Can you maybe upload the save this occurs on?

[Dadamh]

Can't locate Lifevis/constants.pm in @INC (@INC contains: .. . C:/Documents and Settings/.../Desktop/Lifevis v0.258_006/site/lib) at Lifevis/Viewer.pm line 92.
BEGIN failed--compilation aborted at Lifevis/Viewer.pm line 92.
Compilation failed in require at Lifevis\Launcher.pm line 19.


Looks like a failed include or equivalent?

[Mithaldu]

Looks like a failed include or equivalent?

Ugh, a debugging aid moved the process one dir up and as such couldn't find the necessary deps anymore. Fixed release: https://github.com/downloads/wchristian/lifevis/Lifevis%20v0.258_007.zip

[Dadamh]

Well it runs now.  I tried it on a new save, and it works fine there.  Keyboard input is a bit wonky, tends to crash out after freaking out on me and flipping the view all over the place.  Error log:

Modification of non-creatable array value attempted, subscript -9 at Lifevis/Viewer.pm line 1347.

Still fails on the old save.  I figured something stupid about my already fairly stupid above-ground fort.  Who knows what exactly. 

I don't really know where to put the save.  But the current error is something different than before:

ReadProcessMemory failed with code: 299 at Lifevis/Viewer.pm line 112.
   Lifevis::Viewer::_ReadMemory(268, undef, 676) called at Lifevis/Viewer.pm line 919
   Lifevis::Viewer::landscape_update_loop called at C:/Documents and Settings/.../Desktop/Lifevis v0.258_007/site/lib/Coro.pm line 691
   Coro::_coro_run called at Lifevis\Launcher.pm line 0

Anyway, neat little tool when it works.  I always think folks who go out of their way to make things for free for a community deserve thanks for it.  So thanks!

[Mithaldu]

Well it runs now.  I tried it on a new save, and it works fine there.

Phew! I was worried there.

Keyboard input is a bit wonky, tends to crash out after freaking out on me and flipping the view all over the place.

Yeah, that is a known bug i haven't gotten around to debugging yet. It worked perfectly under XP and with Win7 it is borked. I suspect it's not sending the keyup correctly. You need to control things through DF for the time being.

Modification of non-creatable array value attempted, subscript -9 at Lifevis/Viewer.pm line 1347.

That one was mentioned earlier and i'll be looking at it tomorrow i hope!

Still fails on the old save.  I figured something stupid about my already fairly stupid above-ground fort.  Who knows what exactly. 

I don't really know where to put the save.  But the current error is something different than before:

Can you please get a dropbox account and share it from there? That should be the easiest and most convenient way for you. I can look at it tomorrow then.

ReadProcessMemory failed with code: 299 at Lifevis/Viewer.pm line 112.
   Lifevis::Viewer::_ReadMemory(268, undef, 676) called at Lifevis/Viewer.pm line 919
   Lifevis::Viewer::landscape_update_loop called at C:/Documents and Settings/.../Desktop/Lifevis v0.258_007/site/lib/Coro.pm line 691
   Coro::_coro_run called at Lifevis\Launcher.pm line 0

That is very interesting. It indicates that Lifevis is trying to read from a memory position that is undefined, so somehow i'm trying to read from a cell that is not actually initialized and i have not yet seen any of those in my tests. If that is from your save, then i'd REALLY love to have it!

Anyway, neat little tool when it works.  I always think folks who go out of their way to make things for free for a community deserve thanks for it.  So thanks!

Thanks for the kind words.

[Dadamh]

Well assuming drop box is working, the save should be uploaded to:

https://dl.dropbox.com/u/86370856/LVFailSave.rar

I renamed it from "Region1" because I don't want you overwriting something you're playing.

Anyway, there you go.  I have the worst luck with utilities, so who knows, maybe you won't even see the same bug.

[Mithaldu]

I have the worst luck with utilities, so who knows, maybe you won't even see the same bug.

Your bad luck is my good luck.

Thanks for uploading. That save crashes on my machine almost immediately as well, so debugging it should be rather easy.

[Mithaldu]

Modification of non-creatable array value attempted, subscript -16 at Lifevis/Viewer.pm line 1348.

ReadProcessMemory failed with code: 299 at Lifevis/Viewer.pm line 112.
   Lifevis::Viewer::_ReadMemory(268, undef, 676) called at Lifevis/Viewer.pm line 919
   Lifevis::Viewer::landscape_update_loop called at C:/Documents and Settings/.../Desktop/Lifevis v0.258_007/site/lib/Coro.pm line 691
   Coro::_coro_run called at Lifevis\Launcher.pm line 0

Both of these are fixed in v0.258_008: https://github.com/wchristian/lifevis/downloads

Two things were happening here:

First, Toady uses a hack of sorts to make items invisible. He puts them outside the bounds of the map. My detection for that was off by one.

Secondly, when rendering a slice i need to know what's around it. The code that gathered that data reached outside of the map, which caused the array to wrap around at the edge. It is now clamped.

[Dadamh]

Alright cool, glad I could sorta bring some issues to the front.

It works with the save I had.  Though that fort died today to tantrum spirals started by a kobold wereelephant.

The newer versions of DF man.  Nuts.

Anyway, thanks for the fix!