Attempting to reload Json files on-the-fly without recompile

My original question has now been changed. Post 4 is my new question.

A way to test this can be as follows:

currentTime = FileSystem.stat("info/convos.json").mtime;
if (currentTime.getTime() > _lastModifiedTime)
     _lastModifiedTime = currentTime.getTime();
     _currentFileState = File.getContent("info/convos.json");
     if (_currentFileState != _previousFileState)
         _state = _currentFileState;
         _previousFileState = _currentFileState;

Okay, after further testing the above code reports the same timestamp, even if you delete the subject file and resave new content to force a change in the timestamp, the timestamp acquired by FileSystem.stat does not seem to report accurate results.

Is this a bug in the Haxe standard library, do you think?

That’s interesting, Developers should have an ability to set which files they think could be updated periodically.

Okay, perhaps I went too far ahead of myself without testing it properly, and realising that I was saving the wrong file…

So now I have a new question, which I may or may not be able to resolve on my own. I am going to place my entire engine onto Github so that you can test these results yourself and play around with it if you wish.

Currently, I have a function which “reloads” conversations.

    public function reloadConvo()
        if (_state.currentConvo > _state.conversations.length - 1 || _state.currentConvo < 0)
        _lastModifiedTime = [];
        for (i in 0..._state.conversations.length + 1)
        if (_convo == null)
            _convo = new Conversation(getConvoFile(), _parser, _interp);
            if (_previousConvoId != _state.currentConvo)
                _convo.startConvo(getConvoFile(), _state.currentPassage);
        _previousConvoId = _state.currentConvo;

With the above code, this is how a conversation reloads “on-the-fly” without needing to recompile.

However, when modifying the file, the length is reported as inaccessible by Neko straight after setting the _state.

If you wish to test this, the project can be found here. I haven’t upgraded OpenFL (v 3.4) in a while, so results may differ slightly in unprecedented scenarios.

EDIT: I actually forgot to parse the new results, which was causing the issue.