Automatically appending to sys.path would be a convenience. You could also generalize it with

import os
import sys
sys.path.append(os.getcwd())
[/code:1xjyesjw]
On the other hand, when thinking of later uses by other constructors, it might be better to let them just copy the package to Constructpath\Data\Python. This way, everything one might want to use can be found at a central, general place... I made no decision yet.

Writing plugins with Python? I don't think it's possible. The sdk is for use with Microsoft Visual C++/Studio, and embedding Python through C++ (although possible, [url]http://docs.python.org/c-api/[/url]) would just make it more complicated. But maybe some day one talented programmer creates a python-plugin, a precompiled plugin whose functionality is completely controlled by simple python scripts. I would walk over broken glass if that would help to motivate someone developing it

Glad to be of help

But remember to organize your code and try to understand/use classes: they can make your life a lot easier!

I'm pretty familiar with Python and the concepts of modules, classes, methods, functions and oop. The background for my question was, that I'm coding a system that might be of help for many Constructors, and I want to establish it with the least effort for them as possible. The complete system shall run with no more than two (visible) scripts:

Start of layout:

from fancypkgname import attractivemodulename

myclass = attractivemodulename.coolclass(globals())
[/code:25apxpgq]

Always:
[code:25apxpgq]myclass.update()[/code:25apxpgq]

They should not have to alter the code everytime they use it in another project. That was the intention

You can access System using globals() this way:

> def sayBoo():
    Text = vars['Text']
    System = vars['System']
    Text.Text = "Screen is %d,%d" % (System.DisplayWidth, System.DisplayHeight)
[/code:39u3aevf]

Great! Thank you, Keeper, I'd say this is as close as possible to what I had in mind. Someone should start a wiki about Python with Construct, globals() should be more prominent

Fantastic guys!

Thank you so much, globals() is a very good approach. Only "System" isn't referenced, but maybe I find it when I don't look for it

Thank you very much for the answer

__builtin__ won't help in this case, because it refers to previously defined identifiers in modules. The objects of Construct are not defined in a module and can't be. Construct's objects are referenced through their names and they can change from session to session. Take the first example:

def sayBoo():
    Text.Text = "Boo!"

sayBoo()[/code:1n5z6rp3]

If you now rename the text object in Construct to "tBoo", you get the same "global name" error. As soon as you update your script to "tBoo.Text = "Boo!" it works again.

The editor seems to map words to object references on the fly. I hoped I could have access to this mapping too (because 'System' is a built in object that will never change its name it would be easy to access without being too "hacky")

Let's say we have a layout with a Text object named "Text" and create a script in the script editor:

def sayBoo():
    Text.Text = "Boo!"

sayBoo()
[/code:3ijtereh]

We place this script under a "start of layout"-event and run the app. The text is set to "Boo!", just like it was intended.

If we now save this script as a module named "boo.py" in the appropriate folder and replace the script in the script editor with

[code:3ijtereh]
import boo

boo.sayBoo()
[/code:3ijtereh]

and run it, we get the error "global name 'Text' is not defined". Obviously, the interpreter is not aware anymore, that Text is a reference to the text object. Of course, by extending the function with a parameter textobject and in the code using this reference (textobject.Text = "Boo!") it works again.

But what to do, if there is no input possible? Is there another way to reference an object? The above was just an example, what I really would like to access from within my own module are a few attributes from System, like System.AppPath

The script editor resolves the references on the first code layer correctly, so there must be a way. Can someone point me to the right direction?

In my app I want my new spawned objects "inherit" some variables from their ancestors, or object that created them. Is it possible using events?

No, Construct does not support that directly. But you could make your own classes in python or setup some supers with 's' and manage them from there.

I wonder, is there away to detect what the GPU is in a system and deny or print a warning in the application window?

I'm afraid I can only answer this question. The system expression "Display Device" returns a string describing the graphics card (e.g. "ATI Radeon HD 2600 XT")

[EDIT] Was thinking if the vertices are somehow inaccurate. Do you by chance have an uneven number of TBs? If so, does using an even number of TBs change anything?

While Squish showed a quick solution, it is not suitable for all needs.

Imagine you would want to set the sprite's dimension to 50% and a few seconds later to 75%. Let's say the original dimensions were 100x100. Then we would want the sprite to first shrink to 50x50 and later grow to 75x75.

(height omitted)

1) width = width * 0.5 (the sprite is now 50x50)

2) width = width * 0.75 (the sprite is now 37.5x37.5)

You could keep track of when to grow and when to shrink, and calculating that 75% is 1.5 * 50% and therefore replace 2) with width = width * 1.5, but it gets more and more complex as you change the sizes.

An easier way is to use the expressions Get original width/Get original height. They always return the original initial values regardless of any changes to the size.

1) width = OriginalWidth * 0.5 (sprite is now 50x50)

2) width = OriginalWidth * 0.75 (sprite is now 75x75)

It was my understanding that using "Every x milliseconds" will result in the same speed whatever computer it's run on, and whatever frame-rate it ran at, because it's already factoring in the time delta and will run based on actual time passed.

In which case, your first post should run fine.

It's when you use "Every x ticks" that the speed is affected by frame-rate and computer speed.

Correct me if I'm wrong, because all of my game is based on "Every x milliseconds".

Krush.

You are partly wrong, please have a look at the links I posted above, it is explained in detail there (incl from Ashley)

You might also want to read these threads:

I'm sorry, I totally forgot about this thread

Yes, you assume right. Within Construct's implementation of effects you have access to these four stages:

1) the original unaltered texture of the object the effect is applied to (=source)

2) the texture with all previous alterations from other effects in the object's effect chain (= foreground)

3) the texture of all graphical content that was already processed before the current object (= background)

4) the texture of the previous effect in the object's effect chain (=previous)

I never used 4), can't tell you exactly the difference to 2)