> I could not find any but still the project does not open in R397.

Press F12 and check error messages in console log.

Oh thanks for this! I didn't think of that right away and have a large project - was browsing through thinking I'd never find them.

If the new version of Construct isn't going to allow these filenames, I wonder if a hotfix can be applied to the previous version to trim these spaces on filenames.

Thanks for those suggestions. After playing around with this a bit more I think what I setup works for now. If I need to update this later I'll keep what you two posted in mind.

I felt like making a minute long dev vlog video about this:

I don't remember when the "Allows Sliding" property was added to the 8-direction behavior, but I thought it was exactly what I was looking for in my project. The player could get snagged on some solids in spots and I thought it could help gracefully slide around objects at times.

It did help, but I noticed it caused a lot of shaking at times. When I held on the movement controls to keep the player moving into a solid either several objects would shake or the entire screen would shake, maybe due to scrollTo behavior on the player is shaking the viewport/camera.

I'm not wanting to file a bug report (or complain) as I seem to have found one solution: Turn on pixel rounding in the project. I'm not wanting to do this in my project as it seems to make the camera movement choppy at times.

Another solution to the shaking objects it to make sure objects are at integer pixel values themselves. I tested that and it stopped objects from shaking. This didn't stop the entire screen from shaking at times though, as I assume that is caused by the player being at a non-pixel value.

Instead of trying to troubleshoot this and add a bunch of changes (in my large project) to prevent this, I thought it might be better to re-create this functionality. I always view pre-built functionality, such as behaviors, as quicker to use but less flexibility, whereas custom solutions can take longer (sometimes much longer) to create but can be fully customized.

In this case I mainly just want players to not get stuck going through doorways as easy. At least that was the only real spot I was getting caught on. I don't have that many diagonal (non-rectangle) solids in my project so I don't need much sliding. So I don't even need to re-create the entire functionality; I just need something very specific.

Trying to think how the sliding functionality works under the hood, I figured if moving down and running into a solid, it might simply check if the object can continue to move down if moved slightly to the left or right. I thought that might be why the screen shakes - as the sliding mechanic keeps moving the objects back and forth to check for slidability.

I created a sprite that if overlapping with the player while moving the event would set the player's X value over one pixel. A bit to my surprise, it worked and looked as smooth as can be! I added some variables to the object to control direction and amount and came up with this event:

Now I'm not sure this will be my final solution. I just came up with it and I'm not excited about having to have four extra sprites in the project for each doorway. But it definitely is helping so I'm gonna roll with it for now, fine tune it as I go, but also be open to trying completely new solutions.

GIF: imgur.com/a/v0bCft1

So why am I posting this? One is just to share this in case anyone else is looking into this. But though I don't have a specific question I'm asking, I would love any additional info on any of the topics I've brought up or corrections on some of the assumptions I've made. So for example:

• Anyone else experience the shaking when allow sliding enabled? Any other solutions to resolve?
• How does allow sliding work under the hood? (I actually haven't looked if any of Construct's code/repos are public)
• Has anyone implemented their own custom sliding mechanic?

Intro

So I've always wished that there was an integer scale outer option for the fullscreen mode. I think I might have figured out a simple work-around.

The purpose is to keep integer scales to avoid warping pixel art but also filling the entire space, aka no black bars. If you aren't familiar, see the defining the issue section at the end.

But I think there are a lot of people that have been trying to solve this issue. Google searching it has come up with several forum posts on this topic and feature requests. From the forum responses, it doesn't seem people have had much success figuring out work arounds for this.

Experimenting with things, I think I just found an easy solution to this. I am still thinking it through and working out all the details, but wanted to post here to share and see if anyone can think of side-effects or issues this setup might cause. So feel free to call anything out or ask any questions. I'll be trying to work out the details and test this over the next week or two.

Workaround

So far, it seems pretty simple:

• Set viewport size to 1920x1080
• Set Fullscreen mode to Scale Inner
• Adjust zoom (layout scale; probably dynamically in events)

Essentially the viewport size is set to the largest possible size* so there is no scaling. Therefore, the integer scale is preserved. The scale inner setting will never have black bars.

If you do step 1 and 2 then preview your game, you will notice your game is probably zoomed out, depending what your viewport size was previously. So now all you need to do is zoom back in. I'm thinking this could be done in events based on actual viewport size, but I'll have to do some more testing.

When I test it out, my game seems to keep it's pixel perfectness at any integer zoom level. It might actually zoom out more cleanly as well, since scale of 1 in this setup is subjectively "zoomed out" for my game.

Defining the issue

Before I had a viewport size of 640x360 with Letterbox Integer Scale. The Letterbox Integer Scale kept pixel perfectness and if fullscreen the game would scale 3x (640 x 3 = 1920). But if it wasn't full screen, there would be black bars (unless window was exactly 640x360 or 1280x720). So I switched to Scale Outer.

Scale Outer would fill all the space so no black bars. But lets say the layout was 1920x1000, the game would scale up only 2.77777x (1000 / 360 = 2.7777..). This would fill the height and then show extra space horizontally. But of course the non-integer scale would distort pixel art.

Example of distorted pixel art:

It doesn't always "distort" in the same way:

Same art not distorted:

In the past I have seen the response to simply choose a resolution that scales evenly into 1920x1080. But now, ultra-wide and over-sized monitors* are becoming more popular and phones resolutions are all over the place. Meaning there is no way to pick one resolution that scales evenly into all devices.

As I mentioned Integer Scale Outer - it doesn't exist but has been requested. The proposed resolution, to use the example above, would take the 1920x1000 viewport and scale up 2x and then fill the extra space. The 2x comes from 1000 / 360 = 2.777 rounded down to the nearest integer. This would keep pixel perfect and fill all the space - no workarounds needed. But of course it is not a current option.

*Over-sized & Ultra-wide monitors: my workaround wouldn't solve for this, I don't believe. I don't have a larger monitor, so can't really test, but I'd think I could just make the viewport size even larger to accommodate these resolutions. I might end up doing that, but since I can only test myself at 1920x1080, for now, I'll test this out to see if any other issues or drawbacks.

Conclusion

Sorry for the length but wanted to explain all the details for anyone new to this topic. Especially if this is a good workaround, that way when someone is searching for an answer they can get all the details here.

Like I said, I just came up with this so it isn't a proven solution. Feel free to call out anything as I am looking for a long-term solution.

TL;DR

Look at the bullet points, as they are steps to fill the entire screen but keep pixel perfectness (integer scaling).

Great work! I felt the stress immediately! It's a lot of fun already and you could definitely take this idea a few directions. Some quick thoughts:

- I think overall your point about repetition being a fear will make designing this game really fun. The mechanics are great, and you could have a blast adding variety to this. Are there drunk patrons that you want to avoid serving? Are there animations or bonuses for serving a streak of five customers (he's on fire - nba jam)? Does someone get a promotion at work and buy a round for every customer at the bar?

- The overcooked "how many orders can you fulfill" was the first place I went for 'goal'. But you could add values to different drinks or patrons to spice that up (if a group shows up, they order three drinks at once, but you get more points if you pull it off).

- It forgot who did what. Eventually cashier = money = green made sense, so maybe each worker having a different colour shirt would help (if this a broader issue)

- Maybe more visual emphasis (e.g. bigger animations) on the actions besides progress bars would help the player keep track of what actions were happening, and when the action has ended.

- After I got the hang of it, I wanted the workers to switch tiles faster.

I hope you keep exploring it!

For some reason I'm not getting notified of responses anymore so I just now saw this - Thank you! These are all great thoughts and points.

Right now I've gotten back to the project I was working on before the jam, but I do hope to do more with Busy Bar once I figure out a plan that sounds good.

Very cool!

Thanks for writing out the logic of how you would achieve that elsewhere. My brain is a bit foggy today and I'm not in a good spot to write out all of the logic, but let me tell you how I would get started.

This is a non-scripting approach, as I agree, the scripting side of Construct removes a lot of the advantages of Construct.

Create a Family. I'll call it inventoryFamily for now.

Think of the Family as the equivalent of a class. Of course a lot of differences though. Adding sprites to this family will add all the behaviors, effects, and instance variables to the sprite.

To start, will add a string instance variable to the inventoryFamily. I'd just call it inventory.

Create a function for addToInventory. One param will be uid, which first condition will be to select inventoryFamily by UID.

Now you are sure you have the instance you want. Another param can be the inventory item to add, whether it is a word or a reference number. Adding would set inventory = inventory & "," & param (if inventory has value). You can also use scripting in an event, if you want to make use of like .split(',') .push and .join(',').

If another action needs to be taken I'd make another function for that. Sometimes I'll make a function for each different action and other times I'll make one function and pass a param for the different actions. Of course the latter turns into a long event of elses, but if it is only a few actions for each sometimes I'd prefer that to keep them organized and not pollute the function namespace.

This also isn't my favorite, but I'd probably do call function by name. That way, the name of the follow-up action (removeMoney, modifyHealth) could be stored wherever you need it (with the item type; if action from the carrier, would create an instanceVariable on the inventoryFamily of pickupItemAction; or pass the param into the function).

It would be great to be able to attach a function to an object such as a method, but the functions that first grab the instance by UID achieve the same thing.

custom actions canʻt return a value

Does creating a function with a return value not take care of this?

As for some of the other limitations you mentioned - let me remind you my brain is foggy and also mention you prob know more than I do, so this isn't disputing what you say - but I'm not sure about some of the direct downsides or limitations. For example, in general you don't want to pollute the global space, but what advantage is it if all Construct objects were NOT in the global space?

I kind of suggested using scripting because it sounded like you wanted to adhere to common programming practices. I almost always use events, unless I want to hit an API or its code I want to use elsewhere.

I think the thing I like the most about using Construct (non-scripting) is the syntax check. It will prevent you on the spot from using a variable that isn't declared or missing a comma or period somewhere. It's not really even a pain point in my normal dev/day job, but its just nice that when you build your project to preview your game, you don't have everything breaking because of a typo.

I know that didn't address everything, but maybe it's all I got, ha!

Cool idea. I like it.

With the examples in the original post, I think it would make more sense to provide your solution in other engines/languages and the problem you forsee implementing in Construct since your claim is that Construct causes difficulties.

I do agree that sometimes I find myself wishing I could quickly use a .map() to achieve something - and yes, you can use JavaScript in Construct. As others have said, it is preference.

But with events, I don't see why you couldn't achieve either of those with mostly instance variables and functions.

Picking in events is essentially filtering, which can be done on instance variables. Functions can have return values - if you want to break out complex logic into re-usable bits. tokenAt and tokenCount can be used if you want an instance variable as an array. If you need an array of objects, you can use tokenAt and uids. If you want an array of custom objects, as opposed to instances, I prob would recommend JavaScript.

My point is that these are the same tools you would use to achieve your functionality in any programming language. It does seem a bit awkward at times, but that is because Construct was originally built as a no-code engine. So there are some trade-offs there - think target audience. However, I'm a programmer and still enjoy using Construct. I'm not actually sure why, but I do!

but with constructs current limitations . . . to avoid c3 limitations in functions and custom actions.

What are the limitations? Can you elaborate?

Also, I'm not sure who said it, but I don't think it is fair to say a lot of loops or for eachs would kill performance. Of course a certain amount of loops will kill performance - anywhere, any engine, platform - but I've seen people act like adding a couple of "for loops" into their project is the end of the world. I'm just saying, test it to see if it actually does, especially if you are making a video comparing engines, ha.