Maybe it has to do with pasted portions being on a "floating layer"?
Probably... I'm not good at gimp anyway. At least I know how to proceed now. Mabe I'll work on a mod someday!
]]>What are you using to edit them? I used gimp, and by default it compresses the images. That's what was causing the blueprint images to appear when I was working on the mod. As for the blue squares, I believe that the TGA files use the color of one of the corners as the "invisible" color. If that corner gets changed, even slightly, then the background won't be invisible anymore - hence, giant blue squares. One good way that I found to test that is to use the bucket tool (with the "color variance" (in Gimp's case, "Threshold") set to 0). Fill in the background with something like black, and the slightly different shades become VERY obvious. Fill those in with black as well, and then color everything back to blue (or whatever you want the background color to be).
OK, I think I'm getting it. It is not the corner of the image that defines the transparency, but the corner of each sprite (actually the bottom left corner). That makes it a bit difficult at first to locate the corners of the sprite... Plus, there may be several of these "corners" in each image.
(I use gimp too, and disable the compress option when exporting to tga)
[EDIT] The problem I have with lost transparency/big blue square happens when I do the following in gimp: select a rectangular area, copy (Ctrl-C) and paste (Ctrl-V) somewhere else in the image. If I export *right then*, the exported tga file looks fine, but if I launch the game all the sprites contained in the modified image are screwed-up. I come back to gimp, click on a random place to reset the rectangular area, then I export, everything is fine in-game (and the tga file looks exactly the same). I wonder why having an active selection in gimp messes up with the export process...
]]>It was an aesthetic choice - I like the idea of the family being the only real color and life in the house, and I LOVED how killing a family member drained the house of life.
Agreed. Kudos on that one.
]]>iceman wrote:Yeah, I knew I should've mentioned that in my original post.
Thanks a lot Iceman, that explains everything concerning the visual weirdnesses.
Why did you leave the alive family members colourful? For aesthetic purposes?
I have another question: how did you generate the new propertiesSignature (for example in the houseObjects/wife/1 folder)? I imagine every state of every objects needs a specific key to encrypt the signature, and the server tests that signature to detect if you are trying to cheat with properties. Either you work on programming the game, or you submitted the new folder to Jason so that he delivered you the associated signature? Thanks!
It was an aesthetic choice - I like the idea of the family being the only real color and life in the house, and I LOVED how killing a family member drained the house of life. It just adds a nice symbolic meaning to it.
You're correct about the properties - I had to generate new propertySignatures for the new folders. Jason was kind enough to point me in the right direction, though
iceman wrote:As for the dead wife in the new life - I have NO idea what happened there. I don't think there's any way that my mod could've caused that. If you haven't launched the game since then, could you open the "log" file in the CastleDoctrine folder and let me know if there's any errors there?
This probably has nothing to do with the mod, unless that new wife/1 folder you created screwed up something... (the difference now is that the game detects and reads into that folder). I found nothing suspicious in the log file, but I probably relaunched the game before checking it. Anyway I located the bug in the recordedGame file, and I'll e-mail it to Jason.
I had a (pretty funny) problem when I started working on the mod, when I accidentally compressed the image for the power supply. When the game tried to load that image, it gave an error (which showed up in the log), but the games still worked fine. When I opened the tile chooser, though, it wasn't the power supply - it was a weird inverted image of a voltage triggered switch. I finally realized that that was the blueprint image (it's still in the game files), and since it had been loaded into the game just before, it just got copied into the power supply image =P I was thinking that the wife issue *might* have been a similar issue (even though it wouldn't have prevented her from moving).
]]>iceman wrote:Yeah, I knew I should've mentioned that in my original post.
Thanks a lot Iceman, that explains everything concerning the visual weirdnesses.
Why did you leave the alive family members colourful? For aesthetic purposes?
I have another question: how did you generate the new propertiesSignature (for example in the houseObjects/wife/1 folder)? I imagine every state of every objects needs a specific key to encrypt the signature, and the server tests that signature to detect if you are trying to cheat with properties. Either you work on programming the game, or you submitted the new folder to Jason so that he delivered you the associated signature? Thanks!
The game is open source, in houseObjects.cpp it describes how to generate new signatures.
]]>Yeah, I knew I should've mentioned that in my original post.
Thanks a lot Iceman, that explains everything concerning the visual weirdnesses.
Why did you leave the alive family members colourful? For aesthetic purposes?
I have another question: how did you generate the new propertiesSignature (for example in the houseObjects/wife/1 folder)? I imagine every state of every objects needs a specific key to encrypt the signature, and the server tests that signature to detect if you are trying to cheat with properties. Either you work on programming the game, or you submitted the new folder to Jason so that he delivered you the associated signature? Thanks!
As for the dead wife in the new life - I have NO idea what happened there. I don't think there's any way that my mod could've caused that. If you haven't launched the game since then, could you open the "log" file in the CastleDoctrine folder and let me know if there's any errors there?
This probably has nothing to do with the mod, unless that new wife/1 folder you created screwed up something... (the difference now is that the game detects and reads into that folder). I found nothing suspicious in the log file, but I probably relaunched the game before checking it. Anyway I located the bug in the recordedGame file, and I'll e-mail it to Jason.
]]>Whenever you return home after you've been successfully robbed, the game saves the state of most of the house, to let you know immediately your house has been robbed. Like colorfusion said, the game has a 0 folder for home building, and 1-20ish for robbing. When you come back to a broken house, though, it pulls the information for changed objects from the robbery folders. That's why you're coming back to some gray objects but not others.
Some of the objects are permanantly changed - destroyed walls, killed dogs, etc. Others are just temporary, and will go back to the "Build" version when you enter and exit a self test. For the trapdoors specifically, any powered ones at the end of the robbery need to be powered while editing, or else they could have a dog floating in midair (if a dog was on a trapdoor when the robbery ended, and then the trapdoor was unpowered during robbery, it would just look weird =P). Because of that, trapdoors act permanently damaged (i.e. they won't go unpowered in build mode if they were powered at the end of a robbery, even after a self-test), but can be replaced for free.
I *think* that any object that changed states during a robbery is temporarily stuck (destroyed ones are permanent, obviously). So if a trapdoor was ever powered during a robbery, it will appear gray, regardless of whether it was powered or not by the end. Any dogs that saw the robber will be gray, any that didn't will be colored, etc.
That should explain how some objects were gray, while others weren't. I tried to get partly around it by making *everything* stay gray by adding a noAutoRevert property to everything, but that didn't work (EDIT: Apparently I misread the purpose of that property). It wouldn't have fixed the problem entirely, though- you would come home to a completely grayscale house (which I think would've been awesome =P), but after you went through a self test only permanently damaged objects would be gray. I don't think there's any way around that, without editing the code itself. In some cases, such as coming home to two colorful children beside a colorless corpse, it seems pretty neat. Others, like a bunch of random gray walls, not so much. I guess you just have to think of it as a distinct reminder of what needs to be fixed =P
As for the dead wife in the new life - I have NO idea what happened there. I don't think there's any way that my mod could've caused that. If you haven't launched the game since then, could you open the "log" file in the CastleDoctrine folder and let me know if there's any errors there?
]]>Even if there isn't actually a 1 state, such as with wooden walls, you seem to be able to add it and the game automatically recognises it. This is what ice used to have things grayscale in robbery mode.
The problem is that broken tiles only have one state for both robbery and building, and there's no way you can get the game to recognise another one without modifying the actual code, meaning he had to have broken objects grayscale everywhere.
Edit: Started writing this before arakira's second post
]]>