tulamide's Forum Posts

  • 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")

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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)

  • The pixel size values define a fixed dimension of a digital image, whereas the ppi is a variable value defining how big the area will be that an image will use when printed out (ergo non-digital).

    You may have an image of 512x512 pixel and 72 ppi. If you now change the ppi to 144 the image area on the printed page will be half as big. But on the screen it is exactly the same size (unless you change the monitors resolution from normally 96 dpi to something else, but that would only be a visual difference, the screen will still display 512x512 pixel). It also means that the size on disk does not change for such an image with different ppi values. Try it yourself with photoshop. Create a new picture with 512x512 pixel in 72 ppi and save it as .png, then again create a new picture, this time 512x512 pixel in 144 ppi, and save it as png. Now compare the sizes on disk - they are the same. (Opening them in photoshop will show you that they are still defined as 72ppi and 144ppi)

    It is only confusing because photoshop allows you to use the print medium values as definition for a digital image (like 7.1x7.1inch instead of 512x512 pixel), but these values are as described above variable and depend on the ppi. If you would save a 7.1x7.1 inch image in 72ppi, and then one with 142ppi you would just double the pixel size on both axes, so the first one is saved with 512x512 pixel, wheras the second one is saved with 1024x1024 pixel. But both still have the format 7.1x7.1inch.

  • Tulamide how did you do those awesome water effects?.Mine is 75 fps 700 particles.

    Inspired by the quaziblobs, I created an effect doing it, let's call it the blob-shader. But it's not completed yet, that's why I didn't post it yet.

  • Damn

    I swear I will somehow get rid of my fear caused by the lack of language skills and join the chat