WackyToaster's Forum Posts

    Argh! I didn't cancel anything, I just didn't realize my subscription was expiring and I hadn't loaded the card yet -___-'

    That is a massive bummer :(

    Your original price should be carried over if you renew before your current subscription ends.

    That is the case. I still pay the secret cheap price unless I ever cancel my sub which I don't plan to :)

    construct.net/en/blogs/construct-official-blog-1/upcoming-price-changes-new-1718

  • You do not have permission to view this post

  • I agree on the list approach. Keeping a list of x,y positions of tiles that are available to claim makes sense to me.

    To find the nearest tile without resorting to sprites, you can use the distance expression. You'll have to go through the whole list though to find the nearest but I think "pick nearest sprite" doesn't really do anything different to that. So you would go through the whole list, store the distances of each and then use the one with the smallest distance.

    But realistically, there is nothing really wrong with just using invisible helper sprites either... It's a functional solution with little to think about and probably already optimized to run as fast as possible. Many roads lead to rome.

  • This looks correct. Make sure you have all the correct steam SDK files in your package.nw.

    I personally used the Greengrinds addon just recently (on latest beta) and it works perfectly. So worst case you could try this instead. construct.net/en/make-games/addons/244/greengrinds

    Also pro tip: You do not need to edit the package.nw after exporting. I see this repeated time and time again and it's just not true. All you have to do is import the required SDK files into your game directly inside Construct. That's it! I wasted so much time on this nonsense because of that misinfo! Just export it, run the icon updater, zip it and ship it.

    Here's what my files look like. Tested and working on windows, mac and linux.

  • This was a change in a recent beta release

    In other words, if there's nothing happening on the screen, the fps will "drop" simply because it's not necessary to redraw the screen.

    We've also made some changes to framerate handling to clear up some confusion. Firstly, the standard frames per second (FPS) measurement previously actually measured ticks per second, and so could still read 60 FPS even if nothing was being rendered, which happens when nothing is changing. We've changed it to now only measured rendered frames per second, so it will drop to 0 when nothing is being rendered. We've added back a separate ticks per second (TPS) measurement which reflects the old measurement. This all makes it clearer to identify the rate at which frames are drawn and ticks are processed, which are not always the same. We've also changed the 'Set min/max framerate' action to 'Set min/max delta-time' to more accurately reflect what it does, as using the term 'framerate' is a bit misleading there.

    I'm just not sure why the other example doesn't show this drop since there's also nothing happening on screen...

  • Not sure about going with 1.05... The 1 in the formula should stay constant afaik and I don't know about the ramifications. Maybe it's fine?

    This formula will be somewhat different to the framerate dependent lerp and you should adjust the factor accordingly. Basically the higher the factor, the slower the speed.(As opposed to the other way around) I found I'm having to use very small values to make it snappy, like 0.000000001

    But the point is it's framerate independent so even if it's slower than it should be, it will be so across all framerates.

  • Oh I know, that's what I mentioned as the alternate solution ;)

    There's still some issues I see even if I had such an exporter, but it would absolutely be a step in the right direction. At least I think I see issues, I have barely tried the bulk importer.

    I'm also not currently in the mood at all for tool dev, and as mentioned I don't know LUA (which aseprite uses) so that would involve a ton of reading, trial and error. I dunno about relatively easy...

  • You have to define the variable on the family. Individual instance still can have different values. I'd recommend this approach

    - Make family, add variable health

    - Put your instances in a "picker layout" and set them up as templates (this helps to avoid accidentally changing an enemies health value but forgetting to change it for all instances of that enemy) construct.net/en/make-games/manuals/construct-3/project-primitives/objects/templates

    - You can now place or spawn replicas everywhere you need them and they'll have the health value you specified in the template

    - Finally, I recommend using custom actions to handle the logic of damaging enemies. construct.net/en/make-games/manuals/construct-3/project-primitives/events/custom-actions

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I think aseprite files have quite some data that simply gets lost on export, but would be quite useful if retained (frame speed and timings, animation names, loop/pingpong settings) not to mention how awesome it would be if I could just import the aseprite files directly instead of exporting/importing.

    The specs would be here

    github.com/aseprite/aseprite/blob/main/docs/ase-file-specs.md

    The thing is... I kinda doubt that it will be implemented officially, simply because then everyone wants their program of choice to be directly importable (.psd files, .csp files,...) so I wonder if it's possible to somehow make it happen from a user side? I don't think the addon SDK can help here, so I'm at a loss. I'd also have no idea where to start with the documentation, that's beyond my skills.

    One alternate solution would be instead to create an aseprite export script that then exports based on these specifications construct.net/en/forum/construct-3/general-discussion-7/animations-editor-new-161331 along with a json file for the data. Issue is I have no idea about LUA or aseprite scripting so... yeah. Also it would not be as convenient as a direct import.

    In general I feel like the whole exporting/importing procedere throws quite some grit into the workflow... am I alone with this? Maybe I'll write up a suggestion for some stuff at some point, but since I'm mostly doing pixelart nowadays, this importer would be really helpful already.

    Tagged:

  • You do not have permission to view this post

    I think the product has a bit of an identity problem, being that it is heavily marketed toward absolute beginners - who are probably also the audience least likely to commit to a subscription model.

    I do somewhat agree on this. When I was a wee lad I was toying around with all kinds of engines and such. My first "game" was made with powerpoint lmao. I then also tinkered around with various pirated versions of rpg maker (XP my beloved, 2000 was also neat tho) and game maker. Why pirated? Well, free was always too limiting for me (and my brother gave them to me). Why not buy? Because I had no credit card, and even tho I'm pretty sure my parents would have bought me these tools if I just asked... my child brain didn't conceive of it as a possibility for some reason. But back then we were talking about one-off payments, a subscription seems like a big hurdle for lil Toasty waddling to his parents asking for money to buy something online (I also got scammed once when I was like 8-9yo so that didn't help my case haha).

    Maybe that was just a me problem, maybe kids/parents nowadays don't think twice about that. Or maybe there's just an untapped market of children that want to tinker around with gamedev but are scared off of Construct due to the subscription, while at the same time it might be the perfect entry-level engine for them. Afterall it is marketed towards beginners, and beginners are quite often children. Maybe even younger than I was back then, since internet wasn't even remotely as accessible as it is today. God I'm old.

  • Yes I should emphasize it is extremely unlikely that it hangs, like 1000 lottery wins in a row unlikely. But if the object gets created in the wrong spot a trillion times in a row, the game will hang. Limiting the number of attempts can in turn lead to an object not spawning if after 1000 attempts it never got the right spot (which you could add a failsafe for if it runs out, just spawn on a predefined spot)

    It's just that my brain complains that this seems like such an "incorrect" way to do it.

  • There is another method if your object is different from a square.

    You can spawn an object like this and check if it overlaps the spawn field, if so, leave it, if not, delete it and try to spawn it again. It is convenient to do it through a function. For example, you can create pimples on the face where the form of of collision is complicated.

    I've also done that before. Funny enough though, it's theoretically speaking a terrible solution, because it can happen that the object just never spawns in a good spot and your program hangs. Practically though it's just never going to happen... but it can happen. I always assumed there must be a solution for this "spawn on object" that doesn't involve this kind of trial and error approach, but I also never bothered to really look into it.

  • You do not have permission to view this post