WackyToaster's Forum Posts

  • Well if you build a nice eventsheet that contains all the players inputs/actions etc. you can just copy that eventsheet into a new project and have it work there too. Only thing is that the new project needs to have all objects used (e.g. the player sprite) already available and with the same name as the old project.

  • You can switch frames with "set frame"

    You can switch animations with "set animation"

    construct.net/en/make-games/manuals/construct-3/plugin-reference/sprite

    You can check if your player is overlapping with "is overlapping"

    construct.net/en/make-games/manuals/construct-3/plugin-reference/common-features/common-conditions

    You can invert conditions by rightclicking -> invert. So you can also check "is not overlapping"

    Put everything together :)

    I recommend switching animations rather than frames btw.

  • You can put dictionary.asJson into yet another dictionary. So you could have one dictionary "savegame" and one dictionary for each type of sprite like "circles", "squares",...

    On save you loop through all sprites and put them into the "circles" dictionary. Then you put "circles.asJson" into the "savegame" dictionary under the "circles" key.

    When you load, you first load the JSON into the "savegame" dictionary, then you take the "circles" key and load it into the "circles" dictionary via savegame.Get("circles")

    Finally you loop through all keys in the "circles" dictionary and create a sprite for each and load the saved data into them.

  • I'm assuming your square is a sprite?

    You can also save an entire Sprites data by accessing it with Sprite.asJson. So instead of taking individual variables, you can just save the entire Sprite. And of course load it too.

  • In the ghost shooter script, ObjectInstance.TestOverlap(SomeOtherObjectInstance); is used.

    here is no _privateVariable marker there, so I would assume its okay, but again.... it isn't "documented", so technically it isn't. I guesse? Idk?

    This is documented actually

    construct.net/en/make-games/manuals/construct-3/scripting/scripting-reference/object-interfaces/iworldinstance

    But iirc it isn't available in the SDK.

    None of these work. 

    this.testOverlap()
this._inst.testOverlap()
this._inst.GetWorldInfo().testOverlap()

    this.runtime is also not available, but rather it's available as this._runtime. However, this._runtime.testOverlap() doesn't work either.

    I haven't done anything SDK in a while, but maybe it's fine to use _vars because it is in the documentation? Maybe I just misremember something. Either way, I cannot find an easy way to test for overlap like it's done in the regular javascript.

    Hence the direct access to the collision engine which as far as I can tell, is undocumented. It's also bad because I think it actually skips most optimizations like collision cells, it's just a raw call of "Is instance X overlapping instance Y"

  • I remember using it in my flags behavior but it doesn't seem to be officially supported. (Accessing anything with _ is usually a no-no). I made a suggestion a while ago for it but you know... they take a while if they happen at all.

    construct.net/en/make-games/addons/949/flags/versions

    Here's the code: 

    CheckOverlap(flags) {
			const collisionEngine = this._runtime.GetCollisionEngine();
			const flagsInstances = this._behInst._behavior._myInstances._arr;
			let result = false;
			
			result = flagsInstances.some(i => {	
				const t = collisionEngine.TestOverlap(this.GetObjectInstance(), i);
				if(t) {
					if (i.GetBehaviorSdkInstanceFromCtor(C3.Behaviors.Wackytoaster_Flags)._HasFlags(flags)) {
						return true;
					}
				}
			});
			
			return result;
		}

    You'll need to adapt it for your use ofc. I guess the main point is simply 

    const collisionEngine = this._runtime.GetCollisionEngine();
collisionEngine.TestOverlap(instanceA, instanceB);

  • Just so you know, the plugin is 4 years old and by now Construct has official support for autotiling stuff.

    Note the set/erase tile with brush

    construct.net/en/make-games/manuals/construct-3/plugin-reference/tilemap

    You can setup your brushes in the tilemap window.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Unfortunately the save game feature is... let's say "special" because it works fine until it doesn't. But the best way to tackle this currently is local storage. It isn't as complicated as it may seem and you only need to learn it once and then you can use it forever :)

    Here's a basic setup to get you started

    wackytoaster.at/parachute/basicSavegameSetup.c3p

  • The atlas creation is probably a big hurdle because it can mean a sprite may randomly have one of its frames on a different atlas. And as mentioned the atlas will always look different between versions. I wonder if it would be possible (without too much hassle) to export the images/frames/animations without atlas, then create the atlas at runtime in the loading screen of the game from the exported images. It generally doesn't appear to take that long and once created it doesn't have to redo it anyway, unless changes have been made.

    You can load sprite images from a URL which might work better. That bypasses the whole spritesheeting system.

    If that, I'd like to see the QOL improvement of simply being able to load into a defined animation frame rather than the current animation frame.

  • Hello, is it possible to restore the lost file of the project project if there is an HTML5 Zip archive

    No

    I will have to do everything again.

    Yes

    Lessen learned: Backup your project. Put it in the cloud. Put it on a USB stick. Put it whereever. Just make sure it's on at least 3 different devices in 3 different locations.

  • In a sense you do have to worry about performance at least a little bit because there's always gonna be this one guy with his forgotten relic of a computer expecting to play the game. Which is fair enough considering we're talking about 2D games here. They should run on any toaster you throw them at.

    Regardless I do think the engine does perform really well in most cases. Things that do cause bad performance that I'm aware of are:

    - any kind of loops every tick especially if they manipulate instances.

    - The physics plugin

    - Shaders/effects also tend to be unusually(?) expensive, especially on mobile.

    Am I missing something?

    EDIT:

    I wanted to add. Construct being tightly tied to vsync can also cause performance issues, theoretically at least. Lets just assume my game performs 50.000 collision detections per second. That is... as long as it's a 60hz screen. Newer mobiles for example often have 120hz screens, now it's 100.000 collision detections per second. Or a fancy gaming monitor with 240hz... 200.000 collision detections per second. On top of that, don't forget that this also means that collision detections are inherently framerate dependent, just to add a little extra annoyance.

    I'd really like to see these type of calculations untied from the monitor framerate. At least as an optional feature. I'd like to be able to run the game logic at a fixed rate, then have the visuals on top interpolate accordingly. This will stop collision checks from ballooning out of control for no actual reason, and also would guarantee framerate independence for collision checks. And yes, this will slow down the game if the fps dip too low. That is a tradeoff I'm willing to take, considering this approach is good enough for a multi-billion dollar company youtu.be/dDxMv33QlFs

    There's a reason this is done this way. I've run into many many inconsistencies because of this. So many times have I made something that works nicely, then I remembered I have a high fps screen and swap to 60hz. Boom, everything's broken. No amount of deltatime is gonna save me here because how am I supposed to deltatime the rate of raycasts being performed if it's tied to vsync. So I could do something like "every 0.0167 seconds -> do raycast" to have it run at "60 fps". Does this work? Honestly I don't even know, probably not. What about the platform behavior? That is also tied to vsync, but I don't have the ability to execute that only "every 0.167" seconds. How can I tie this together without massive spaghetti? I probably can't.

    But I also don't expect this to change, because changing that is probably a massive task. What I do know is that the whole interpolate on top thing works because I sort of do exactly that in my current project. Technically speaking, it runs at ~13 fps. I get position updates to my sprites that I then simply tween to their new position. Visually it runs at a normal framerate, just everything in the background happens at 13 fps. And it will run at 13 fps in any case.

  • It's quite possible that some browser plugin is messing something up. You can try disabling them. Does it also happen with different browsers? In any case, I couldn't find any issues on my end when scrolling around in the tweening menu.

    You can try and file a bugreport with as much information as possible, but chances are this will lead nowhere and the issue is on your end somewhere. Some software, plugin, etc.

    github.com/Scirra/Construct-bugs

  • I did not expect timers to be this complex :V

  • I have a feeling that the main reason why timers are fake triggers is simply because of backwards compatibility. The timer behavior is ancient and changing it will probably cause a ton of older (but also current) projects to break. I wonder what the best course of action would be... deprecating it and make a new one with real triggers?

    Arguably, in any case the timer behavior should be the best performing option.

  • And by the way, when using lerp you need to use delta-time. Instead of 0.005 in the last parameter, it should be 0.3*dt. Otherwise the game will run differently on different frame rates.

    I'd go directly with the mathematically correct way of 

    lerp(a, b, 1 - f ^ dt)

    construct.net/en/blogs/ashleys-blog-2/using-lerp-delta-time-924