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.

nimos100, where can i find the audio object source in order to change the path?

You can't that's the whole problem. So you have to make a "fictional" source to bypass it. That's why I wrote in the original post, that its a mystery why you can't access the source of an audio object, because it should be fairly easy to do.

But here is how you bypass it:

The folder setting can be ignored, so doesn't matter if its "Sounds" or "Music" so don't worry about that.

Notice that in the variable Audio_filename = "Sound_effect.ogg", it actually need to be "Audio_filename = "Sound_effect" otherwise it wont work. I just added the ".ogg" so you could see it was the filename. Since you can't load files without the extension you will always get the filenames with it, so you have to extract just the filename from you sound files which you can do with Tokencount and Tokenat if the files are in different locations, or just with tokenat if all the sounds are in the same folder.

Since you say you have 10000 sounds, you of course have to add some functionality that can automate this for you. So you have to update the variables rather than trying to change the source of the audio object. But again its not a elegant solution, but the only way I have made it work.

I know the engine already does this per layout, but the option to do it manually for a sprite that we want when we want it is what allows more flexibility. Sure, people can mess up if they don't know how to use it, but that's a poor excuse to not have that level of control at all.

Completely agree with this. Its no different in my opinion than people can screw up loops, that doesn't mean that loops should be removed as well. Almost everything can be screwed up if done wrong, but what matters is the ability to be able to do something when its actually needed and to use it where it doesn't hurt performance, which should be a decision made by the person designing the game and not those making the software, because sure in some cases it would be a bad idea, but that doesn't justify that then its bad in every single case and therefore shouldn't be an option.

nimos100

Thanks again man. Now I could finally understand what you mean. But the thing I can't see is how I would store de UID or retrieve it when I need it. I mean, until now i'm using the system condition "compare two values" when I need the game to know some global value. I'm still crawling around the expressions. I would guess that that's how you do it? Which the expressions?

I don't know even the basics of logical programming... That must be the reason it gets so hard for me to communicate with you.

Aaand is there anyway I could give you guys some prestige? Like an upvote or something.

Sure no problem.

You can store the UID in a global variable, "Pressing V" while not in an event and you just name this "Last_created_UID = 0" this can then be used to store any number you want.

Since its global it means that its available to you from anywhere in the project. So when you need it you just do like this:

Pick Object.UID = Last_created_UID
[/code:ioxwfbzv] 

"Compare two values" doesn't make the system know anything, its simply compares two values and you can use the result to trigger whatever you need to. But maybe that was what you meant? But more important which is a normal mistake new users make is that they think that compare two value picks something, so it results in bugs, normally in the sense that suddenly more objects do things, where they thought it was only the one they "Picked". But "Compare two values" simply compares two value nothing more. So you have to pick the correct objects to compare before hand or it will cause problems.  For instant:

[code:ioxwfbzv]
Compare Object.UID = Last_created_UID
----> Object.destroy
[/code:ioxwfbzv]

This would destroy all Object and not only one.  So therefore you need to pick the correct Object first:

[code:ioxwfbzv]
Pick Object.UID = Last_created_UID
Compare Object.type = "Rabbit"
----> Object.destroy
[/code:ioxwfbzv]

Here you first Pick the object which UID is equal to the global variable "Last_created_UID" and if that Object have a type which is "Rabbit" it will be destroyed. 

The reason I changed the compare to "Type" is because it doesn't really make sense to compare UID using "Compare two values" as it doesn't pick anything and because if "Pick Object.UID = Last_created_UID" is true you already know that they have the same value and you have already picked it. So when you pick something you are at the same time performing a comparison automatically.

Your desire for better pathfinding or smarter pathfinding is in fact seeking the holygrail of RTS AI. Many many big-time RTS still struggle with smart pathfinding. What they achieve, it's all logic from "hacks and work-arounds", thinking outside the box.

I doubt we will ever get a smart pathfind AI out of the box. It's gonna require a lot of logic.

Think you have a point there, but also in defence of Scirra, its not easy to meet every ones demand on which path finding method should be used, they use A* which is fine I think but of course if they can improve it somehow it would be good.

But now that they have added a path finding behaviour and you start working with it, you quickly realize that its very basic and lots of details are missing in it. Like the single collision mesh, which of course is a design issue, but also there could be an option to make the path finding good for grid based games. And an option to make it move as close to an object as possible if you try to path find to a closed off area and that it would be able to path find correctly when in comes to diagonal movement etc. Besides the collision mesh, these things are details that should have been added to the behaviour to increase its functionality. So having to make work around is fine, but it shouldn't be that you have to spend 80-90% of the time doing this, because its obvious that its stuff that should have been in C2 by default, but aint.

Think these concerns have been made a few times before and agree with what you are saying. C2 can do a lot of things which are great, but as mentioned you always have the feeling that only the basics have been implemented and all the details needed to really complete it are skipped. The examples that you give are good examples of that. But think one of the most obvious examples of this are something as simple as text object and the fact that its not possible to change alignment during runtime even though you can do it in the editor. I mean its a very common functionality in any form of application, where you work with text. Still after using C2 for such a long time, its still a huge mystery why such details are not seen as important to add. And there are loads of such issues which again underline what you are also mentioning.

So my hope with C3 is that Scirra release a much more polished application from the beginning, where all these details are added. So rather than spending so much time having to adding new functionality that should be there from the release, they spend a lot more energy listening to the community of dedicated users, that in my opinion comes up with a lot of very good ideas that could really improve the program and that they spend time adding those things instead. Most of the people that come up with these ideas are not newcomers to the program, but suggest stuff because they actually have used the program a lot and see gaps in it, that should be fixed. So really hope they keep a list of suggestion made through the years of what people are really missing in C2 so they can make sure its not the same issues C3.

Here is something I wrote some time ago for another post, Thought it might be useful for you as well when it comes to organizing large projects or just project in general that I as least find useful.

[quote:2q4w5gpc]Here are some advise that might be useful.

1. Clean up

Objects that you don't need to be there from the start, by this I mean sprite objects that would be "Units", "Bullets" etc. you should destroy at the beginning of the game. This is simply to make sure that you don't have rogue objects in your program.

2. Precise functions

Make as small and precise functions as possible. Even though some of these functions might seem to simple for it to make much sense.

An example of why this is a good idea. Imagine you have a "Car" object and in you code you might change the speed to whatever you think is fine. like "Car.speed = 100". This would be fine until the point you decide that it could be fun to add something like, if the speed gets above a certain value the car should start loose control. If you add it in your code you would have to change/test for it every time you changed speed. But with a function you can simply add the test here and update it for the whole program at once. So using loads of functions is in my opinion one of the best ways to maintain an overview of your project, but they are very easy to replace, maintain and bug fix as you know what inputs and outputs they have.

3. Global constants

This can be very useful for reducing spelling errors, and to quickly change things in your game. Imagine in the above example, that you have several "Car" objects, which are categorized by a type, "Cheap car", "Normal car" and "Expensive car"

If you in your code manually add checks if ( Car.type = "Cheap car" ) and then do something, at some point you might figure out that the name "Cheap car" weren't that good an idea after all and something else would actually have been better, then instead of having to go through your whole code and replace "Cheap car", you can just update one global variable instant.

4. Use several event sheets

Don't be afraid of using event sheets even though you might not add a lot to them. It will really help you maintain an overview of your game.

5. Split events and functions

Unless you are 100% sure that an event sheet should only be used one place, its always a good idea to split events and functions, even though they work on the same object. So an event sheet called "Car events" and "Car functions" would be a good idea. You can always move functions later on, but think it good practice to just get used to splitting them. The reason for splitting them is that Functions wont execute without being called, so if you suddenly figure out that the functions in a event sheet could be useful in another, but have mixed a lot of events into it. You will have to move all the functions to a new event sheet to avoid unwanted problems of events suddenly executing when they shouldn't.

6. Requirements and returns

When making functions I find it very useful to add comments above them with requirements, and potential return values. This will make it very easy later on as you move along and might forget what a function actual does when you return to it.

An example could be like this:

7. Bug sheet

Make an empty event sheet, that you just use for comments. You don't include it in your program. But the purpose is that as you test your game and might be testing something, suddenly notice that something else is not working as intended. Then instead of fixing it straight away, you just in your "Bug event sheet" add a comment explaining what you noticed. And if possible the cause for it. Then you can always fix it later and you wont forget about it.

8. Quick reference function sheet.

This can be a bit time consuming but very useful. The idea is again to add an event sheet that you don't include in your program. But you simply add function calls to it, with the required amount of parameters.

This can speed things up quite a bit as you can just copy/paste function calls from this sheet to wherever you need them, and just update the parameters, and you don't have to remember the name or how you spelled the function name etc.