Search options (Page 3 of 18)

I had a quick attempt at this last night, but it occurred to me that any solution is going to be difficult and seem pretty hacked in. There is no real concept of a lua environment that I can add to because the lua_State gets cleared when you start a new scene. In the MScriptableBehaviour component I have sort of worked around this by (re)loading the relevant behaviour script whenever a behaviour of that type is created, which obviously has a number of issues.

I have come up with the following possible solutions:

1. Create an event system that you can subscribe to, so if you get an event of MEventScriptEnvironmentInit then you know to load the scripts at the right time
2. Be able to add to the environment by cacheing the scripts. This is probably the easiest solution, but would require to keep a local copy of all environment scripts in memory, or to write them to temporary files...
3. Use something like lua rings, which will allow multiple states to be active, so we could pretty much have the event system in lua, and the master (environment) state could set up a recreated slave (game) state.

Unfortunately, my "ideal" solution of having a clean environment state that we clone doesn't seem like an option, I haven't found any way of cloning a state (yet)

Thank you.

With regard to the embedded script stuff. What should you like to do? The easiest solution is to allow parsing of a lua string passed to MScript, but that technically could break the abstraction as it requires that MScript always deals with lua, and couldn't be extended to support other languages later. Personally I quite like the idea of allowing embedded files because it then lets us package small amounts of assets with plugins automatically

Update to github branch
1. Removed MSaveFile
2. Added more output on plugin load failure
3. Added MResource interface

Updates to MSaveFile
1. Added binary file support
2. Moved from Maratis to plugin
3. Implemented MResource interface
4. Lua integration
TODO for MSaveFile:
1. Unit tests
2. Extended lua integration
3. Hierarchical binary files

The lua integration is very straightforward, but I would also want to make a more "OOP-like" interface if possible. However without significantly extending MScript to allow exposing classes with something like luabind. The easier way to do it would be to do it in lua, but that would require either giving MScript a string of a lua "file" to load, or to extend the Maratis filesystem to allow named embedded files to be opened by M_fopen. So yes, still some work to do.

XML files are currently saved by breaking down a key such as "some.random.key" into hierarchical elements, but the binary files are saved with entirely flat paths, which I'd like to change, and that would mean I'd probably need to add file versioning also.

That's all for now

Edit: Updated to have a very basic lua interface

I think there needs to be a further discussion then before MSaveFile is accepted into the official repository. If you don't see it as a core engine component, then it shouldn't be added. I think it would be a useful thing to have it available for Maratis as standard in some form, so I think we should try to find an agreeable solution. The options I think are:

1. Build it into Maratis/MSDK. The benefits here are that it's easy to integrate with lua, it's available both for game code and editor variables, and also, it's already done. The issues with it are that it is an enforced component in all projects, whether you need it or not.

2. Create it as a plugin. The only real benefit I see in this over #1 is that you can choose whether or not to have the support in your project. The disadvantage is that the editor can no longer access it as it isn't a general solution.*

3. Create it as a static lib. This is a pretty nice all-round solution. It can be linked into the editor executable and any plugins that need it, but the problem is that, for one, it creates extra complexity (having external static lib dependencies for plugins) and that it's no longer possible to easily expose save file functionality to lua without creating a plugin.

* Editor-specific plugins _should_ be a thing. I have intended to add them, but I haven't got around to it yet. But even that wouldn't solve this problem because you would then have two (identical?) plugins for a project that needs save data, which could cause confusion both for users, and for code compatiability (editor plugin is old version, project one is newer)

Anyway, as I said, I'm happy to go with whatever you want for this, but I think it needs a little further discussion regarding what is the best solution.

Just a small update that I've been playing about a bit the last few days on my commute, I present to you:

MSaveFile!

I will admit to have been "inspired" by Unity's PlayerPrefs system a little. At the moment it only reads/writes text files (XML) but I'm part way through adding some very basic binary file support. After that's done (maybe by the weekend) I will probably add some lua hooks in for save data.

For now, you can do as follows:

MSaveFile* save = MEngine::getInstance()->getNewSaveFile("path/to/save/file", M_SAVE_FILE_MODE_TEXT);

save->setString("some.key", "value");
save->setInt("some.other.key", 1);
save->setFloat("yet.another.key", 12.55f);

char testStr[256];
save->getString("some.key", testStr);
int testInt;
save->getInt("some.other.key", &testInt);
float testFloat;
save->getFloat("yet.another.key", &testFloat);

save->destroy();

The class is pretty much an RIIA object, so it will load on construction and save on destruction, you can also call save/load manually if required. When the binary mode is added, it will be pretty much seamless. If you specify binary, but it loads text, when it saves again, it will convert it to binary and similarly the other way around. You can also specify M_SAVE_FILE_MODE_ANY and it will default to whatever it reads in, or binary if making a new file.

This can then be used internally for Maratis Editor to save preferences, such as the last opened project directory. I haven't done this yet... if anyone were to send me a pull request with this added, I would definitely appreciate it *hint hint*

Anyway, let me know what you think.

Anaël, could we at some point discuss about potentially merging some of these changes back into the official repository? I would very much like it if we could continue to maintain this "community" Maratis branch and then I/you/someone could merge back changes that would be suitable for the official repo.

That's fine com3D. Which plugin was causing the problem?

I did have a sample for the editor-lua variables but it was never finished and in my infinite wisdom, I deleted it. The main problem is that MVariable expects variables with the lifetime of the MBehavior, if I pull values from lua, the lua state manages their lifetime and will clean up the returned values shortly after they're returned (I believe) The only way I can think of getting around this is to load all the variables from lua on the first update and store them within the C++ class, and then every update pump the values to/from lua. The only problem is, if both the lua and the C++ side changes, which one takes precedence?

I know I can get around this by pushing a load of lua code to handle checking in... but I am not embedding any lua (yet) and I don't want to say "you can use this plugin, but you first need to add these huge lua scripts to get it to work" because that will remove from the simplicity.

The variables are definitely on the todo list, and pretty high, I just need to work out the best method of doing so.

As for onBegin. That's not a problem at all, while I'm at it, are there any other callbacks you'd be interested in?

Update!

I've updated the github mirror to r203 from svn, and I've also made some more minor changes:

1. I extended MScriptContext::callFunction to be able to take functions within lua tables (so you can call, for example, player.update)
2. I added optional userdata to the registration of MBehavior factories. The reason for this is that you can then use one base class with different options (see #4)
3. I added MScriptContext::addScript which is pretty much the same as MScriptContext::runScript but only will load the script if the state has already been created, and won't clear the state, or do anything if it fails.
4. I made a plugin. It is pretty rough and dirty right now, but it works. If you drop this into the project folder and then create a "behaviors" folder along side it, and populate it with lua scripts, it will add one behaviour to Maratis for each script. It currently expects the script to have a similarly named table within it, with an update function. I haven't yet done the variable translation between lua and C++(/editor) but at least it's a start

Example behaviour script:

player = {
    update = function(object, behaviour)
        
    end
}

Edit: I totally forgot, I also merged in a change from Sponk! Maratis editor is now themable! There are two themes provided (default and grey) although currently there's no way to switch them without recompiling

Let me know what you think

Thanks for the reply (and apologies for not being on for so long, been stressful, but that's not important)

I think what I was trying to suggest got a bit misunderstood here. I wasn't wanting to decode and play a movie in game (although this would always be useful) but rather use the Maratis Engine and Editor to work as a scene manager for rendering video. The backwards issue was to be to make iteration over the scene easier (rather than resetting back to the initial state and replaying only in one direction) An example of what I mean is in the talk by Bret Victor.

This was basically just a dream project, something I thought would be pretty cool to do Not sure how feasible.

It was pointed out that my reply may not have been entirely clear. I'm sorry about that.

Usually, there are two steps to a save system, collecting the data to save, and then writing to file. The collecting shouldn't take too long (depends, of course how much data you have to save, but this should be fairly minimal) Writing to file, however takes considerably longer.

For a standard menu-based load/save system you could do both of these one after the other and would hardly notice... I mean, it takes a while to save, so what? However, for a quicksave system, one thing you do not want is for the game to pause for a second or two when you hit save. To achieve this, the best way would be to collect the data as normal, when you press F5 or whatever your chosen key is, which should go fairly un-noticed, then start a background thread to write the savedata to file. As it's not in the main game loop, it shouldn't affect the normal gameplay and everything should happen smoothly.

There's a lot of 'should's there. One issue is that, when working with threads, you don't have two threads changing the same data, which could lead to crazy stuff happening, or threads waiting for other threads to release data, which would lead to locks, causing more freezes than the initial problem.

Anyway. for this reason, quicksave is a little more complicated than a standard save system.

And, while I remember, I should mention loading. There are currently no loading screens (this, again, would probably need a background thread...) so you would get a significant pause when "quickloading" which might not be ideal, although if you showed a prompt, I guess it would be better. The main issue with loading is clearing the "world" and resetting it to the exact state you want it in before.

Just let me know how urgent this is and what degree of integration you'd like and I'll see what I can do

By the way, my solution is currently that there will be a config file system with semi-DOM-esque accessing, and then a semi-singleton config file that can be used similarly to Unity's PlayerPrefs. The basic usage from code would be:

I haven't decided how I can do save/load stuff in script, but I guess it would be something similar. Thoughts?

Also, so far, I've only got it reading and writing binary files (I can put the spec here if required). I was intending to add some form of human readable format to it too, I'm not sure what to use, the choices seem to be xml, yaml, json or a home rolled format. Any preferences?

Unfortunately I've not had the time to watch your videos yet (the only real "free" time I have is during my commute, where I can't really watch videos) It's great that there are more people contributing tutorials to the Maratis community, so even without having seen them yet, thank you! I'll make sure to work my way through them soon.

Hi, I'm sorry about the delay, I've been pretty busy.

The -> is the crappy web formatting. I thought I managed to fix it all, it's meant to be ->. It's replacing > with >. If you notice any of these, can you please let me know which tutorials it's on and I will fix it.

In other news, I've started working on this stuff again, so I might have another tutorial up soon. I think I'm going to leave the video tutorials for a bit though