Daiz's Forum Posts

  • Pretty sure I read it's fixed in at least an unstable release, but what always worked for me was that instead of writing Panel('whatever') or just 'whatever', I wrote Panel.Variable('whatever').

    Looks like this is indeed the case, the private variables for Panel work perfectly for me in 0.99.85. 'value', Panel('value') or Panel.Value('value') all work just fine. (Sadly, Light's private variables are still broken)

  • The new "is contained in"-expression is great, but now I have a small problem.

    My code at the moment is like this:

    + MouseKeyboard: On Left Clicked on Blue
    ++ S: [negated] Object "Blue" is contained in {"selobjs"}
    --> S: insert object Blue to {"selobjs"} at "end"
    + MouseKeyboard: On Right Clicked on Blue
    ++ S: Object "Blue" is contained in {"selobjs"}
    --> S: Delete Object {"selobjs"}[/code:20rfpigi]
    
    Now, the problem is that I can't get the Delete Object action to do what I want, since I have no idea what to put in the range. Is there any way to get the range values of picked objects or something? Or do I need to resort to some sort of painstaking for each -loop once again?
  • It's a known bug of Panel object, you can't reference it's private variables properly. Go kick David to fix it.

  • You said in IRC that there's a new version of S that includes search expressions for easy index referring without the need for extensive "for each" looping.

    Can you upload it, pretty please?

  • Probably the easiest way would be to do this:

    Add your objects in different layers to two families. For example, put Layer 1 objects into Family Yellow, and Layer 2 objects into Family Blue.

    Now, in events:

    When Player is on Layer 1

    -> Remove attribute from Blue: "Solid"

    -> Add attribute for Yellow: "Solid"

    When Player is on Layer 2

    -> Remove attribute from Yellow: "Solid"

    -> Add attribute for Blue: "Solid"

  • I wouldn't call Construct's level editor bad or inferior to GM's - even for tileset-based stuff. You just need to be wise about how to use your tileset - a combination of tiled background objects and sprites with sprite index works wonders for level creation.

    The initial set-up time might be a bit longer, but once you have established the base, building things becomes quite fast - if you need something, it's very quick to just select one or multiple objects already existing in the level and ctrl+drag a copy of it in the new place. Maybe change one tile here and there, and tweak the width/height of some tiled backgrounds using the snap resizing to grid -function as help.

    Take this tileset and starry sky here for example:

    <img src="http://planar-studios.com/bin/tileset.png"><img src="http://planar-studios.com/bin/bgstars.png">

    In relatively short time I came up with this:

    <img src="http://planar-studios.com/bin/pixelevel.png">

    It takes use of all the stuff I mentioned earlier, plus filters, layers and rotation for ease of work. Looks pretty slick, huh? It's very easy to expand as well when you already have stuff laying around in the layout - just ctrl+drag a copy of one or multiple things and do some little tweaking. I'd say it's quite a lot faster than selecting tiles from tileset every time when you want to add a different tile.

    Here's the cap too:

    http://planar-studios.com/bin/tilesetting.cap

  • This is pretty much the only thing that makes Construct crash for me. It usually only happens after a relatively long time, though. Since I save often, I don't usually lose much progress if at all.

  • Looks like you indeed can't get the value of a key with Python. However, a quite easy workaround exists by using the Run script action. See this cap:

    http://dl.dropbox.com/u/326175/pythonhashtable.cap

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • You mean 0.99.84 right?

    Anyway, the game runs for me, looks like I was just having some sort of weird problem earlier. Though I can't say anything about the saving yet since I didn't get so far yet.

  • Well, this is certainly weird, because I'm on Windows 7 and for example INI file can create files, but not folders. File object can create folders just fine.

    What version of Construct did you build your game in?

    Also, for the record, when I try to run your game, it just stays in black screen and nothing happens. Also, as a recommendation, please don't make the game run fullscreened on first startup.

  • Are the folder names always the same? Couldn't you just create them beforehand with the installer or something?

  • Another way to do it: After destroying an object, Unload the textures for the layout you are in. It will flush the destroyed objects from the VRAM while keeping everything else intact.

  • Now, we all know that Construct doesn't support Unicode. Thus, it's easy to think that it'd make translating your program to Japanese or Russian or to any other exotic language impossible. However, this is false: It is entirely possible. Since Construct is a non-unicode program, it, along with any exe created with it, will run in the user's system locale. Due to this, you can in fact translate your program to any language you want, like this little example application here:

    <img src="http://planar-studios.com/bin/multilanguage.png">

    Now how do we achieve this? First of all, your game obviously needs to be fitted for translation: All your text data should be loaded from external files.

    Then, if you don't feel like changing your system locale and rebooting for every exotic language, or can't get anyone else with the desired system locale to edit your files, you're going to need Microsoft's AppLocale. If you're on Windows Vista/7, you'll most likely need to install and run it in compatibility mode to XP and run it as an administrator.

    Anyway, the important thing about your external files is that they are saved in ANSI, not in Unicode. Therefore, you should open Notepad (or your favorite text editor) in the desired locale using AppLocale, and editing your files appropriately in ANSI.

    Now that you have your external files in ANSI, you just proceed to make Construct load them like business as usual. If you preview your game with the exotic languages, you'll probably notice that they show up as garbage. However, if you run Construct or the built application with the appropriate system locale (either using AppLocale or having the proper locale on your system), you'll notice that it works exactly as it should! Since chances are that your Japanese players have their system locale set to Japanese, they don't need to do anything on their end to make the game work like it should in Japanese.

    Obviously, as you noticed earlier, you can't run all languages in any system locale like you could if the application was Unicode, but that's just something you have to deal with.

    To download the above example program and its source code, click here.

  • That's what I ended up doing, but it'd be nice if we didn't have to use such roundabout ways to achieve something that should work properly in the first place.

  • One good place to start would be to make the forum search suck less. It's not really fun when you try to search for something just to get this:

    Search found 922 matches: create object python

    ignored: create object

    ()