Posts by ProdigyX

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.

    After about ~ 6 weeks of the site being down, it is back up! The site has moved from a .US domain to a .INFO domain. Everything on the website should as functional as it was before. Additionally, every link on this thread, is working. Any of the PDF documents will be linking back to the old website domain, but they will get fixed / updated at some point in the future. Additionally any site which is linking to the .US domain will be broken until it is updated to the .INFO domain.

    For now I intend to complete some of the "coming soon" items scattered throughout the website. Afterwards, I think it time to doing more tutorials.

    If you have a particular request for tutorial or anything else, pm me and we can discuss further!

    Regards,

    I'm glad you found the paper to be useful. As schrodinger mentioned, most expressions are used in the following manner:

    <expression name>(<expression parameter 1>, <expression parameter 2>, ... , <expression parameter n -1>, <expression parameter n>).

    So to use the upper or lower functions, you would use lower$(<MyStringHere>) or upper$(<MyStringHere>). The document schrodinger linked should contain most of the actions, conditions, and expressions, for the default MMFusion objects.

    @10MBRA1, Yes. The differently colored events, which are green by default, do have a different processing time than black events. The green events are not processed every frame; they are processed only when their trigger happens. In the case of 'On Collision', it would be when a pair of objects initially collide. In the case of 'On Overlap' this would be checked every frame. This can be costly in terms of performance because the 'On Overlap' condition can consume a lot of computer processing resources relative to most other black events. They are ways to mitigate this performance decrease, but you typically will not notice the different unless you have a) a big / complex game, b) multiple huge objects colliding with each other and none have the bounding box collision option checked, or c) play your game on a device such as a handheld phone.

    So I was browsing the forums and the Clickteam Fusion Discord just now when it hit me that it might be useful to get an idea of the technical background/experience of the users. A lot of the time, I see users ask for general programming/game develop questions as opposed to Fusion specific questions. Getting to know the general user make-up should allow any future tutorial makers a good start on what to cover.

    Thus, vote for the poll option which best describes your technical experience when you were first introduced to Multimedia Fusion/Clickteam Fusion.

    As Nadapp mentions, you may only have decimal variables during runtime. Specifically, you are unable to have decimal numbers in variables during edittime. During runtime within the Event Editor, however, you can force a number to be a decimal by multiplying or adding part of the number by a decimal. In short, variables may only possess decimals if some event from the Event Editor forces them to.

    + Set Alterable Value to 1.5, for example would do the trick

    Follow this link and you can get another example of this. Please login to see this link.

    Glad to hear you got it working! Also glad to hear you say my tutorials are helpful! At one point, I was going rewrite all the PDF tutorials in Word instead of another software I was using, but other life things came up and I never got around to it. I still intend finish the last thing I was working on and continue on with a breadth of introductory knowledge, but who knows when that would be haha.

    Ok. In this case of "Pick One of 'Hero'" it is always choosing the same object because you have already scoped the object under the ForEach loop. The condition tries to pick one object from the current list of scoped objects, but there is only one object since it is under a ForEach loop. So basically the Pick one of condition is not doing anything. If you were to use it outside of the ForEach loop, you would see random Hero being picked.

    To change the ordering of the object, use one of the actions within the order submenu of the within the object.

    Oh Clark, I think I know another reason why it is choosing the same one each time.

    As I mentioned, if you are using the method I suggested, then you are update some variable with the fixed variable (or other object ID) of the object with the highest HP within a certain range.

    If it seems like it is always picking the same object, it could be because the same object is being iterated last. By what it sounds like, it sounds like you have it such that the object ID is saved when the algorithm finds an object >= than the current saved highest HP. So if you have Object A and Object B which fit the criteria you have, Object B will be ultimately selected if Object A is iterated first (since Object B will overwrite the value of Object A after Object A is iterated) and vice versa. If this is the case, then you can resolve this by changing the order in which the objects are iterated. If you are using a ForEach loop, you can change this by changing the object's ordering during runtime. Backmost objects are iterated first while frontmost objects are iterated last (or maybe vice versa).

    Do this sound like what is happening?

    You should be able to use the "Pick one at random" conditions within the object. That being said, there should only ever be one candidate based on my understanding. After you have done all of the iteration, you should one object's fixed value stored. Even if multiple targets have the same HP, only one fixed value is saved after all of the iteration is completed. Then you scope to the object who has that given fixed value and it should target that object.

    Hypothetically, you would find all players within a certain distance and iterate through them. As you iterate through them, you would store the player's HP (and some object ID such as a fixed value) into some variable. This variable only gets overwritten when a higher player HP is found. After you have iterated through them all, you have found the player with the highest HP within a certain distance

    Is the hotspot centered for every frame in every animation for each of your physics objects excluding those with the Physics - Platform Movement?

    It could be that you have the hotspot centered for one direction in the ball object but not the other directions or the hotspot is not centered in those floor objects.