Print

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

That's right

That is right

[mizipzor]

Just did a checkout of the Stonesense SVN. Somehow, it manages to crash the Visual Studio 2008 linker. SVN revision is 680. I couldnt find a bug tracker on the google group so I just post here.

I didnt change anything, just attempted to run a build just after a check out (and running the cmake scripts).

Output:

Spoiler (click to show/hide)

2>Linking...
2>LINK : C:\Code\stonesense\Debug\stonesense.exe not found or not built by the last incremental link; performing full link
2>   Creating library C:\Code\stonesense\Debug\stonesense.lib and object C:\Code\stonesense\Debug\stonesense.exp
2>Embedding manifest...
2>Microsoft (R) Windows (R) Resource Compiler Version 6.0.5724.0
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>LINK : fatal error LNK1000: Internal error during IncrBuildImage
2>  Version 9.00.21022.08
2>  ExceptionCode            = C0000005
2>  ExceptionFlags           = 00000000
2>  ExceptionAddress         = 0130FCF7 (01290000) "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\link.exe"
2>  NumberParameters         = 00000002
2>  ExceptionInformation[ 0] = 00000000
2>  ExceptionInformation[ 1] = 0085D670
2>CONTEXT:
2>  Eax    = 404288F0  Esp    = 0037ED2C
2>  Ebx    = 40008178  Ebp    = 0037ED54
2>  Ecx    = 0085D670  Esi    = 40428758
2>  Edx    = 0037ED44  Edi    = 0129D6C0
2>  Eip    = 0130FCF7  EFlags = 00010246
2>  SegCs  = 00000023  SegDs  = 0000002B
2>  SegSs  = 0000002B  SegEs  = 0000002B
2>  SegFs  = 00000053  SegGs  = 0000002B
2>  Dr0    = 00000000  Dr3    = 00000000
2>  Dr1    = 00000000  Dr6    = 00000000
2>  Dr2    = 00000000  Dr7    = 00000000
2>Build log was saved at "file://c:\Code\stonesense\build\build-real\stonesense.dir\Debug\BuildLog.htm"
2>stonesense - 1 error(s), 85 warning(s)
3>------ Skipped Rebuild All: Project: ALL_BUILD, Configuration: Debug Win32 ------
3>Project not selected to build for this solution configuration
========== Rebuild All: 1 succeeded, 1 failed, 1 skipped ==========

Edit: Solved. I was a bit to literal when reading the compile guide. The allegro folder got a bad name:

Unpack allegro into the stonesense directory
(so you have a stonesense/allegro-mingw-4.2.2 directory)

mingw seems like a bad name when you compile with visual studio. 
Ill leave the post here in case anyone searches. If you use Visual Studio 2008, make sure that you have the folder:

stonesense/allegro-msvc80-4.2.2

[Rose]

actually, the cmake scripts are only needed for MINGW.

for MSVC, you just open the project file that's there.

[mizipzor]

actually, the cmake scripts are only needed for MINGW.

for MSVC, you just open the project file that's there.

...which I totally missed >.< it compiles and runs fine now though so everythings great.

[Kaelem Gaen]

Any idea how to get this to compile with VC++ 2008 Express? when I try and build it after the convert it fails everytime.
 says something about png.h  not included or missing, or something along those lines only happens omn loadpng.h and uh... regpng.h ... I think.

[Daimyon]

Greetings all, I downloaded Stonesense today and- after opening DF and continuing to play, attempted to run SS and got an error.

"The Application failed to initialize properly (0xc0150002). Click OK to terminate the application."

I've looked around a bit and all I could find regarding the error was OS's not starting up after being shut down before systems updates could be completed. I am using MayDay's tileset and nothing else, mod wise. Any ideas?

[mizipzor]

Greetings all, I downloaded Stonesense today and- after opening DF and continuing to play, attempted to run SS and got an error.

"The Application failed to initialize properly (0xc0150002). Click OK to terminate the application."

I've looked around a bit and all I could find regarding the error was OS's not starting up after being shut down before systems updates could be completed. I am using MayDay's tileset and nothing else, mod wise. Any ideas?

I get the same error (same hexcode) when I compile and run Stonesense from the solution file directly under the root (after its been converted to VS2008 format). Its before the first line in main() is reached so something must have gone terribly wrong. If I compile and run using the cmake scripts however, it works perfectly.


On an entirely separate note, Ive taken the time to import the entire svn repos into github. All metadata is preserved from commits so that proper credit is given. I just dont like the feeling of hacking away without version control. Since it takes quite some time to convert the tree, anyone else wanting git can happyily head over to my github.

[Footkerchief]

looking at this again, it should be doable procedurally to mesh things into this sort of order. {[ITEM]->[GRASP/STANCE]/(extermity)->(connections toward body)} in order bottom to top, in back, STANCES before GRASPS
{[LOWERBODY]->[UPPERBODY]->[NECK]->[HEAD]}
{(connections from body)->(extremity)->[ITEM]->[GRASP/STANCE]} for the "front"ward bits.
(bodypart)->(equipment on that bodypart, UNDER->ARMOR->OVER->COVER) unless it has a STEP, in which case draw it after all those bps/equipments it STEPS over.

Shields would not work with it, though, nor would pincer-held items, nor prone/non-upright critters. hmm...shields are easily excepted. Pincers are just where one finds out GRASP parts need separating, and prones/not uprights can just be made to have their body draw order anterior to posterior or vice versa,like we're going distal to proximal or the other way when needed.

If you're trying to come up with draw-order logic that will work on any creature, I don't think that's practical.  People will inevitably come up with a creature for which it doesn't work (or they might just want to use a different stance).

[JanusTwoface]

If you want to use Stonesense with 40d17, you can grab the Memory.xml file directly from a DFHack repository.  It's working for me.

Here's the copy I'm using:
http://github.com/peterix/dfhack/raw/master/output/Memory.xml

[Retro]

Question: At this point in Stonesense's evolution, is it entirely up to the users to fill out the last few missing sprites? Currently using a lot of metal ramps which are showing up as regular stone ramps; should I just go ahead and make my own, or will they eventually be forthcoming?

I'm also planning on recolouring the constructed stone object so that they look like the in-game colours ('realistic' looks bother me because then what looks cohesive in DF looks messy in SS), since I don't believe that's been released either, so I'll be posting that when I'm done and then asking for help on how to insert it into the game when I've finished with that.

[lordcooper]

This looks amazing.

What sort of FPS hit should I expect from this?

[soul4hdwn]

This looks amazing.

What sort of FPS hit should I expect from this?

depends on the refesh rate and your computer. DF would only be hit due to SS taking up a slight chunk of processing. i get about 2 to 14 fps hit with a 5x5 map with 100 population and minimal water and stone interaction.

[lordcooper]

Thats me waiting til I get a new pc then.

I generally GET around 14 fps under those conditions.

[CobaltKobold]

looking at this again, it should be doable procedurally to mesh things into this sort of order. {[ITEM]->[GRASP/STANCE]/(extermity)->(connections toward body)} in order bottom to top, in back, STANCES before GRASPS
{[LOWERBODY]->[UPPERBODY]->[NECK]->[HEAD]}
{(connections from body)->(extremity)->[ITEM]->[GRASP/STANCE]} for the "front"ward bits.
(bodypart)->(equipment on that bodypart, UNDER->ARMOR->OVER->COVER) unless it has a STEP, in which case draw it after all those bps/equipments it STEPS over.

Shields would not work with it, though, nor would pincer-held items, nor prone/non-upright critters. hmm...shields are easily excepted. Pincers are just where one finds out GRASP parts need separating, and prones/not uprights can just be made to have their body draw order anterior to posterior or vice versa,like we're going distal to proximal or the other way when needed.

If you're trying to come up with draw-order logic that will work on any creature, I don't think that's practical.  People will inevitably come up with a creature for which it doesn't work (or they might just want to use a different stance).

If I get it right it should be possible to get all the bilaterally-symmetric vertebrates with the one I was considering, if you have all limbs as branching off the spine. I don't think anything has radial bodyplans yet (I don't even know if it's possible in DF yet!)

I mean, if it's really too much trouble, you find the ones that don't work and give a custom draworder in the same place you define the attach points for parts, if you weren't using a full-size sprite per part to get them to be placed right simply.

I'm sure it won't be possible to make a good wrestling imager simply because it is possible to do crazy/impossible things with your joints and theirs, but most of the rest of the normal actions should be feasible.

[darkflagrance]

^If so, would the downside of people's modded, crazy creatures not fitting the model be enough to prevent a system like this from at least being implemented in vanilla?

Given that most people will start out playing vanilla, it might be a suitable goal to devote most attention to visualizing the things normally found in there, and while you would consider mods, they would be of lower priority.

I'm sure that modders can live with their unusual, bizarre creations happening to act in a slightly glitchy way.

[Kaelem Gaen]

Well the memory you gave me sorta worked, I'm getting yellow blocks in a lot of places.... is that a side effect of missing stuff or some change in the Memory.xml?