next »

[William Broom]

Well, even if the taser does no damage, we'll still need to eliminate stunlocking since it could be used to stall indefinitely in order to win a 'time' match. So what I might do is give the taser a cooldown time during which you can use other attacks, but not the taser. That's what you did with Turner's knife, right?

And you may well be right about the Av. I'll see what I can do about that.

[shig]

Just make it so that if someone is tased twice they just fly away or fall down instead of getting stunned.

[Soulliard]

Good point, Chutup. Either of the two solutions would work nicely.

(And yes, I gave Turner's dagger a cooldown time, like Nikujin's shuriken. I felt that they should be primarily melee attackers, but I didn't want to make their ranged attacks useless.)

[William Broom]

I finished Trilby!
.gmk: http://www.filedropper.com/brawl59trilby
.exe: http://www.filedropper.com/brawl59trilby_1

Notes:
- His Smoke Bomb (Sv) lets him teleport in any direction he chooses. You are basically aiming an invisible cursor for the duration of your invisibility. He cannot teleport through solid walls though.
- His Av doesn't block, but it has high damage and knockback.
- His Taser does deal a small amount of damage, but it has a cooldown time to prevent stunlocking.
- His A^ is an excellent horizontal recovery, but hopefully it will be balanced by the fact that a) it can't be cancelled until you hit the ground and b) horizontal recovery just isn't as important in IB as it ever was in Smash Bros.
- I wanted to make his grapple feel a little different to Liero's, maybe by making him reel in a little slower, but I honestly couldn't get my head around the grapple code. So Trilby's grapple is pretty much a copy+paste of Liero's.
- I've found that when the enemy is on high HP, Trilby has a nice combo of Taser+Umbrella Swipe+Umbrella Shield. When they're weakened, though, he'll need to skip the Umbrella Swipe or else knock them out of reach. I think it's a cool little detail for highly experienced players to take note of.

[Soulliard]

I like it. Thievery and Smoke Bomb work very well. Trilby should be an interesting character to play. He's got a very tricky fighting style.

[Clemens]

Ha, I'm really looking forward to test this at home. I always like to have sneaky fighters with special abilities who can't rely on brute force.

At this rate, the first thing that's going to be done in IB is all the characters coded! Nice job! But what are you going to do once all twelve are coded?
Should we keep on adding characters? I think it might be advisable to refrain from coding more characters then until we got all the graphics, menus, stages etc. up to the same milestone level.

[Inanimate]

Ha, I'm really looking forward to test this at home. I always like to have sneaky fighters with special abilities who can't rely on brute force.

At this rate, the first thing that's going to be done in IB is all the characters coded! Nice job! But what are you going to do once all twelve are coded?
Should we keep on adding characters? I think it might be advisable to refrain from coding more characters then until we got all the graphics, menus, stages etc. up to the same milestone level.

Well, then all the coders would just be waiting, wouldn't they?

[Clemens]

Yeah, well, that's a valid point I guess, but there's no way the spriters will ever catch up with that speed, so we could go on like this until infinity.
I don't know exactly about technincal difficulties, but wouldn't it be possible for coders to also collaborate on other things than characters, like the main menu, interface, item system, stage programming, etc.?

I know coding characters is probably the most attractive part of developing IB, but I think it would be good to keep things tied up as much as possible...

[Inanimate]

Yeah, well, that's a valid point I guess, but there's no way the spriters will ever catch up with that speed, so we could go on like this until infinity.
I don't know exactly about technincal difficulties, but wouldn't it be possible for coders to also collaborate on other things than characters, like the main menu, interface, item system, stage programming, etc.?

I know coding characters is probably the most attractive part of developing IB, but I think it would be good to keep things tied up as much as possible...

Yes, that is an excellent idea. I was just thinking of the characters, because I have a small mind. Good idea!

[Soulliard]

While there's a relatively easy system in place for adding characters, those other additions mostly require modifying the engine. So I'm in charge of that. I don't have plans to add any characters for a while, now that Chutup seems to have that under control.

I'll try to make items a higher priority, though, since once I have a solid framework built for them, adding new items shouldn't be too difficult.

[William Broom]

By the way, I forgot to explain what sections of the code I changed, which should help you to integrate the character.
- I changed the Character>Step>Action 1 event where it limits their momentum to 24. It now limits their momentum to 'maxvel_x' and 'maxvel_y', which are usually set to 24 - but Trilby's umbrella glide reduces his maxvel_y.
- I changed the 'naija_shield' variable to a more generic 'shield_timeout' so that Trilby could use it too. But in the end he doesn't actually use it because I took out the blocking part of Umbrella Shield.
- In the Character>Create event, it now initializes the values blocked_3 to blocked_10. In Character>Step>Action 1, whenever it sets the next attack it will check if that attack is not currently blocked. Also in Character>Step>Action 2 is some code to make the blocked_x variables act as alarms. So if you want to lock out a certain attack, like with Thievery or Cracking, all you have to do is set the relevant blocked_x variable to a positive number and it will count down from there.
- I changed attack_create and gave it the line 'a.origin_action = current_action'. This is what tells the attack which move it originated from. Likewise, attack_create2 passes origin_action on to the attack that it creates. Then Thievery uses this variable to lock a certain attack. The downside of this is that aerials are counted as the same attack i.e. if Trilby steals Naija's spin kick, he'll also steal her downward Beast Charge.
- This also means that you cant call attack_create before you call attack_start since attack_start sets current_action. I don't believe this puts any limitations on us at all. There was only one attack I had to change to fit this, which was Quote's Booster. With Booster, attack_create and attack_start were in the same block of code, so I simply rearranged them without it having any effect on the attack.
- For the Taser's cooldown, I used the same char_timer mechanism as Nikujin and Turner. So in the code that handles char_timer, it now applies to a char_id of 8 as well as ones of 3 or 4.
- Likewise for the rope code in the step event, it now applies to char_id 8 as well as 7.

I'm pretty sure that's all.

[mokesmoe]

Found a bug!
When a move is restored from being stolen, all their other stolen moves come back at the same time.
Example: I use thievery on Naija's spin kick. When spin kick is about to come back, I steal beast charge. Beast charge then comes back right away, when spin kick does.

[William Broom]

Are you sure? That doesn't seem to happen for me.

[Soulliard]

I can't duplicate it either. 

[mokesmoe]

I have a new theory then.
I steal naija's spin kick, mess up trying to take beast charge, press the buttons wrong so I do spin kick not beast charge, but spin kick is stolen so it does nothing, think I successfully stole beast charge, spin kick comes back, use spin kick, then use beast charge, thinks it's broken cause i'm retarded

Thats what happens when I open my mouth. err... keyboard