Open the wizard. Instead of picking an object right-click over the bar and select "use expression" from the context menu.

I wasn't able to get either threading or multiprocessing to fully work with Python. For some reason, I can't seem to populate the entire Construct array inside the thread (only the first element). It is like it runs the loop once then just stops.... also can't set globalvars from inside the thread, etc... For multiprocessing I get an error "AttributeError: 'module' object has no attribute 'argv'...perhaps related to running the program via the Construct IDE and not commandline.

That's really too bad. I assume that Construct's objects are only updated per tick and threads are running outside the scope. Threading might only be usable with a Python array/list/dict etc.

AttributeError: 'module' object has no attribute... most often indicates that there is no correct path to the module. Maybe a 'sys.path.append' with the working or temp directory in the script before calling any other functions could help? Also, try saving the script to Construct's python directory and import it.

A few weeks left until I can really test things out instead of just proposing them and hoping for the best ^.^

Also, Python may be an alternative. The standard library, starting with v2.6, supports threading/multiprocessing:

http://docs.python.org/release/2.6.7/li ... ading.html

http://docs.python.org/release/2.6.7/li ... ssing.html

>

> Not directly, but you can use UID to find identical objects:

>

index=0
> for i,obj in enumerate(Sprite):
>     if obj.uid==SOL.Sprite.uid:
>         index=i
>         break[/code:2vs3xkyj]
> 
> 

Does this work with indirect references? I mean the selected objects list:

def getIndex(constructObject):
    index=0
    for i,obj in enumerate(constructObject):
        if obj.uid==SOL.constructObject.uid:
            index=i
            break
    return index[/code:2vs3xkyj]
If it isn't possible, is there a workaround without direct access like SOL.Sprite ?

Yes, the new code makes more sense

But being the smart ass I am I can't let go and need to talk about the expression 'timer' again. You are using 'Every 1000 milliseconds', which isn't a bad thing. But you are not counting seconds this way. And this is why:

Every event including every x ms can only be triggered on a tick. A tick has a duration, and that duration depends on many details, e.g. the number of events that need to be executed (something that differs from tick to tick), the processor speed, the cap is run on, even the system may interfere because of heavy hd access or other background tasks.

This all leads to totally different tick durations, even when overall the game runs with stable 30, 60 or whatever fps. So when will every x ms be executed? On the nearest tick right on or after the specified time. In other words, every 1000 ms may be executed after 1002 ms the first time, after 1011 ms the second time, after 1000 ms the third time, etc.

I know, this might not be essential for a game, but then again, if you really want to count seconds (up or down) you can only rely on 'timer' (followed by timedelta), because those are counted outside of the event loop, so whenever you ask for 'timer' you get a very accurate time measure.

But, as I said before, this might not be that important for a game

I know, but I do think it has the same reason, the time units needed to evaluate the or'ed conditions. On the top level of the event tree it gives the impression of always working (although it does only work beginning with tick 2 (instead of tick 1).

I use the following image to explain it to myself:

Tick N: First condition is retrieved. Second is missing, so it can't be compared. Any call to the 'or' event will fail.

Tick N + 1: Second condition is retrieved. Both are present to compare. A call to the event will be successful.

There is an issue with 'or'. I think I found the possible reason for it some time ago, and wanted to work on it now that I started helping with Construct Classic development. But I currently don't have a pc, I can't work on it.

Here is the link describing the possible issue: http://www.scirra.com/forum/viewtopic.php?f=3&t=7428

I hope I don't misunderstand you, but every expression does its job on every tick, unless it is forced not doing so by using conditions.

+ Always

-> Add 1 to a

-> Set b to 1

This will add 1 to the currrent value of a (whatever it is) on every tick as well as setting the value of b to 1 on every tick.

Tick 1

a = 0

b = 0

doing always-event:

a = 0 + 1

b = 1

Tick 2

a = 1

b = 1

doing always-event:

a = 1 + 1

b = 1

Tick 3

a = 2

b = 1

doing always-event:

a = 2 + 1

b = 1

etc.

But using another condition breaks it:

Tick 3

a = 2

b = 1

+ a less than 2:

a untouched

b = 1

EDIT: Add to value is nothing more than a shortcut for n = n + 1

pyteo, I would love to investigate your caps, but I don't have Construct for a while. Whatever it is, there's something wrong with the sizes. Not only in theory but practically 4 256x256 textures consume the same texture memory as 1 512x512 texture.

I once made an example for effective slicing, where I could prove that a bunch of sprites with totally different sizes (1x2, 256x32, 512x512, etc.) formed a picture of the size 700x700. A picture of that size needs 1960000 bytes of texture memory (1.87 MB), and all the sprites combined used exactly that size of texture memory.

Here is the link to that post: http://www.scirra.com/forum/viewtopic.php?f=8&t=7786&p=60406&hilit=vram#p60406

A 256x256 texture takes up 256 kB of texture memory.

A 512x512 texture takes up 1 MB of texture memory.

If you are experiencing other values (like 1.5 MB for 4 256x256 textures, or 3.5 MB for the 512x512 one) then there is something wrong. Graphic card reporting wrong sizes, driver issue, not exactly cut images, Construct reporting wrong sizes, I really don't know...

It would be interesting to find out what is going wrong in your cap, maybe someone else could check it.

I made some examples using the date object as well as timer. If everything is set up accurately it works reliably.

For counters, I recommend using the system expression timer only. The technique is straight forward: Whenever a countdown is needed, set a timestamp. Compare timestamp against timer and that's it. timer returns the time passed since start of the game, it does not reset across layouts, so you can rely on that.

+ bomb('armed') = 1

-> bomb('timestamp') = timer

-> bomb('time') = 35

-> bomb('output') = 35

-> bomb('armed') = 2

+ bomb('armed') = 2

-> bomb('output') = floor(bomb('time') - (timer - bomb('timestamp')) / 1000)

++ bomb('output') <= 0

--> bomb('armed') = 3 (signal for explosion code)

++ Else

--> Set text to "0:" & right("00" & bomb('output'), 2)

Or have a look at the examples (like Verve!, etc.)

For using the counter across several layouts, make bomb global.

Damn, you're killing me

But I'll do my best to make a third attempt.

Distance from edge in pixel:

d = DisplayWidth / 100 * desiredPercentage, e.g. d = DisplayWidth / 100 * 10 or just use a fixed value based on the display size, e.g. d = 100

To get the "real" value:

d = d * (100 / ZoomX)

Applying left aligned:

-> Scroll to x PlayerSprite.X - d + (DisplayWidth / 2)

Or applying right aligned:

-> Scroll to x PlayerSprite.X + d - (DisplayWidth / 2)

I sincerely hope it works

In my opinion, using Python makes sense whenever complex custom data structures, inheritence or reusable code is needed. For the latter it wouldn't make much sense to "hardcode".

from math import *

class Magnet(object):

    def __init__(self, centerX=0, centerY=0, radius=200):
        self.center = (centerX, centerY)
        self.radius = radius

    def lerp(self, a, b, x):
        return a + (b - a) * x

    def attract(self, construct_object):
        a = self.center[0] - construct_object.X
        b = self.center[1] - construct_object.Y
        c = max(self.radius * 0.5, min(self.radius, sqrt(pow(a, 2) + pow(b, 2))))
        f = self.radius / c - 1
        construct_object.X = lerp(self.center[0], construct_object.X, f ** System.TimeDelta)
        construct_object.Y = lerp(self.center[1], construct_object.Y, f ** System.TimeDelta)[/code:3jh1c5m5]

The script could now be saved, e.g as magnet.py, to ...\Data\Python\ and then be reused in every project with every object that has X and Y properties:

+ Start of layout
-> Script[code:3jh1c5m5]from magnet import *

myMagnet = Magnet(300, 300, 224)[/code:3jh1c5m5]

+ Always
-> Script[code:3jh1c5m5]myMagnet.attract(Sprite)[/code:3jh1c5m5]

Clean and simple 

(Please don't test if the code is actually working, it was just a quick written example to show the principle)