Official Request to Change "Display as Background"

Warning: The following post contains both solutions and rancor.

Recently, I posted about a problem I was having with switching between frames:

http://www.clickteam.com/epicenter/ubbthreads.php?ubb=showflat&Number=88629#Post88629

Specifically, whenever I got the frame jumps to work correctly, the graphics would go bonkers (regardless of the means I used). Active would blink in an out of existance, only partially reappearing as other active objects moved across them.

In light of the dearth of ideas on how to address the issue (I'm not blaming anyone for that--after all, I couldn't figure it out) I resorted to stripping objects and code chunks out to see if it was a particular object that was causing it.

As the third party extensions seemed the first logical place to look, I did them first. Sure enough, I found out that if I removed the Named Variable object, the glitches went away. So I tried replacing it with the Associative Array object, but that had the same problem. So I reloaded and deleted the Named Variable events line by line to find out which event was causing the problem. Eventually I found it: I had a text object that was displaying the contents of the named array object for debugging purposes and that line was the one causing the game to go bonkers.

And a possibility as to the exact cause occurred to me.

(Warning: Rancor starts here.)

I found myself thinking "No. NO. There is no WAY they wouldn't have changed that by now."

But sure enough, my darkest suspicions were confirmed when I looked and saw that...

...How many of you have guessed already?

No, go on, see if you know. I'm guessing a lot of you do.

"Display as background," the default setting that screws up everything it ever touches, is still the default. My entire game was unplayable because I forgot to uncheck the "be retarded" button on the text object.

Needless to say, my elation at having finally solved the problem is sprinkled liberally with bitter crumbs of extreme annoyance that Clickteam hasn't fixed that. Frankly it confuses me. Whenever I come to the forum there's always at least one person asking about a graphics glitch with their lifebars or whatnot, one person person telling them it's because "be retarded" is checked, and ten more people chiming in and complaining about it, begging that it be changed. I know because I've been one of those ten people like four or five times now.

Isn't it way past time for that to be changed? There can't be insurmountable technical obstacles keeping you from changing the default setting. "Display as background" has never worked for anything I have ever made. In my experience it has caused things to display incorrectly in 100% of cases, and now it's even causing *other* objects to display incorrectly. It doesn't really matter if there's a performance hit or whatever if you have to uncheck it anyway just to get the game to run correctly.

If nothing else, could we at least get a program preferences option that lets us change our personal default setting for the retard button? As this case demonstrates, checking to see if the retard button is on isn't always your first impulse, and if it is, that just makes it all the worse because it means it's what's wrong most often. And if it never occurs to you at all, you're totally boned.

That nonsensical default has gone beyond a nitpick and into the realm of being a serious liability. I nearly had to abandon a major project completely, and over a year's worth of work along with it, just because that stupid checkbox was on. That seems to me to be a pretty big deal. Frankly, I had already started to move the project to another development platform out of pure necessity because the problem seemed unsolvable, and as a result I was having to start over on like half of the work that I had done.

So can we please get that fixed?

I'll give you a cookie if you do.

A cookie with ice cream.

And fudge.

And whipped cream. And a cherry. [Edited] if that's what it takes. Come on, I'm on my knees here.

(Disclaimer: Don't worry, Clickteam. Despite my venting of righteous anger I still love you. I love the new ini++ and the hardware accelerator and all of that stuff. It's just that bells and whistles don't get you far when little nitpicky things persist in destroying a project's basic functionality.)

While I agree that Display as Background probably shouldn't be the default, I'm rather surprised that even though you took the time to write this colossal tirade and say that it's always the problem, it never occurs to you to check.

Referring to it as the "retard button" is not the most mature or convincing of arguments.

Maggot: I guess you must've clicked the "be retarded" button way too much.

It's just a default feature. Something easily changeable.

Being bitter and angry is making the text hard to read - are you saying that the "display as background" causes bugs?

Quote:

---

While I agree that Display as Background probably shouldn't be the default, I'm rather surprised that even though you took the time to write this colossal tirade and say that it's always the problem, it never occurs to you to check.

---

It's not always *the* problem, it's always *a* problem. In this case it didn't occur to me to check because there was nothing to indicate that it had anything to do with the text box and I didn't know text boxes even had the "display as background" option until it occurred to me to check and see. And compared to the time and effort it took to diagnose and fix this problem, writing that tirade was practically nothing.

Quote:

---

It's just a default feature. Something easily changeable.

---

That's easy for you to say. You didn't sink hundreds of hours into something only to find that you were going to have to abandon it because of something "easily changeable" that you didn't know was wreaking havoc on your program. Because of this "easily changeable" feature, I've lost dozens of hours not only in trying to fix this one particular problem but in gearing up to make the game with a different dev tool.

Sure, it's a totally simple fix now that I've spent a dozen hours figuring out what was wrong. But right up until an hour before that post, I didn't know what was wrong, and neither did anybody else. It still looked like the problem was out of my hands and I had been working on converting the game to a new platform. Mind you, this problem first cropped up many months ago, and thwarted every attempt to fix it. (Imagine for a moment that you don't know the text box has that "feature" and you're trying to debug the program. It would be, and was, impossible.) I tried dozens of things, using every workaround I could think of, testing everything I could think of, and nothing made a dent--the problem stayed there. My only choice was to make the game in some other program.

Thus, I ended up having to re-work my art assets and start coming up with completely new designs that would work on the new platforms--not to mention programming prototype code on those platforms to make sure they would work. And we're not talking about small changes; this game has thousands of frames of animation based on 3D models, all of which suddenly had to be downrezed, re-skinned, re-textured and re-animated in order to work in a realtime 3D engine. If I resume development in MMF again, all of that will have been wasted time--wasted time that is firmly the fault of that stupid button. (As it turns out, none of my events or graphics had any bugs--unticking the button fixed every single thing that was going wrong.)

In short, I wasted a huge amount of time and hard work because of some obscure "feature" that shouldn't even have been there. Can't you see how that might be frustrating?

Quote:

---

Being bitter and angry is making the text hard to read - are you saying that the "display as background" causes bugs?

---

Yes. It was preventing the active objects in the frame from displaying properly. Some of them would blink in and out of existence while others would permanently vanish until another active object moved over them, in which case they would partially reappear (the parts that had been moved over would become visible, but only temporarily). This all stopped once the box was unticked.

It always causes unwanted behavior, but usually it's confined to the object itself (i.e. if it's a counter, the counter won't display correctly--or at all--until you untick the box). This time, though, it was affecting everything.

Sorry to hear that. If it's any consolation, I had a similar problem with animation object (where it blinked and flashed and got distorted - even recorded a video of what's happening) and no official reply whatsoever ;_;

Despite the arguments that the way this article was written by Maggott, wouldn't we get further if someone who understood the pro's and cons of the "Display as background" feature commented and then maybe as a community we could decide whether we feel there is enough cause to take action to change functionality...?

Personally I have never had any issues like the ones described.

...nor have I. To me, this have never been a problem.

Default settings have trapped me more than once. I wish there would be a way to change them permanently. All of them.

I for example cannot count the endless hours i have spent with downtracking why something doesn't work just to find out that i was once again trapped by "destroy object if too far ..." and "inactivate object when ...".

Quote:

---

Originally Posted by Maggott

That's easy for you to say. You didn't sink hundreds of hours into something only to find that you were going to have to abandon it because of something "easily changeable" that you didn't know was wreaking havoc on your program.

---

You assume things. Yes, it did happen to me. In fact, it happens I must make sure everything is configured correctly everytime I start a project with programming language IDEs or while testing. I do prefer it to be that way, it gets me more control on what I'm doing.

Quote:

---

Originally Posted by Maggott

because of some obscure "feature" that shouldn't even have been there. Can't you see how that might be frustrating?

---

Shouldn't be there? Why? While I understand your frustration, you did learn something from it it's unlikely to happen again. We all have to learn to deal with what we have right now instead of saying this is an "official" request. This attitude won't get you anywhere. Please, realize that Clickteam is involved in HWA and the Java engine, so Yves may probably add it to the wishlist. He watches this forum a lot.

Again, a way to have some default options configured by the user is a good idea so let's just leave at that for now.

Agreed. Default settings should always be for the application to work logically.. like not destroying objects if they are too far away, not destroying objects if there are more than 500 and display counters and backdrops properly even if they are overlapping an active object...

Quote:

---

Originally Posted by Tiles

Default settings have trapped me more than once. I wish there would be a way to change them permanently. All of them.

I for example cannot count the endless hours i have spent with downtracking why something doesn't work just to find out that i was once again trapped by "destroy object if too far ..." and "inactivate object when ...".

---

To me that doesn't sound like you take enough care into making your applications very clean and effective. Sort of like when people doesn't comment their code. I check every property of every object I create, and consider what effect it will have on the game. By that reason, this type of problems does simply not happen to me.

My guess is that the default object configuration is specifically built for our new users, who doesn't think of resource management, and doesn't always make sure that objects are removed when they leave the frame, etc. I guess the object default configuration is intended for them, and I don't mind that as I always make the changes I need as soon as I create an object.

It sounds more that my projects are more than once this complex that i simply overlook such things from time to time, having dozens or more subsolutionfiles besides the mainbuild around. Even with having written even every little global value and its meaning down to documets, having lots of comments over every single of those thousands necessary lines, and checking and checking and triplechecking everything again and again ;)

The "destroy object if too far ..." and "inactivate object when ..." have been naggers when i first entered MMF with 1.0 back in 2k, and are still naggers today. Having them unchecked never caused any trouble to me. Never.

Having them checked by default caused me lots of trouble though, and has cost me lots of not necessary time to fix the quirks caused by them.

More than once you can read as a solution for a quirk to untick them. Have you ever read the advice to TICK them over the years? I never have. And my advice is always to untick them too. Even to novices. Especially to them. Because of the trouble those features ticked can cause.

You would hear a big hooray from me when i could untick them forever with one stroke.

Young man, you are making a mountain out of a molehill -.-

This molehill has grown to several mountains over the years at my end. We talk about my experience here. What's so bad about saying that i am not this happy with a feature?

I understand Maggotts frustration. I share it. And one's for sure, improvement comes from complainers. Not from the users that are happy with the software as it is.

I don't say i want it changed immediately. I just say i would love when it would change. Very possible that it stays as it is. For what reason ever. But at least i have tried.

A possible solution to this would be creating a template object outside the frame, setting its properties to the way you want them to be, and then using it to clone multiple objects based on it.

Tiles, I was talking to Maggott :)

Quote:

---

Despite the arguments that the way this article was written by Maggott, wouldn't we get further if someone who understood the pro's and cons of the "Display as background" feature commented and then maybe as a community we could decide whether we feel there is enough cause to take action to change functionality...?

---

I do agree with this. It would certainly make me feel better if I at least knew there was a reason. There may well be a good reason--I just can't think for the life of me what it could possibly be.

Quote:

---

You assume things. Yes, it did happen to me. In fact, it happens I must make sure everything is configured correctly everytime I start a project with programming language IDEs or while testing. I do prefer it to be that way, it gets me more control on what I'm doing.

---

Then surely you've had a time when you've nearly pulled your hair out because of something like this? I ran down the checklist of "the usual suspects" for everything as I was developing. The program is well-documented, organized, the object limits are set correctly and have the right "destroy/inactivate" settings, and the video/menu settings are all correct. Because I knew about that stuff. The testing counters even had the "display as background" option unticked.

The problem was that I didn't know text boxes had that option (ironically, I've never actually had a display problem with a text box until now--looking back at my projects that have text boxes, there were never any other objects that overlapped them). What's worse, the symptoms did not suggest that the textbox had anything to do with it; the textbox itself was displaying correctly, and the problems seemed to extend to areas outside of the textbox (though I'd have to double-check that). Even now, I suspect it's a genuine bug and not an intended effect of the Draw as Background feature.

Quote:

---

Shouldn't be there? Why? While I understand your frustration, you did learn something from it it's unlikely to happen again. We all have to learn to deal with what we have right now instead of saying this is an "official" request. This attitude won't get you anywhere. Please, realize that Clickteam is involved in HWA and the Java engine, so Yves may probably add it to the wishlist. He watches this forum a lot.

---

I apologize for any genuine offense I may have caused, to Clickteam or anyone else, and kudos for HWA and the Java engine. Both are huge throbbing awesome. That said, I stand by my decision to make the original post. I understand that it was not as polite as I usually try to be. That's why it came with a disclaimer. I basically meant to say "Warning: The following post is being made under the influence of raw, unfiltered Maggott-Rage and should be taken with a grain of salt."

When I say "Official" I'm only referring to me. (Think of it as me being facecious.) Others are free to agree or disagree. And you're free to decide I'm a total [insert favorite expletive here]-face. I won't resent that; I accept it as a logical consequence of the tone I chose. The fact is that the cumulative effect of months of frustration don't go away in an hour (at least, not for me. I can't use the excuse that I posted spur-of-the-moment, because I had had plenty of time to "cool off." Honestly, when I am genuinely enraged, it is hard to get me to say anything--I'm one of those "clam up and go fester in the corner" types.) The way I saw it, I had two choices: Post nicely, or post honestly. I figured I needed to post honestly in order for the full extent of the problems this caused me to be expressed.

In being bluntly honest I let my direct thought processes through, which--when something is seriously bothering me--inevitably ends up translating into a certain amount of biting sarcasm. (I'm like that. Rather than drinking or beating my imaginary wife, I rant. I usually try to rant in a way that is at least slightly constructive, but people can have a lot of reactions to a rant...including hating the poster and, by association, whatever point he/she was trying to make.)

My concern in sugar-coating my post--which, honestly, I would have been more comfortable with, since I don't like causing or being the target of strife, especially among people I otherwise like and respect--was that it would have conveyed the wrong impression, which was that this little detail was just that: a little detail. The truth, that it had caused nothing short of a catastrophe for me, could have been lost or dismissed as exaggeration (though the latter is still possible anyway). The game is half a year behind schedule (not that I have a deadline, but it's still not good) and I basically had to send away the few people who were helping me because even I no longer knew what assets I was going to end up needing (a 2D game written in MMF has very different needs from a 3D one made in DirectX, Truevision 3D or Ogre3D, and they have different needs from 3D Gamestudio, etc). Basically, speaking my mind exactly as it was was the only way I could think of to say "look, this really can screw people in a serious way and it's time to change it." On the surface it looks trivial, but this case proves it's consequences can potentially be very severe--if it can throw off a hardcore veteran for such a long period of time, it's a problem. And yes, I acknowledge that "veteran" is a subjective thing, especially since nobody here really knows me, and my supposed veteranhood may easily be cast into doubt if someone interprets this situation in the opposite way (that not checking the box means I'm incompetent). But I figure I'm good for several reasons: I've gotten MMF to do all kinds of crazy backflips, I only ever stumble on quirks when they are brand new (the save frame action, for example) despite making some very complex functionality, and it typically takes months of checking the forum before I'll see a question I don't already know the answer to. So I think of myself as at least a seasoned user. Thus, that is the perspective I speak from.

(As a side note, so long as we're mentioning the forums, I would like to stop being a [insert favorite expletive here]-face for a moment and say that despite my apparently venomous nature in this thread I am very appreciative of the people on this forum, especially the members of Clickteam, as most developers don't bother to listen to their userbase, let alone actually reply to them. While not all of my questions prove answerable, people almost always try, and a majority of my questions were answered. The ones that weren't were usually so bizarre, complicated or specific to my program that I couldn't realistically expect an answer anyway. In fact, one of the reasons I don't post often is because everyone is so quick at answering questions that I rarely get the chance, and I learn enough just from reading answers to other people that I rarely need to ask questions of my own. When I do post it's because I know of another way to accomplish something that might be easier, more efficient or just subjectively better, which is also fairly infrequent (most threads end up containing answers that are as good as the ones I could give unless the topic is extremely complex--finding ways to make complex functionality with simple techniques in MMF is something I consider to be one of my specialties).

My attitude is the result of the combined frustrations I have mentioned and the damage my project incurred. With most of the things that screw me up, I just take them in stride, or just make a normal, slightly less psychotic request. I don't complain about the initial 500 object limit and automatic deactivation/destruction, because I can at least see why those exist. They serve a purpose, even if it's one that a lot of people don't use. I even leave them on on certain objects sometimes, though they're still in the minority (even with projectiles I usually build a lifetime into them rather than simply having them go splodey when they leave the frame). They've screwed me up in the past, sure, and back when I was a n00b (or, rather, back when TGF 1 first came out) they screwed me up all the time, but it wasn't nearly as annoying because it only screwed me up a little bit and, once you know about it, it's an easy problem to diagnose--the object limit and object destruction/deactivation both have obvious symptoms (your creation events cease to work, you scroll over and find fifty objects all stacked on top of each other, or objects that moved off frame will suddenly be gone). I'm willing to accept them as idiot-proofing, because they don't cause genuine problems; when they stay on and I miss it, it usually just makes things a little tweaky rather than breaking them (since if they're breaking something, I'll spot that). Other things, like the fact that the program doesn't save frame data until the end of the frame, also didn't bother me all that much once I knew it was happening (thanks to the forum). It made things a bit more complicated, but not by too much, and there's probably a technical reason for doing it that way. The important thing is that it works. My only request with that was for them to mention the fact that it doesn't save until the end of the frame be added to the documentation for the sake of future users. (And me, if I end up forgetting and don't have old projects to look at.) And my biggest pet peeve in general, the fact that object picking usually only works on the left side with most events, is also understandable even if it does mean I have to increase my workload and program complexity by manually forcing dual object picking via fastloops. I figure if Clickteam has looked at the costs/benefits of the speed vs. utility of single vs. double instance picking and decided to opt for single, that's their prerogative. They're the only ones who know what the real performance hit is, and there are workarounds, so I can live with that. (The workarounds can be a major pain sometimes, but whatever...)

The problem with this particular case was that it was exceptionally hard to diagnose, screwed me up a lot, serves no practical purpose that I can see (again, if anyone knows otherwise, feel free to argue with me here) and would probably take all of thirty seconds to fix on Clickteam's end, yet in all this time they haven't done it. (Adding a formal preferences option would take longer, but changing the default would probably be a matter of changing a variable somewhere in the code from "1" to "0" and hitting compile.)

Between trying to diagnose this problem, working on moving the game to another engine (not to mention evaluating the engines in order to decide on one in the first place), and all the other incidental time-wasters this has caused, I've probably wasted over a hundred work-hours just because of this one bug. I agree that you have to be willing to accept a few stumbling blocks with any project--in fact, I've come to expect that there will be a large number with any project, regardless of platform--but there's a limit.

I usually build my designs to what is basically a double or triple contingency standard; I assume each component (graphics, code, gameplay design, etc.) may turn out to be impossible to create, won't or can't work as intended, or won't be up to an acceptable level of functionality/speed/file size/looks/gameplay/chocolate/whatever, and that it will potentially happen several times with each component. Usually I have 2-3 backup plans for each major part of the game. (I figure if three or four consecutive designs for a component fail, the project needs to be re-designed from the ground up with that component in mind in order to ensure it works.)

I try to make sure that whatever I have as far as codebase, assets, gameplay and overarching design can work in any combination or be easily adapted to other combinations (I make sure the art assets can be finagled to work with any of the 3 gameplay designs, for example, and I make sure the gameplay can be implemented 3 different ways). When designing contingencies, I try to emphasize different things with each, so if one implementation is too weak in a certain area, there will be another design for it that is strong in that area. I also try to make sure that they don't share weaknesses or potentially problematic requirements like time, organizational complexity, or quality. For example, with graphics, one design might emphasize making best use of the engine's particular inherent strengths and built-in shortcuts in order to make good looking animations and effects without adding extra work. The second design might emphasize a simple, iconified graphical style in order to minimize the time necessary to create them and minimize the complexity of implementing them in-game. The third might emphasize using modular sprites that allow art assets to be used in combination with one another, allowing for a wide variety of characters/monsters/whatever without increasing the actual number of sprites/models that need to be made. This way, if making the modular system doesn't work because I can't get the Z-order of the bodyparts right, I can switch to the one that emphasizes the engine's graphical strengths. If it turns out that this increases the time required to create or pre-process the sprites or models by too much, I can switch to the iconic style. If the iconic style just isn't enough to make for an entertaining game, well, I'm pooched--unless the iconic style was the first one I tried. (Incidentally, the game I'm currently working on uses both the modular bodyparts and the engine's strengths; I've already got some pixel shaders set up to use and abuse Clickteam's wonderful HWA build. I'm not currently running or testing in the HWA version, though--otherwise I would have assumed that was the cause of the graphical glitches. And while I do have the occaisional Z-order issue, they're never serious. At absolutely worst, I manually set the Z-order according to the current animation frame and direction. So far that has only been necessary in one animation.) I also design things so that if one falters, I can make up for it with another (for example, if pre-processing sprites takes too long, I will write a program that automates it. This is also a real example; I have a visual basic utility that I wrote that fiddles with the colors of the sprites so that they will work correctly with my pixel shaders. It also does some other refinements like redefining the pixel borders that were on the original render, since if the original, aliased edges are there the bodyparts will have visible seams. That probably won't be necessary for the release, since the HWA can use alpha channels and those look better anyway...)

I also make sure I have some sort of last resort emergency solution for each component in case none of the options work; the difference is that the emergency solutions will usually require re-working the other things as well.

In this case, as far as I could tell, both the normal contingencies and the emergency solutions would all have been hit by the same problem, as they all required the same kind of frame switch somewhere. I could think of ways to spaz out the design to get rid of all but one of those frame switches, but that one was, unfortunately, non-negotiable. The conversation frame absolutely has to be separate from the combat frame, because if you can still be attacked while using the conversation engine, the whole thing comes down--and since the conversation engine is built into the quest engine and the 'unusual events' engine, it will inevitably have to be present in frames that have enemies. If nothing else, there will be hostile territories that contain NPCs you can talk to, and that has to be accomodated.

(Incidentally, the fact that I built a fully functional branching conversation engine in MMF--one that's quick and easy to script conversation trees for, no less--is one of the reasons I'm willing to classify myself as pretty good at it.)

The only thing I could think of was freezing everything while the player was using the conversation system, but that just set off way too many warning lights in my head; the number of things that could potentially be affecting the player combined with the potential number of unforseen side-effects of freezing and un-freezing everything, not to mention the added time and complexity required to actually do it (and to implement fixes and workarounds for whatever side-effects cropped up) meant the experienced developer in me was screaming to stay the frack away from that idea like it was a rattlesnake with rabies.

The uber-contingency philosophy has seen me through many projects that otherwise would have crashed and burned (in video games and non, though in non-video games it's a lot easier to get assets to play nice together so I wing it a lot of the time--if you're writing an RPG book, you can change the mechanics all you want and you won't have to re-write the descriptions of the setting or the IC fiction snippets, for example. But I digress).

There are times, however, when this doesn't work. Specifically, when one bug or production problem will affect every possible design for a crucial component in the game. That's more than a stumbling block. That's a brick wall. And that was the case with this particular bug; it would have broken any design I used, and it was very hard to find. (I've been trying to convey that it seems simple in hindsight, but from where I'm sitting it sure wasn't a simple or easy thing.) That's why I'm taking it so seriously. It was a total dealbreaker that I never would have found or fixed if not for the fact that I kept on it like a bulldog, even as I was grudgingly re-making the assets for another engine. The fact is I picked MMF as the original platform for a number of good reasons (development time as far as code was actually only one of the advantages MMF offered; it also simplifies compiling/distribution, offers graphics options I can't duplicate with my homemade 2D engine, eliminates the requirements for external data file management--or would, if not for the fact that the conversation engine, spells, monster stats, and a ton of other things are stored in external text files...the list goes on.) Abandoning it truly was a last resort. (In that respect I was almost lucky that the other engines were giving me problems too--I had an incentive to keep trying to solve this issue.) Thankfully, having seen several large projects to completion has required that I learn to continue to bang my head on things long after they seem hopeless and/or start driving me crazy. (In my experience, there are two keys to success: knowledge and tenacity.) But even with all that, once I had started making serious progress with another engine, I probably would have ditched MMF and designated it as great for action gameplay prototypes but too unpredictable and unreliable for serious projects. (Even now, it's classified as something that has to be handled with care--one thing I think people will agree with me on is that it's often quirky and doesn't always do what you would expect it to. And a lot of things are just plain harder to do until you've reconfigured your thought processes to do things in a way that makes sense in MMF rather than what would make sense in a conventional language--things like basing your game's logic and behavior on sub-objects rather than functions. For example, all damage in this particular project is processed through a single object that automates and centralizes the gruntwork of checking for resistances, armor, skill modifiers, etc. It only throws the damage onto the target after it has done all the calculations and adjusted the damage accordingly. That means all of the wacky math for damage is all in one place, making it easy to access and tweak. It also means damage application is very simple--as the attacker, you tell the damage object who you are and who the target is. It will do all the retrieval and processing for buffs, debuffs, resistances, armor, stats, rolling for damage, modifying the damage, applying the damage, and everything else involved, for any object type, so long as it has the qualifier that the damage processor uses. All I need to do to have an object--whether a critter or a projectile--attack another object is to pass their unique IDs to the damage processor and then call it's fastloop. (The attacker goes in one alterable value, the defender goes in another.) As you can probably guess by now, this project is very elaborate in both design and implementation, and since I always do the hard stuff first just to make sure it's doable, what was left were fairly simple things like making frame switches and grunt work like adding spell and monster data. That's a lot of why the thought of losing it completely and having to start over was so icky--that and, while rebuilding things like the conversation engine and universal damage processor would be a little easier in a normal language than they were in MMF, things like the actual spells and such would be a lot harder. Especially since the plan calls for around 200 of them. That's an example of playing to an engine's strengths; 200 spells is doable in MMF. Half of them would just be a single rotated sprite with particle effects that don't require anything more complicated than setting their stats (the events are set up so that most spell behavior is universal and handled through qualifiers and centralized sub-objects; to make a new spell, all you need to do is fill out it's stats in an external text file--speed, damage, element(s), debuffs it inflicts etc--and add two events to the engine: one that tells the spell slots which frame of animation corresponds with that spell and what it's name is, and a fastloop event with the spell's name that creates the actual projectile (all you need to do is create it; it will aim itself and set it's speed and such automatically). Everything else is handled through a set of qualifier events. You don't even have to program in a way to cast the spell; the spell slots themselves are automated to kick on all the appropriate events for spellcasting (casting time and mana cost for the spell, etc.) and call the fastloops for whatever spell has been assigned to them. (Making a spell with an unusual effect is simply a matter of making a fastloop with the spell's name and assigning the desired actions to it. Everything else, from when you learn the spell to which animation plays when it is cast, is automatic.) I'm quite proud of the design as a whole, actually. But it seems I'm digressing again. If not outright bragging. (At this point I'm stuck on a computer with nothing better to do--I don't have any of my project stuff here so I can't work on it.)

Back to the point: I figure it should be simple to switch the default and from all the experience I've had, the pros of doing so would vastly outweigh the cons. That's why I requested that it be changed. It isn't that it's hard to go hit the button; that was never the problem. The problem was figuring out that it was the cause of my problems in the first place.

I did eventually find it, and you are right that it will probably never mess me up again, just because now I know that if the graphics go wiggy and there's a textbox in the frame, I need to uncheck the...well, I'm still tempted to call it the Be Retarded button, but for the sake of being nicer I'll call it the Draw As Background button. But the facts remain that it nearly killed my project as it stood, took me a few hours short of forever to find and fix, and may well do the same thing to someone else down the road (assuming it hasn't already, which I'm guessing it has). And they may not come to the forum, and if they do, the people who read the message may not know the answer. They may not have as much to lose as I did, but that may only make it worse--they may just abandon MMF, and potentially game making, altogether. (And I did have a lot to lose--in addition to the spiffy infrastructure, I had thousands of frames of animation. They add up fast when you've got 9 bodyparts, 8 directions per bodypart, about 10 animations per direction, and 5-20 frames per animation. And that's for one set of armor. Right now there are three or four sets; it's been so long since I was able to work on the sprites for this that I can't even remember. The plan is to cram in as many as I can fit on a CD, after accounting for all the other graphics, music, and so forth. And what's really scary is that there were originally 800 frames of animation per character, as opposed to the severely pared-down 150 or so that they have now. The characters were also two or three times the size, pixel-wise. But that made the file way too big--about 500 megs per set of limbs/armor--and it took 45 seconds just to load the frame, so I pared down the animations, made the characters smaller, and decreased the game resolution...ramble ramble ramble. I know. Sorry.)

Anyways. Thanks to everyone who tolerated my rant. And those who read this monster of a post. (Like I said, nothing better to do. Work has been incredibly slow today.)

Quote:

---

It would certainly make me feel better if I at least knew there was a reason

---

I thought I read recently here on the forums from Francois recently that it slows down the runtime so it defaults to the fastest method. I could be wrong.

Holy wall of text batman!

That being said, I agree that the best solution would be to make it user configurable.

Its always important when asking for a change that could have a serious effect on games (think of all games in development and those made if you change the default setting of an object) that its handled with common sense.

I dont doubt it was irratating to you personally, but if you want people to sit up and say "Actually thats a really good idea" you've got to make sure you dont just rant... otherwise it will just upset people (remember this is a family friendly forum).

If there is a bug with this option i am sure the guys will look at it. But i also believe the reason that it was switched on was because of performance.

That doesnt mean it cannot or shouldnt be changed, but there are always consequences for such changes.

I would add one little thing, MMF is a very powerful programming tool. You can make commercial programs with it, but its very easy to use. Unfortunately this means people can just dive into the program and make things. If you intend to make a serious application with it, then its essential you read/understand and digest every option you can. Thats the responsibility of the game maker. If you were learning C++ you have to learn the right and wrong ways of doing things and what options do.

CT create an amazing program that doest require you to learn C++, but its the developers role to learn what the features are and how to correctly use them. Its so easy to design a game badly in any language, but MMF allows people to get away with it more than a tradditional language. Which means people just dive in... how many people (me included) have re-written a game more than once because we learn of a better way to make a game... I would think alot. Its mainly because we dont want to spend time reading and learning, we just want to make, who wants to spend time designing ;)

Anyway I think all that needs to be said has been said on this post. We will raise the question with Y&F, but I am going to close this post.

Thanks

Jason