Thanks Lucid for the details. Unfortunately, everything still looks ok. On a separate note, I am getting an error when building for release mode (something about:

ConstructSDK.def : error LNK2001: unresolved external symbol GetInfo

Release/ConstructSDK.lib : fatal error LNK1120: 1 unresolved externals

The whole debug/runtime/release mode settings for output and linker confuse the heck out of me. I still get a warning about output path being different than linker path even though they all seem to be the same. It compiles fine under the "Debug" build option.

I zipped up the relevant source files if you have time to take a look:

http://www.box.net/shared/dmdy4r6qta

I'm at a loss at this point how to debug this. Is there a way to be able to debug the execution of this plugin?

I just built-up the example plugin to get started learning how to write these. Everything compiled fine and I was able to load the plugin with Construct.

Then I followed all the steps in the tutorial to build the color gradient plugin with the setcolors actions and getcolor expression. The problem is when I select "Get Color" from the expression box nothing happens and the window just closes. Any ideas on what I'm doing wrong? I can't find any mistakes in the code.

This new plugin sounds really exciting!

Try reading the "Part4: Layout Transitions" off of this link:

It covers different aspects of moving between layouts and should give you some ideas on how to do it. Basically, any object that is placed on a layout at build time will always be there when you return to it (even if you had previously destroyed it) and any object that is placed dynamically will always be gone when you return to it. The tutorial covers one way to address those problems.

You can call it just like it was a Python method: Sprite.Destroy()

What is the error you are getting? You could always parse the INI file with Python with a "for each line" type method.

The only two option would be too:

1. Hide the data/file. Since you probably don't want a rootkit with your game then you could hide your data in a format that the user couldn't easily understand. Or hide your files inside other files.

2. Encrypt the data on disk. Then decrypt the file when you want to read the data. I think the S plugin supports encryption or you could use Python to encrypt.

If you don't care about hiding and just want the user to not be able to change it, you could try a checksum. I think Minor or somebody else wrote a tutorial about. As anybody would say, all of these techniques are pretty easy to get around, but will work to keep your average gamer honest.

To the developers:

Is this a change that would require the ProfUIS library?

What type of fixes/additions would require having the library. I checked the price for it and it is like $350!

I am interested in working on 0.x. Mostly for making sure Python continues to be supported and to maybe fix a few bugs here or there. I don't see myself making any massive structural changes or additions as I have little free time to spare.

You shouldn't notice a performance impact with a 50x35 array and leaving entries blank. However, one way to do it would be to have a hashtable hold your characters with the value an index into the array. That way you would always get really quick access to your array info without any searching or sorting. When you delete a character, the hashtable entry would be deleted (the hashtable is an automatically sized list) and the index could go into a deleted index hashtable for use later if you add a character back.

> when hidden, the game won't be reciving any key presses. Consequently, it won't get the

input CTRL+Space (or any other), and so won't show up!

Why do you have a game where the game window isn't even showing?? But to answer your question, your game window has to be active to receive key presses. It is a Microsoft Windows thing and you don't have control over that without writing a separate background program that hooks key presses.

The examples in this thread might help you out.

Not sure I really understand your problem from your post, but I believe the examples will help.

If I do understand it...I don't see a good reason to store the item powers and other stats in a hashtable. It makes more sense to store those in an array or to just compute them all on the fly. You could have a base array with all the default values for the item, # items, power, weight, attack bonus, etc. Then you could use the hash table to store the name of the item and the value would hold the index to the array. To delete an item you simply remove it from the hashtable. I did something similar in the Mikeys Adventure tutorial part 5: