Ashley's Forum Posts

  • I just tried opening the 9-patch example and adjusting the 9-patch's Z elevation - it seems to work fine.

  • This video covers how the new functions work, including how parameters are handled now. In short they're treated the same as local variables - so you can compare them using system conditions and retrieve them by typing their name in an expression.

    Subscribe to Construct videos now
  • How does it check which one we passed as a Parameter

    Internally this would be done with a map lookup, which is very fast (and faster than a sequence of if-else-ifs).

  • I think the main benefit of events are they can use a dynamic string for expressions when creating a function map. Given the whole point of the feature is to allow for a more dynamic use of function calls this seems to make sense. Also new actions are relatively easy to add, but new event blocks are a lot of work to integrate in to all sorts of parts of the editor (everything from internal logic, UI, drag and drop, copy/paste, saving/loading to projects, find all references, find by text, etc...). It would be a shame if we did a lot of work to make a new block for this, then the first request after that was for the ability to use dynamic strings - in which case it may as well have been events from the start.

  • gberenst - your events are indeed wrong. You try to load all the pictures in to the same Binary Data object at once so they will all overwrite each other. Try loading them one at a time.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • sajmons - I've added Slovenian to POEditor.

  • If it's on a similar scope to Instant Games, I don't know if we can justify the time spent on this. Instant Games took a couple of months of dev time, requires constant maintenance, had a bunch of awkward platform-specific bugs, and is still does not cover the entire API surface available (e.g. Instant Games' own IAP system). We're a small team that this really sucks away time from other projects and will noticably slow down development of other features - and then there's always yet another platform after that people want us to support... and as much as we'd like to be a hit in the Chinese market, there's not much evidence that we have a lot of users there yet.

    Anyway I think it's a moot point because I found this:

    The running environment of the Mini Game is a JavaScript VM with some methods bound to it. Unlike the browser, this running environment does not have a BOM and DOM API, only the wx API.

    Uh oh. It's not a real browser engine. This will likely be a development disaster. From long experience working with all sorts of non-browser engines (Ejecta, Canvas+, directCanvas...) they are missing tons of features, not standards compliant, require all sorts of special cases and second paths throughout the engine obfuscating the codebase, and a minefield of nightmare bugs that don't reproduce anywhere else, and bug reports are usually met with a shrug by the developers who don't understand the significance of well-tested, standards-compliant software (and then users blame us for it not working). The situation was so bad that we deprecated all non-browser wrappers a whole 4 years ago.

    This is a huge shame since they could have just used a real browser engine, like Instant Games does, and it would immediately be about 4 times easier to implement. Modern browser engines work great - but I guess maybe the Chinese market has a lot of devices with older software (which will be another development problem in itself - hello mysterious GPU driver bugs on old devices not available in western markets...)

    You can go ahead and file a suggestion for this on our suggestion platform as usual, but I'm afraid to say, so long as it doesn't use a real browser engine, I think it's very unlikely we will work on this. Non-browser wrappers were deprecated a long time ago for very good reasons.

  • like a switch statement though, would it have a default case? just in case for whatever reason the string is not mapped, or in that case would it just not call the function, and we get a warning in console?

    That's a good question actually. I think it would be useful to have a default-case function call in case nothing else matches, e.g.:

    + On start of layout

    -> Create function map "color"

    -> Map "color" string "Red" to RedFunction

    -> Map "color" string "Green" to GreenFunction

    -> Map "color" string "Blue" to BlueFunction

    -> Map "color" default to OtherColorFunction

    Then if you call a function by the string "Yellow", which isn't otherwise in the map, it would call OtherColorFunction. In this case it makes sense to pass all the parameters to OtherColorFunction since you'd probably want to look at the colorType string and do something different depending on that. So I guess if the default case is used, it should forward all parameters, ignoring any index provided.

    That sounds like it would cover everything - and actually be quite a flexible and handy feature, especially since this way the default-case handling is more elegant than calling functions by a string (which would just do nothing if the function name doesn't exist).

  • Doing anything by a string of the function name fundamentally removes the ability for Construct to do things like update all references to the function when you rename it, or show accurate results for "Find all references", etc. It would force you to go back to having to review the project when you make certain changes, which is slow, error-prone and laborious, and exactly what the new functions feature is designed to avoid.

    I think it should be possible to support this without using expressions for function names, though. The equivalent in a programming language would be a map or a switch-case of a string to a function call. Construct doesn't yet have any equivalent, but we could add one. It could work something like this. Suppose you have "Call function <string>" which can call one of "Red", "Green" or "Blue". That could be replicated with a "function map" feature along the lines of this:

    + On start of layout

    -> Create function map "color"

    -> Map "color" string "Red" to RedFunction

    -> Map "color" string "Green" to GreenFunction

    -> Map "color" string "Blue" to BlueFunction

    Note that RedFunction, GreenFunction and BlueFunction refer to built-in functions, and aren't strings (this would be some kind of new function-picker parameter). Then instead of "Call function <string>", you could use:

    -> Call function from "color" map with <string>

    This would then look up the string in the color map and call the corresponding function. E.g. call fucntion from "color" map with "Red" will call RedFunction. This should be the best of both worlds: you can dispatch function calls by a string, and it separates the concept of the string lookup from the function name. So if you rename one of the built-in functions all the references update and nothing is broken, and "Find all references" can still give you exact results.

    This doesn't cover passing parameters though. One way of solving that would be to forward the parameters of another function call. So you could add a function like:

    * On function ColorCall

    * Parameter colorType

    * Parameter someNumber

    -> Call function from "color" map with string colorType and forward parameters from index 1

    This would skip the first parameter (colorType) and just forward someNumber. So RedFunction, BlueFunction and GreenFunction all get called with one parameter (someNumber). Then in your events you can do:

    -> Call function ColorCall (colorType: <string>, someNumber: <number>)

    This then calls RedFunction(someNumber), GreenFunction(someNumber) or BlueFunction(someNumber) depending on the string 'colorType'. So you essentially get the same thing as calling a function by an expression, but you never used an expression for a function name.

    Does that sound like it would cover this case?

  • I still don't even know the name of the service you're asking us to integrate. Do you even know? Those links mostly refer to Chinese content again.

  • This will mean suddenly nobody can open projects they saved in the newer version, which I think is likely to be even worse.

  • I'm still not clear what you're after. Do you want a plugin that integrates with messaging? Is there a service similar to Instant Games that you want to publish to? Is it "mobile apps" or "mini programs"? It looks like a huge platform and I have no idea where to start.

  • What are you doing in those events? Sometimes you can eliminate the redundancy by using what you're passing as Enemy_type in an expression. For example you could look up a dictionary key, create an object by name, etc...

    I'd rather not add this feature if at all possible, since it negates literally all the benefits of the new functions feature.

  • Use the Addon SDK.

  • Is there any English documentation available? It's hard to even work out if it's possible without that.