WackyToaster's Forum Posts

  • Iʻve been running some comparisons and I noticed many times the events are already so well optimized that rewriting it in JS seemed to do nothing to speed it up. I actually managed to slow it down using JS in some cases

    I had that exact same experience a few times. :)

  • Yeah I found working with data in C3 in terms of arrays and such is... meh. It works but handling it in javascript is so much better, easier and faster. So in that regard I'd just go for subclassing. construct.net/en/make-games/manuals/construct-3/scripting/guides/subclassing-instances

    I had no idea that plugin exists, seems pretty useful. I had that thought a while ago where I wanted to add a json object as a new type of instance variable, don't remember if I ever posted a suggestion for it or anything.

  • Not that I'm aware of. I've also never done it myself.

    You can probably try and take a look at the official one, though that will cost you 20 bucks. I guess there's a how to set up included.

    construct.net/en/game-assets/tools/multiplayer-signalling-server-2

  • I've tinkered with firebase before and it does work pretty well. Haven't used it in a good while though, but it does pretty much exactly what you're looking for and then some. It's not super complex to set it up either.

    I'd also argue having your own little server somewhere has it's flair, but you'll have to deal with authentication, security etc. yourself and that's not exactly easy.

    As for a solution somewhere between:

    1. Setup a wordpress page that handles all the rating etc.

    2. Hook up the game with the wordpress api developer.wordpress.org/rest-api/using-the-rest-api

    developer.wordpress.org/rest-api/using-the-rest-api/backbone-javascript-client

    3. This should now allow the user to create "posts" on your wordpress page under their username from inside the game

    4. Setup user privileges etc. so you can moderate everything and so that people don't post questionable stuff. (As in posts need to be admin approved before being visible to the public)

    I'm not 100% sure on the whole api thing if that works (I think it should?) BUT the point is that a wordpress page can also just be used outside of the game. So if the API approach fails, you can easily fall back to just having the website as the level hub. And wordpress has categories and tagging and filtering build in too.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Ah, so you can "store" that expression itself in the form of a function, that returns the resulting value. As for the sliders, I'd put them into a family and use custom actions.

    This setup will change the sliders frames at 97 for all sliders. But you can also then add overrides if a specific slider should change at 50 for example.

    I suggest reading into functions and custom actions:

    construct.net/en/make-games/manuals/construct-3/project-primitives/events/functions

    construct.net/en/make-games/manuals/construct-3/project-primitives/events/custom-actions

    Hope this helps!

  • It should be possible, but you'll still need to host a websocket server on the local network. Probably via node.js or python. You don't need a hotspot, just both devices on the same network.

  • In your case, if the value only is calculated when you change the fader, I'd go with a global variable to store it.

    So, On input -> set global variable to round(3.1 * (1 - exp(-0.035 * FaderValue)))

    This stores the result until you change the input again. So yes, you can set a variable to that equation, just keep in mind it stores the result, not the equation itself.

    As for applying it to several objects in your project, that depends on what exactly you want to do. You could use families and custom actions to handle whatever the objects need to do based on the value. Perhaps a function also does the trick in your case. Most likely either of those will be what you're looking for.

  • Truth of the matter is i burnt myself once by using a lot of Rex' old add-ons back in the day and ever since then i stay away from 3rd party things, even though there's great stuff being done.

    Yeah these addons were great while they lasted. The only reason why I'm not that reluctant to touch 3rd party plugins is the simple fact that in most cases I'm probably able to fix an issue myself if a plugin breaks, at least if it's a relatively simple fix. But I think it demonstrates Ashleys points quite well. 3rd party support can just vanish from one day to the other for any reason, then something breaks and you're kinda screwed. Recent examples: ProUI and LiquidFun, and those were even paid addons, not some random free addon from the exchange.

    But there's also the point that there's a lot of things people want that Ashley is reluctant to implement for one or the other reason. So what option is there other than a 3rd party addon?

    Prime example is UI stuff. Highly requested for years at this point. Best we got was the HTML plugin. Mind you, that plugin is great for all kinds of purposes and I use it quite some, but not for making a good UI in a game due to the nature of DOM elements being almost entirely detached from the games rendering and always draw on top no matter what (+ some extra annoyances) Yes, implementing it on a canvas level has a rats tail, but it's an important rat regardless.

    Just something like flexbox/scrollbox implementation for a start would already be a huge win, but alas.

    is this because the official plugins use undocumented features or is it because their code is not publicly available in a plugin-like package?

    The latter. You can access the code with the inspector if you know where to look and unminify it, but that's not exactly useful for anything other than looking at it.

  • I remember something similar tripping me up some time ago. In this case my guess is that "For each Sprite" is a loop and actually does iterate over all objects and also applies the actions in the event individually. The second one is a filter condition, which is faster and the action is applied to all sprites that end up being picked simultaneously and only once.

    Or in js 

    	objects.forEach(e => {//thing});

	VS

	objects.filter(variable => variable < 0)

    People commonly misunderstand this. For example, if your event would be "add 10 to score" both examples would seemingly work at first glance. However, the second one will not work if multiple sprites end up with variable < 0 at the same tick. It will only add 10 score even if 1000 sprites have variable < 0, whereas foreach will add 10 score for each of the 1000 sprites individually. I think the "most correct" solution is actually the filter condition & adding 10*object.pickedcount to the score.

  • Huh, I've tried it and that's actually what's happening. Kinda weird. I've noticed that it has something to do with the screen size/resolution. If my layout is 1920x1080 and I preview in fullscreen, the effect is not as pronounced (if it exists at all). But if I scale the window down further and further, the effect gets worse and worse.

    A 32x32 sprite at 1/8 resolution is effectively just 4 pixels high. And it needs to shrink 8 pixels in actuality, to reflect a single pixel of shrinking onto the scaled down sprite, which will visually result in distinct steps of shrinking.

    Looks like subpixels are not rendered correctly when scaled down? But I dunno, someone with more knowledge gotta weigh in on that.

  • Yeah that happens occasionally. I think Ctrl+ and Ctrl- should work. You can also just open Construct in the browser (editor.construct.net) and then you have access to the browser menu, including a way to reset the zoom level.

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • Hmm, maybe I'm understanding something wrong but wouldn't this work? (Pseudocode) 

    	if X tapped -> { doThing(X); return;}
	if Y tapped -> { doThing(Y); return;}
	if Z tapped -> { doThing(Z); return;}

	// nothing was tapped
	doThing(Bail);
	return;

    So, if everything that can be tapped resolves to false, you're left with "nothing was tapped". I guess you're sort of doing the inverse, and instead check "was nothing tapped" first, then handle all the tappable objects. But I think my version would spare you having to iterate over all objects that cannot be tapped and instead only iterate over the objects that can be tapped.