Ashley's Forum Posts

  • There's vague plans for a plugin that can to tile-based 'painting' of levels directly in the layout editor, but I don't know if it'll make 1.0.

  • I think the Canvas object would be best for this, but it doesn't support loading images yet... I'll see if I can update it for the next build.

  • The documentation is wrong - I've checked the source and it will exit the application if the current frame is the last and you go to the next layout, or if the current frame is the first and you go to the previous layout. I've updated the Wiki to state this.

  • Does it say "Out of memory" or "Out of VIDEO memory"? An exact copy/paste of the error message might be handy... if it involves video memory, what is your graphics hardware?

  • one time construct crashed and ruined the .cap i was working on INCLUDING all the backups i had!

    Just to shed some more light on this, along the lines of what Rich was saying: we figured out a ribbon bar button corrupted the application in memory, which meant every time you hit save it saved a corrupt .cap file which would never load. I'm sorry this happened, but it's fixed now (thanks in part to your reports), and unfortunately these kinds of things happen with pre-release software

  • I've looked up the error and something weird is happening like every plugin is crashing as Construct tries to load it, so you don't get any plugins loaded. I have no idea what is going on. I guess you should try older versions, in case it was something I changed recently.

  • It's a long shot, but could you try installing this, rebooting and trying again?

    I've read that file does not visually do anything after you double click it, but that it will have taken effect anyway (it looks like you double click and nothing happens). Alternatively you can unzip it in winzip and extract a bunch of DLL files from it, which might work if you dump them in the Construct.exe directory.

  • Well, there's a bit of an undocumented feature here. If every object in a family has the same behavior - ie. family 'Friendly' consists objects A, B and C, all of which have the 'Bullet' movement - then the 'bullet' tab appears for the family as well in the dialog. If one of them has it missing, it won't appear - if it were there, a 'Set speed' action for the bullet can't be applied to an object that doesn't have a bullet movement, hence the requirement that all objects in a family have the same behaviors for this to work.

    I think it might crash in the current build, but if it does, it's fixed for the next build.

    I haven't documented this feature anywhere yet. But I hope when/if it works, it satisfies you

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Does it happen if you reboot and start Construct for the first time that boot? Sounds like it might've crashed and not released all the plugins from memory.

  • j0h, you are describing exactly what families do and what they're for. Why wouldn't you put "Left_block", "Right_block", "Top_block" and "Bottom_block" in a family "Blocks", and use the event

    + "Blocks" on layer 7

    --> Set X to ...

    You may argue you'd have to put every Sprite in your game in to one family, but this is necessary. Any large, complex game will have sprites for completely different purposes, ranging from the player, enemies, interface, terrain and effects. Applying events indiscriminately to all of them would not be useful, and you would want to specify exactly which, by using a family.

    If there WAS an 'All sprites' type family automatically built in, you'd probably run in to some serious problems quickly. If you code 100 events using 'All sprites', then you add another Sprite you don't want to be affected by all these events, you have to add a family to all the objects you want to affect, then edit 100 events! It might be boring going through adding a family to a lot of objects (perhaps a Family Manager dialog could be added to make this process quicker, eg. mass-selecting objects and adding them all to a family in one go), but I think it's the best solution, because it gives you the option of not having a Sprite affected by those events.

  • the "for each object (ordered)" event loops trough objects

    ...

    Then you come to make an action. And the first thing the action wizzard does is ask you "wich object"?

    You just pick the same object as you are looping through! Is there something difficult about that?

    This is like any other scripting language, where the object is mentioned twice in the loop, eg:

    for (ObjectA in ObjectAInstances)
	ObjectA.X *= -1;[/code:3at97xq8]

Note the two references to "ObjectA" there.  Making it automatically pick the object currently being looped is impossible, because one event can loop two objects, iterating every combination of the instances:

+ For Each ObjectA
+ For Each ObjectB
-> An action MUST pick an object - Construct doesn't know on its own!

If you choose an object which is NOT being looped in the object picker, it is like doing this in a script:

[code:3at97xq8]for (ObjectA in ObjectAInstances)
	OtherObject.X *= -1;[/code:3at97xq8]

In other words, the action is simply done as many times as there are ObjectA instances.  In my opinion, this makes perfect sense and is completely logical!  It's impossible to leave the 'pick an object' field blank.

[quote:3at97xq8]"pick object (x) "

As Rich said, this condition has no effect.  The 'On collision' event already picks the two objects.  Rich's example is identical, and exactly what you need.

  • He did't answer me (as usual)

    If I don't answer a thread, it's usually because I don't have time

    [quote:32kn1z8n]No individual event sheets are a major draw back

    No they're not - I've read and I think I understand your suggestion for them, and they wouldn't make eventing more flexible. They'd be purely for organising your events in to different places. None of the things you have mentioned sound difficult, let alone impossible, with ordinary events!

    Still (back to topic), another interesting point about being pre-1.0, is if you have your major frustrations or bugs or ideas, they have a decent chance of being implemented.

  • Just wanna throw in that the RTS movement's Move To XXX actions run a fairly CPU intensive search algorithm to generate the shortest path around obstacles. You should avoid running it every tick (add an 'every 1 second' or 'trigger once' condition for example) to avoid redundantly wasting CPU time.

  • I develop Construct, and just to repeat what Doppel said a little, the most telling thing is it hasn't yet reached version 1.0 - we're still in beta. I have to admit there is still one known case (although hopefully rare) where your .cap file can become corrupted and you can't open the file any more - although autobackup should help stop this from ruining everything. The aim is to have construct 100% stable and completely viable for at least semiprofessional game development when we reach version 1.0 - you could look at our release date history and make your own guess as to when that might be.

    So while I would not advocate serious or professional usage of Construct until 1.0, I would welcome any dabbling and reporting of issues, bugs and those annoyances that send you fuming, so we can fix them for the 1.0 release. That's how 1.0 is going to end up stable and useful - with the input of our testers!

  • .........................