Posts by Snail

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.

    How about you download my framework and give it a try? I promise you'll learn something from it and you'll get at least something out of it--dogma can only go so far. My recommendation now is for both of you to look at it as it'll give you at least an introductory understanding of objects and inheritance, etc. That will carry over to just about every object-oriented programming language, including what Clickteam 3 is going to be. Please login to see this link. the password is Godot

    As an aside, I believe I know best regarding where my framework can and can't be used.

    Absolutely. I was initially thinking Lukiestar wanted to do something along the lines of a real-time strategy game with fog of war for the AI. Definitely not the case, however! Still, if someone has a use for this, there it is. :) I'm sure there's a way to optimize it to get it closer to the performance of your example but this was the first method that I thought of.

    Lukiestar, which part are you having trouble with? I'm sure we can still help you out with it if you're stuck on any part of it.

    Quote

    Wow, really interesting work Snail.
    I studied it for a while but I don't get what the non-player items can see,
    green square gets its non-seen squares alphaed when hovered,
    is this mechanic also replicated in some way for other square classes?

    This request by Lukiester has a backward history I was aware of:
    Please login to see this link.
    so I guessed the simpler task he was in need of

    I didn't realize he was looking only for enemies seeing the players; I thought he meant objects seeing each other. I know yours is faster when it's all enemies to each player, but I don't know if it'll scale up as well to enemies seeing each other. What mine does is it identifies all objects that each kind sees and hides the ones that they don't see. The green box (the only Neutral one) isn't the player, per se; it's simply another class. Hovering over it will show you what it sees. If you added two of them, hovering over them would show you everything they see shared between them. Hovering over the other classes will do the same.

    I was surprised how much of a performance hit it takes, however, to do it with this method using the lists. Yours is definitely faster.

    You shouldn't use Line of Sight 4; it's only here so you can see what's going on internally. I optimized Line of Sight 6 for general-purpose uses but you should be very wary of running a line-of-sight function anytime a sensor's involved. This should work well up till you get to about 100 objects--after that, you'll want to consider what it is you want to achieve because I'm fairly sure what you're asking for isn't what you want. :) A level created in an array, for example, would completely remove the need for the sensor object and it'd drastically improve performance.

    Each class gets its own list of all objects it can see, including itself and its friends. These lists are created dynamically in Line of Sight 6 and you can customize what it sees and what it ignores, though any conditional rules will reduce performance.

    I was looking at Schrodinger's example and that one's definitely going to help you! Mine's specifically in response to your first question: "how to make it that instead of making them just see player 1 they see all actives in another group. So the group enemy makes a line of sight for every thing in another group?" If you need to track sets of objects within sets of other objects, this will do that. If all you want is to have line of sight for player characters, Schrodinger's will work great for that.

    Fusion is completely object-oriented, so you just need to use a for each loop. If someone can put together an example for you today, that'll be really great. :) If not, I'll try to remember to do it tomorrow, and remind me please if I forget to do that.

    There had been a line of sight extension but I don't know if it's still around.

    Hey guys,

    I think at this point, any potential changes to this policy will have to come from Clickteam. As they are aware of this post and these ideas, I don't think continuing this thread will serve much of a purpose; rather, it will distract them from focus elsewhere, which is counterproductive.

    Thanks for all of your input and for you understanding!

    It isn't crazy at all. :) If you don't include a decimal point ever in the variable (in this case, xPos), the variable will remain an integer unless it encounters an expression that converts it to a decimal point. That is, if xPos is equal to 25 and you use this expression in Fusion:

    xPos / 2

    xPos will become 12, not 12.5. If you need to do any division or multiplication with a variable, it's always a good idea to convert it with a decimal point. Since addition and subtraction are the fastest operations you can perform, it's better to add 0.0 to the value than it is to multiply or divide it by 1.0.

    You're exactly right with your analysis of what it's doing and you're right to see where the slowdown's going to be when you use the distance variable here. Hopefully someone has a more efficient way of performing that test but it was the easiest one I could think of that doesn't use a loop. When you have 100 missiles, each frame Fusion has to recalculate the distances for all of them. Thinking more about this, using small hitboxes would be much better than calculating the distance as long as the hitbox is no smaller than the speed of the missile. You'd do Missile collides with Target: Start loop for each Target/Missile the same way it's set up now, but Fusion would only ever run that event when a missile hits its target.

    You don't even need to worry about posting it in that thread. :) Mostly just as an exercise so you can try new ways of doing things and see what works and what doesn't. Without knowing more about what you're doing here, there isn't too much specific help we can offer you. From what I've gathered, you're trying to store and access large numbers of strings in your objects and it's slowing down Fusion, but there are lots of ways to speed that up and it really does depend what the strings are for.

    Do you have an example .mfa that you can upload so we can see more what's going on?

    Yeah, you're going to be stuck running the same number of loops whether they're "fast" loops or for loops. A for loop just identifies each instance as it loops through them so you can write data specifically related to them. There's definitely no way around running a loop like that to write the data, but for reading it, you should never have to run a for loop.

    You can mimic the behavior of for loops using "fast" loops if you wanted to do that, but for loops make your life much easier and there's no downside to using them.

    You can store that externally in any format you like, but to do it efficiently, you'll need a way to identify the corresponding data for each object. The INI and INI++ objects should be able to help there. Internal List if you want to structure the data yourself. Array, however, is going to be the least efficient because you'll have to loop through it since you won't know ahead of time where the data is stored for any given object.

    Using an .ini file:

    -Start of frame
    +Run loop "Restore objects" 100 times

    -On loop "Restore objects"
    +Create Active object
    +Set id("Character") to loopIndex("Restore objects") + 1

    Start of frame
    -id("Character") < 10
    +Set Health("Character") to GroupItemString$( "Ini", "Monster" + str$(id("Character")), "Health")

    -Start of frame
    -id("Character") == Range(id("Character"), 10, 20)
    +Set Health("Character") to GroupItemString$( "Ini", "Constructor" + str$(id("Character")), "Health")

    With the Array object, you have no way to know which cell the Characters should read from, which is why you'd need to run the loop to do that. Here, you're taking advantage of Fusion's object scoping to pull all relevant data without performing a single loop.

    Yeah, because you can't create multiple array, it's fairly difficult to work with for instances of objects unless you want to constantly loop through all of your objects. Technically you can work backwards to create instances of it but that would look really weird: Basically, to do that, you'd create an Array object for each Active object and then set a variable in each Active object to the fixed value of the created Array object. After that, any time you need to store object-specific data, you'd run a loop for each of your Array objects and each of your Active objects. If the fixed ID of the Array object matches the stored ID in the Active object, you'd write your data to the Array object.

    Why you'd want to ever do that with Fusion is something I don't know, but it's possible if you ever do want to assign an Array object to an Active object. What's more, I can't see how that'd improve performance in the least since you're still looping through your objects.

    Anyway. Because Fusion's Array doesn't have any abilities that the normal Active is missing, the better method to do this is to create instances of your Active objects in a forward manner: Create your main Active objects followed by helper Active objects. When you create both of them, store the fixed ID of the helper Active object in the main Active object. When you have to share values or strings across them, you just run a loop for each of your main Active objects and then if the fixed value of the helper Active object equals the stored value, write your values or strings to the helper.

    -Start of frame
    +Create Character
    +Create Helper
    +Set helperID("Character") to fixed("Helper")

    -Upon pressing Enter
    +Start loop for each Helper

    -On loop for each Character
    -fixed("Helper") == helperID("Character")
    +Write values and strings from Character to Helper

    The 10 String variable limit per object is quite challenging to work around especially when you need to achieve the highest performance possible, but it's doable in most cases. In the above example, I'm assuming that all the Characters have strings that all the Helpers needs; otherwise, just write your strings to the Helpers and you'll never have to run the loop for each Character. :) If a collision occurs, for example, Fusion automatically scopes that to the colliding objects, so when you run your loop for each Character, Fusion will only run a loop for each of the colliding Characters, not all of the existing Characters. This is incredibly efficient (and almost always necessary regardless), so understanding how this works and what Fusion is doing internally will save you a ton of time and allow you to do some really amazing things quickly and easily. I can put together an example of you'd like to see that?

    The INI method is the slowest method you can implement for this. If you're experiencing performance issues, switching to an .ini file will not improve the situation at all unless you also change the method you're using for writing data. From fastest to slowest, the order's Global > Alterable > Array > INI. When practical, you should always transfer stored values to memory using static and local ("global" and "alterable") variables.

    For loops are expensive and you should avoid them when possible. This applies to everything; Fusion isn't an exception, it's just that its base speed is slower than a programming language's speed so the performance impact is more noticeable. Writing data, however, necessarily requires that you loop through your objects, so the challenging part is finding the most efficient ways of doing this.

    No. The unnecessary complexity is using hitboxes and collisions, both of which will reduce performance significantly more than a single loop will. :D Remember, if you have 100 missiles on the screen and only one reaches its target, the loop will run only one time. If five of those missiles reach their targets at the same time, the loop'll run 5 times.

    The reason Fusion's removing all of the target points is because you have "Destroy" still on #30. Deleting that action fixes the remaining issues you're having here.