MiM (hacked) - On Hiatus since Feb 17, 2013

[Ivan-Aedler]

Blargh, thank you for you time to answer. You know, so many things to exchange. All for a better Princess Peach game. FTW.

I keep having to look up which is which all the time (key codes)

Me too. But as I've discovered, using a variable for a given key (like keyLEFT, keyW), not only is easy to understand, but faster in performance!

You pretty much have to have some sort of limiting variable to keep it out of the 'if' statements

The problem is that game engines really use that 'big main loop', with all those ifs and cases (its a commonplace).

Spoiler (click to show/hide):

But these 'onClipEvent (enterFrame)s' are devil, as they run about 1000 to 10.000 times each second! It doest work like in frames (one entire loop per second). So those ifs are tested in a blazing speed. (if masturbate if run if masturbate if right , if masturbating then pressing down, if masturbating then pressing down again.... As the 'ifs' are in the top hierarchy (no nesting ifs and cases), they can mangle the code while trying to apply jumping IF in certain circuntances (like wandering into char frames). So these enterframe areas is nice for 'immediate code', as 'notice' events that will run before anything else in this on-object in general (it will run first than any code inside its timeline).

In the beginning, I've thought the 'enterframe's acted only 'when entering the frame once'. NO! Its actually an endless loop! Thats why some guru coders recommends the minimal cases there (better, clean the code altogether in the on-object, putting code into a timeline frame instead, and having , say, two frames, with gotoAndPlay(1) in the second one, so this frame will check all those if / cases in the frame time (one second), instead of thousands of checks per second in the 'enterframe', giving more performance).

If 'enterframe' (in on-object area) aren't avoidable, gurus recommend the least code as possible in them, making structured cases that executes only if a really important thing is about to occur, like notice events. Instead, if we have three CASE statements in regard to moving types in the enterframe, with ifs inside each of them, the loop will respond faster to the statements, as the second and third may not be required to enter (the program checks for them right away). Remeber that the enterframe checks those cases in a blazing speed.

This logic also applies to every enemy. They're with their enterFrames running like the Large Hadron Collider! Depending on the optimizations done (not necessarily new code, as collision, but a more structured nested ifs or better, code transferred for the first action frame in the timeline), the game might be even 2x faster.

And it'll be a lot more effort to program pathing for other enemies.

I'll study the enemy pathing code. It will be so nice to have goombas and mushrooms wandering along the level, instead of the fixed 'walk left, then walk right', for example.

Spoiler (click to show/hide):

Its not difficult to make it, theoretically. Its like 'living peaches' wandering around, with their own _x and _y properties being changed with some gravity and the default ground collision peach uses already (if ground_hittest(_x_y, true)). I can point you which peach on-object code the goomba may need to use in its on-object.

I only have one system, and I built it to play everything.

Me too Its normal to do that. A dedicated computer for gaming. We usually use mid to high-end cards. Its so nice to play latest games with good to incredible performance. All is slick and so fast. However, I'll be addressing what can be done to increase performance for low end systems, as sometimes it's nice to play, say, in a laptop. Sometimes, a given frame that is not 'stopped()' is causing a performance hit. The less hungry the program is, the better, anyway.

I'll doing this in a "code lounge" spare time.

these blue and all (water cum)

I noticed this cum was acting on with a sensation of 'wrong color' (mostly in morton scenes). Peach was cumming in white, all is being good, yeah, "morton, more!" Then, all of a sudden, a blue liquid comes out. A clean pee? Mineral water coming from the urinals? So I readjusted the colors to the normal ones (white/light brown shadow). Total of 25 small pieces.

[Biles]

When a lot of thins are said and done (regarding major updates and features), at what point would it be an ideal if we added a "Shift" button to make Peach run? I know that it might affect a number of power ups, but it's an idea suggestion. With the shift, Peach can do a spin and break bricks, coin blocks, and even knock out enemies just like the real SMB game. If the player held down the shift and down key button, Peach could turn into a nude statue and let either the enemy walk by or fuck the statue hehe.

[Ivan-Aedler]

The code I'm using from now on (look for the scroll at the right - the list is bigger):

Spoiler (click to show/hide):

Code: Select All Code

keyUP=38;
keyDOWN=40;
keyLEFT=37;
keyRIGHT=39;
keySPACE=32;
keySHIFT=16;
keyCONTROL=17;
keyALT=18;
keyESC=27;
keyDELETE=46;
keyBACKSPACE=8;
keyW=87;
keyS=83;
keyA=65;
keyD=68;
key0=48;
key1=49;
key2=50;
key3=51;
key4=52;
key5=53;
key6=54;
key7=55;
key8=56;
key9=57;


Now, its only a matter of time to change all Key.isDown(83) to Key.isDown(_root.keyS) and others.
Even being larger ('Key.isDown(_root.keyS))', its much more understandable.

You may say: hey, how about the variable that substitutes the entire Key.isDown?
It didnt work :/ Peach didnt respond to commands. This may only work in AS3. So, no performance gain here.

[LuftMallow]

I've been working on improving the faces of the Pokemon girls since I'm still unhappy how they turned out. I don't know if it's the eyes or the fact I can't cover the jawline all too well. I also have been experimenting with the straps of the sling bikinis. Trying to make the static move dynamic is an exercise in frustration, but it's a learning experience.

MarleySling.jpg (26.7 KiB) Viewed 4103 times

[Biles]

Hmm, is the sling bikini intended to be something very tight fitting? If so, then I don't think the back straps should sag like that. When tightened, the straps straighten out.

[Ivan-Aedler]

Maybe because its intended to be blowing out? Actually I loved these sling bikinis I just imagined one with no bra tissue (just a string). I have this alternative already done

[Blargh]

Long story short, I will try to update on Saturday. Friday is going to be lost to Secret World beta weekend #2.

Blargh, thank you for you time to answer. You know, so many things to exchange. All for a better Princess Peach game. FTW.

Spoiler (click to show/hide):

I keep having to look up which is which all the time (key codes)

Me too. But as I've discovered, using a variable for a given key (like keyLEFT, keyW), not only is easy to understand, but faster in performance!

You pretty much have to have some sort of limiting variable to keep it out of the 'if' statements

The problem is that game engines really use that 'big main loop', with all those ifs and cases (its a commonplace).
[spoiler]But these 'onClipEvent (enterFrame)s' are devil, as they run about 1000 to 10.000 times each second! It doest work like in frames (one entire loop per second). So those ifs are tested in a blazing speed. (if masturbate if run if masturbate if right , if masturbating then pressing down, if masturbating then pressing down again.... As the 'ifs' are in the top hierarchy (no nesting ifs and cases), they can mangle the code while trying to apply jumping IF in certain circuntances (like wandering into char frames). So these enterframe areas is nice for 'immediate code', as 'notice' events that will run before anything else in this on-object in general (it will run first than any code inside its timeline).

In the beginning, I've thought the 'enterframe's acted only 'when entering the frame once'. NO! Its actually an endless loop! Thats why some guru coders recommends the minimal cases there (better, clean the code altogether in the on-object, putting code into a timeline frame instead, and having , say, two frames, with gotoAndPlay(1) in the second one, so this frame will check all those if / cases in the frame time (one second), instead of thousands of checks per second in the 'enterframe', giving more performance).

If 'enterframe' (in on-object area) aren't avoidable, gurus recommend the least code as possible in them, making structured cases that executes only if a really important thing is about to occur, like notice events. Instead, if we have three CASE statements in regard to moving types in the enterframe, with ifs inside each of them, the loop will respond faster to the statements, as the second and third may not be required to enter (the program checks for them right away). Remeber that the enterframe checks those cases in a blazing speed.

This logic also applies to every enemy. They're with their enterFrames running like the Large Hadron Collider! Depending on the optimizations done (not necessarily new code, as collision, but a more structured nested ifs or better, code transferred for the first action frame in the timeline), the game might be even 2x faster.

And it'll be a lot more effort to program pathing for other enemies.

I'll study the enemy pathing code. It will be so nice to have goombas and mushrooms wandering along the level, instead of the fixed 'walk left, then walk right', for example.

Spoiler (click to show/hide):

Its not difficult to make it, theoretically. Its like 'living peaches' wandering around, with their own _x and _y properties being changed with some gravity and the default ground collision peach uses already (if ground_hittest(_x_y, true)). I can point you which peach on-object code the goomba may need to use in its on-object.

I only have one system, and I built it to play everything.

Me too Its normal to do that. A dedicated computer for gaming. We usually use mid to high-end cards. Its so nice to play latest games with good to incredible performance. All is slick and so fast. However, I'll be addressing what can be done to increase performance for low end systems, as sometimes it's nice to play, say, in a laptop. Sometimes, a given frame that is not 'stopped()' is causing a performance hit. The less hungry the program is, the better, anyway.

I'll doing this in a "code lounge" spare time.

these blue and all (water cum)

I noticed this cum was acting on with a sensation of 'wrong color' (mostly in morton scenes). Peach was cumming in white, all is being good, yeah, "morton, more!" Then, all of a sudden, a blue liquid comes out. A clean pee? Mineral water coming from the urinals? So I readjusted the colors to the normal ones (white/light brown shadow). Total of 25 small pieces.

But losing the onClipEvents sounds so AS3'ish! Also, I think the difference between actionscript code on-object and the calculations necessary to change an object's orientation/position between frames might actually be in favor of the onClipEvents. The coins might make the best comparison, since they should be easily modifiable into using timeline code, there's a hundred of them for stress-testing, and they're already programmed to stop spinning when the quality is set to medium.

For enemy paths, I don't mean complex calculations to determine their position, mode of movement, and gravity. I just mean how they move from left to right. Even going left to right and up, then down, then reversing became a huge mess of calculations. Trying to add gravity and ground hits would surely break the code bank, at least for me. I'll just be settling for tweens and figuring out why focusing doesn't work even though the variables all trace correctly except for them inexplicably tracing 0 for long periods before going back to tracing correctly.

The color change on Peach's cum was to set it apart from the cum wads from Morton and others. If it's the same color as the male cum, it gets lost in the noise and just looks like Peach herself is cumming like a guy. >_>

(I'm hiding your post because it's pretty long.)

The code I'm using from now on (look for the scroll at the right - the list is bigger):

Spoiler (click to show/hide):

Code: Select All Code

keyUP=38;
keyDOWN=40;
keyLEFT=37;
keyRIGHT=39;
keySPACE=32;
keySHIFT=16;
keyCONTROL=17;
keyALT=18;
keyESC=27;
keyDELETE=46;
keyBACKSPACE=8;
keyW=87;
keyS=83;
keyA=65;
keyD=68;
key0=48;
key1=49;
key2=50;
key3=51;
key4=52;
key5=53;
key6=54;
key7=55;
key8=56;
key9=57;


Now, its only a matter of time to change all Key.isDown(83) to Key.isDown(_root.keyS) and others.
Even being larger ('Key.isDown(_root.keyS))', its much more understandable.

You may say: hey, how about the variable that substitutes the entire Key.isDown?
It didnt work :/ Peach didnt respond to commands. This may only work in AS3. So, no performance gain here.

Thanks for the list! That'll shorten my reference time. There wasn't much of a need to replace Key.isDown with keyDown, though, was there? Since they'd both be functions that do the same thing and aren't really named much differently, right? Although, most likely the reason it didn't work is because you'd just copy the 'isDown' function, but not the Key object that holds it, so it wouldn't have the same functionality anyway.

I've been working on improving the faces of the Pokemon girls since I'm still unhappy how they turned out. I don't know if it's the eyes or the fact I can't cover the jawline all too well. I also have been experimenting with the straps of the sling bikinis. Trying to make the static move dynamic is an exercise in frustration, but it's a learning experience.

The jawlines are kind of a hard point because they need some bit of hair or other thing to cover the point where the jaw and head piece meet at the ear, but it of course can't be too big with short hair.

Does it need to be a string bikini, though? Why not just a bikini? In either case, I guess, the straps should just match up (on Normal and Smaller sizes, if possible, but smaller at the least) when there is no movement. During movement, the illusion of bouncing boobies will hide any inconsistencies of the connections. If you're going to keep the piece that hangs away from the body, though, it should only need to match up to the smaller size because all the other ones will drop down and cover it over. There's no need to overthink it.

[LuftMallow]

I've been working on improving the faces of the Pokemon girls since I'm still unhappy how they turned out. I don't know if it's the eyes or the fact I can't cover the jawline all too well. I also have been experimenting with the straps of the sling bikinis. Trying to make the static move dynamic is an exercise in frustration, but it's a learning experience.

The jawlines are kind of a hard point because they need some bit of hair or other thing to cover the point where the jaw and head piece meet at the ear, but it of course can't be too big with short hair.

Does it need to be a string bikini, though? Why not just a bikini? In either case, I guess, the straps should just match up (on Normal and Smaller sizes, if possible, but smaller at the least) when there is no movement. During movement, the illusion of bouncing boobies will hide any inconsistencies of the connections. If you're going to keep the piece that hangs away from the body, though, it should only need to match up to the smaller size because all the other ones will drop down and cover it over. There's no need to overthink it.

Some one asked for a sling bikini for the frog power-up,which is why I went with it. I doubted getting Misty's suspenders on her outfit, but that managed to turned out differently.

Here's the .FLA including all the fixes I've made. It also has a few irrelevant test outfits and character I made to see how the new part system worked. I don't expect any of them to be used, except for maybe one of them. I did notice while making one that the vest and skirt parts switch layers between standing and moving, which could be a problem if some one makes an outfit with a skirt.

http://www.mediafire.com/?84n4x89ppdfr79h

[Ivan-Aedler]

But losing the onClipEvents sounds so AS3'ish....And its a hundred of coins for stress-testing, and they're already programmed to stop spinning when the quality is set to medium.

Hmmm yes, using frames code instead of onClipEvents will let the program more 'inner', more code-oriented, but certainly it will be more portable (say, you can modify code of one peach without having to copy and paste code to another peach instance). In a full length game, any change to 'onenterframe' in one peach will force us to copy and paste to all other peaches.
But......

Spoiler (click to show/hide):

I tested that today, for the Peach (putting all in the first frame of _root.char). Huh, It didnt work. Thats because of the need of jumping codes to be in the same area of _root.char. This new code must be in frame 1, which loops itself. This will optimize code. But now, Peach uses jumping in frames 4-14. So the code should be in every frame. You know the result: mangled code, difficult to maintain.

Also, I've brainstormed more about putting the jumping frames again in the right frames (_root.char.character). Tests and tests. All failed. But this time, I found the culprit.
Here is it (in peach on-object code)

Code: Select All Code

if (Key.isDown(_root.keyRIGHT) or Key.isDown(_root.keyD))
        {
            setProperty("", _x, _x + _root.char.charspeed);
            right = true;
            _root.char.character.gotoAndStop("walkright");
        }
        if (right)
        {
            _root.char.character.gotoAndStop("standright");
        } // end else if

        if (Key.isDown(_root.keyLEFT) or Key.isDown(_root.keyA))
        {
            setProperty("", _x, _x - _root.char.charspeed);
            right = false;
            _root.char.character.gotoAndStop("walkleft");
        }
        if (!right)
        {
            _root.char.character.gotoAndStop("standleft");
        } // end else if


As these has more 'ifs' (instead of if elses), the program will be crazy when jumping code is activated, as it will only play the first frame , and even with the sound of masturbation because it harms the masturbation if (already discussed). When I delete those code above, she jumps correctly (all the frames) but, of course, she doesnt walk anymore.
Trying to put elseifs in the others 3 ifs let her going right but not left, or jumping with endless loop animation of jump, or jumping then walking after the jumping frames goes to the end, like shes in a hurry, even in the air!

Jumping is like 'a new peach'. So it needs its own frame (or frames) to separate her for the standing peach, which transforms to walking during gameplay. Thats why _root.char isnt able to remain with 1 frame only. When you go to frame 4, for example (in my code) you see that the entire peach changes (movie clip is now peach_jumping). So when you go right, left, while jumping, she still maintains the jumping animation.

Conclusion: either we change entirelly the code above from scratch (ala hummingbird), in order to be able to use the 'jumpingright' and 'jumpingleft' frames in _root.char.character, or we just keep as it, as its the way playshapes developed.
Once playshapes' code already works, the frog animation (which I will certainly do it) will also follows the same rule in _root.char (from frames, say, 15 to 25) using 'peach_frogging' or anything like that. So far, so good.

For enemy paths, I don't mean complex calculations to determine their position, mode of movement, and gravity. I just mean how they move from left to right.

But you dont need complex calculations to add moving on x axis, for example. Moving is with _x like Gravity is for _y positions of the entire goomba movieclip. Its not hard, trust me. The goombas , then, could only start walking when Peach is in his side of view (or given a distance from the two movie clips, peach and goomba) so he will get his _x property changed by -1. In Mario games, goombas starts walking to the left. If he touches a obstacle, he changes direction. If he loses contact to the ground, he falls (gravity acts on). Thats all.

It could be like peach code: enterframe code in the goomba on-object.

Spoiler (click to show/hide):

For block collision (when walking), use this peach code, already in our versions:

Code: Select All Code

if (ground.hitTest(_x + _width / 4, _y - _height / 4, true))
        {
            setProperty("", _x, _x - _root.char.speed);
        } // end if
        if (ground.hitTest(_x - _width / 4, _y - _height / 4, true))
        {
            setProperty("", _x, _x + _root.char.speed);
         }


Reading Peach code above: 'if any image in the 'ground' instance (ground layer) touches Peach in x position near her right foot, and y position near her arms, push her left.'
The speed is just a variable. It can be 1, 1.5, 2.... Its just a number that will push her back in a given centimeter. So in every block, Peach will ricochet in the left (in this case). The following code is testing her left side, so she will ricochet to the right.

For goombas, speed will be actually just '1' (he will walk one pixel at a time) but it can be 1 or -1, according to his direction. So I've created the variable 'DIRECTION', which can have a value of -1 or 1. You put this in each frame (not enterframe) of goomba timeline (which will be just two frames, left OR right).

Code: Select All Code

setProperty("", _x, _x -DIRECTION);


In his on-object, lets change the peach code above to goomba code:
Instead of the tween frames of 'walk left' and 'walk right' of goomba, erase all of them and just put two frames with labels 'walk right' and 'walk left'. According to the direction changed by DIRECTION, just 'gotoandPlay' to the desired frame.
gotoAndPlay("walkright");

Code: Select All Code

if (ground.hitTest(_x + _width / 4, _y - _height / 4, true))
        {
            gotoAndPlay("walkleft");
            DIRECTION=-1;
        } // end if
        if (ground.hitTest(_x - _width / 4, _y - _height / 4, true))
        {
           gotoAndPlay("walkright");
            DIRECTION=1;
         }


Okay, problem solved. Now to add the gravity, just use the code also in goomba on-object (same as peach):

Code: Select All Code

 
grav=0;
gravity=1;
//GRAVITY FALLING - This will put Goomba lower, until reaching ground objects
        for (grav = grav + gravity; ground.hitTest(_x, _y, true); grav = 0)
        {
            setProperty("", _y, _y - gravity);
        }


As goombas dont jump, grav doesnt require to change (like '-18', the jumping height). Its zero in the beginning. You dont need to even understand its hole;

The implementation of this code for goomba is in my to-do list.

The color change on Peach's cum was to set it apart from the cum wads from Morton and others. If it's the same color as the male cum, it gets lost in the noise and just looks like Peach herself is cumming like a guy. >_>

Understood! Well, at least for me, it was not a visual problem to let her cum equal to others. On the contrary, it increased sex appeal (you see cum as they're really coming for the genitals). Anyway...why not then changing her color to white-ivory, and the others, a bit browner?

See you, great man, and happy coding Any doubts, I'll be able to help.

[theblacknphbutnotgay]

I've been working on improving the faces of the Pokemon girls since I'm still unhappy how they turned out. I don't know if it's the eyes or the fact I can't cover the jawline all too well. I also have been experimenting with the straps of the sling bikinis. Trying to make the static move dynamic is an exercise in frustration, but it's a learning experience.

The jawlines are kind of a hard point because they need some bit of hair or other thing to cover the point where the jaw and head piece meet at the ear, but it of course can't be too big with short hair.

Does it need to be a string bikini, though? Why not just a bikini? In either case, I guess, the straps should just match up (on Normal and Smaller sizes, if possible, but smaller at the least) when there is no movement. During movement, the illusion of bouncing boobies will hide any inconsistencies of the connections. If you're going to keep the piece that hangs away from the body, though, it should only need to match up to the smaller size because all the other ones will drop down and cover it over. There's no need to overthink it.

Some one asked for a sling bikini for the frog power-up,which is why I went with it. I doubted getting Misty's suspenders on her outfit, but that managed to turned out differently.

Here's the .FLA including all the fixes I've made. It also has a few irrelevant test outfits and character I made to see how the new part system worked. I don't expect any of them to be used, except for maybe one of them. I did notice while making one that the vest and skirt parts switch layers between standing and moving, which could be a problem if some one makes an outfit with a skirt.

http://www.mediafire.com/?84n4x89ppdfr79h

this is the only post that has ever disappointed me here that's a zip files with like 100mb of things and no swf or fla.... but it says fla... i'm gonna cry now

[Blargh]

Some one asked for a sling bikini for the frog power-up,which is why I went with it. I doubted getting Misty's suspenders on her outfit, but that managed to turned out differently.

Here's the .FLA including all the fixes I've made. It also has a few irrelevant test outfits and character I made to see how the new part system worked. I don't expect any of them to be used, except for maybe one of them. I did notice while making one that the vest and skirt parts switch layers between standing and moving, which could be a problem if some one makes an outfit with a skirt.

http://www.mediafire.com/?84n4x89ppdfr79h

Oh right! Sorry, I'm already forgetting the origin of the pink sling bikini. I blame lack of sleep. >_>
I'll fix the layering on standing/moving. Vest should be above Skirt.

But losing the onClipEvents sounds so AS3'ish....And its a hundred of coins for stress-testing, and they're already programmed to stop spinning when the quality is set to medium.

Hmmm yes, using frames code instead of onClipEvents will let the program more 'inner', more code-oriented, but certainly it will be more portable (say, you can modify code of one peach without having to copy and paste code to another peach instance). In a full length game, any change to 'onenterframe' in one peach will force us to copy and paste to all other peaches.
But......

Spoiler (click to show/hide):

I tested that today, for the Peach (putting all in the first frame of _root.char). Huh, It didnt work. Thats because of the need of jumping codes to be in the same area of _root.char. This new code must be in frame 1, which loops itself. This will optimize code. But now, Peach uses jumping in frames 4-14. So the code should be in every frame. You know the result: mangled code, difficult to maintain.

Also, I've brainstormed more about putting the jumping frames again in the right frames (_root.char.character). Tests and tests. All failed. But this time, I found the culprit.
Here is it (in peach on-object code)

Code: Select All Code

if (Key.isDown(_root.keyRIGHT) or Key.isDown(_root.keyD))
        {
            setProperty("", _x, _x + _root.char.charspeed);
            right = true;
            _root.char.character.gotoAndStop("walkright");
        }
        if (right)
        {
            _root.char.character.gotoAndStop("standright");
        } // end else if

        if (Key.isDown(_root.keyLEFT) or Key.isDown(_root.keyA))
        {
            setProperty("", _x, _x - _root.char.charspeed);
            right = false;
            _root.char.character.gotoAndStop("walkleft");
        }
        if (!right)
        {
            _root.char.character.gotoAndStop("standleft");
        } // end else if


As these has more 'ifs' (instead of if elses), the program will be crazy when jumping code is activated, as it will only play the first frame , and even with the sound of masturbation because it harms the masturbation if (already discussed). When I delete those code above, she jumps correctly (all the frames) but, of course, she doesnt walk anymore.
Trying to put elseifs in the others 3 ifs let her going right but not left, or jumping with endless loop animation of jump, or jumping then walking after the jumping frames goes to the end, like shes in a hurry, even in the air!

Jumping is like 'a new peach'. So it needs its own frame (or frames) to separate her for the standing peach, which transforms to walking during gameplay. Thats why _root.char isnt able to remain with 1 frame only. When you go to frame 4, for example (in my code) you see that the entire peach changes (movie clip is now peach_jumping). So when you go right, left, while jumping, she still maintains the jumping animation.

Conclusion: either we change entirelly the code above from scratch (ala hummingbird), in order to be able to use the 'jumpingright' and 'jumpingleft' frames in _root.char.character, or we just keep as it, as its the way playshapes developed.
Once playshapes' code already works, the frog animation (which I will certainly do it) will also follows the same rule in _root.char (from frames, say, 15 to 25) using 'peach_frogging' or anything like that. So far, so good.

For enemy paths, I don't mean complex calculations to determine their position, mode of movement, and gravity. I just mean how they move from left to right.

But you dont need complex calculations to add moving on x axis, for example. Moving is with _x like Gravity is for _y positions of the entire goomba movieclip. Its not hard, trust me. The goombas , then, could only start walking when Peach is in his side of view (or given a distance from the two movie clips, peach and goomba) so he will get his _x property changed by -1. In Mario games, goombas starts walking to the left. If he touches a obstacle, he changes direction. If he loses contact to the ground, he falls (gravity acts on). Thats all.

It could be like peach code: enterframe code in the goomba on-object.

Spoiler (click to show/hide):

For block collision (when walking), use this peach code, already in our versions:

Code: Select All Code

if (ground.hitTest(_x + _width / 4, _y - _height / 4, true))
        {
            setProperty("", _x, _x - _root.char.speed);
        } // end if
        if (ground.hitTest(_x - _width / 4, _y - _height / 4, true))
        {
            setProperty("", _x, _x + _root.char.speed);
         }


Reading Peach code above: 'if any image in the 'ground' instance (ground layer) touches Peach in x position near her right foot, and y position near her arms, push her left.'
The speed is just a variable. It can be 1, 1.5, 2.... Its just a number that will push her back in a given centimeter. So in every block, Peach will ricochet in the left (in this case). The following code is testing her left side, so she will ricochet to the right.

For goombas, speed will be actually just '1' (he will walk one pixel at a time) but it can be 1 or -1, according to his direction. So I've created the variable 'DIRECTION', which can have a value of -1 or 1. You put this in each frame (not enterframe) of goomba timeline (which will be just two frames, left OR right).

Code: Select All Code

setProperty("", _x, _x -DIRECTION);


In his on-object, lets change the peach code above to goomba code:
Instead of the tween frames of 'walk left' and 'walk right' of goomba, erase all of them and just put two frames with labels 'walk right' and 'walk left'. According to the direction changed by DIRECTION, just 'gotoandPlay' to the desired frame.
gotoAndPlay("walkright");

Code: Select All Code

if (ground.hitTest(_x + _width / 4, _y - _height / 4, true))
        {
            gotoAndPlay("walkleft");
            DIRECTION=-1;
        } // end if
        if (ground.hitTest(_x - _width / 4, _y - _height / 4, true))
        {
           gotoAndPlay("walkright");
            DIRECTION=1;
         }


Okay, problem solved. Now to add the gravity, just use the code also in goomba on-object (same as peach):

Code: Select All Code

 
grav=0;
gravity=1;
//GRAVITY FALLING - This will put Goomba lower, until reaching ground objects
        for (grav = grav + gravity; ground.hitTest(_x, _y, true); grav = 0)
        {
            setProperty("", _y, _y - gravity);
        }


As goombas dont jump, grav doesnt require to change (like '-18', the jumping height). Its zero in the beginning. You dont need to even understand its hole;

The implementation of this code for goomba is in my to-do list.

The color change on Peach's cum was to set it apart from the cum wads from Morton and others. If it's the same color as the male cum, it gets lost in the noise and just looks like Peach herself is cumming like a guy. >_>

Understood! Well, at least for me, it was not a visual problem to let her cum equal to others. On the contrary, it increased sex appeal (you see cum as they're really coming for the genitals). Anyway...why not then changing her color to white-ivory, and the others, a bit browner?

See you, great man, and happy coding Any doubts, I'll be able to help.

Peach can be one of those "few" objects that gets to keep the onClipEvent code. It's the masses of coins, ? boxes, doors, flags, and enemies that could do with code inside.

It's the Blooper that was giving me issues of coding. Up and toward Peach, slowly drop to Peach's level, re-determine where Peach is compared to the Blooper, and repeat. And it ignores all obstacles. I had a fairly simple bunch of statements, but it was much longer than I was willing to work with.

I don't how much browner/yellower you'd want to make the cum. <_< I'll be sticking with the blue, though.

Some one asked for a sling bikini for the frog power-up,which is why I went with it. I doubted getting Misty's suspenders on her outfit, but that managed to turned out differently.

Here's the .FLA including all the fixes I've made. It also has a few irrelevant test outfits and character I made to see how the new part system worked. I don't expect any of them to be used, except for maybe one of them. I did notice while making one that the vest and skirt parts switch layers between standing and moving, which could be a problem if some one makes an outfit with a skirt.

http://www.mediafire.com/?84n4x89ppdfr79h

this is the only post that has ever disappointed me here that's a zip files with like 100mb of things and no swf or fla.... but it says fla... i'm gonna cry now

I think you have the wrong link. The file is only 13.9 MB (you can see it on the MediaFire page), it's not a ZIP file, and the FLA opens fine in CS4. It's not something you can open in Flash Player.

[Blargh]

Slow week this time. >_>

New this update:
- Minor re-positioning of Blooper scenes and adjusted the start of the Blooper anal scene
- Added a few signs of life to the Bloopers as they move around
* There's no do-over option for the Bloopers anymore, they don't restart. Instead, I've just added a bunch more to the underwater area (6 in total so far).
- Added Peach orgasm to the second and third Blooper scenes.
- Added fourth Blooper scene.
- Adjusted skirt layering on the moving animation.
PS: This update's FLA is here: http://www.mediafire.com/?4b6lkso7a5n46av.

I still haven't figured out why the focus zoom on the Bloopers isn't working. -_-

[gako84]

Hi, I'm new to the board and I'm trying to figure out a few things about the MiM.

1. What's that FLA file that comes within the ZIP file?
2. Where's the underwater area I've been reading about in the game?
3. Bloopers? I don't see an option for this anywhere.


Any help would be appreciated. And keep up the great work on the game.

[sean649]

Hello everybody! I have a subjection for the underwater level. Why don't make a kind of (boss) blooper, you know, like in super Mario sunshine. The giant blooper that have many tentacles. A tentacle monster I think that's would be great, to add one of the most popular Japanese fetish in your game... And sorry for my bad English. My first language is French. ^^

[GoeyKick]

I still think it'd be really awesome if you could recolour the peach dress to look like Daisy's and Rosalines respectively, so it looks right playing as them. As opposed to walking around in Peach's Dress. :3 Other than that there is never anythign wrong with any update.

[Hip0krit]

Great work on this game however i found a bug where if you kump to much underwater against the ceiling you shoot out and because the pipes dont work you cant get back into the normal area with refreshing the game.
Keep up the good work though.

[Niskala]

Do you think you could either fix the Continue button or add a gallery for the Bloopers? It's getting pretty tedious to keep playing the entire game just to check out their progress.
Thanks.

[Blargh]

Hi, I'm new to the board and I'm trying to figure out a few things about the MiM.

1. What's that FLA file that comes within the ZIP file?
2. Where's the underwater area I've been reading about in the game?
3. Bloopers? I don't see an option for this anywhere.


Any help would be appreciated. And keep up the great work on the game.

The FLA is the game's source, so it's a file for developers to use with Flash Creative Suite 5 (or later) so that they can modify the game.

After beating Morton and leaving the castle, there is a new pipe in the Mushroom Kingdom area near the burn mushroom. You can also jump in where the two Bloopers are jumping out of the water in the hole next to the mid-level flag to find the underwater area. The only exit for now is a pipe in the ceiling, and the area's pretty empty too. >_>

Hello everybody! I have a subjection for the underwater level. Why don't make a kind of (boss) blooper, you know, like in super Mario sunshine. The giant blooper that have many tentacles. A tentacle monster I think that's would be great, to add one of the most popular Japanese fetish in your game... And sorry for my bad English. My first language is French. ^^

Special area bosses are planned, but it'll be a long time before they ever get implemented.

I still think it'd be really awesome if you could recolour the peach dress to look like Daisy's and Rosalines respectively, so it looks right playing as them. As opposed to walking around in Peach's Dress. :3 Other than that there is never anythign wrong with any update.

Well, Daisy's and Rosalina's dresses aren't the same design as Peach's, so they wouldn't exactly look right just as re-colors. When their dresses have been designed, they'd be added as a separate costume option so that you can always set their dress specifically for them, or have Peach wearing them as revenge for them being forced into her dress all the time. <_<

[Destrocto]

Blargh I'm still getting a glitch since you reformatted the screen size you cannot see morton at all like it won't scroll to him I just get stuck right before that I can engage the scene etc. but you can't ever see it anymore.. Thought someone else might have pointed this out earlier but I guess not.

[Destrocto]

Also theres a yellow hand glitch if you get the frog mushroom and have sex there but then leave and change your costume, it happens when you fuck a goomba after that.