I would focus on the editor itself. It is the tool allowing access to Construct's functionality, so it should work hassle-free.

That involves everything, from the picture editor to the project tab (e.g. remove Sounds, Music, Fonts and Menues, they have no functionality and are just irritating first time users; renamed sheets appear with their previous names under layout, etc.), animator tab and especially the wizard with its inconsistencies, wrong labels, wrong descriptions, etc. All of them on the tracker.

And in general, I would rather like to see everything removed, that doesn't work and can't be fixed, than letting it in and confusing users.

Another example is the script editor: why having icons for loading and saving when they have no functionality?

Davio was a bit faster...

Anyway, the same technique he described, but in a documented .cap

Download ChangeColor.cap

You're welcome

Could it be some kind of reference problem? Take the "PyPkgTest" folder as an example and copy one of the .pyd (e.g. base.pyd) to the folder "mypython". Now (having appended the game's folder path to sys.path) to reference it, you can't just import "base". It needs to be

import mypython.base[/code:nbqn8006]or
[code:nbqn8006]from mypython import base[/code:nbqn8006]

For the first one, all calls to "base" must be "mypython.base", the second one let's you reference it directly, without "mypython."

EDIT: Also, Python is case-sensitive. Something like "import myPython.base" won't work, cause the folder is known to Python as "mypython"

tulamide, I don't mean to be a bother but is there any way you could show me a working example, both *.cap and compiled? I feel really stupid but for some reason, I just can't get your method to work

Here you are

PyPkgTest.rar

The rar contains a folder "PyPkgTest". Wherever I move this folder to both .cap and compiled .exe work. Of course, the inner structure of this parent folder needs to be kept intact. The module is a very *very* easy example module, it's just a class that counts from 10 up with step 10 and resets when reaching 100. But with it you can validate that it's really working.

Tulamide, they should work identically, I suspect the blank __init__.pyd caused it not to work. I didn't "import sys" because it was already imported when Construct initialized python.

Thank you, R0J0hound. The information about sys is stored

For the curious among us: The blank file I mentioned should be named __init__.py not .pyd (two leading and two trailing underscores), and is a kind of identifier for a python package. The __init__.py files are required to make Python treat the directories as containing packages.

This is a python package folder structure inside your games folder:

- plants
    __init__.py
    - trees
        __init__.py
        beech.py
        oak.py
    - flowers
        __init__.py
        tulip.py
        violet.py[/code:1ly30354]
The package is identified by its name "plants".

Now you only need to add the current working directory (= the path to your games folder) to sys.path:

version 1
[code:1ly30354]import os
sys.path.append(os.getcwd())[/code:1ly30354]
version 2
[code:1ly30354]sys.path.append(System.AppPath)[/code:1ly30354]
version 1 is of help if you happen to import a package from within a module.

Either way, the package is now available for import. You access them with their folder and module names in a dot structure, and there are several ways to import what you need:
[code:1ly30354]import plants.trees.oak[/code:1ly30354]
This imports the module oak, and it must be referenced in code with the full name structure:
[code:1ly30354]plants.trees.oak.grow(speed, branch)[/code:1ly30354](assuming, grow is a function of the module oak)

A reference shortcut is:
[code:1ly30354]from plants.trees import oak[/code:1ly30354]
Now oak can be referenced directly:
[code:1ly30354]oak.grow(speed, branch)[/code:1ly30354]

These techniques work for all files that are imported directly using import, either pure python or extensions (like the dll for python, identified by the extension .pyd)

R0J0hound, could you explain what exactly could be the difference between

import os
import sys
sys.path.append(os.path.join(os.getcwd(), "joystick"))[/code:hnv0bltc]and

[code:hnv0bltc]sys.path.append(System.AppPath + 'joystick')[/code:hnv0bltc]?

The first one works like a charm for me, so why didn't it work for [b]kmvegas[/b]? Also, why the inconsistency of not needing to import sys? (According to python.org it needs to be imported)

If I'm totally aside just ignore me, but does the standard package way not work?

If you create a folder (e.g. named joystick) for the .pyd in your games folder, place a empty __init__.py there too and in the script editor before anything else write

import os

import sys

sys.path.append(os.path.join(os.getcwd(), "joystick"))

That does not work?

Particularly in Construct (never tried writing shaders for anything else) they go in screen space, not object space as the algorithm goes.

So I have no idea how to even go about it.

You're not bound to screen space. That's what boxLeft, boxRight, boxTop, boxBottom, pixelWidth and pixelHeight are for

Example:

Tex.x / pixelWidth would give you the horizontal pixel index in the screen space.

Let's say you have a window canvas of 800x600, then pixelWidth would equal 1/800 or 0.00125

Tex.x is a value between 0 and 1. For Tex.x = 0.5 this would be 0.5 / 0.00125 = 400

If you want to know the relative pixel index just substract boxLeft: (Tex.x - boxLeft) / pixelWidth

boxLeft is the horizontal position of the left edge of the current object as a value between 0 and 1.

Let's assume it is 0.25 (which would be 0.25/0.00125 = 200 as pixel index). Then we have (0.5 - 0.25) / 0.00125 = 200, which is the relative pixel index from the left edge of the object.

One problem is that you could have situations where you sample a space between two pixels, you then get a mix of the two colors of that pixels. Often this is avoidable by rounding the pixel index value, but then you may sample a pixel more than once.

And when pixel sampling isn't important you can even normalize the object's dimensions, making it easier calculating:

float2 coord = float2((Tex.x - boxLeft) / boxWidth, (Tex.y - boxTop) / boxHeight);

now you have coordinates relative to the object, ranging from 0 to 1 (0 being the left or top edge of the object, 1 being the right or bottom edge)

One thing is important: With a pixel shader you're working on the final output not the input. You have to reverse think about those algorithms.

You know, you guys could always just use functions. Name the function object F, make an on function abscosp and set the return value to:

lerp(.Param(1),.Param(2),abs(sin(lerp(0,180,.Param(3)))))

Then you can use it with F.abscosp(a,b,t) anywhere you want.

While you're right in general, the difference to using Python is that once written you can use the very same script/module etc in every project without the need of rewriting it. You can literally build your own library, and as long as Construct does not support "outsorcing", Python would be the only way.

I have resized a lot of objects in the layout editor, could that have something to do with it?

Only, if you actually resized the canvas of the objects in the picture editor.

I wonder...

PyGame is a wrapper to sdl. sdl is written in c, fully supported in c++, and open source. I found that the joystick support is just on file with a few headers: http://hg.libsdl.org/SDL/file/0972c2893e68/src/joystick/win32/SDL_dxjoystick.c

We have a few ambitious c/c++ programmers in the community. I don't have much knowledge of actual development with c++, but wouldn't it be possible (without months of 16h per day work) to pack this to a plugin?

Are you using ogg files? They might be stored decompressed when embedded, I'm not sure.