Page 1 of 1
[FIXED 0.78.0] Jump Pad Bug.
Posted: Fri Aug 28, 2009 6:46 am
by Digitalboy
Hey guys.i was trying out the rf demo and i encountered a bug.
In the demo level with the mask guy(defaultname:daniel) there is a jump pad.i stood over it and and it threw me up.i waited and gravity pulled me down again and i went into the ground under the jump pad!any idea why is this happening?
(i know.Horrible explanation!)
Re: Jump Pad Bug.
Posted: Fri Aug 28, 2009 6:23 pm
by darksmaster923
Wait, so what happened?
Re: Jump Pad Bug.
Posted: Fri Aug 28, 2009 6:27 pm
by Digitalboy
?? then i was stuck underground and had to reset the level..doesnt it consider as a bug?
Here is a pic:
Re: Jump Pad Bug.
Posted: Fri Aug 28, 2009 6:53 pm
by darksmaster923
Restart the app and see if it still happens
Re: Jump Pad Bug.
Posted: Fri Aug 28, 2009 7:07 pm
by Digitalboy
it is still there.
Changing video setup,restarting comp,reinstalling RF -all no use.
its not really a super critical bug or something.but i think it should be fixed
Re: Jump Pad Bug.
Posted: Sat Aug 29, 2009 2:54 am
by darksmaster923
I'm not really sure why that's happening. Try landing on a platform or something
Re: Jump Pad Bug.
Posted: Sat Aug 29, 2009 3:14 am
by Digitalboy
landing on the platform above is working fine.the bug only occurs if i land on the jump pad.
Re: Jump Pad Bug.
Posted: Sat Aug 29, 2009 6:59 am
by darksmaster923
I honestly have no idea why it does that, maybe someone else can help
Re: Jump Pad Bug.
Posted: Sun Sep 04, 2011 7:41 pm
by QuestOfDreams
Fixing collision bugs is always a painful task ... Finally tracked down this one.
Code: Select all
--- CModelManager.cpp rev 201
+++ CModelManager.cpp working copy
@@ -1936,2 +1936,2 @@
- if(EmptyContent(pMod->theModel))
+ if(EmptyContent(pMod->theModel) == RGF_SUCCESS)
return RGF_EMPTY;
Re: [FIXED 0.78.0] Jump Pad Bug.
Posted: Wed Sep 07, 2011 7:44 pm
by Jay
Was just passing by and had to comment... This bug was thanks to the antique way of code the RF source is written in... (basically c style - if something goes wrong you pass the user of your function an error number and let them handle it)... thus demanding that we always test for RGF_SUCCESS... (since there rarely ever are any boolean functions)... which can easily lead to mistakes being made while programming because you didn't test for RGF_SUCCESS.
The problem arises because every nonzero number gets converted to true... and that means that any error code you give will translate to "success" in the if statement...
Exceptions or even inside-function-error-handling would be better. However, it is not worth rewriting RF for this. Heck, no.
I guess this style stems from the Genesis engine being written in pure C. (Also, i don't know how people programmed when RF was written... might be just an "old way" of programming things)