Little Fighter Empire - Forums
BG-Dependent actions - Printable Version

+- Little Fighter Empire - Forums (https://lf-empire.de/forum)
+-- Forum: Little Fighter 2 Zone (https://lf-empire.de/forum/forumdisplay.php?fid=7)
+--- Forum: Data Changing (https://lf-empire.de/forum/forumdisplay.php?fid=11)
+---- Forum: Advanced Data Changing (https://lf-empire.de/forum/forumdisplay.php?fid=13)
+---- Thread: BG-Dependent actions (/showthread.php?tid=1703)

BG-Dependent actions - Silverthorn - 12-13-2008

CAUTION, long essay! Not recommended for people that don't like texts over 1300 words!

You might have seen my latest project called "Sky High". In there, I'm using a method to spawn certain objects. Well great, spawning objects in general is easy, just add a file in data.txt with an id between 100 and 199, and it'll drop from the sky.

But now we get to the neat things: bg-dependent spawning. You must know about the characteristics of a bg. There are just a few things that make backgrounds totally different from each other, and these are:
  • The images (no way!)
  • The name (didn't think of it? Oh well, me neither =P)
  • The width
  • The zwidth
We don't care about the first two points, as they're just ridiculous and not contributing in any way. The other two, however, open a whole option of possibilities. Let's get to the width-part....

CAUTION! This method is only recommended if your background is the largest in the game, otherwise the DC-code get a little nasty :P

A weapon will drop, like regularly. But instead of being pickable, it'll act as a zero-placer. This means the following:
  • The weapon will move with a constant speed (for example dvx: 10) towards one direction
  • Every frame, the weapon will create a type-3-object (set the wait to something like 3 or 4 to prevent a crash because of too many objects)
  • Four frames are essential for that type-3-object:
    Code:
    <frame> 50 destroy_other pic: 999 state: 3005 wait: 4 next: 51 dvx: 0 dvy: 0 dvz: 0 centerx: 50 centery: 50 hit_a: 0 hit_d: 0 hit_j: 0 bdy: kind: 0 x: 0 y: 4500 w: 100 h: 50 bdy_end: <frame_end>
    Code:
    <frame> 51 being_destroyed pic: 999 state: 3005 wait: 4 next: 52 dvx: 0 dvy: 0 dvz: 0 centerx: 50 centery: 50 hit_a: 0 hit_d: 0 hit_j: 0 itr: kind: 9 x: 0 y: 4500 w: 59 h: 56 injury: 10 bdefend: 100 vrest: 10 zwidth: 3 itr_end: <frame_end>
    Code:
    <frame> 52 other_side pic: 999 state: 3005 wait: 4 next: 1000 dvx: 0 dvy: 0 dvz: 0 centerx: 50 centery: 50 hit_a: 0 hit_d: 0 hit_j: 0 opoint: kind: 1 x: -(BGwidth - 50) y: 50 action: (dummy-frame) dvx: 0 oid: (weapon-file) facing: 0 opoint_end: <frame_end>
    Code:
    <frame> 40 disappear pic: 999 state: 3005 wait: 1 next: 1000 dvx: 0 dvy: 0 dvz: 0 centerx: 50 centery: 50 hit_a: 0 hit_d: 0 hit_j: 0 <frame_end>
    Basically, what this does: as long as the weapon is on the bg (as soon as the weapon trespasses the boundaries, it'll disappear), it'll spawn objects, which will always kill each other (itr:/k: 9 goes to frame 40 as soon as it is being "hit" by a bdy). When the weapon finally goes over the border, the last object that has been spawned will go through all these frames. It'll remove the pre-last object, and then go to the next frame. What a wonder, there's nothing left to make this object disappear! So, it's gonna go to the next frame where it'll spawn the weapon again. If the background is smaller than you specified, the weapon won't come into existence. If it is that BG, the weapon will appear. There, it'll opoint your special attack.

    Note that, depending on your bg-size, this method might take some time. So, if you F8, it won't directly do what you want. Just wait.... =P

    Boom, done with part one :D

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

And here comes the "better" method :D
Remember the other thing I was talking about? Yes, the zwidth. Each background has a unique zwidth. If you want to apply this method to your bg, use a characteristic zwidth. It's actually quite unimportant where the two boundaries are, what we need is the distance between them. For example: "zboundary: 393 502" has an effective area of 109. We're gonna abuse that Twisted
By the way, the first one that I know of who has used this method was Jerry Hawk in his JW LF2-mod. But I think he never revealed it to public. Time to change this :D
MH and I talked about this thing for quite a while - credits go to him for giving the final hint ;)
Implementing, testing, and tutorial-writing (which, according to its length, is quite a good job) is done by me^^

We still need our spawning-weapon, its sole purpose is to fall from the sky and opoint a type-3-object. Since I like type 2 because it has quite few default frames, I used it. The important frames are these:
Code:
<frame> 20 on_ground pic: 999 state: 2004 wait: 2 next: 22 dvx: 0 dvy: 0 centerx: 29 centery: 56 <frame_end> <frame> 22 on_ground pic: 999 state: 2004 wait: 1 next: 1000 dvx: 0 dvy: 0 centerx: 29 centery: 56 opoint: kind: 1 x: 29 y: 56 dvx: 0 action: 50 oid: 171 facing: 0 opoint_end: <frame_end>
action: 50 is the start of my type-3-object. This time, the type-3-object will check for the right bg. oid: 171 is... well, guess... that specified type-3-object.

Now, in the type-3-object, we're checking if we have the right background. How are we gonna do this? Easy, just do the following steps:
  • duplicate the created object.
  • make one object go up (back into the screen) and the other go down
  • now, let them approach each other
  • bdy and itr/k:9 will take care of the rest

Basic knowledge: "hit_j" in type-3-objects works as a z-moving tag. numbers higher than 50 will move your object to the front, lower than 50 to the back. 50 = 0; no movement.

Example:
Code:
<frame> 50 Start pic: 999 state: 3005 wait: 0 next: 51 dvx: 0 dvy: 550 centerx: 29 centery: 56 <frame_end> <frame> 51 Start pic: 999 state: 3005 wait: 1 next: 52 dvx: 0 dvy: 550 centerx: 29 centery: 56 opoint: kind: 1 x: 29 y: 56 action: 55 dvx: 0 dvy: 0 oid: 171 facing: 10 opoint_end: <frame_end> <frame> 52 front pic: 999 state: 3005 wait: 4 next: 53 dvx: 0 dvy: 550 centerx: 29 centery: 56 hit_j: 99 # => 109 <frame_end> <frame> 53 front-backwards pic: 999 state: 3005 wait: 3 next: 54 dvx: 0 dvy: 550 centerx: 29 centery: 56 hit_j: 40 # => 69 <frame_end> <frame> 54 front-backwards pic: 999 state: 3005 wait: 30 next: 1000 dvx: 0 dvy: 550 dvz: 550 centerx: 29 centery: 56 itr: kind: 9 x: 0 y: 4500 w: 59 h: 56 injury: 10 bdefend: 100 vrest: 10 zwidth: 3 itr_end: <frame_end> <frame> 55 back pic: 999 state: 3005 wait: 4 next: 56 dvx: 0 dvy: 550 centerx: 29 centery: 56 hit_j: 1 # => 0 <frame_end> <frame> 56 back-fowards pic: 999 state: 3005 wait: 4 next: 57 dvx: 0 dvy: 550 centerx: 29 centery: 56 hit_j: 62 # => 60 <frame_end> <frame> 57 back-fowards pic: 999 state: 3005 wait: 0 next: 58 dvx: 0 dvy: 550 centerx: 29 centery: 56 hit_j: 61 # => 69 <frame_end> <frame> 58 back-fowards pic: 999 state: 3005 wait: 30 next: 1000 dvx: 0 dvy: 550 dvz: 550 centerx: 29 centery: 56 bdy: kind: 0 x: 0 y: 4500 w: 59 h: 56 bdy_end: <frame_end>
One object is moving to the front, the other is moving to the back. From there, these two are moving towards each other. The numbers behind the "#" shall represent the z-pixel that is getting approached to in the specific frame.

When these two are overlapping, the bdy-object will be removed due to its next-value, the other one will go to frame 40:
Code:
<frame> 40 tadah pic: 999 state: 3005 wait: 1 next: 41 dvx: 0 dvy: 550 centerx: 29 centery: 56 <frame_end> <frame> 41 tadah pic: 999 state: 3005 wait: 1 next: 1000 dvx: 0 dvy: 550 centerx: 29 centery: 56 opoint: kind: 1 x: 29 y: 56 action: 60 dvx: 0 dvy: 0 oid: 171 facing: 10 opoint_end: <frame_end>
Another property of itr/k:9 is that the object is losing all its hp. In order to use timers in type: 3, you need these hp. Yes, the timer is reducing the hp of the weapon. And, yes, a weapon has also 500hp. Take it as a fact =P

So yea, basically, you can now do whatever you want. From frame 60 on, you can let out your creativity ;)

Advantages of this method: faster, random x-positions

That's it! I apologize for getting so long but it was simply inevitable for me =P

Finished, and so I just have to say: happy coding :)

RE: BG-Dependent actions - YinYin - 12-13-2008

(12-13-2008, 10:01 PM)Blue Phoenix Wrote:  By the way, the first one that I know of who has used this method was Jerry Hawk in his JW LF2-mod. But I think he never revealed it to public. Time to change this :D
he released the meteor and ion storm bgs with a tuto in the chinese section of the official forum

RE: BG-Dependent actions - snorsorbet - 12-14-2008

It was a good tutorial. Even if I can't code, I understand how it basicly works. A 5 out of 5!

RE: BG-Dependent actions - sadbhav - 12-14-2008

Yeah I like it very much, 4 Thumbs up!!! (2 hands, 2 feet is all that I got)

RE: BG-Dependent actions - MH-Razen - 12-14-2008

oh I just have to post this:

while chating with him blue phoenix told he will eat a broom when this work - well, it worked and I gave him the broom, and he eat it :p

RE: BG-Dependent actions - Silverthorn - 12-14-2008

...

you forgot the most important part.....

[Image: white.jpg]