Just add the index after the array, you are interested in, e.g

{"Opponent", "Ant", 4, "Inventory", 2}

selects the third item in the inventory from the fifth ant (s is zero-based).

Have a look at this thread:

and go through the tutorials, it will present you with the core of 's'

These options are already there. The actions are called

Set image angle

Set image offset

Set image scale

https://sourceforge.net/apps/mediawiki/ ... und_Object

The wiki isn't all that bad

It is always a good idea to have a look at the wiki:

http://sourceforge.net/apps/mediawiki/c ... n_features

It doesn't answer every question but still really helps a lot, so go bookmark the wiki

I wouldn't recommend changing the SDK this way. It still is a quick'n'dirty patch, and was only tested with the creation of a relative simple plugin. I'm still in doubt if all string tasks will work.

But if it is fine for Scirra, I could prepare an alternative download. Then everyone can freely decide wether to get the official SDK, or the at-your-own-risk patched version.

Sprites have a hotspot that you set in the picture editor (select it with the little red icon below the ellipse tool). For more information, have a look at the wiki: http://sourceforge.net/apps/mediawiki/c ... ure_Editor

The panel object does not support setting the hotspot in the picture editor. However, it has a property "Hotspot" that you can set to a few positions like top-left or bottom.

Most other objects don't support hotspots.

But that's exactly what lucid's example does

Or do you mean, you have a list of e.g. 20 different objects, and you want to loop through them? Then just create an array "names" that you fill with the names of your objects, and a global variable "selector"

then do:

+ On key Shift pressed

-> Add 1 to global 'selector'

++ Is global 'selector' greater than 20

-->set global 'selector' to 1

+ On left click

-> create object names(global('selector')) at mousex, mousey

(this is the action "Create object by name")

lucid did beat me to it, but I made such a nice example (although a little more complex), well commented and such, so I will post the link anyway

using_s_to_save.cap

I can't tell what you are experiencing here. But I can say for sure, there's an error in the source code.

main.cpp, lines 616-619, eDisplayAngleTurnRandomiser is set to return pp.growRandom instead of pp.daTurnRandom

but this is only returning the wrong value, the correct values are set using the actions.

Anyway, the above is a very easy to solve issue, put it on the tracker and hopefully here are also reading people who are working on updates to Construct 0.x

I remember a year or so ago, the main developer of the unreal engine 3 was asked how long it will take until a realtime engine could do all the sweet things those non-realtime raytracers of Maya, C4D, etc can do.

He smiled and said that they do it already.

Seeing something like this makes me believe he wasn't just promoting his product ...

Wow, ROJOhound, you should turn your last post here into a separate thread, and it should be stickied.

I did exactly what you proposed, and the only thing additionally left to do was to open "ConstructSDK.rc" and comment out

#include "afxres.h"[/code:1leexwxx][h2](I replaced it with "windows.h" instead of commenting out, but I think this is nonsense)[/h2]

and
[code:1leexwxx]#include "afxres.rc"[/code:1leexwxx]

afxres is part of mfc, but I'm working with the "Template Win32 VC8-9 Static", so I simply hope, that they aren't needed.

I've gone through the GradientCalc Tutorial and successfully created the plugin and it works without problems. That encourages me to think, afxres isn't needed...

Summary:
To be able to create plugins for Construct 0.x, you need
1) Visual C++ 2008 Express
2) Construct's plugin SDK
3) WtlStdString
4) changes to the template as described by ROJO and me

...no 600MB downloads needed anymore

...can I just have an event which is "every millesecond" then have tons of events under that event as sub-events?

No, you can't!

I can't stress this statement enough. 'every x millisecond' is not a reliable way of programming time based! Its timeslice is dependent on the framerate and that is exactly what you try to avoid when using a delta time.

If your game runs at 60 fps, the shortest timeslice you get for 'every' is 1/60s, ~17ms. You could try to set the condition to 17ms, but if for whatever reason the game runs on another computer with 30 fps the shortest timeslice is 1/30 or ~34 ms. In result, the game will be half as fast as on the first computer, because the 'every'-event is still triggered on every tick...

Btw, the example above also shows, that you can't even set the actual values but an approximation (e.g. 17 instead of 16.666666666666...)

This is actually an interesting problem because the Every event can only trigger at most once per tick (like Always). So if you're running at 10fps, the Every event will only trigger at most every 100ms. This is kind of awkward because it can make things framerate dependent again, even in well-designed, framerate-independent games.

h2]Source

'Every x milliseconds' also triggers in the next possible tick, not at the exact time. For example, with 60 fps, the 20th tick is reached at 333.33333333...ms, the 19th at 316.6666666...ms. If you'd now have it run 'every 320 milliseconds' it will occur in the 20th tick, not in between tick 19 and 20. This isn't that bad when just, let's say, switching a light on and off, but it is crucial when constantly moving a sprite or fading a color, etc. It will get slowly out of time.

Here is a cap. Run it and watch for a while (half a minute or more). The two sprites are both set to repeatedly move 400 pixels per second. The one above uses timedelta, the one below uses 'every...' I think, seeing this is better than a thousand words.

TimeDeltaVSeveryXms.cap

I'm not quite sure what you mean.

The time scale is just one project-wide setting, you can't apply it to a few things but not to others. When you set the time scale to 0.5, everything moves half as fast.