Alright, I must come forth and say that Ive been working to develop these programs I have mentioned, mainly in theory, sometimes in actual code.
As for my solution to tools like cutscene maker etc, I always try to make them as modular and straight forward as possible, and try not to limit the user in any way.I guess the solution was somewhat revolutionary for me at the time;
Write our own file formats. Using the file_str/var commands it can be easily done. For the cutscene maker, not only did I want to be able to interpolate the POS' and ANGLES, but I wanted to give the user the ability to interpolate everything else as well, ARC, ASPECT, TRANSPARENCY, etc.
The only reason I never released these tools is because there is a bug in my interpolation code. Not always, but everyonce in a while, the camera will do the wrong thing. Here is the problem;
Since its KEYFRAMES that are used, my code resolves the direction to travel on a given axis as being the shortest of the two directions to the next keyframe's pos/ang. This works fine if the animator understands that, but in the case where POINT B is farther away in the intended direction than in the opposite direction (think rotation), the object would simply take the shorter direction(go the other way), which is not what was wanted by the animator. Ive tried several different methods, but all have a problem somewhere. For instance, if I dont use ang(); to return wrapped values (-180 to 180) for angles, then Im working with absolute rotational values, and thus the camera/object would do several rotations (spinning) before ending at point b. Its been hard to find the perfect solution. Also, my code is all built on simple arithmetic, and uses functions like:
dist_on_axis = getgaps(sourcevalue, destval);
to always return either 0 or a positive value giving the distance, because you have to manage the fact that the different positions could cross 0 pos/neg threshold at any time.

I am considering releasing some of these tools for further development by myself and others, if anyone is interested in seeing these tools become of real use, let me know. The only real work left to be done on them is to fix the interpolation code so that it always works perfectly.
PS: The other problem with my equation is that it uses distance_per_cycle as speed, and if this distance is not within a certain range, problems can occur; Ive resolved this as good as I know how by manually setting the final position if the distance to travel is larger than the distance remaining.
Also I still need a final smoothing pass where the movement speed is the same over different distanced keyframes within the same animation.

I am quite sure you never worked with a modelling / animation software if you write such a comment. You need more than just recording coordinates. You also have to interpolate between keyframes and sometimes you have to edit some adjustments.

I have no problem when some users like you want to program everything themselves. You can do it. Please show me the results. Maybe some other users want to buy it.

By the way: It is not very prudent if everyone invents the weel again and again (except for learning purposes but not if you want to make a game).
Some other just want to be more productive.

So let us talk about the topic: "next gen workflow".
I am really sure that you missed this topic a bit since "programming everything myself" is far away from being a good workflow

I did not mean that you should write a cutscene editor with keyframes and all those things. You don't need them when you record actual movements, angles, timing of sounds and so on. I've already programmed such a recorder for making my own cutscenes. I only had to program that once.

Quote:

---

"programming everything myself" is far away from being a good workflow

---

Programming everything yourself and recording and playing it back is not a extremely cumbersome method of doing cutscenes in my opinion. You can't usually re-use the movement calculated in cutscene editors or animation software because it was interpolated between keyframes, not made with actual code. When recording it you don't have to worry about doing all that twice...

Quote:

---

Some other just want to be more productive.

---

..either that or you're just being lazy. Being more or less productive doesn't quite apply to my method. It has sped up the process a lot. Sure, I had to write the recorder/playback code, but after only a few days or so I had that finished. It's modular so I can use it in all my 3dgs projects, I'd say that provides me with a very acceptable work-flow.

Quote:

---

I have no problem when some users like you want to program everything themselves. You can do it. Please show me the results. Maybe some other users want to buy it.

---

I currently have no intention of selling it, but who knows maybe later...

Cheers

@ Friendly Frank: I agree with you completely. I know because several years ago, when I first attempted cutscenes, I thought like PHeMoX, thinking I would just script everything hardcoded. Of course, it wasnt long before I realized that this method was not the answer. Even if you did everything by hand, meaning recording every camera position/angle by hand, every objects angles etc, what you would end up with is massive scripts that would consume too much resources, simply by sheer size.
In light of this debate, Im going to go ahead and release my cutscene tools to the community. It is under-developed atm, but I'll take a day or two to go back through the code and clean it up, and write a new interface for all the features, since I mainly called all the functions from the command line when I was working with it.

PS: I'll post the zip file in User_Contributions thread, so other users will be able to find it, so check there for it.

That's very kind!

You mentioned some issues in the code, in a post above, maybe, you want to wipe them out with the help of others in the script forum...?

OT:

JCL added these days

"External Tools - A set of small tools/plugins for improving certain game design tasks. Planned: vegetation generator; GUI editor; improved terrain texture generator / editor."

to the forecast. Nice!

@ JulzMighty:

The way I visualized what Phemox was talking about was refering to hardcoding each cutscene specificly, meaning in functions setting each property individually, like a line by line script execution. Therefore, what your doing lies at the other end of the spectrum, and if you've got your own system for "interpolating" recorded waypoints, then that is exactly the same as keyframes, and:
if A==(recorder + playback) + fileexport(loaded for playback,interpolation))
then you are using keyframes and {A = cutscene_editor.}