game-editor.com

1.5 wont have the new interface so before it is released you should make some new and better gedts.

#define statements in script events have problems bein changed. happens in global code to but not as much.

Jagmaster wrote:On a few occasions, after I tested the game a few times, random letters on random bits of text would go haywire. It almost seemed like the letter was cycling through the text like an animation. Eventually Game Editor would crash.
(Click the picture to see what I mean)

Text Glitch2.gif

This happened a while ago, I think the .ged was corrupted. I don't think I still have the .ged, so this probably doesn't help much.

I had the same issue while I was running this in windows XP.

Possible bug report***
It seemed to like 2 of the ones sky mentioned in the first post but a bit different. I think it happened because I had to many variables/actors start with the same name. I try to organize everything starting with what it is (ie text#### friend##### shot####) anyhoo. I ended up clicking script editor on one of them and gE froze on me.

After ending gE through task manager I restarted gE. It immediately crashed. I had to go gE's .ini file to delete the reference to the undo file. Anyway... when I opened up my hour old version the bug still persisted. If I tried to make any changes gE would crash. By some miracle I decided to save it as a different file. That seemed to fix it and so far (30 mins) I have not had a problem. I deleted all the recent actors and variables and now I am starting to redo everything. Kinda scary!

This thread is great! I think the bugs I hate the most are the script editor bugs.

If I use the list of functions in the editor to insert a function that's somewhat long(like a music or createactor), if I try to put a close brace there at the end the editor starts scrolling to the right. And everything you try to type keeps pushing it right. I have to just save it unfinished and go back to edit it. The reason I put a brace there is because of the error below, it somewhat gets around it if I do that then move the brace to a newline.

I come from a javascript background, so I prefer typing braces like this:

Code: Select all

if(something == true){
    //stuff
}

But when I try to type the closing brace, it flies up to match the one above, like this:

Code: Select all

if(something == true){
    //stuff
                     }

and I have to backspace it all the way to the beginning of the line.

Lastly, I don't know if it's a bug but does anyone else find it stupid how if there is an error it references a line number yet there aren't line numbers in the editor. I've had to count down to line 86 before lol. Also sometimes the editor will come up with an error but it'll say it occurs on line 2256! I've seen it even go to line 6043 before. Don't understand what causes that but it's annoying cause how am I supposed to find the bug then.

ikarus the brackets moving to match each other is not a bug, its actually good practice to have your opening and closing brackets at the same level like that, it makes it easy to read through your code
something like this

Code: Select all

If(brackets == same)
{
      Then its easier to read
}


Is easier to read through that

Code: Select all

If(brackets != same){
its a ruddy nightmare
     }


although it seems picky when your just dealing with one if statement or some loop when you have lots of loops and selection statements inside each other its a lot nicer

Yeah but you see that kind of style is very dangerous to do in javascript. So for about 4 years the style I'm trying to do is all I've read, besides some python and lisp which don't count. Reading them on the same indention is a lot harder for me to do and doesn't look as clear to me, and doing it like that is very tedious. But it's all cool, the main thing is the scrolling to the right which is weird and mostly gets in my way more than the auto brace thing.

Another Bug: I noticed along with animations not showing up after 4 rows, Actors won't show up on the actor list after 3 rows.

A quick update on my last post. The cause could have been that I was saving directly to my dropbox folder and and it was trying to sync/save/overwrite at the same time maybe? Who knows. But I got passed it woohoo!

ikarus, there are line numbers. The top right of the script editor has Ln #, # being the line you are on. Keep any and all bugs coming, I'll start adding them to the tracker again.

skydereign wrote:ikarus, there are line numbers. The top right of the script editor has Ln #, # being the line you are on. Keep any and all bugs coming, I'll start adding them to the tracker again.

HOLY MOTHER OF CHRIST! There is! How have I spent a whole month working in ge everyday and never see it!
Oh man... all that time counting lines...

I have a bug to report.

I had an actor who had a collision > physical response action with another actor. I set the values to

80
1
1
1

and the event actor wouldn't bounce against the other actor because I set the first value so high. But, if I made any changes to the game, whether related to the collision or not, and I went to game mode, it would start bouncing. However, if I pressed ctrl + z (undo) before entering game mode, it wouldn't bounce. I have no idea what I was undoing, because I made no changes to the physical response. If ever I made an edit to the game at all, I would have to press ctrl + z at least once before going to game mode.

Bug: I have a ridiculously long sprintf line, and when I "commented it out" GE crashed. The line contained lots of \n and %i pointers as well.

Edit: the line was pretty close to the 255 char limit I think. The last part of the text got cut off, so I reduced some of the chars.

Edit 2: I think the crash is a problem with commenting a line of code that doesn't fit the window.

Yeah, that bug has been reported somewhere on this, but I don't think a concrete (isolated) example has been put up. Thanks for the observations, I can upload an example to the ticket now. Though it isn't if it doesn't fit on the line, I think over 130 or so might be accurate though.

That rarely happens to me, lines can be incredibly long. But I also have 8GB of page filing so I have enough memory to handle it. Perhaps it's a memory issue?
Just so you know, page filling is a system that sets to use hard drive space when you don't have enough memory. The default is like 1024mb I think.