Print

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

[thewonderidiot]

I dont know wether you have a use for it actually but i created a video covering your mod in my tutorials here:

http://www.bay12forums.com/smf/index.php?topic=88207.0

Directlink to Video: http://www.youtube.com/watch?v=lgTja48gRhE

Thank you very much for this mod, it is simply stunning!

Awesome, thanks for making a video about us! Much appreciated.

another really cool thing to do with this is in adventure mode when in a town =) I used it in a human town built into the mountain-side and it was pretty cool

I actually didn't realize that Overseer could do this until well after it was released. Completely surprised me. I'm pretty excited to check out the new towns in the next release.

I got overseer to work a couple times, but now it throws an exception every time.
...
Any clues?

Thanks.

Holy bug report, Batman. Thanks for being thorough! There's a relatively lengthy discussion about this over on the Ogre forums, it seems to have only really manifested itself in one other game before, and the cause of that isn't applicable to the shader in question. I have a guess though: your video card is probably running out of memory. Loading the shaders takes place after the geometry generation phase. If you've since started work on a megaproject, the amount of geometry in your scene has gone up, so the amount of stuff being sent to the video card has gone up as well.
So, try increasing 'zstart' in overseer.ini. That'll reduce the amount of geometry/textures generated as well as the strain on video memory. If you're working on a megaproject, there's a decent chance you're aboveground anyways (or at the very least not in hell).
If that doesn't work, you can fool around with some of the other settings in overseer.ini to further reduce strain (though zstart is definitely the most direct way).

As for the rest of the issues you brought up, those are all normal. Ogre's just complaining, more or less, and they don't cause any errors. They'll all be fixed in the long run but they're not urgent.
And don't worry, now that Overseer is out of the test-demo phase and into actual development (when I have time <_<), magma will show up if not in the next release then very shortly after.

Good luck, and let me know if you figure anything out!

[Fridgetroll]

Good luck, and let me know if you figure anything out!

Thanks for the reply.

You may be right about the video RAM.

I do have a lot of above ground construction. Since the last thing it chews on before choking
is the textures for the stairs, I suspect it's my stairwells. I currently have four free standing
stairwells ranging in height from 30 to 40 levels.

The previous log used a zstart of 130 which is about 7 levels below the lowest surface point of my project.
I tried bringing it up to 175 so that only the topmost 2 layers of stairs and open space are being rendered
and it still chokes.

20:32:23: Mesh: Loading stairs.mesh.
20:32:23: Texture: ObsidianN.BMP: Loading 1 faces(PF_R8G8B8,512x512x1) with 
 hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,512x512x1.
20:32:23: Texture: Obsidian.BMP: Loading 1 faces(PF_R8G8B8,512x512x1) with 
 hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,512x512x1.
20:32:23: OGRE EXCEPTION(3:RenderingAPIException): Cannot create D3D9 pixel shader
 Fragment/ReliefMapSelfShading from microcode. in D3D9GpuFragmentProgram::loadFromMicrocode at
 ..\..\..\..\..\RenderSystems\Direct3D9\src\OgreD3D9GpuProgram.cpp (line 369)

I'll build walls around the top levels of stairs and try again with zstatus=175.

Edit: Walling off the top levels of stairs didn't change anything, so I dropped the resolution down from
1280x1024 @32 bit color to 640x480 @16 bit color just in case it is RAM and the error is unchanged.

When I did my original screen cap, the zstart was 0.

Spoiler (click to show/hide)

[thewonderidiot]

That's really, really weird. I have no idea what might be causing this then. The fact that it was working and then just suddenly doesn't anymore, with a shader-based error, and with presumably no change to the system/program, completely baffles me....

Sorry I don't have an answer for you now, I'll think about this some more and get back to you if I come up with anything.

[Lancezh]

(SOLVED)
Dont laugh, i managed to capture a video of ogreseer but havent found an easy way to make screenshots yet, the hotkey doesnt seem to work for me... am i missing anything ?



Edit: Nevermind, it works now for whatever reason...

[Graebeard]

I don't know if I've missed it somewhere in the thread, but is there a way to have the program render materials differently?  Specifically, glass and obsidian render the same way right now.  Is there a way I can turn glass green or change the color of obsidian?

[DrKillPatient]

I've got the Overseer starting up fine in Wine on Linux, and the Windows version of DF is running with it (in Wine as well). However, Overseer doesn't detect it. How does it look for the DF process?

[Kaelem Gaen]

Nice viewer, though it doesn't seem to show the water in caverns for me.

[thewonderidiot]

I don't know if I've missed it somewhere in the thread, but is there a way to have the program render materials differently?  Specifically, glass and obsidian render the same way right now.  Is there a way I can turn glass green or change the color of obsidian?

Assuming all the materials are getting properly assigned, you can check out all of the material definitions in overseer/materials/scripts. If you find the material definitions in the 3 non-parent files for the materials you want to change, you can edit them and your changes will show up immediately on re-run of Overseer. If the materials you want to change aren't listed, open up Ogre.log and see if it complains about them being undefined -- if so, you can add new materials of that name to whichever material script files you want. This will be more streamlined/complete in future versions...

I've got the Overseer starting up fine in Wine on Linux, and the Windows version of DF is running with it (in Wine as well). However, Overseer doesn't detect it. How does it look for the DF process?

As far as I know, this is unsupported by DFHack. I'm not surprised at all that two processes running under Wine can't find each other.

Nice viewer, though it doesn't seem to show the water in caverns for me.

Thanks, you can make it render water in caverns by default by tweaking the water settings in overseer.ini. It's off by default because the current method of drawing water is expensive and caverns tend to have a lot.

[Dr. Hieronymous Alloy]

I don't know if I've missed it somewhere in the thread, but is there a way to have the program render materials differently?  Specifically, glass and obsidian render the same way right now.  Is there a way I can turn glass green or change the color of obsidian?

Assuming all the materials are getting properly assigned, you can check out all of the material definitions in overseer/materials/scripts. If you find the material definitions in the 3 non-parent files for the materials you want to change, you can edit them and your changes will show up immediately on re-run of Overseer. If the materials you want to change aren't listed, open up Ogre.log and see if it complains about them being undefined -- if so, you can add new materials of that name to whichever material script files you want. This will be more streamlined/complete in future versions...

If someone can spell out in small words how to do this to make ice show up properly, i'd appreciate it -- I'm digging a tower out of poured ice and it's showing up brown instead of blue/white. =(

[Graebeard]

I don't know if I've missed it somewhere in the thread, but is there a way to have the program render materials differently?  Specifically, glass and obsidian render the same way right now.  Is there a way I can turn glass green or change the color of obsidian?

Assuming all the materials are getting properly assigned, you can check out all of the material definitions in overseer/materials/scripts. If you find the material definitions in the 3 non-parent files for the materials you want to change, you can edit them and your changes will show up immediately on re-run of Overseer. If the materials you want to change aren't listed, open up Ogre.log and see if it complains about them being undefined -- if so, you can add new materials of that name to whichever material script files you want. This will be more streamlined/complete in future versions...

I took a crack at this.  I may have made a mistake or overlooked something, and my last experience writing code was with BASIC in 1994, but I think I've encountered a bug of some kind.

I took a look through the .material files you mentioned and there's no entry for green glass, clear glass, or crystal glass.  Then I went through the ogre.log file, but I didn't see anything that looked like a material being undefined.  The closest I saw was this: 

Spoiler (click to show/hide)

Code: [Select]

10:43:52: Can't assign material _NULL_ to SubEntity of SkyXMeshEnt because this Material does not exist. Have you forgotten to define it in a .material script?

.  I don't know if that's referring to glass or something else.

Then I went and added an entry to constructed.material and rough.material for "green_glass."  I just copied the entry for olivine each time for the format and color and changed the name:

Spoiler (click to show/hide)

Code: [Select]

material constructed_green_glass : ConstructedParent
{
set $maskingcolor "0.717647058824 0.882352941176 0.133333333333"
}

That didn't work either, so out of curiosity I decided to mess with the color of obsidian.  That worked just fine.  The obsidian looks like gold now.  The funny thing is that all my green glass and crystal glass also look like gold.  Is there some reason the program would be treating all glass as obsidian?

If someone can spell out in small words how to do this to make ice show up properly, i'd appreciate it -- I'm digging a tower out of poured ice and it's showing up brown instead of blue/white. =(

I'm not sure, but this seems like a similar problem.  On a different fort, my snow looks like dirt and my constructed ice walls look like granite or something.  I tried adding snow to the textured.material file (copying and tweaking the red_sand colormap and reliefmap), but that didn't do anything.  I also added an entry for ice in the constructed.material file, but that didn't change anything either.

[thewonderidiot]

Aye, that would all be issues with the material placement. I know for a fact it doesn't support snow, so I'm not surprised ice isn't working either. Not sure why glass isn't. I'll be sure it's all fixed in the next version.

[Graebeard]

Sweet.  Can't wait to see how it looks.

[Armeleon]

Alright, I need a little help here.  Every time I try to run the program, it manages to access Dwarf Fortress, but only to freeze the game.  Overseer then displays a DFHack::Error::MemoryAccessDenied error, saying that the SHM access was denied.  Overseer then crashes, and DF freezes, causing me to restart.

I have the latest version and have updated the XML file.

Ideas?

[Andyfuji]

Alright, I need a little help here.  Every time I try to run the program, it manages to access Dwarf Fortress, but only to freeze the game.  Overseer then displays a DFHack::Error::MemoryAccessDenied error, saying that the SHM access was denied.  Overseer then crashes, and DF freezes, causing me to restart.

I have the latest version and have updated the XML file.

Ideas?

Try moving the folder you have Overseer in, into Dwarf Fortress's folder.  I had problems running it outside the DF folder, worked perfect once I moved it inside.  You may want to try running Overseer in Administrator mode if that doesn't work.

[Armeleon]

Thanks for the info, but it was a no go.  Here's the entire text of the error for those tech geeks out there:

Ok, so after the whole successful connection info, it reads:

Windows Error #127: [Screen #0] chooseMatchingPixelFormat() - wglChoosePixelFormatARB extension not found, trying CDI. Reason: The specified procedure could not be found.

Rendering in software: pixelFormatIndex 1
Terminate called after throwing an instance of 'DFHack::Error::MemoryAccessDenied'

what(): SHM ACCESS DENIED

Then it terminates in an 'unusual way' and freezes DF. woot.