Making better use of Ogre's capbilities?

[jhooks1]

Wouldn't it be more efficient to split the text keys up by "\r" and "\n" within the loader? That is how the old method did it.
As it stands now each text string within the text key map can be a combination of multiple keys at the same time position. You could split these up to separate entries in the map.
Also a simple text output file of the keys would be nice (was provided before by the "anim-verbose" switch, otherwise no files were outputted).

[Chris]

Wouldn't it be more efficient to split the text keys up by "\r" and "\n" within the loader? That is how the old method did it.

I had considered it and it may be something to do. It would require using a multimap instead of a plain map though, since multiple markers would appear at the same time point, and the current method does understand the line-separated markers.

Also a simple text output file of the keys would be nice (was provided before by the "anim-verbose" switch, otherwise no files were outputted).

How useful would this be?

[jhooks1]

If you made the map <std::string, float> it would work I think (that was the old way).

The file output would be very useful once we start AI. You could view the text keys without nifskope or the construction set, in a clean output.

[Chris]

If you made the map <std::string, float> it would work I think (that was the old way).

Unfortunately that way won't sort by time, which can be important since some of the markers are sequential action triggers.

The file output would be very useful once we start AI. You could view the text keys without nifskope or the construction set, in a clean output.

I think a console command would be better. Click on someone, type 'dumpanimkeys' and have it write the keys out to a file based on the actor name.

[jhooks1]

I think a console command would be better. Click on someone, type 'dumpanimkeys' and have it write the keys out to a file based on the actor name.

Sounds good to me.

[Zini]

I would prefer to not add new script instructions prior to 1.0.

[Chris]

I would prefer to not add new script instructions prior to 1.0.

They don't strictly need to be scripting functions, just commands you can run in the console (if there's any way to separate them). The console is supposed to be a tool to help developers when making the game, after all, and it's only in the game because devs don't bother to take it out.

[Zini]

if there's any way to separate them

I was about to say that there isn't one, but I would have been wrong with that statement. Actually you could use a different extension object for the console compiler and install additional opcodes in the console too.

Will require some work though to do it properly. Can it wait a couple of days? Don't have the time to get into it right now.

The console is supposed to be a tool to help developers when making the game, after all, and it's only in the game because devs don't bother to take it out.

Personally I have always seen the in-game console primarily as a tool for content development, not engine development.

[Chris]

Will require some work though to do it properly. Can it wait a couple of days? Don't have the time to get into it right now.

I'm in no rush, it's not anything I need (any time soon, anyway).

Personally I have always seen the in-game console primarily as a tool for content development, not engine development.

I tend to see it for development in general. It's for content, but the engine is mainly tested through the content (e.g. you can't test the animation subsystem without playing in-game animations).

[Zini]

I see that the people previously working on animations are inactive right now. Can't have that Shall we get started with integrating the animation system into the rest of OpenMW? We aren't ready for most of them (I am still waiting for some roadblock tasks to finish), but I am sure I can find something on the tracker.