[WIP] Ale Effect Editor
-
I’ll mess with adoxa’s tool this weekend. I do understand some of treewyrm’s documentation and see what i can come up with. I know your more focused on your opengl project, but I am hoping you and skotty do continue on this as I do believe you have more then myself hoping for a beta. Many thanks on what you guys have come up with so far, cheers.
-
Thanks! I had a look again at the fields and since I solved the mystery about the approach value the last time I am not sure whether there actually still is a problem with the fields. I’ll try to let you know until the weekend. I also will go through the document again to see if there have been any changes.
Last time I checked treewyrm had errors in the documentation. If we have the time and are sure enough it is not our mistake we will correct them.
One thing which is still a tough problem is the randomness of the emitters. If you do a naive implementation and use the frequency you will get an absolute deterministic behaviour, meaning your e.g. engine flame will flicker in always the same way (Example: 1,1,1,2,1,1,1,2, … particles per time step) . But this is not like FL behaves. It is what I was working on the last time when I was trying to figure out stuff.
-
That being said the work on it would have been faster if I actually had the access to whatever unfinished build you had of the editor, alas at the current state of things the likelihood of editor coming out in any form is… well, somewhere too unreasonably far away.
-
I am not sure I follow. I knew which flaws there were left and I did solve most of the difficult problems. There are not many left to solve. Why would I let someone test software for errors I already know?
It might be difficult to understand for some, but my opinion is like the old saying “too many cooks spoil the broth”.
When I had difficult problems I did ask you. In the end I found a solution and I think you underestimate the work that is already done. Also keep in mind that we still are taking lectures at university and thus they take precedence (although I am finished soon).
Taking breaks from the code allows me to rethink certain problems and start with a fresh mind again. This is actually the reason why I work on many projects in parallel and for now this has worked out very well. Although it takes more time. But it is a hobby, isn’t it?
P.S.:
In order to guard against misunderstandings: We did not use your ale document. We already had reversed more of the ale stuff. When we are finished we plan to document any differences of our implementation, which hopefully will behave like FL. But it was good that you started it, so it is not so much work anymore to document all the stuff. -
Docs are for everyone to learn and use however they see fit. Feedback is welcome and errors should be fixed so if you know them why not point out so I can fix them? Knowledge empowers others to do, so that other modders don’t have to do same research over and over again all on their own. There’s no point or practical benefit to anyone in keeping their findings in closets. Formats, structures, behaviors, utilities and codes, the more there is known and available to everyone the better it is for everyone involved.
Don’t get me wrong, I’m glad you’re still working on it. It’s just from the conversations back then and as the time went by it all left me quite skeptical of it ever being released for anyone left around to make a good use of.
Would it be prudent to say the point of others testing is to find errors that you don’t know yet, hmm…
-
I think you misunderstood: As long as we are not sure our implementation is correct it does not make sense to “correct” anything. It can very well be that we make it worse.
Addition after I read your edit:
Regarding the errors: You are assuming that errors are not caused by other errors. This is often not true. In fact most of the time when I changed the implementation other errors vanished as well. I don’t want to waste time looking for things which are just a side effect. And there have been a lot unexpected ones.
I want to reach at least a state where I can say that the implementation is as close as I could get it to FL (otherwise you are constructing effects which don’t look the same) and it only has minor errors we can fix after a beta release. The problem with the fields and random behaviour of the emitters are basically the kind I want to have gone because they cause other stuff to not work correctly. There are not many of such errors left, so it should not take that long anymore.
-
I don’t think I misunderstood.
Also I had not assumed that errors cannot be caused by other errors. Where did that come from?Because what I’m saying here is that in pursuit of perfectionism (while a commendable trait on its own right) there’s a case to be made where a functional yet inaccurate implementation is preferable to continuous unavailability in a struggle for accuracy. None of the existing tools out there are perfect, each has own array of bugs and features missing, that’s normal and I don’t think anyone expects them to work perfectly. I’m fairly certain DA own toolset seldom worked right if the sources to C:FW tools are of any indication of quality and stability. Besides the underlying implementation, state of its accuracy or inaccuracy at various cases, there’s also user interface, the front-end functional part of the utility is the area certainly benefiting from testing and fresh perspectives.
Like anyone else I’m eager to see new tools being made available even if they’re not perfectly behaving or accurately conveying FL’s own implementation, for practical reasons it doesn’t need to. Just like any other content authoring tools previews are at most approximations, and for most part they are good enough to be useful for content makers.
-
Ah, ok now I see what you are getting at. At first I was a little confused.
Yes, we have a quite high quality of standard, because we think as long as you are more annoyed with it than it is useful you can as well use the xml files for editing. I have tried editing effects and it is not working well enough yet (this is more Skotty’s fault as he already wrote). I have been thinking more than once about whether it would be useful as a preview, but there always have been issues so that it was not really a preview yet. But most of that is solved now. The plan was to have a look at it again soon and then try to release a somewhat usable beta. Let’s hope it’ll work!
-
I’m awaiting a Beta, it would very really awesome to have one. I’ve been using Adoxa’s XML for ages now, and made some pretty cool things. This tool could advance it to the next step
I can imagine how the preview would really streamline the whole process!
-
is the project dead or working on it?
-
I don’t have time for the OpenGL wrapper and this tool at the same time. I want to finish the wrapper first, so this is on hold until then. I have gotten a few ideas for it, though.
-
Any update on the same?
-
Topic is being updated here:
