FSM Editor 1.2.1 bug?

There is a nasty memory limit for each code block per state. The FSM Editor (v.1.2.1) can handle such an overflow and will save everything, it will also run fine in the game itself (so this is clearly a limitation of the editor only), but: the FSM Editor will not be able to load such a file with too much code in a single state's code block (init) again, probably because the fsm decompiler is limited for some reason or not enough memory gets allocated... so the editor refuses to read any further at some point.

See these test fms, add one more line to the init block of the start-state and bang, the FSM Editor won't be able to open them anymore:

• fsm blocklength test 1
  
• fsm blocklength test 2
  

The good news is, that it's easy to circumvent this bug, by simply distributing "too much" code over more states, and linking them up with a link without any condition.

---

Full text (initial text including some confusion)

I ran into a weird problem with the FSM Editor 1.2.1 from BIS and could need some advice here.

Last time editing the troublemaking fsm, everything was fine and it ran in game with no problems whatsoever. So I come back today to this fsm file, load it with the FSM Editor only to find an empty page. That's right, FSM Editor refused to load the fsm, no states, not even an init state, nothing. I haven't touched the file outside the FSM Editor, so I'm sure that it wasn't me who screwed the file up..

I checked the file against the latest working backup file, but couldn't spot anything. So I made a copy to play with, deleting specific parts of the fsm and I pretty soon found the culprit. It was the init-block that is causing the trouble. Starting with an empty init-block, the fsm loaded just fine - everything else was there. So I started to copy back in the init-block, code block for code block, up until the editor again wasn't able to load it.

Up to here I was expecting some trouble-making line of code or something, that messed up the editor or its (de-)compiler. Well, that's probably not the case. It turns out that at some point, the editor stops reading the init-block, and then it's luck if it will be able to load anything or just chop of the init-block. If he manages to load the init-block, the last code-block (which is a function) is chopped of. If I finish this code-block inside the editor and save, I'm back to my problems and the file won't load again...

For example, take a look at this, which is the end of the init-block that the editor managed to read:

_runToNext = {
//[...]

// overwrite waypoint
[
	["group", _group],
	["type", "MOVE"],
	["position", _currentMoveTo],
	["behaviour", "AWARE"],
	["combatMode", "YELLOW"],
	[

:936: ... it simply stops "reading" or interpreting any further. If I delete code above this point, it stops later in the code or doesn't manage to load the fsm at all.

Why? Is there a limit? A maximum states code block length or something? Or is this just a bug with the FSM Editor, some kind of buffer overflow or what not? And if so, what are the chances that this gets fixed?

If you wanna have a look at the fsm in question, here is a modified copy that currently loads in the FSM Editor, but doesn't read the full init-block (start state). The last line it manages to read is line 683 (viewed from a text editor). Try to delete the for-loop (line 673-681) and it will end up in the state described above, delete the line 682 too and it won't manage to load anyhting at all... :936:

Ok, I guess I could stop defining all these private functions in the init's code-block and put them somewhere else. But still, this is a bug, no?

--

EDIT:

ok, this seems to be really some kind of buffer/memory overflow in the FSM Editor itself.

Here are two more fsm, this time minimal to better demonstrate the problem:

• fsm blocklength test 1
  
• fsm blocklength test 2
  

The init code block is made up of lines defining variables. The test was to look how many lines the FSM editor can take, before it can't open the files anymore. These two test fsm's in the current state may be still opened by the FSM editor, but add one single line more and it will fail.

The first test is made up with lines like:

      "_var783 = 2126;" \n

while the second test has lines like this:

      "_var483 = ""78161118-1573"";" \n

with roughly double the amount of characters than the first test - guess the escape character doesn't count. Now since the first test manages to read up to _var783, while the second test manages approx. only half as much, it's pretty clear that there is some sort of memory-limit (try adding one more line). And this probably per each states code block.

The good news is that this is only a problem with the editor, you may overflow this block, the editor will save everything and the game will execute that fsm without any problems, but if you try to load that fsm again in the editor, you're out of luck.

So maybe this bug could be fixed, for it's quite a nasty one. Or is there a reason the editor isn't allowed to use more memory?

some more FSM Editor suggestions

And if someone really is gonna touch the editor's code, maybe there is time to improve the editor slightly in other areas:

• Please let us allow to set our own fontsize (maybe even the font itself) and tab-size for the included text-editor. Yes, using an external editor is possible, but it isn't really a nice workflow that way.
  
• Please - for the love of god - on refocus of the window, please do not scroll the included text-editor back to the top. This is so annoying. Every time you focus another programm (the browser or even another instance of the FSM editor) and switch back, you can scroll down again, back to where you've left... grrrr
  

Otherwise it's really a nice piece of software to use.

Great work ruebe!

You must have spent a lot of time to find the reason....

I second this. There is nothing more frustrating than doing all that work and then coming back to tweak something and not being able to use the editor... it takes so much time to work around it.

I also agree with the scrolling to the top of the code when you save or alt-tab out. Also... it would be nice to be able to ctrl-f and ctrl-h... along with storing more undo's in memory.. I like to use ctr-z... a lot.

please BIS, update the FSM editor!!