game-editor.com

Oh yes, speaking of annoying script editor bugs, I have a few to report.

Sometimes (I'm not really sure under which conditions, but I'll be more alert next time it happens), the cursor will not be in the correct place, so when you type, it'll be to the wrong column. Closing and opening the script editor fixes this. A much more aggravating bug, specially if you're using bitwise operations, is that the tilde ("~") won't be displayed (It is there, and you can use it as a bitwise operator normally, it just appears as whitespace in the editor), this has been reported before I think. And it's a fairly old bug. x3

I wrote:Bug: I have a ridiculously long sprintf line, Blah......

skydereign wrote:Yeah, that bug has been reported somewhere on this,

Man, I can't seem to find any bugs that aren't reported. I'll have to look at the tracker next time. Sorry for redundant bug posting.

This bug is probably not a huge deal, instead of commenting a line, I can just cut and paste into notepad no problem.

Hey, the more times it is reported, the more we know it is a problem, and should be fixed. I'm of the opinion though that we should try to get any crash bugs fixed. Luckily though whenever it crashes for me, I can reload it, but I hear that isn't the case for everyone.

I've been working off of a USB 1.0 Flash drive so, it's slower and likes to crash more. But, I still work on a flash drive for the sake of portability. The only times crash recovery doesn't work is when I didn't save the document at all, (which is completely logical) or, if the document has crashed already, and then it crashes again without saving. Other times it crashes and doesn't recover and I have no idea why. I'm happy to report any bugs as long as it helps.

I don't know how reproducible this is but when I have an actor that's parented to the view, if I use MoveTo to move it and then set it back to its original place on move finish it kinda wobbles while moving with the view :/

[edit]
say:
y = view.height-30;
on move finish.

tried to reproduce it in another ged but couldn't, but can't imagine it'd be a bug with my code since after it's done moving and resets back, nothing at all modifies its position.

Yeah, I recall something happening like that when I started gE. It was one of the main reasons why I originally avoided MoveTo. Too bad it isn't reproducible, considerably lowers the chance of fixing it.

Ok, so here is a really weird bug I found. It happens to me all the time. When I click add in the script editor, sometimes I accidentally click "wait for immediate action". Of course, the next thing I do is click "cancel" and then click "add" again. But then GE crashes on me and I lose all of my work

Hope that made sense

this was reported more than once, the quick fix around this. After you realized you clicked wait for frame, click cancel, type a line of two of random jiberish, then delete and then add your script, as long as you mess around a bit, it shouldn't crash!

Thanks Gogo

That might work better than clicking "Global Code" and then cancel, for that doesn't work sometimes.

2 bugs dealing with iPhone, so this is probably a geapp problem

1. fopen, fgets, fput, etc. Do not work on iphone
2. Open url does not work on iphone

As I mentioned in your other post, fopen and other file functions worked fine for me when I tested. What version are you using? And, not sure if the fix for open url was ever put into the the geplayer, but I know there was a fix in the xcode geapp project (unless this is a new problem).

Ah im using a really old geapp that someone compiled for me. Ive just been replacing the geapp.dat so i can test my own games

Here's a bug I just ran across:

If canvas is erased with a transparency value of 1, it won't register mouse clicks. Kinda annoying if you are implementing any kind of drawing functions into a game. Canvas does receive input if you have 0.9 as the transp value, but anything much lower than that basically reacts like it does when set to one (.9999, which makes me suspect the values in the function are float and not double).

I'm assuming a similar thing happens with normal actors and collisions if I recall. That is if I recall, transp set to one does not register collisions. I could be wrong, and the solution is already present if that was an issue (Visibility state).

I'm just wondering if these are related. If so, it will probably be harder to fix. Again, the cheap fix is to set the transp value on erase to 0.9. It's barely noticeable, but it still feels cheap to the individual coding /reading the script.

That canvas erase bug is a real problem for me- i was thinking of a way how MULTIPLE actors could move through the dark, carrying their own light source. if it were just one player you would simply slap on an image with an alpha, parented to the player. The only way you can have multiple light circles carried by multiple actors is to have the canvas erase/draw an image (like a shadded version of the game or a simple blackout) and then have a draw function at the location of each actor to erase the blackout around it- (this should let the light circles combine with others- as you would expect it to) The trick would be the need to erase or redraw the blackout/canvas at each step so that the lights remain only around the actors and don't leave draw/light squiggles as they move accross the screen.
I think its the best g.e will get to dynamic lighting but with the bug in place- you can't even mange one frame (if you are using a separate image to represent your 'shadow zones')- i suposse if you are simply darkening the space with an alpha at the surgested 0.99 it will work...)