KrushBrother's Forum Posts

  • Well, it appears that in one of the polls you've had, you were explaining workarounds to life without groups, using booleans, etc, and other people were saying how they'd still prefer groups.

    Looking at it just now, it's clear that you were talking about how to do it "until" you got around to adding them, and I guess I read it as you explaining why you weren't going to.

    Glad I'm wrong.

    Groups are one of my favourite things in C1.

    Now all you need to add is an .exe exporter.

    lol

    Krush.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • > Last I heard, groups were going to be left out of C2

    >

    Where did you hear that?! We've always planned to put groups in, to match Classic's features!

    Seriously, I remember the discussion, and some people were saying the same as I was thinking, and that was how powerful groups can be.

    I'm sure I didn't dream it.

    I'll have a quick look and see if I can find the thread.

    Maybe it was when you were still brainstorming C2.

    Krush.

  • Thanks for taking the time to do that test Dave.

    I think we can conclude that, at least with it's current implementation in C1, Python is no match for Construct's events.

    Thanks again guys.

    Now I can concentrate on the next stage.

    Krush.

  • Last I heard, groups were going to be left out of C2, so it's good to hear that you've changed your mind.

    Still not enough to make me use C2, but a step in the right direction.

    Krush.

  • Some interesting reading there.

    Thanks guys.

    Those FPSs are particularly interesting Lucid.

    Especially the loops.

    My data is manipulated within nested loops, with the arrays written to and read from a lot, based an several factors, so it's hard to say whether Python would be faster or not.

    If I could have a definite answer as to whether arrays are directly accessible from Python or not, I could either test it in Python or just give up and be happy with the results I get from the events.

    Krush.

  • I just send it to a friend and he still don't have sound

    What else can be wrong?

    Did you also send all the sound files to your friend?

    Krush.

  • Thanks guys.

    Yeah, Python would have to interact with Construct, in as much as it would be reading and writing to the array that is being used by Construct.

    The post that I mentioned concerning Python not being able to access arrays directly was quite a while ago, so I'm wondering if it was fixed in later versions.

    Then again, we don't really know when the original devs stopped working on C1, so it's probably as it was.

    And yeah, it's a lot of data, and I'm happy with the speed.

    I can't optimize the events any more than I have, so I would have taken a little increase in speed if it was on offer via Python.

    Krush.

  • I've just written an algorithm using Construct Events that manipulates a huge array (around 4.8 million items of data), and it works beautifully, taking around 2 minutes 18 seconds to complete.

    Now, I was about to write the same algorithm in Python just to compare the speed, and I came across a couple of threads here that may mean I'd be wasting my time.

    First of all, I noticed a conversation from last year where there was talk of the speed difference between events and Python, and it seemed that events were thought to be faster (if that's true, well done Ash & Co).

    Secondly, in another thread, someone mentioned that Python couldn't access Construct arrays directly, and the overhead of the workaround would mean that it would lose any speed advantage you may have gained.

    Now, I realise that this place has gone pretty quiet again, but I thought I'd ask anyway.

    Anyone have any further insight into this?

    Krush.

  • Well, you're bound to get fanboys defending every console.

    They seem to come out of the woodwork.

    Never understood it.

    Personally, I own all 3 main consoles.

    The PS3 rarely gets used except for GT5 and the brilliant Uncharted (rarely online).

    The Wii gets a fair bit of attention for a quick game of something (rarely online).

    The Xbox 360 gets used the most by far (quite a lot of online play).

    But this isn't about which console/company, or fanboyism.

    This is about a company not looking after your personal data.

    This time it happened to a company whose network I rarely use, but if it happened to Microsoft's XBox Live (and I'm sure they'll be targeted) then I'd stop using it.

    People are too easily pacified, even after such a breach of security, and the offer of free games being lapped up by people makes me laugh, which is why I made my original comment.

    I don't accept it from $ony, and I wouldn't accept it from the other 2 either.

    And yeah JayJay, a month is a hell of a long time for a network like that to be down.

    Unthinkable really, when you consider the resources at their disposal.

    Krush.

  • Lol $ony

    "Yeah, we let your private information fall into the hands of hackers, but if you forgive us we'll give you some freebies!"

    I'm not sure whose worse.

    $ony or those who think it's a fair trade.

    I won't be taking them up on it.

    I rarely use the PS3 online anyway.

    Krush.

  • The InputSystem plugin looks good, and the author seems to have responded with fixes when bugs were found.

    But it is still beta, and loading the 3rd example that comes with the plugin shows a strange behaviour when detecting a click on a text field.

    It seems to be miscalculating where the text field is, and you need to click above the text for it to register.

    This is why I mentioned a simple plugin that gave us access to the same drop-down choices we have in the editor.

    Plugins that try to do everything are great, but obviously they are prone to a lot more bugs, and most of the time they are overkill when you're just looking for a single feature.

    I was hoping that one of the devs (or caretaker devs) would join in this discussion.

    I will test InputSystem to destruction, and hopefully find it'll do the job without any problems, and then consider adding it to my project.

    For anyone who doesn't know what I'm referring to when I talk about the player controls at edit-time, I'm talking about the drop-down lists at the bottom of the left panel in the Application Properties, where you choose which key is used for left, right, jump, etc.

    If we just had access to those drop-down choices during runtime, user-defined keyboard controls would be simple to implement without the need for plugins.

    If I'm honest, it's one of the things that I thought should have been in Construct from the very beginning, because it's something that almost every game has.

    Krush.

  • InputSystem plugin sems to be fine?

    Well, I don't know if it is, as I haven't looked into it.

    I remember one of the input plugins had problems, and I don't want to introduce a buggy plugin into a major project at this late stage.

    I will do a search on the plugin and see what the general consensus is.

    But my point remains valid.

    For a simple way of redefining controls, all we need is access to the properties of player 1 at runtime that we have at edit-time.

    Should be simple to implement.

    Krush.

  • Hi guys.

    I was just messing around with changing the control keys for Player 1 in the Layout properties in the editor, so I could test my game with various sets of controls, and I got thinking.

    I know that there's a plugin for custom controls (not sure if it's stable, finished or appropriate), but I was wondering how difficult it would be for the guys who are now updating C1 to allow us access to those properties at runtime.

    It would then be simple for us to program our games to allow the user to decide which key was for which action.

    Any thoughts on this?

    It just seems like the ability is there to change it in the editor, so surely it wouldn't be too hard to allow us to set those same properties at runtime.

    Krush.

  • Hmm, this is strange!

    When I read your posts, I thought of course I did, it's obvious, but then thought perhaps I hadn't for some reason, and was rather hoping I hadn't.

    Unfortunately, I had, so it wasn't that.

    Maybe something's screwed with my plugins folders.

    The problem is, whenever there's an update to Construct, I don't immediately update, but when I do find a version stable enough to update for use with my projects, I tend to copy over the plugins/effects folders each time, and I'm wondering if I have some conflicts going on.

    Also, I've used LibNoise in the past with Python, long before I used this plugin, so perhaps I'm using an old version in my exports folder.

    So, seeing as I'm overdue a proper cleanout of my Construct files, I'm going to start fresh with Classic 2.1 and install the plugins that I need one by one.

    Hopefully that will mean that I have all the right versions of the files, and things will work as planned.

    I'll keep you posted.

    Krush.

  • Well, the libnoise.dll fixed the startup (should have realised that was missing, lol), but I get the same (126) error when running the exported .EXE

    I know that the plugins are renamed as a number during runtime, so maybe ROJOhound could tell me which plugin 5.csx relates to?

    Krush.

    EDIT: It does look like it's the noise plugin.

    When examining the 5.csx file in the temp directory, it seems to be the noise.csx renamed, so I'm not sure whether the plugin is to blame or Construct is.

    Shame.

    Although I only use one small aspect of the Noise plugin currently in my game (and that part is easy to reproduce other ways), I had planned on using it's more advanced features for other parts of the game.

    I'll wait a day or two to see if this is fixable before exploring other avenues.