Just posting to mention that this exact issue has been happening to my own script lately. At a point where a script is supposed to run, the game instead freezes and I have to tab out and force close it. This only seems to happen sometimes, however. During one run, I can execute the script and it runs, then when I execute it again it might just freeze up. Sometimes it happens the first time. I don't understand what's causing it because the hpl.log does not finish printing so it shows no errors.
I think the problem I have is the same as what you have here. I think it must be somewhere within the script that causes the game to freeze, but I really don't know what is causing it. There doesn't seem to be a specific problem.
The problem was indeed an infinite loop. Due to a problem with both the if-statement and the contents of it in the function Amn pointed out, it caused a loop that never ended, ultimately being too much for the engine to handle.
In my case, I solved it by implementing a new way of searching for areas that hadn't already been shooting steam. I did this like this:
void RunSteamFlow(int alEventCount){ int iSteamArea = RandInt(1, 6); int RunCount = alEventCount;
if(GetLocalVarInt("iBlockedSteamArea_"+iSteamArea) == 1){ if(iSteamArea < 6 && GetLocalVarInt("SteamFlowCountDirection") == 0){ //SteamFlowCountDirection determines whether to add or subtract from the number that has already been used in SteamEvent();. 0 = Add, 1 = Subtract. SetLocalVarInt("iSteamAreaRecount", iSteamArea + 1); //Add 1 to the integer to search for an unoccupied number. RunSteamFlow(RunCount); //Run the function again to keep searching for numbers until a useable one is found. } else{ SetLocalVarInt("SteamFlowCountDirection", 1); //Changes the SteamFlowCountDirection so the number being manipulated is being subtracted from instead. SetLocalVarInt("iSteamAreaRecount", iSteamArea - 1); //Subtract 1 from the integer to search for an unoccupied number. RunSteamFlow(RunCount); //Run the function again to keep searching for numbers until a useable one is found. }
Well, my script is rather short with big intention. It's also very specific to the entities I've made so it might be difficult for me to explain, but I'll give it a go. It's only about half way done at the moment though, but I can't finish it before I fix this issue. Prepare yourself for a long explanation! :O
I'm making a puzzle that requires the player to find small slates represeting paths. Here's an example of how a horizontal slate looks like:
Spoiler below!
This entity also has a body with the name of "west_east" This comes in play later.
I also have slates representing vertical paths, turns and combinations. The body names of all these include the directions they face: "north_south" "south_east" "north_west_south" are examples.
These slates can be placed with sticky areas into the slots of a big frame in the floor. This frame has 5x5 slots with a few built-in slates that can't be moved. It looks like this (the empty slots have the Ankh symbol):
Spoiler below!
This frame is also located inside a maze of sorts. The map consists of 5x5 rooms with doors in between them. The setup for this whole room is like this:
Spoiler below!
This system works in the way that each room has their own co-ordinate. The room in the middle is named x3y3. This is also the room with the cross slate as well as where the big frame is located.
The idea is to place a slate in the slot next to another used slot in order to open the door in between the represented rooms, as long as the slates connect with each other. For example placing the horizontal slate in x4y3 will open the door connecting room x3y3 and room x4y3. The naming system I'm using for the doors (they are MoveObjects btw) is "move_room1_room2. The door mentioned above is named "move_x3y3_x4y3" This is the best system I could come up with to make it organized. The first room is always the north or west room, the second room is always the south (if first is north) or east (if first is west).
The remaining things to mention within the map are just the different slates as well as the sticky areas. The slates do not use any naming system other than the body names mentioned way up, but they all include "slate" in their name. The sticky areas are named "area_co-ord" similar to the doors, except they only have 1 co-ord for the room and not the 2 connecting rooms. These areas accept entities with "slate" in their name to connect with. Upon connecting, they call the script function "AttachSlate."
So far in the script, I have not implemented the connecting slates part. So far it only opens a door leading to the room represented by the area the slate was placed in. This is where the problem occurs. Only sometimes, the game freezes up, just like what happened to you, the moment the slate connects with the area. I'm unsure why this happens. It seems to work fine with the horizontal slate in all slots (though only on the "west" side). Whenever I take a "north_east" slate, it freezes. It also freezes (randomly) if I enable the script for closing the doors again within a "DetachSlate" function, which is similar to the attach one. I have excluded it because I don't need to close the doors before I can properly open them.
Do you understand what's going on here? Any ideas?
(03-14-2014, 02:59 PM)Mudbill Wrote: Do you understand what's going on here? Any ideas?
After going through it really briefly, your script looks fine to me. However, while trying it in my head, I noticed that sometimes a co-ordinate will result in containing a zero in one of it's numbers. Like this:
This isn't what's causing your crashes, but it's a bug (unless I'm too tired and sick to be able to think straight), since I'm guessing you don't have a door named like that.
I'll keep looking for a possible cause to your problems and I'll let you know if I find something.
Founder & Legally Accountable Publisher of Red Line Games.
Environment & Gameplay Designer and Scripter. http://moddb.com/mods/in-lucys-eyes
I made some tests of your script and I noticed that there are some problems with --x and --y. Changing them to (x-1) and (y-1) solved the crashing for me. However, ++x and ++y don't seem to make any troubles.
I made some tests of your script and I noticed that there are some problems with --x and --y. Changing them to (x-1) and (y-1) solved the crashing for me. However, ++x and ++y don't seem to make any troubles.
Yes, this is the problem I pointed out. It gives incorrect values sometimes. However this shouldn't cause the game to crash.
Founder & Legally Accountable Publisher of Red Line Games.
Environment & Gameplay Designer and Scripter. http://moddb.com/mods/in-lucys-eyes
Now it is x=0 and the for loop starts at the beginning with that value,
so x is raised to 1 again.
Basically x toggles between 1 and 0 and never reaches the end condition.
Ah, I see. Thank you =)
I'll get to that and see. Yeah, it knew it went to 0 at times, but in the terms of doors, that didn't seem to cause any problems so I just left it there. It just makes the script ignore the execution rather than crashing.
This x and y thing I really need to fix though. The point is of course to have them work together in the loop, but I can make an alternative variable to separate them.
Thanks again for pointing this out <3
Yeah, the issue seem to be fixed if I change it like this:
Search
Member List
IRC
Help
Script Crashes The Game
![[Image: expl_slate.png]](https://dl.dropbox.com/s/xk2vmkmsz7tbplm/expl_slate.png)
![[Image: expl_frame.png]](https://dl.dropbox.com/s/8w7z3sdyrtkhcbq/expl_frame.png)
![[Image: fric_sys_ex.png]](https://dl.dropbox.com/s/o2mh6tyg97fp78p/fric_sys_ex.png)
