Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Extremely difficult bugs to fix
#1
I have had a problem with my SSJ Goku since over a year. What happens is that special attacks from either SSJ Goku or other characters I put in the game, get messed up. For exemple: kamehameha data is alright, but sometimes it doesn't hit or the opponent flies backward, or a whole other special move doesn't work the right way, sometimes even other characters get messed up. What I thought is that it'd probably have something to do with the amount of data and sprites that had to be loaded (almost 50 files in total I think). What is the limit?

The character is practically finished and in good quality, too. The only thing that has to be done before I can release it, is that the bugs have to be fixed. It would really be a shame if I couldn't release him, as I put hundreds of hours of work into making him. But I can't get him to work, no matter what! You guys are probably my last hope on this, as I tried about everything. I've tried:
- reducing the amount of .bmp files that have to be loaded;
- moving special moves from one file to another, so there wouldn't be 8 pictures in ssjgoku_kame.dat;
- changing the ID order in data.txt;
- putting the frames in a logical order;
- overwriting an old version with the data from the newer, instable version

However, problems still occur... Any more ideas? Could the huge "flashes.bmp" files cause trouble because of their size, maybe? I don't really feel like rewriting the data completely while the character is basically finished, you know :s But it seems like a last option.


This is the old thread, from over a year ago: http://www.lf-empire.de/forum/showthread.php?tid=8913

The problem stated in that topic was actually the first problem that occured in the character, I think.
Reply
Thanks given by:
#2
Oh Goku! Cool :P. Bugs don't just come up randomly like that. You must be violating some limit or something. Here are all the limitation I know of:
1-399 frames. You can't have a frame number that is more than that.
2-10 BMPs. 1 dat file can only load that amount of BMPs. The number of sprites is irrelevant.
3-10 itrs+bdys per a frame.

One more thing: Are you sure you're loading the sprites correctly? Like you're not mixing the row and the col numbers.
Can we see your .dat file? Better show us on http://pastebin.com/ since I am usually very lazy when it comes to downloading files :P.
[Image: signature.png]
A-Engine: A new beat em up game engine inspired by LF2. Coming soon

A-Engine Dev Blog - Update #8: Timeout

Reply
Thanks given by:
#3
Alright. I never used pastebin before, so I hope this works:

ssjgoku.dat: http://pastebin.com/zss0J0hv
ssjgoku_ball.dat: http://pastebin.com/rGy9AHBk
ssjgoku_down2.dat: http://pastebin.com/z3d6DQa4
ssjgoku_kame.dat: http://pastebin.com/agvYjM4u

I checked the things that you stated, and the max amount of ITRs, BDYs etc per frame is 7. So that shouldn't be the problem.. ssjgoku_kame.dat loads 9 files, so still less than 10 as well.. and there aren't any frames with a number higher that 399.. ssjgoku_kame.dat goes untill 185 or something. I changed those numbers before when I was trying to fix it, but that didn't work
Reply
Thanks given by:
#4
Does the older version of Goku in the original thread have these problems?
Edit: Wait a second.
Edit2: Alright:
1-Found a stray Unicode character at the end of both files: ball_1 and down_2. It can be found at the end of the file. Those might cause issues if the parsing doesn't support Unicode.
2-Hmph.. Checked if you've missed a tag or forgot to close your bdy,itr..etc stuff; None.

Unless the problem is with the DCing itself, this is really really weird. One more thing you might have done is the titles of your frames.
[Image: signature.png]
A-Engine: A new beat em up game engine inspired by LF2. Coming soon

A-Engine Dev Blog - Update #8: Timeout

Reply
Thanks given by:
#5
(07-24-2014, 04:18 PM)A-MAN Wrote:  Oh Goku! Cool :P. Bugs don't just come up randomly like that. You must be violating some limit or something. Here are all the limitation I know of:
1-399 frames. You can't have a frame number that is more than that.
2-10 BMPs. 1 dat file can only load that amount of BMPs. The number of sprites is irrelevant.
3-10 itrs+bdys per a frame.

One more thing: Are you sure you're loading the sprites correctly? Like you're not mixing the row and the col numbers.
Can we see your .dat file? Better show us on http://pastebin.com/ since I am usually very lazy when it comes to downloading fiiles :P

Um, its 5 Itr/bdy not 10, but yeah upload your .dats to paste in so we can have a look ;)
Spoilered Spoilers (Click to View)

You're just dying if you're living and thinking about a betrayal, revive yourself.
Think about that one person that has trusted you forever, not the thousand people that have betrayed you.
Reply
Thanks given by: Memento
#6
pssst, take a look at post #3!
if it really comes down to the number of tags per frame, try to opoint t3 objects for compensation.
(or use my engine huehuehue)
Reply
Thanks given by: A-Man
#7
I read the DC code, can't find any theoretical errors at all, although I must say I've never seen a ball that uses two itrs with different zwidth. All I can suggest are:
1) Add "effect: 0" into the itrs?
2) Does this problem get better or worse if you split the tail into multiple smaller itrs?
3) Split the beam into a front part and a tail part. I know this could cause a beam to hit twice since it becomes two separate objects dealing separate itrs, but I'm sure you could manipulate the dvx/y or even the vrest of the tail in such a way that those two will never meet.

Alternatively for number 3... you could make the ball carry a hidden weapon. This weapon would have an itr that acts as the tail, while the ball itself has only the head itr. I don't know, just mess around a bit.
Reply
Thanks given by: AmadisLFE
#8
I modified some ITRs and BDYs and I removed the stray unicode at the end of the files. Removing the unicode was something I tried before, but it just always showed up again somehow.

SSJ Goku is working fine in my version now, but that still doesn't tell if the errors are really fixed because the errors are kind of diffirent from normal errors. Would anyone like to test my character to see if it's working properly? Having more custom characters in the game would cause trouble with these characters too, sometimes, even when SSJ Goku would seem to be working fine. So it would be best to test them, too..

Here's the link, if you'd like to test him: https://www.mediafire.com/?1sxm8s4gvtear56

Edit: I added him to Bash's LF2 DBZ, and it's not working well yet. So testing isn't required anymore for now..
Reply
Thanks given by:
#9
(07-25-2014, 12:17 AM)STM1993 Wrote:  I read the DC code, can't find any theoretical errors at all, although I must say I've never seen a ball that uses two itrs with different zwidth. All I can suggest are:
1) Add "effect: 0" into the itrs?
2) Does this problem get better or worse if you split the tail into multiple smaller itrs?
3) Split the beam into a front part and a tail part. I know this could cause a beam to hit twice since it becomes two separate objects dealing separate itrs, but I'm sure you could manipulate the dvx/y or even the vrest of the tail in such a way that those two will never meet.

Alternatively for number 3... you could make the ball carry a hidden weapon. This weapon would have an itr that acts as the tail, while the ball itself has only the head itr. I don't know, just mess around a bit.

1) Wouldn't work, the problem isn't in the data itself.. I'm saying this, because everything worked before and when I modify ssjgoku_ball.dat for exemple, problems may suddenly occur with the ssjgoku_kame.dat file or even a file from another character (for exemple: vegito's kamehameha if installed).
2) I tried applying the max 5 ITR/BDY limit, and the problems still occur. More ITRs doesn't change anything either. Again: modifying the data will often give a change in EITHER Goku or another custom character. It just messes with the files in data.txt, opointed files that are effected either don´t show, don´t hit, or both. The thing is, changing the amount of ITRs doesn´t make a diffirence.
3) The beams already have a front part and a tail part. Besides, the problem isn't in the data itself..

I tried all options mentioned before in this topic, any more suggestions on what the problem might be? I still suspect some kind of limitation to be exceeded. I couldn't find the exact numbers on the main site, so if you know a webpage or got something to add, please do..
Reply
Thanks given by:
#10
Curse my C++ registry error, else I'd download and check it out myself.

You mentioned in the old thread that installing it into your modified lf2.exe(that has no exe changes) has no problems, but has issues in default lf2 (2.0a). Have you tried any other .exes including 1.9c and that new one made by the chinese community, or perhaps on a different computer(mine is Windows XP has little RAM, will crash trying to load DR.LF2 and fails to load the giant dialogue sprites in X-LF2)?
Reply
Thanks given by: Memento




Users browsing this thread: 1 Guest(s)