Arima's Forum Posts

  • There is an option in the touch object's properties to use mouse clicks as well.

  • That would make it smoother and use less RAM, but it still has the problem that it would require reimporting the level files every time they're updated.

    As far as I understand it, C2 couldn't just automatically grab the file from a path when exporting because browsers don't allow overwriting files unless it's through a file selection window - which could be used instead of the one click solution, I suppose, but that's a lot more clicks every time you save... but I guess it's the best option available. Could C2 do it that way then? Have the user point to a file that is grabbed at export rather than stored in the .capx itself? That could be helpful for updating other assets as well, like music. You wouldn't have to reimport after updating the file, it would be incorporated automatically at export.

    It's a shame browsers don't have a 'developer mode' of some sort to unrestrict access for a page if the user sets it to. That would make this stuff way easier...

  • In response to the conversation on twitter between Ashley and konjak - I thought I would add my thoughts and we could discuss it on the forum.

    This is been one of my main concerns about C2 using HTML5. I like to make custom files for things like levels since I like to do some unconventional stuff sometimes. With CC it was easy, there were actions for saving and loading arrays and hash tables. C2, not so much because of the web format - security limitations obviously don't allow that sort of thing. That presents a frustrating challenge for developers.

    Let's assume I'm trying to make a level editor. I could save the instance data (position, animframe, etc) to local storage as a JSON string, but there are several problems with that.

    1, local storage only works up to 5MB of data. I've heard chrome stores its data in a different way, basically resulting in only having 2.5MB. So what happens when the level data is above that amount? The browser throws an error to the console. That's it. The only way to tell if this happens is to have the console open and watch it when you save. So you could be working, forget to check, and lose your edits. It would be nice if there were 'save successful' and 'save unsuccessful' conditions so we could display an error message in game.

    If there was a way to raise a browser's local storage limit, I would set it to a gigabyte and not have to worry about it at all, and it would solve most of the problems, except for...

    2, the data in local storage is stored in a very insecure way. What if there are multiple users of that machine, and one of them decides to clear the local storage? Bam, all the levels are erased.

    What I'm doing in response to the two problems mentioned above is using the file saver plug in to save the JSON string to disk as a file to make sure it gets saved correctly. The problem with this is I get a gazillion copies of the file that I have to keep cleaning up because it won't overwrite the previous file. That's a mild annoyance, though.

    Also, I tried using the array's new save feature, but chrome put up a 'popup blocked' message. Even allowing popup windows, though, the right cliking and selecting save as requires a whole lot more clicks each and every time I want to save. You might want to check out how the file saver plug in does it - one action and it saves.

    3, then the're the problems resulting from not having enough space if you need more than 2.5MB. Mainly, the loading problem. Once I've got the data out of the program and on to disk, I can't get it back into the program at runtime without using the file loader plug in, which requires clicking a button, selecting the file from the window that appears, then clicking OK - every single time I preview. Very annoying. That also obviously won't work when the user is actually playing the game. Even if local storage allowed more data, that data can't be transferred when exporting.

    So then before exporting, I have to put the data directly into C2. To do that, I have to save to disk, open it in a word processor, replace all the quotes with double quotes because construct won't accept it as is if I paste it as an expression, and then copy it and paste it back into C2.

    To get around having to do all that I've been trying to come up with some sort of method to save SOME of the level data in local storage - the stuff that's been currently worked on - and only needing to load from disk when switching from one major area to another - but then I need to do that even when playtesting the game and not editing it, and I still need to redo the process in the paragraph above every time I want to update the exported levels. I don't really have an elegant solution for this.

    The process, honestly, is just frustrating. It was so simple in CC, one action to save and one action to load. If it wasn't for the local storage limits, it wouldn't be as much of a problem, at least when editing.

    I realize that there is a lot about this that you can't do anything about, but having conditions to check if saving to local storage was successful or unsuccessful would be at least some help to know if I've gone over the 2.5 MB limit, and maybe an expression to know the amount stored/available, because on a one-person machine, everything before that point is fine for editing. I don't know what could be done to simplify the process for incorporating the data back into C2 though.

  • It doesn't matter what you use, it's simply not easy to make a strategy game. It's one of the more difficult and complex genres.

    That said, it's entirely possible to make a strategy game in CC, and some things are in fact made significantly easier, such as pathfinding with the RTS behavior, and target acquisition with the turret behavior.

  • It was just added to r87. It's been renamed to pickedcount.

  • Hey, no worries harrio, don't let it discourage you from being involved on the forum!

  • What are you trying to achieve? If it's z-ordering based on y position, try this plugin: construct.net/en

  • Fantastic! :) Thanks, Ashley! Any word on allowing multiple conditions between ors as well?

  • Notice there is only one condition between each or in those examples. You can't have:

    Sprite.x=1

    Sprite.y=2

    or

    sprite is visible

    If you try it, it will result in:

    Sprite.x=1

    or

    Sprite.y=2

    or

    sprite is visible

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • harrio - I think you're overcomplicating it a bit. The way it works now:

    Imagine there are two instances of a sprite. One has a variable=1, the other variable=2.

    If sprite variable=1

    or

    If sprite variable=2

    • rotate sprite 1 degree

    In this case, every tick, both instances would rotate 2 degrees. Add a third instance and a third condition:

    If sprite variable=1

    or

    If sprite variable=2

    or

    If sprite variable=3

    • rotate sprite 1 degree

    ...and the sprites will rotate 3 degrees, because the actions are run 3 times.

    Not only is the or condition not currently separating the objects from one condition to the next (why would the one with variable=1 rotate 3 times anyway? It seems the instances are being added together the way I think it should work as described below, and then the actions are running 3 times for no reason at all then? I'm a bit confused as well), I don't understand why the actions should run multiple times either.

    In the first example in this post, I think condition 1 should pick the instance with variable=1, then condition 2 should add the instance with variable=2 to the selected instances, and then run the actions once on the selected objects.

    Also, you can't currently have multiple conditions between ors, which is why I suggested or should be a normal condition above.

    harrio, in regards to what you suggested above, it's currently one condition only between each or, so this:

    If right arrow is down

    or

    If D is down

    or

    if D and right arrow are both down

    - set sprite x to sprite.x+1

    ...wouldn't work. Not to mention the sprite would move 3 pixels because all three sets of conditions would be true. You just showed what I mean about what's intended - for the sprite to move 1 pixel if any of the conditions are met!

    Adding an Ashley to make sure this thread doesn't get missed.

  • So I wanted to discuss the or condition and the way it works. I think the way it's currently working has the same sort of problem the on collision condition used to have - it's inconsistent. For example:

    If right arrow is down

    or

    If D is down

    • set sprite x to sprite.x+1

    This could be handy for having both wasd and the arrow keys control a player, but if you hold right and D down at the same time, it doubles the speed of the sprite.

    Sure, you could have another event limiting the speed or something, but that would be another event, which defeats the purpose of the or block. There might as well be a second event for if D is pressed and the right arrow isn't pressed.

    I think instead of the way it works currently, it should be an additive selection list.

    If sprite x is > 100

    or

    If sprite y is > 100

    • rotate sprite

    In this example, what I think should happen is construct should check which ones x position is greater than 100, then check which ones y position is greater than 100 and add those instances to the selected list, then run the actions once on the combined list, rotating all of the selected sprites once.

    The way it currently is seems inconsistent - the number of times the actions will be run depends on the number of conditions that return true. What if you wanted to toggle a flag with an or condition? Then depending on the number of conditions that return true, it might get toggled twice.

    Also, it would be nice if the or condition was more of a traditional condition that could be dragged and dropped so that multiple conditions could be checked between an or.

    If sprite x is > 100

    If sprite variable = 1

    or

    If sprite y is > 100

    If sprite variable = 2

    • rotate sprite

    It would allow more control this way.

  • Couldn't you just set the variable to 0 each time before the for each? It'll add 1 to the variable however many times there are instance of the object picked.

  • I might use separate layouts if it weren't for the runtime error that occurs everytime I either:

    Go to a different layout.

    Restart the same layout.

    Load a game save.

    Are you using transitions? If I recall correctly, those can cause crashes. The 'or' condition can cause crashes as well.

    If you want to find out what's causing them, save a copy of your .cap then start deleting chunks of code to find out what causes it.

    I have been working on a different game and made a very large map, a size in the tens of thousands, and neither Construct nor the app so much as coughed about it. I heard layers were rendered as textures so it didn't make sense to me that it could handle images that large unless it were culling things off screen. Mind you this layout had several layers with various graphics and objects spanning the size of the map, the level layouts, decorations, background layers, game objects, etc.

    Tens of thousands is no problem. Layers are only rendered as textures if you set them that way in the layer properties. Even then, it's only the part of the layer that's visible on screen. Stuff that's off screen isn't rendered, the graphics card takes care of that automatically, but the logic of the objects is still there and being processed.

    Loading only parts of the map when the player is near is a good idea too, but how do I do that? Do you mean loading external images in place of sprites? I tried that too and it was picky about what images were loaded. Some images worked and others gave me the same runtime error that changing layouts gave me.

    Don't load external images unless you're willing to put up with a delay while the hard drive reads the file, stores at memory and then flings it to the graphics card. That can take long enough to be noticeable. Best to load from files during transitions between areas.

    You would want them to be preexisting objects that you create and destroy based upon the proximity of the player. You could divide all of the objects into a sections on a grid, save all of the instances in each grid cell to an array, and when you get close to the boundary of one section, you could create all the instances in the new section, and when far enough away from the old one, delete them. This isn't really a simple thing though.

  • I think what you want is the countmatching("object") expression that CC had. It would return the number of picked instances. It would be very useful!

    Currently you can use a for each and add to a variable.

  • You should definitely not use layouts that size. As I understand it, floating point precision starts getting less accurate at 100,000 pixels.

    Also, CC may be fast, but there is still a bit of overhead from having an object in the layout. My computer can manage 100,000 sprites in a layout at 60fps, but that's with no code or behaviors at all.

    It would also use a lot of memory, and likely would take longer to load as well. These reasons are why games segment areas. Games that don't segment areas fake it by streaming in data to make it seem like it's one huge area - it is, it's just only processing one part of it at a time.