Menu

Tools Commit Log


Commit Date  
[r60] by SumolX

fixed function drawmpbar(); and usuable of "mpbarsize" variable

2006-08-09 16:58:29 Tree
[r59] by SumolX

fixed if(!pmpUsed[0]) to include a default for when plife is used. Also fixed cheat options to hall of fame bug.

2006-08-09 15:57:25 Tree
[r58] by SumolX

int inputbuffer = 0; previously not assigned during init within function.

2006-08-08 21:51:41 Tree
[r57] by SumolX

updated v48 to v49

2006-08-08 21:47:39 Tree
[r56] by SumolX

Cleaned up some code...

2006-08-08 21:21:19 Tree
[r55] by SumolX

Updated verison number and compatibleversion to 20049. Removed savedata.times_completed variable as it was already saved under the save game files. Update pmp variable to be compatible with videoMode's that are less than 3 or not 4x3 mode.

2006-08-08 18:44:13 Tree
[r54] by SumolX

All of Fugues new features...

Vaulting:
Thanks goes to CGRemakes for helping fix this feature.
Here's how it works: Give all your grabbable enemies a height value. Give a player a non-looping VAULT animation. Instead of putting the offset point at the player's feet, put it at the location you want the player to rotate around. For instance, if you want the player to grab the enemy's shoulders and flip over them, put it where the player's hands are. Also, add a blank frame (one without any graphics in it) with a delay of 1 before the VAULT animation begins.
Now, start up the game and go grab someone. Press jump. The player will play their vault animation, and their offset will be centered on the enemy, at their head level. Once the animation is finished, the player will turn around.
I can see why people have wanted it added. As useless as it seems to flip over someone's head midgrab, it sure is a heck of a lot of fun.
At the moment, all it does is put you behind the opponent. However, adding new moves which are used from the back shouldn't be too hard to do.
The blank frame with a delay of 1 is just there to take care of a bug that we've been unable to fix so far. It's really hard to see the blank frame, even when you look for it, so it shouldn't be a problem.
One more thing- for now, don't try vaulting when next to a wall. Currently, it'll just put the player inside the wall. This will be fixed later.

New attack types:
There are three new attack types: attack2, attack3, and attack4. They work just like shock, burn, and attack. The only difference is that they don't change to the last frame of the normal FALL animation when their FALL animation is finished (shock and burn both do this). These also have custom PAIN, FALL, and DEATH animations, naturally (PAIN2, FALL2, DEATH2, PAIN3, FALL3, etc.).

Attack chains:
You can now pretty much set up your basic attack string in any order you want. If you use the new atchain command, you can specify up to five attacks (Although there are only 4 ATTACK animations right now, more could be added very easily). Just give it five numbers in order. 0 means don't use any attack (i.e. end the attack string), 1 means ATTACK1, 2 means ATTACK2, and I think you can guess the rest.
If you use this, you should fill any unused steps in the combo with 0 (i.e. a 3-hit combo should be something like
atchain 1 2 3 0 0
), although it isn't neccessary.
Enemies can also use ATTACK4 just ATTACK1, ATTACK2, and ATTACK3. Just give it a range.
Unless you're using the new CHARGEATTACK animation, the last attack in a player's attack chain will be used if players hold attack for 3 seconds and let go (even if the last attack isn't ATTACK3).

New jumping animations:
Two new midair animations, JUMPCANT and JUMPSPECIAL.
If you assign an MP cost to a Jumping attack, and attempt to use the attack without enough energy, the JUMPCANT animation will play (If it's there, otherwise, nothing will happen). If the player does have a JUMPCANT animation, they will also start falling, as if they had 'tripped' in midair.
If you press the Special button in midair, you will perform your JUMPSPECIAL (You can also call it SPECIAL3, the engine will read either one). Don't set this to loop. While playing your JUMPSPECIAL animation, your player will not fall down- they hover in midair. They'll still move around if you use move commands, but until the animation ends they will disobey the laws of gravity.

BURNDIE/SHOCKDIE:
You can now have seperate death animations for burning and shocking. They're called "SDIE" and "BDIE."

Charging:
There's now a CHARGE animation. To use it, hold special and press and hold jump (Or press and hold both at the same time). As long as the buttons are held, the player will play their CHARGE animation over and over again, and will quickly recover MP at a specified rate. The recovery increases MP 4 times more often than the normal time-based MP recovery. You can specify the specific rate using the new chargerate command (You can define it seperately for each character. The default is 2).
Oh, by the way, Players can't charge if there are no enemies present. Otherwise they could just max out their energy before every encounter.

BACKWALK:
You can now give enemies a BACKWALK animation. If they have it, they will play it when walking backwards instead of just playing their WALK animation in reverse.
If an enemy is on a different 'z' than the player they're facing, and walk behind the player, they will NOT switch to this animation. They will continue to play their normal WALK animation.

SLEEP:
You can give players a SLEEP animation which will play if the player does not move at all for a while. If set not to loop, players will return to their IDLE animation when it finishes. If you use a FAINT animation as well, this is overridden by FAINT if players are low on life. How long a player will wait before playing this animation is set by the new 'sleepwait' command which can be set seperately for each player. The default is 1000. If you want to get an idea of how long that is in real time, MP will refill under 'typemp 2' every 200.

CHARGEATTACK:
If this animation is present, players will use it instead of the last attack in their atchain when they hold down attack for three seconds and let go.

flipframe:
This is specified exactly like jumpframe, except you use the word 'flipframe' instead, and you only pass in the frame number. When the specified frame is reached, the entity will turn to face the opposite direction automatically. Management is not responsible for damages caused by putting this command in silly places like the WALK animation.

nopain:
Works just like nodrop and nograb. An enemy with this flag will not play any of their PAIN animations when hit- they won't even slow down (unless you're using a hitpause, in which case it doesn't really matter since you slow down as well). This is independant of nodrop and nograb, so you can have any combination of either, neither, or all three set. Try to remember that an enemy with all three of those features will be nearly unstoppable once they begin attacking.

credit:
This can go in an entity's .txt file or in a level spawn. When given to an item, that item will give the player(s) an extra credit when picked up. Like all other item bonuses, only one can be given to an item at a time.

escapehits:
This is for enemies and can be set on a per-enemy basis. All you need to give it is a number. If an enemy is hit this many times in a row without being knocked down or having a chance to counterattack, they will automatically perform their SPECIAL2 animation to counterattack. That'll teach players to spam the first three hits of a combo.
The count will be reset whenever the enemy uses any animation but IDLE, FAINT, or any of the PAIN animations, even if that animation doesn't complete.

mprate:
This affects both methods of MP recovery (by time and by hitting enemies). If typemp is set to 1, this is the amount of MP players will recover on a hit (defaults to 1). If typemp is 2, this is the amount of MP players will recover on regular intervals (defaults to 2). You can give this to each player individually.

itemtrans:
Makes dropped items transparent. This belongs in level spawns. You can use any of the new transparency types.

mpbarsize:
This works exactly like lifebarsize. It just affects the MP bar instead.

p1mp/p2mp:
These commands work like p1life and p2life, except with the MP bar.

trans/alpha:
Setting it to 1 still gives alpha transparency like before, but now you can also use 5 other kinds of transparency! Here they are:

2: The entity will use negative alpha transparency (the darker colors are stronger, like shadows).
3: The entity will overlay transparency. It's described in the engine as being a combination of alpha and negative alpha, and the formula is "bg<128 ? multiply(bg*2,fg) : screen((bg-128)*2,fg)". Try it for youself.
4: The entity will use hardlight transparency. Seems to be the opposite of overlay. The formula is "fg<128 ? multiply(fg*2,bg) : screen((fg-128)*2,bg)".
5: The entity uses dodge transparency. Described in the code as being "Very nice for a colourful boost of light."
6: The entity will use 50% transparency. The entire entity will be 50% transparent: every pixel will be averaged with the pixel right behind it.
Of course, I didn't code these myself. I found the last four transparency types listed, but not used, in one of the support files. So I don't know too much about them, except that they work.
Something else I've noticed probably worth mentioning: remapped entities CANNOT use transparency. In other words, if an entity is displayed in a remap pallete, it WILL NOT use it's alpha setting. This is a limitation of the actual engine, as there are seperate sprite-displaying functions for remapped entities and transparent entities (And only one can be used to display a single entity). Although I'd guess it could be worked around, I don't have any idea where to even start looking.

These go in MODELS.txt:
lifescore/credscore:
lifescore is how many points players must earn to get a 1-up. credscore is how many points are needed for a continue. Set either to 0 to prevent players from getting 1-ups or credits from points.

blockratio:
If this is set, blocking will not completely nullify damage. Entities will still take one fourth of the original damage.

mpblock:
If set, damage taken while guarding is removed from the MP bar instead of the Health bar. If players run out of MP, it's taken from the health bar instead. This obviously doesn't affect enemies, and it doesn't do anything if blockratio isn't set either.

nochipdeath:
Also needs blockratio. With this on, entities can't die from chip damage (damage taken while blocking). They can be reduced to 1 health, but they won't die as long as they succesfully block the attack.

noaircancel:
You may have noticed that, while you're in air, you can interrupt any move by simply using another attack. For instance, you can press attack, then quickly press down+attack and skip any remaining frames in the normal JUMPATTACK animation.
If noaircancel is set to 1, players can't change to another attack while jumping unless the old animation is not set to loop and has finished playing.
If set to 2, players simply can't change to another animation after attacking until they land and jump again.

And these are old features which have been updated:

aggression/risetime:
It's back! Except that it's been divided into two different fields. aggression is a positve or negative integer which will decrease (or increase if it's negative) the amount of time an enemy will pause before launching an attack once players are in range. For the most part it's not a huge difference, and there's still a random element to it, but it's still there. The other part is risetime. It determines how long they'll wait on the ground after FALLing down before they get back up.
The default for both is 0. Positive numbers decrease delays, negative numbers increase delays.

Followups:
Also back! This uses two new commands, 'followcond' and 'followanim.' followanim takes one argument, a number from 0 to 4. If you give it a number greater than 0, it will try to use that FOLLOW animation if the followup conditions are met. Those conditions depend on the followcond command, which takes one argument as well:
1: This animation will followup as long as it hits an entity.
2: This animation will followup as long as it hits an enemy (Or player if an enemy uses it).
3: This animation will followup as long as it hits an enemy and the target does not get killed or block the attack.
4: This animation will followup as long as it hits an enemy, and the target is not killed, does not block the attack, and is not set to be ungrabbable.

Counterframes:
These are also back. They use 'followanim' to determine which animation to play next, but they have a different command to control the conditions ('counterframe'). counterframe takes 3 arguments:
counterframe: The first argument is the number of the frame in which the counterattack is available. The user must be hit in this frame in order to counter.
countercond: The conditions under which the counter will be used:
1: The counter will always be used.
2: The counter will be used as long as the attacker was an enemy (Or a player if an enemy uses it).
3: The counter will be used as long as the attacker was an enemy, the attack was not unblockable, hits the user from the front, and was not a FREEZE attack.
counterdamage: This is a flag which controls damage.
0: The entity which performs the counterattack will not take any damage from the attack.
1: The entity which performs the counterattack will take damage, even if the counterattack is successful.

rock:
The two new rock types are back. Just use 'rock 2' or 'rock 3' instead of 'rock 1' in a stage file to get a different rocking pattern.

Here are examples for followups and counters:
followups:
Let's say you want to make an attack which starts off with a punch. If the punch hits, the player will automatically perform a kick as well. If the punch does not hit, the player will fall down.
This is the punch animation:
anim freespecial1
hitFX data/sounds/pow.wav
# This is the number of the FOLLOW animation to use- in this case, FOLLOW2.
followanim 2
# This controls the conditions under which the followup will be used.
# In this case, as long as the attack hits something, it'll work.
followcond 1
loop 0
delay 7
offset 35 132
frame data/chars/Sol/Punch01.gif
frame data/chars/Sol/Punch02.gif
frame data/chars/Sol/Punch03.gif
# The followup animation will be used if any attack boxes in the animation hit a target
# and the 'followcond' conditions are met.
attack 84 40 24 42 10 0 0 0 15
frame data/chars/Sol/Punch04.gif
# If the previous attack hits, the rest of the animation will not be played.
# It will skip to the first frame of the FOLLOW animation.
# If it doesn't hit, then the rest of the animation will continue instead.
attack 0 0 0 0 0 0 0 0 0
frame data/chars/Sol/Oops01.gif
frame data/chars/Sol/Fall01.gif
frame data/chars/Sol/Fall02.gif
frame data/chars/Sol/Fall03.gif

This is the kick animation:
# You don't really need to do anything special in this animation.
anim follow2
hitFX data/sounds/whap.wav
loop 0
delay 4
offset 28 120
frame data/chars/Sol/Kick01.gif
frame data/chars/Sol/Kick02.gif
frame data/chars/Sol/Kick03.gif
attack 5 64 113 46 12 0 0 0 15
frame data/chars/Sol/Kick04.gif
attack 8 68 101 41 12 0 0 0 15
frame data/chars/Sol/Kick05.gif
attack 0 0 0 0 0 0 0 0 0
delay 10
frame data/chars/Sol/Kick06.gif
frame data/chars/Sol/Kick07.gif

Here's an example for counters:
Now you want an enemy who will sometimes strike a pose. If a player hits him while he's posing, he'll automatically dodge the attack and strike the player.
This is the posing animation:
anim attack1
# This is the follow animation to use if the counter conditions are met. This one goes to FOLLOW3.
followanim 3
# This controls the conditions under which the counter will be used.
# In this case, in order to counter, the enemy must be hit in frame 3
# (remember that the first frame in an animation is considered frame 0!).
# Also, the counter will not be used if the attack was not unblockable
# or freeze-type, and didn't hit him in the back.
# And since the last argument is 0, the enemy won't take any damage
# from the initial attack if the counterattack works.
counterframe 2 1 0
range 0 130
loop 0
delay 60
offset 77 119
bbox 54 35 36 85
frame data/chars/billy/pose01.gif
bbox 52 35 36 85
frame data/chars/billy/pose02.gif
# This is considered frame 2. If an attack hits during this frame,
# the rest of the animation will not be played.
# It will skip to the first frame of the FOLLOW animation.
# If nobody attacks the enemy, then the rest of the animation will continue instead.
# Make sure the user has a bbox in this frame!
bbox 54 35 36 85
frame data/chars/billy/pose03.gif
# From this point on, the enemy will not counterattack even if they get hit.
bbox 52 35 36 85
frame data/chars/billy/pose04.gif
frame data/chars/billy/pose05.gif

This is the dodge and strike:
# Again, you don't really need to do anything special here.
anim follow3
loop 0
delay 3
offset 77 119
bbox 77 35 36 85
attack 16 63 71 42 15 1
frame data/chars/billy/swing03.gif
bbox 75 41 50 80
attack 95 41 111 71 15 1
frame data/chars/billy/swing04.gif
attack 125 38 84 15 15 1
frame data/chars/billy/swing05.gif
attack 99 7 61 45 15 1
frame data/chars/billy/swing06.gif
attack 25 9 86 43 10 0
frame data/chars/billy/swing07.gif
attack 27 14 39 40 6 0
frame data/chars/billy/swing08.gif
frame data/chars/billy/swing09.gif

2006-08-08 18:28:39 Tree
[r53] by SumolX

SDL_HWACCEL added for window/fullscreen modes.

2006-08-07 18:54:02 Tree
[r52] by SumolX

Redone load_levelorder() when using PSP/SDL widescreen to make it easier to add code in for later use. Also temporarly removed for loop for SDL within display_ents(). Possible bug reported. Also removed unnecessary code under add_level() for PSP it was redundant logic.

2006-08-07 00:56:18 Tree
[r51] by SumolX

update old function from fileexists() to fileExists and moved it to util.c

2006-08-06 16:53:37 Tree
Older >
Auth0 Logo