I'm not able to check this update so I have one question: was bone behavior multiply problem solved?

You mean the one where having multiple objects with the bone behavior didn't work properly? That was fixed a while back(the original 0.99, I think), but there was no mention in the change log.

I finally tracked down the problem I mentioned and it's not related to runtime image loading. It's... well, here's the tracker entry.

In all honesty, it's the most retarded and messed up bug I've ever seen.

The persist file isn't a backup. It stores editor information, such as which layouts and event sheets you last had open.

You could use a private variable to store rotation speed. Whenever you hold down the right or left keys you would either add or subtract a certain amount from this variable. Then you would apply the rotation speed to the object by setting it's angle to: Object.Angle + RotationSpeed * TimeDelta

Here's a quick example: Inertial Rotation

Hope this helps.

It's pretty well established that the build on the front page was called stable too early. The latest version, while marked as unstable, is actually more stable than the build on the front page, so you shouldn't have any problems.

Just keep in mind that you should backup your projects often so that if something goes wrong your game doesn't get toasted.

How far does it go? Do you use int or long int for the coordinates?

I think it uses a signed 32-bit integer, so the maximum layout size is on the order of 2,000,000,000 x 2,000,000,000; this is most likely far more than anybody really needs, although I could be wrong.

You're welcome.

I've got another new version which brings a new feature, fix, and change:

Command Line Plugin - v0.92

Download Now(no example) - 101KB

Adds/Changes/Fixes:

[ADD] - "Get program path" expression added. This gets the path of the program, including the program name. This is usually the first command line argument, but has been absent from the arguments list. Now you can access it with this expression.

[CHANGE] - The "Get argument", "Get argument name", and "Get argument value" expressions have been changed. Before, entering an index lower than 1 or higher than the greatest index would return "NULL". Now the first and last arguments will be returned, respectively.

[FIX] - Inputting an index of "1" in the "Get argument", "Get argument name", and "Get argument value" expressions would return "NULL".

Thanks, guys.

New version with added feature and a change:

Command Line Plugin - v0.91

Download Now(no example) - 101KB

Adds/Changes/Fixes:

[ADD] - "Start arguments" and "Use start arguments" property added to the edittime properties section. These allow you to specify starting arguments which will be passed to the application. This is useful during testing so that you don't have to build the app/game to test it with command line arguments. However, I suggest using this only for internal testing.

[CHANGE] - The plugin should now be fully quicksave/quickload compliant, meaning that arguments will no longer be lost after using quickload.

Once again, be sure to leave comments, suggestions, and any bug reports.

Those must be some huge images you have. I'd suggest switching to realtime particle effects. They take practically no VRAM and they run at whatever framerate the game is at.

Of course, if you want to keep your prerendered effects, you could always find a batch image resizer to shrink them. But even at 256x256 with 80 frames, you're still looking at around 20MB of VRAM usage, which is alot when you consider that it's only one effect.

Well, I was bored this afternoon and I realized that a command line plugin could be pretty helpful, so I hammered one out over the course of the day, and this is what I have to show for it.

Command Line Plugin - v0.91

Download Now(no example) - 101KB

Unfortunately, there's no example to go with the plugin because, honestly, it's pretty tough showing off a plugin like this. So, hopefully this is simple enough for anybody to pick up and figure out. I'll try to explain things as best as I can.

First of all, this plugin allows you to retrieve any command line arguments that were passed to your application/game at execution. These could include various options or a file to load upon start of the program. There's also an action to execute an external program with command line arguments.

Here's a list of the various conditions/actions/expressions, which should help when figuring out how to use the plugin:

Conditions:

For each argument - Loop through each command line argument sequentially. There are various expressions to retrieve information about the currently iterated argument.

Actions:

Execute file - Execute an external program and supply command line parameters for it to use. This could be used, for example, in the case of a level editor and game. The level editor could execute the game program with command line arguments telling the game what level to load. In this way, levels could be tested directly through the level editor.

Expressions:

Argument count - Get the amount of arguments that were passed to your application.

Get argument - Get the argument at the specified index(1-indexed).

Get argument name - Get the name of the argument at the specified index. In the following example -- arg=value -- "arg" is the name of the argument.

Get argument value - Get the value of the argument at the specified index. In the following example -- arg=value -- "value" is the value of the argument. If the argument does not contain a value, the return value will be the string "NULL".

Current argument - Used in conjunction with "For each argument". This gets the current argument in the loop.

Current argument index - Used in conjunction with "For each argument". This gets the current index of the loop.

Current argument name - Used in conjunction with "For each argument". This gets the name of the current argument. In the following example -- arg=value -- "arg" is the name of the argument.

Current argument value - Used in conjunction with "For each argument". This gets the value of the current argument. In the following example -- arg=value -- "value" is the name of the argument.

Hopefully that tells everybody most of what they need to know. It should be pretty easy to figure out.

Just a note about when you use this to load a file at the start of the program -- whether by dragging an a file onto the EXE or opening a file through it -- the file will always be the first argument. Also, to check that this is actually a file, you should use the "File" object to check that a file at that location with that name exists.

Well, that's it. I hope that somebody can find a use for this and that it's easy to understand. Be sure to leave any comments or suggestions you have.

Have fun.

EDIT: Forgot to mention that arguments are separated by spaces. If you want a single argument with spaces in it, put it in quotes.

I think the correct term would be dead reckoning, which is essentially making educated guesses as to where an object might be at any point in time between data packets. I don't really think a system like this would work for such high latencies, though.

Thanks, table. Glad you find it useful.

I have a small new update ready here. Nothing earth shattering, but there it is:

Sprite Button Plugin - v0.71a

Download Now(with example) - 128KB

Adds/Changes/Fixes:

[CHANGE] - Drawing speed optimizations. Text would still be processed and drawn even when there was none.