nimos100's Forum Posts

  • The "temporary sprite list" is pretty much exactly how it works already, and it moves those instances to the main list at the end of the top-level event. However if every condition also checked the temporary list as well as the existing list, that would add a performance impact to every event again, since now every condition has to check two lists instead of one.

    I see.

    However im a bit confused why it would hurt performance. Because wont it be the same in the end anyway? For example we create 100 objects which are transferred to the main list at the end of the top level, and this is what confuse me. Because during the next tick, all 100 objects will be on the main list so whatever condition that would check these objects would apply to all 100 objects. So the performance impact happens from the period of creation to the end of top level, when working with the temporary list?

    Since im not 100% sure to be honest what these lists are, but assumes you mean they are stored in memory? it might be what confuses me a little. Because if we assume that in our game we have at max 1000 objects at a given time and for the sake of argument the temporary list is checked as well. So we have two scenarios, this is just so I understand what you mean:

    A: There are 800 objects on the main list and 200 on the temporary list

    B: There are 150 objects on the main list and 600 on the temporary list

    So if I understand you correct, the performance impact would be higher in scenario B than A, if the temporary list was checked as well?

    And to further extend this and we remove the check of the temporary list, using the same scenarios.

    Then during the "tick" of creation until the end of top level, you would have better performance in both scenarios due to not checking the temporary list, but the next tick. You have 1000 objects in scenario A and 750 in B. Hope you see what I mean when I ask if its not the same in the end? or did I misunderstand you?

  • Rotate objects

    The general idea is to extend the rotation of objects. As it is now they rotate around there origin. So adding two new options could be very useful, I think.

    Rotate around imagepoint - Instead of rotating around origin, you can choose whatever imagepoint on the object you like and it will rotate around that point. (Could maybe just replace the normal one, as it does exactly the same. And the origin could just be set by default.)

    Rotate around position - Same as above except you can specify a X,Y position and the rotation will happen around this point.

  • Instead of doing it like this, can't you just make a function that you call every time you change it in the code. For instant if you need something to happen depending on its value:

    Set Global_var = 1
Function.call("Global var changed")

Function "Global Var Changed"
---> If Global_var = 1 <Do something>
---> If Global_var = 2 <Do something>
[/code:13lb70fe]

Then you don't have to constantly check it, because you know you only call the function if a change takes place.

  • Hi,

    I want a group at the start of the frame to load a new image into the tilemap objects, but not from a URL, from a file... specifically I intend for the game to be exported via Node Webkit to Windows, Mac and Linux.

    Can someone please set me straight on what I would put in the "load image from URL" action to get it to load an image from the install folder of the game for example?

    Thanks very much.

    -Mike

    You can use the NW.JS to do that. Like so:

    NWjs.AppFolder & "Filename.ext"
[/code:3rkm6ej3]

However be advise that this wont work during development, so a good idea is to hook up a System -> is in preview so you can test it just using a fixed path.

Since you want to load it during runtime, I guess your intention is to load several different ones? However im pretty sure you will run into problems with this. Due to how graphic is handle in C2, at least images have this problem which requires some workarounds that are not really good. Anyway if that is not your intention you should have no problem doing it that way.

  • + For each Sprite

    -> Create "Sprite"

    "For each Sprite" will iterate every Sprite instance, but the event itself modifies the set of Sprite instances. It's difficult to handle this case correctly without introducing a global performance impact to the event system, because every condition has to constantly check if the set of instances it is iterating has changed. (It's also interesting to think about how this event would turn in to an infinite loop if it also iterated the instances it just created!)

    BTW the stated goal of C3 is to rebuild the editor and keep the same runtime, so this is not really the kind of thing we intend to change anyway in the scope of that project.

    It had of course crossed my mind since you have already stated in the C3 presentation that C2 projects are compatible with C3 that this of course could cause some problems if something like this were redesigned.

    But as I suggested with the temporary objects/data, couldn't that be a viable solution, for in the example that you made with the For each Sprite, Assume you have 5 Sprites (Existing instances), So for each of these, a temporary object is created. So even though there now are 10 objects in total, only 5 of them are on the "Existing instances" list and 5 is on a "temporary instance list". So at the point the for each runs it will only include the 5 "existing instances" as the temporary ones are not currently sharing this scope. So imagine you apply yet another For each Sprite after the last one, it actually knows at this point that 10 exists as it include or checks any former created temporary lists, so it will create a new temporary instance list which will hold the new temporary instances, in this case 10. So to put it visually, it would look something like this:

    5 (Existing sprites list)

    5 (Temporary sprites list 1)

    10 (Temporary sprites list 2)

    So still you could update these objects as if they were all part of the same instance list, but would make some of the changes to the "Existing sprite list, some to temporary list 1 and 2. When the process at some point hit the top level all instances are then moved to the normal "Existing list". But whether that would ruin the C2 projects or even work im not sure of, at least not if some sort of fail save weren't added. Maybe it could know that if its an original C2 project it could simply not make use of temporary lists, or it could ask the user if they wanted to update there project to a C3 one, and what problems might occur. So users are left with both options.

    Would something like that be possible, assuming that this was on the agenda for C3, which you of course have already mentioned that its not?

    Because if you look at the example I made earlier in this thread, and assumes that for some reason this was an important game mechanic. How would you go about solving it, with the way that it currently works, because I don't find it an unrealistic scenario?

    Anyway cheers for sharing your thoughts on this matter.

  • I'm guessing you're referring to when you can pick new objects.

    New object's do exist instantly, but here's info on what's happens with regard to picking new objects:

    It's basically do to how the object filtering works in the event system. The question is how to implement it better.

    Maybe having the ability to make lists of objects. It would be a bit tricky when dealing with destroyed objects though.

    I'd like to think the whole event system could be overhauled to be simpler and more powerful. I've been trying to come up with a design that addresses things like picking two separate instances and this toplevel thing in a simple way. Imo a good design is key before I make argument how I think things could be better. Maybe eventually I'll find that holy grail of perfect simple design.

    Yeah think you make a good point and recall that thread you are linking too as well. How to solve it is of course the whole issue, also why I was curious to whether it was on the table when designing C3.

    One way I thought it might be possible or at least worth a consideration, could be something in the lines of creating "temporary" objects/data. Meaning that when a create takes place, all the information is stored temporary until the actually creation takes place, said in another way. Because you of course is correct that the object is created. But in lack of better terms I just refer to it as "not being created". But what I mean is that during the period until a top level is reached, maybe the information could be stored and all interactions etc. would then be done on this temporary data/object and copied to the actually object when its ready. If that makes sense? But whether something like that is possible, a good solution or even worth it, I don't know.

    But that way you would be able to just destroy the temporary data, instead of the actual object, or said in another way never create it. Anyway just some thoughts about it. Hopefully Ashley have already figured something out, if its of course being considered

  • i was using containers as an explanation for how simultaneous objects should be created in general, not for your example. trust me, containers are GREAT, and they lower the amount of coding. also, when it comes to your example, i don't see the problem. random 1-3, have a var which defines what is 1,2,3, spawn depending on the number. also i was talking about design in general.

    that's not true. during my time of development with c# / c++ i've noticed a lot of things that don't work as expected and need workaround because computers calculate them differently. the same is with this wait thing. you either accept it, or leave it. you will see much more trouble with unity / ue4 / any engine. but it all depends how masochistic you are

    to work your ass off on something. and in the end it all comes down to learning how computers work, how interpreters work, how compilers work, to just fix that ONE bug.

    of course it's not impossible that something relies on something else. but you used "on created" that was connected to another "on created" that was calling a function that does something. you can't do that in 1 tick since you've got a chaining of events. that's why wait (0) stops the chain before calling function for 1 sec so that the objects are completed and then continues from there to get the right values and print them out.

    i'm pretty sure you don't know what happens, and how c2 engine works.

    Sorry Saiyadjin, but you speak to me like you assume that I have no clue how C2 works, which of course is fair enough if that's how you see it. But I did make you aware of this issue in the first place, which is known by Scirra, that it is designed that way. Why I asked about it in the first place. I fully respect if you do not see a problem with this, but that doesn't make it go away. And I made a simple example of how and when it happens, not because I was trying to show good design, but to explain the problem to those people, including yourself that related this issue to being maybe about the UI. If you have never used a wait() in your code to solve varies issues even though you knew it was bad, then I fully understand why you haven't noticed this.

    Besides that im not comparing to other software solutions and whether they have problems or not, because its of no concern to me. But if you have experience with C++/C# you know just as well as me, that you would never solve problems with creating objects by throwing in waits(). So why you would even compare those with C2, im not sure of.

    Besides that you have moved from my initial question, which I have no clue why you would even argue against in the first place, that if objects could be created so they exist instantly, that it wouldn't be better than having to wait? to how I made the example, which shows the problem and then explain to me, what happens in it? Since I made the example, im well aware of what it does, again it weren't made to show good design, but to show where the problem occurs and in what situations. And if you can solve it some other way under the same conditions that I put up, then I would be glad to see it and learn from it. But still why defend how it works now, if it can be changed in C3 so this wouldn't even be an issue, since this is a part of the core of how C2 works, it would make sense to change it for C3 if possible, which is why I asked the question and not to be shown 10 examples of how to use waits for varies things, that have nothing to do with what this is about.

  • i see what you're tryin' to do.

    you want to use the object you created at the same moment as it was created (in the same tick).

    so basically what you do is use wait ( 0 ) to go to next tick and continue where the it left off (at that function).

    by default that is the expected behaviour - suggesting that your desing is bad. and probably top level won't be removed any time soon, but if you design your game good it's not even needed. also if you're aiming for the instant spawning of more elements that need to be "stuck together" and you want to do that in one tick - use containers. that's what they're used for. also "on created" is used for defining start state of an created object. but only after one tick is done your object gets UID, therefore you never had any output without wait(0).

    also, if you aim 60+ fps, have in mind that 1 tick is 0.016s (1/60)s which is really fast, and if you pick your objects in next ticks that won't look / work wierd. i know it takes some time to design the game correctly, but it works good.

    also what newt told you - do an action and if you want to set up some basic object items do it on created, otherwise use wait for some behaviours/events in your game that need to happen after some time /at some defined moment. instantly picking item that you created won't do much since that tick you're in has to PASS for object to really appear there.

    Think you are missing the point. Using containers for something like this is not very good I think. In my example I said imagine that you have several options and you have to choose one at random, lets say you have 10 options. Then when you spawn your object you spawn 10 other objects as well that is part of the container, to only use one of them, how is that a good design?

    And you are correct that the problem you run into is that it will be a bad design.

    "if you aim 60+ fps, have in mind that 1 tick is 0.016s (1/60)s which is really fast, and if you pick your objects in next ticks that won't look / work wierd. i know it takes some time to design the game correctly, but it works good."

    I don't think this is a valid reason. Computers doesn't work as we do, where you can say that if we don't see it, then the computer wont either. It notice every tick, and if something in your code does something in that 1 tick it gives you problem whether you see it or not.

    Newt just gave an example of how wait works, but I can come up with lots of example of how to use it where it works fine. But im not interested in that.

    So try this and you can use my example if you want, but when you make it and spawn the Red square, make it so, depending on a random roll of 3, which we assume is some important setting for the Red square, you make it spawn another object depending on the roll all in one go and print out the values from both of them. Its not unrealistic that your game when creating a unit might spawn something else that rely on some setting from the first unit.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • O star of layout- set text to "hi"

    -wait 5 sec

    -set text to "This is an example of a timeline"

    -wait 5 sec

    -set text to "wait can do other things besides text"

    -wait 5 sec

    -set text to "like make a trigger out of a variable"

    -wait 1 sec

    -set variable "dostuff" to 1

    And again Wait in itself is not a problem and yes there are lots of examples of how it can be used And your example is also a fine way to use it, but again it could be done with a Timer just as well. But its fair enough to leave Wait and not remove it, its not really that huge of a problem.

    But If you as in my example have to create several objects which depends on each other in one go, then its not all that simple as it allow Wait() to be misused, not because there is something wrong with wait itself, but because C2 when creating objects doesn't make them available before the next top level.

  • It's actually very helpful in a few instances as it's one of the few techniques that allows some measure of finite control. However it is a problem due to how it works. Personally the only time to use wait are for automated sequences. if at any point there is a possibility of interuption or reset, then wait will hurt. It's best to use Timer.

    I'm not sure about the top level reference either. Are we talking about UI or are we talking about how all programming is in C2 is Functional and not say Object Orientated, which would be I suppose downward up.

    -------------------------

    Replied before I sents.

    Wait doesn't hold the program. Wait encapsulates the current set of information and starts a JS Timer to execute after the given period of time. However once doing so obliviously moves that piece of code out of our control.

    As I said its not because Wait() can't be useful, my point is that its shouldn't be needed at all, at least not when it comes to solving problems, or what to say.

    I don't mean like if you throw in a wait of 10, then nothing will happen in the program for 10 seconds. What I mean is that you create a "fake" break in your program that shouldn't be needed.

    Actually wait has it's uses, you just haven't encountered them yet.

    Like pressing a sprite button. You switch the buttons animation, wait one second, and switch it back.

    Having to also set up a trigger to switch it back is as silly as wait(0).

    or like not allowing a key to work for 3 seconds after it's pushed:

    Using wait for something like a button and the audio in your examples can be ok. But you might as well hook up a timer. That when its up, triggers and you act on that. So my point in general is not that Wait() is broken and can't be used at all. But again it shouldn't be necessary to use to solve problems. You using it for a button or for the audio is fine. But you are just showing how it can be useful and that is not what im talking about.

    So to show you the problem and this is of course a simple example, but if you have a huge game and you solve problem using Wait() its could/will cause problems.

    Imagine we have a game where we spawn a Unit (Red square) based on this unit we want to spawn something else (Green square), but depending on some settings we might spawn different things. In this example I have only added one which are the Green square, just to keep it simple. But imagine it could be a Blue, Yellow, Black or a Pink square, all depending on some value when the Red square is spawned.

    So the Red square have two variables A and B and we assume that based on whatever, we ended up spawning the Green Square and we store the UID of the Red Square in the Green one. So when you hit the button to create the squares, we want Red Sq. A to be 1 and B to be 2 and write the UID stored in the Green Sqr. as well.

    In the top part of the image when I click the button it fails so all it writes is 0.

    Adding a Wait(0) in the Green square create event and then trying again, will solve the problem and now the values are correctly read and written to the text objects.

    So Wait(0) can be (mis)used to solve problems like this to fake It going to top level, instead of just having the Red and Green squares exist straight away, so the wait is not needed. So the code would do the same thing but the Wait(0) could be removed.

  • i don't see why anyone would use wait(0) since it calls the wait function not to wait. but i've had a couple of good wait usages and i find it pretty usefull.

    also i don't see what is your "top level design" problem? if you are thinkin' on gui/UI i don't see how removing that would solve your problems

    What im referring to is the problem with objects not existing before next top level when created, which you can "solve" by throwing in a wait = 0. Which is part of the top-level design problem or what to call it, there are other issues which can be solved with just throwing in waits.

    But a functionality in the form of a wait is a poor design decision in my opinion in general. Especially when its used to solve varies issues like working with newly created objects, but more, why on earth would you ever make a design that would force the program to wait? Unless you actually want the user to wait, but then there are timers way better suited for that, as they have built in triggers. I don't disagree with you that waits can be useful, but this is not because they are needed, its because C2 is designed the way it is. But if that was redesigned you wouldn't have to use Waits at all. It have nothing to do with the UI/GUI.

  • Wonder if the top level design/problem will be removed from C3 as its really not good in my opinion. Especially because its kind of encourage, especially new users, to solve problems using wait = 0, which is a bad way to handle problems in general, even though in some cases its really difficult to avoid it. But every time you do or are forced to do it, you are almost 100% certain that you are going to have problems later on. So wondering if that design is going to be removed from C3? So the Wait functionality can be removed as well, for good?

  • I was wondering now that form controls are part of C2 and they are rendered above other objects, which of course causes a lot of problems when running a project. But what are the supposed solution to fixing this, because it seems to be something that have been with C2 for a long time now.

    Here is an example:

    Left image is the original design in the editor.

    Top right image - Is full screen, and here the Red squares are being overlapped by the textbox and buttons, the Text object is misplaced compared to the textbox and there are different spaces between the buttons compared to the original one. The Big button have its X,Y value written as text, which match those in the editor, so the position should be the same but clearly aint.

    Lower right image - Is scaled down meaning the window size have been decreased and I zoomed in so its easier to see. The text object have now moved even more compared to both the original layout in the editor and the full screen version, as now the "T" in text is covered by the textbox.

    So the problem is, what is the solution or the idea to how to fix these issues, when it was designed? Because it seems like the form control uses a different scale or something and since the position reported in the C2 editor seems to match the position during runtime, why don't they appear correctly or how are you suppose to compensate for it, so your project looks correct when you run it?

  • Hi

    Wonder if anyone know how to get the display resolution from Windows?

    Im working on making my program work at different resolutions and the "full screen in browser" options are not really good solutions and causes more problems than they fix to be honest, some works for something but ruin something else etc etc.

    But can easily fix it manually if I can get the Windows resolution, but can't seem to get it anywhere. So anyone know of a plugin that can do this? or know a workaround of getting it some how?

    Or put in another way how do you target multiple aspect ratios like 4:3, 16:9 and 16:10 all in the same program, so im not talking about aiming for just one of them but all of them, any suggestions on how to do that is also appreciated?

    Cheers

  • nimos100, I see that your new audio path points to your local C: drive. Will this solution work for a folder hosted online?

    Thanks for your help...

    Not sure, so you would have to try to see if you can make the url so the filename can be added without the extension as that seems to be the important part when it comes to the source. But whether it will actually play it, even if you can get the filename and it will accept an non "<drive:>" format, is of course uncertain, as im pretty sure it weren't designed to work the way I did it in the first place, reading how its suppose to be used.