|
Title: UQM Tools Post by: Megagun on October 02, 2010, 08:17:54 pm UQM tools is a set of tools (unafilliated with the official UQM team/project) designed to aid those seeking to edit various stuffs of UQM.
Keep in mind that these can be buggy. Currently, there's two tools: UQMDialogTool (Java, multiplatform; ZLIB license) (http://mooses.nl/uqm/tools/uqmdialogtool_thumb.jpg) (http://mooses.nl/uqm/tools/uqmdialogtool.jpg) UQMNamegen (Java, multiplatform; ZLIB license) (http://mooses.nl/uqm/tools/uqmnamegen_thumb.jpg) (http://mooses.nl/uqm/tools/uqmnamegen.jpg) UQMAnimationTool v0.1 released: (http://mooses.nl/uqm/tools/uqmanimationtool_thumb.jpg) (http://mooses.nl/uqm/tools/uqmanimationtool.jpg) Downloads, more info etc etc etc: http://mooses.nl/uqm/tools/ Title: Re: UQM Tools Post by: JHGuitarFreak on October 02, 2010, 08:37:13 pm Awesome ;D
This would be a really useful tool for translators. Title: Re: UQM Tools Post by: Valos Cor on October 02, 2010, 09:13:41 pm Sounds neat! I downloaded it and put it in a UQM directory I copied over but I couldn't find the content\base\comm directory, although there is a content\addon directory. What am I doing wrong here?
Title: Re: UQM Tools Post by: Megagun on October 02, 2010, 09:52:05 pm Sounds neat! I downloaded it and put it in a UQM directory I copied over but I couldn't find the content\base\comm directory, although there is a content\addon directory. What am I doing wrong here? Hmm, right, I remember that vanilla UQM has things in .uqm files. Drat! (I have been testing this using p6014, which doesn't package into .uqm files)Well, you can extract the content .uqm file (which is just a ZIP file) so that the files appear in content\base\comm and then run it. If you're running Linux you should run the .jar from the folder "below" UQM's content folder so that it can find \base\comm\*. OSX? Dunno. I guess I could add in support for .uqm files someday. Either way, new tool UQMNamegen! See original thread message... Title: Re: UQM Tools Post by: Valos Cor on October 02, 2010, 10:21:13 pm Well, I did just that, all I had to do was rename the .uqm to .zip and extract. However, it did not have a base, so I made one. The editor worked pretty well except that clicking the arilou or urquan or stuff doesn't change anything. Anyway, I went in and edited and saved the first Earth message. However, now the uqm.exe can't find it (probably because of the added base directory in between). Also, if it did, whats to say it won't use the uqm instead of the directories? On linux, I remember looking at it, but nah. hehe, oh well, it looks cool though.
Well, what's UQMNamegen? I looked for it in search but it doesn't show anything (except your post) Title: Re: UQM Tools Post by: chenjesuwizard on October 02, 2010, 10:54:08 pm This is great! Perhaps someday we can have a complete editor, so it's very easy to edit Ur-quan Masters
What's Namegen? Title: Re: UQM Tools Post by: Megagun on October 02, 2010, 11:47:09 pm Namegen generates names based on a "pattern".
For instance, the pattern "CCC\-UU" will generate Androsynth-like names, "CVC" will generate VUX-like names, etc. This way, you can have one alien race have names that all follow a certain pattern, and thus have a certain 'feel' to them. The pattern "Fvspv", for instance, generates these somewhat-similar names: Quote Gokky Shydde Fadde Fikka Hetty Febbo Shuddi Chackky Sickki Fekku Thotty Sedda Vebbo Chubbu Thippi Ghokka Focci Shippu As far as UQMDialogTool goes: I'm fixing some bugs and making it compatible with .uqm files now. Also, it turns out UQM0.6.2 has content in content/comm/* whereas p6014 has 'em in content/base/comm/*. I'm also fiddling with that so it all works out nicely, and if you edit dialogs from a .uqm file it'll save them under content/$PRESET/comm/* so that those edited files will override the originals (like in UQM) Title: Re: UQM Tools Post by: Megagun on October 03, 2010, 01:13:38 am Okay, I've released v0.3 of UQMDialogTool.
Now it supports vanilla UQM by scanning .uqm files and extracting from them if needed. It'll also support p6014 and extraction of .uqm files once it supports those. There is a bug, though: dialog voices may go out-of-sync when extracting from a .uqm file... Will check into that tomorrow. v0.3 can be redownloaded from http://mooses.nl/uqm/tools/ Title: Re: UQM Tools Post by: Valos Cor on October 03, 2010, 03:10:28 am I just barely tested it, and it works! Thanks!
I don't know anything about the sync. I wish I knew enough c or java to do that. Title: Re: UQM Tools Post by: Megagun on October 03, 2010, 03:43:07 pm V0.4 released of UQMDialogTool:
-Fixed sync bugs and a few other bugs. Should be production-ready tool now! :) -Added option to stop bugging the user with the help/notes screen Title: Re: UQM Tools Post by: chenjesuwizard on October 03, 2010, 03:54:43 pm Quick Question:
Are you planning to make more of these or is this just a one time thing? Title: Re: UQM Tools Post by: Megagun on October 03, 2010, 09:51:33 pm Quick Question: Dunno. Maybe.Are you planning to make more of these or is this just a one time thing? UQMDialogTool v0.5 released: -Added "strings.h" file generation. Title: Re: UQM Tools Post by: chenjesuwizard on October 03, 2010, 10:07:56 pm Love the improvements. This should make it so much easier to mod UQM or Project6014.
I was wondering, is there any way to change whether a dialogue option means that you have to fight the enemy? Title: Re: UQM Tools Post by: Valos Cor on October 03, 2010, 10:10:48 pm I'll add on to chenjesuwizard's question:
Is there any way to find out which conversation produces which result, create ones and link the captain's talking with the reply or link the statement with the captain's available replies? Just wondering. Title: Re: UQM Tools Post by: Megagun on October 03, 2010, 10:29:04 pm Other than reading and/or modifying the source code; no. UQMDialogTool only modifies the text, not any logic behind it. The Strings.h generation thing is there for when you've added a few entries and want to code the dialogue logic for that.
But I'm looking into things like that right now. Title: Re: UQM Tools Post by: chenjesuwizard on October 03, 2010, 10:56:09 pm If you can't, it's fine
it's good anyway. Title: Re: UQM Tools Post by: dczanik on October 04, 2010, 12:14:56 am Awesome.
Any chance on some animation tools too? Animating for me has been rather trying. It's hard enough trying to find the X,Y coordinates. I also have to edit .ani file, then go into a game, wait for the loading screen, load a save game, and watch the animation. When you've loaded the game the 50th time, it gets a little monotonous. Then there's ship animation. After editing any of the 4 .ANI files (big,medium,small,captain), I have to load the game, go to melee, set it to human, select 2 ships, and then test it while asteroids are coming, and gravity is pulling the ship. These are just screaming for tools. I'd love a tool that I can edit the file, and hit a reload button, and see how the changes look instantly. It would save me a lot of time. Title: Re: UQM Tools Post by: Angelfish on October 04, 2010, 08:12:05 am Awesome. Any chance on some animation tools too? Animating for me has been rather trying. It's hard enough trying to find the X,Y coordinates. I also have to edit .ani file, then go into a game, wait for the loading screen, load a save game, and watch the animation. When you've loaded the game the 50th time, it gets a little monotonous. Then there's ship animation. After editing any of the 4 .ANI files (big,medium,small,captain), I have to load the game, go to melee, set it to human, select 2 ships, and then test it while asteroids are coming, and gravity is pulling the ship. These are just screaming for tools. I'd love a tool that I can edit the file, and hit a reload button, and see how the changes look instantly. It would save me a lot of time. Animations are partly done in UQM source and partly in ANI file, I think to make a standalone editor for it you'd have to revise how UQM loads and displays these things. That might require a bit more direction, to establish a well thought out animation file spec ;). Title: Re: UQM Tools Post by: Lukipela on October 04, 2010, 09:01:58 pm Interesting. Mind if I stick these on PNF at some stage as well, just to collect tools for people?
Title: Re: UQM Tools Post by: Megagun on October 05, 2010, 07:14:00 pm Not at all; as long as you link to the page containing all tools, rather than copy the .jar files over to PNF, so that I can update the existing tools and introduce new ones properly.
Title: Re: UQM Tools Post by: Lukipela on October 05, 2010, 07:18:40 pm Absolutely. If at some point you get bored with it or have a finished version, let me know and I'll copy that over for posterity. Until then it's link city
Title: Re: UQM Tools Post by: Megagun on October 07, 2010, 10:59:16 pm Currently working on a conversation editor thingy which generates C code (no release yet as it contains a lot of debug stuff.. :P):
Code: //AUTOGENERATED BY UQMCONVERSATION TOOL //FUNCTION DECLARATIONS: static void Test1 (RESPONSE_REF R); static void TestFunc (RESPONSE_REF R); //FUNCTION DEFINITIONS: static void Test1 (RESPONSE_REF R) { //START BODY GENERATE NPCPhrase (HELLO_SAMATRA); Response (where_am_i, TestFunc); Response (why_does_my_head_hurt, TestFunc); //END BODY GENERATE } static void TestFunc (RESPONSE_REF R) { //START BODY GENERATE NPCPhrase (SENSE_EVIL); DISABLE_PHRASE (where_am_i); DISABLE_PHRASE (why_does_my_head_hurt); //END BODY GENERATE } It's currently a pretty basic GUI tool that loads a Dialog TXT file (output of UQMDialogTool, or files distributed with UQM) and allows a user to create "functions" (which maps perfectly to a function in C) each of which has a few "statements" which map fairly well to a line of code; statements are one of "Response", "NPC Phrase", "Disable Phrase (response)", "Custom code (user-specified C code)" and "Function call". Saving and loading of this conversation object (which is a combination of Dialogue Entries parsed from Dialog TXT files, plus the entire logic bit) is handled neatly through XStream. All I have to do now to make it work properly-ish is to create some new classes that neatly map my existing functions and statements to something that UQM players should recognize ("ConversationTreeNode" and "Response-NPCPhrase", or something along those lines).... I'll probably end up releasing a non-production-ready test version of it tomorrow. I've decided to keep development of this new tool seperate from UQMDialogTool (for now), but I will probably end up merging the tools once they've proven to be workable. :P As far as converting existing C code to a format readable by my tool goes: I probably won't do it (too much effort involved).. Title: Re: UQM Tools Post by: Valos Cor on October 07, 2010, 11:02:50 pm It could certainly help those of us who don't know much C (like me). I await the release with much eagerness.
Title: Re: UQM Tools Post by: Admiral Zeratul on October 08, 2010, 01:25:35 am The Vux preset needs some work. It isn't entirely horrible, but most names generated are inadequate. "GAW" and "MUM" do not suit the Vux at all. "CAR" and "MAN" are plain ridiculous.
Title: Re: UQM Tools Post by: Quinarbre on October 08, 2010, 02:57:38 pm I don't know if that third tool you're talking about is really useful : if you do have to create functions and statements, you might as well do it in C directly.
What I'm thinking is that : for 90% of the dialogs, all you really need are the basic structures : - which player phrase triggers which answer from the alien - which alien answer opens which phrases options for the player - when the alien should just answer the question and then give the same options, minus the one just answered (typical of Hayes' statements about races) - which phrases trigger combat or good-bye That would allow to code the basic structure of most dialogs ; then, for fancy stuff like trade, one can always fiddle with the code your tool produces. Title: Re: UQM Tools Post by: chenjesuwizard on October 08, 2010, 06:54:45 pm This is for people (like me) who cannot work out how to compile it.
Title: Re: UQM Tools Post by: Megagun on October 08, 2010, 07:28:29 pm I don't know if that third tool you're talking about is really useful : if you do have to create functions and statements, you might as well do it in C directly. What I meant with:What I'm thinking is that : for 90% of the dialogs, all you really need are the basic structures : - which player phrase triggers which answer from the alien - which alien answer opens which phrases options for the player - when the alien should just answer the question and then give the same options, minus the one just answered (typical of Hayes' statements about races) - which phrases trigger combat or good-bye That would allow to code the basic structure of most dialogs ; then, for fancy stuff like trade, one can always fiddle with the code your tool produces. Quote All I have to do now to make it work properly-ish is to create some new classes that neatly map my existing functions and statements to something that UQM players should recognize ("ConversationTreeNode" and "Response-NPCPhrase", or something along those lines).... Is pretty much what you say here. My current version is very rough like that, but in a future version players can create "TreeNodes" (or whatever) which then have a few "PlayerPhrases", which can optionally specify that they shouldn't be able to be used again, etc. In the background, flagging a phrase to be "Do not show again" actually creates a new Function object which contains a DISABLE_PHRASE statement.The reason why I'm using functions and statements at the moment is that it allows for future additions, and that I can simulate an entire conversation pretty nicely with this. Furthermore, my current system maps pretty much 1-to-1 with the current code, so if I want to at one point move code to my own representation of conversations, it should be somewhat possible. The real value in a tool like this is mostly ease-of-use though. Dialogs (Strings only) can very easily be edited by hand (text editor to open the .txt files in comm/*) but it's annoying as hell and it's quite easy to make mistakes. The same goes for this conversation tool: if you're doing conversations by hand you have to have a .txt file open (for the phrase identifiers; unless you know what phrase "WHAT_HAPPEN" maps to) AND your IDE/code editor/whatever. Conversation editor tool simplifies this greatly; all in one window. Furthermore, my tool spits out an XML file that can be transferred by a clueless no-C-knowing user to someone else that can turn the XML into code and integrate it within UQM. At the very least, it appears to be a much nicer workflow than what p6014 seems to be doing: creating .docx documents containing color-coded text and having diagrams composed in Visio or the like and having a programmer code that into C.. :P Title: Re: UQM Tools Post by: Megagun on October 10, 2010, 05:02:28 pm Any chance on some animation tools too? Animating for me has been rather trying. It's hard enough trying to find the X,Y coordinates. I also have to edit .ani file, then go into a game, wait for the loading screen, load a save game, and watch the animation. When you've loaded the game the 50th time, it gets a little monotonous. Then there's ship animation. After editing any of the 4 .ANI files (big,medium,small,captain), I have to load the game, go to melee, set it to human, select 2 ships, and then test it while asteroids are coming, and gravity is pulling the ship. These are just screaming for tools. I'd love a tool that I can edit the file, and hit a reload button, and see how the changes look instantly. It would save me a lot of time. UQMAnimationTool v0.1 released: (http://mooses.nl/uqm/tools/uqmanimationtool_thumb.jpg) (http://mooses.nl/uqm/tools/uqmanimationtool.jpg) -Shows .ani file contents... .big/.med/.sml are also supported but not working nicely yet (hotspot issues; probably fixing those later) -No editing (yet?). Just viewing. -Read in-tool notes for more notes. :P (Let me know if anything is wrong or you need more features, but read the notes first as I explain some wrongstuffs there). http://mooses.nl/uqm/tools/ As far as the conversation editor goes: I'm doing some more work on that. Title: Re: UQM Tools Post by: Megagun on October 10, 2010, 08:27:12 pm UQMAnimationTool v0.2 released. Changes:
-Proper support for .big/.med/.sml (hotspots now work properly). This means you can finally debug your ship graphics and the like. And there was much rejoicing! -Added "Load" button. No more exiting and restarting to load a new file, woo! -Can now drag the rendering around. Click and drag anywhere in the rendering-panel where there's not a rendering image. -A few bugfixes here and there. http://mooses.nl/uqm/tools/ A few things I've found whilst using my tool: http://mooses.nl/temp/aarghspathi.avi (Spathi have a mouth! Supposedly a few people in coredev knew this. Bastards never told any of us! This is significant scientific knowledge!!!) http://mooses.nl/temp/androsynthwobble.avi (I've always thought I've noticed that odd wobble in the 'East' position of the Androsynth, but I guess this proves it!) Title: Re: UQM Tools Post by: chenjesuwizard on October 10, 2010, 09:22:05 pm Thanks, used all three.
Title: Re: UQM Tools Post by: onpon4 on October 11, 2010, 02:27:45 am http://mooses.nl/temp/androsynthwobble.avi (I've always thought I've noticed that odd wobble in the 'East' position of the Androsynth, but I guess this proves it!) Just from observation of the game, this seems to happen with a lot of ships (I've particularly noticed it with the flagship), mostly because of how ship rotation works. I've actually experienced the same problem quite some time ago, when I was making a space game in GM (which, funny enough, I'm starting to work on again in Python) and at first tried to use that same technique combined with image rotation. The problem is, it's almost impossible to cause the rotation to look perfectly smooth, so there are bound to by "snap" points like that. Title: Re: UQM Tools Post by: Angelfish on October 11, 2010, 08:06:37 am the timewarp ships are perfectly rotated for the most part, so it's not impossible ;)
Title: Re: UQM Tools Post by: Megagun on October 11, 2010, 12:18:36 pm Just from observation of the game, this seems to happen with a lot of ships (I've particularly noticed it with the flagship), mostly because of how ship rotation works. I've actually experienced the same problem quite some time ago, when I was making a space game in GM (which, funny enough, I'm starting to work on again in Python) and at first tried to use that same technique combined with image rotation. The problem is, it's almost impossible to cause the rotation to look perfectly smooth, so there are bound to by "snap" points like that. The snap points are pixels, and the maximum 'wrong offset' you can get is an offset of one. What I'm seeing here with the Androsynth isn't a technical limitation at all; someone probably just made an error in the .big file...Lower resolution graphics are way more susceptible to hotspot issues, which is also why the ships in Timewarp don't suffer these issues at all (and I would say that neither do any of SC2's ships, with the sole exception of the Androsynth in blazer form). Thus, a cheap trick you could use to solve this is to upscale your graphics by 2 and set the hotspot based on the resized graphics. That, or use floats/doubles for your hotspot coordinates. Title: Re: UQM Tools Post by: Quinarbre on October 11, 2010, 09:57:24 pm Awesome, especially if you make it possible to edit hotspots on the fly.
And sorry for not understanding what you had in mind with the conversation tool. I remember when I discovered the mouth on that Spathi and thought "Why weren't we told that before ?" Also, to answer your notes, project6014 uses duplicate lines just to make some frames appear longer than other ; your way of handling it is perfect, you'd want to eliminate duplicates when tweaking hotspots but not when replaying the animation. You might want to say somewhere what the unit is for the rate (which is actually not a rate but a frame duration). Another suggestion which would help the animation artists (but may not be straightforwardly done just playing with the z axis) : give the option to test the animation only on a (continuous) selection of frames. Title: Re: UQM Tools Post by: chenjesuwizard on October 15, 2010, 08:57:16 am How's it going?
Title: Re: UQM Tools Post by: Megagun on October 15, 2010, 12:59:35 pm Awesome, especially if you make it possible to edit hotspots on the fly. Shouldn't be too hard to do; might end up doing that. Editing hotspots and offsets by hand works nicely too, though. I'll see if I can get that to work after I've gotten the conversation tool done.Also, to answer your notes, project6014 uses duplicate lines just to make some frames appear longer than other ; your way of handling it is perfect, you'd want to eliminate duplicates when tweaking hotspots but not when replaying the animation. Ah, yeah, I thought that must've been why they were duplicated, but I wondered why that wasn't done in the code.You might want to say somewhere what the unit is for the rate (which is actually not a rate but a frame duration). Right. Frame duration is x milliseconds, where x is the value of the slider. Another suggestion which would help the animation artists (but may not be straightforwardly done just playing with the z axis) : give the option to test the animation only on a (continuous) selection of frames. Maybe later. :)How's it going? I've spent most of my uqmtools-developing time on creating a buildbot (using the buildbot/buildslave tools from http://buildbot.net/trac) for p6014 (to automatically build Linux binaries). It works, but I've still got to fix some security issues on my end. The conversation tool is proceeding semi-nicely. There's a few things that are pissing me off and a few things I still need to implement (initialize functions/end functions, mainly)...Title: Re: UQM Tools Post by: Megagun on October 16, 2010, 12:23:58 am Here's a very early alpha of UQMConversationTool built in a bit of a hurry (but I really wanted to release a preview of this today):
(http://mooses.nl/uqm/tools/uqmconversation_thumb.jpg) (http://mooses.nl/uqm/tools/uqmconversation.jpg) Binary (Java/zlib): http://mooses.nl/uqm/tools/uqmconversation.zip (place in the same folder as your UQM binary for optimal effect; note that I have only really tested it with p6014, but it should work nicely under vanilla UQM aswell) Sources (zlib): http://mooses.nl/uqm/tools/uqmconversation_src.zip Example project XML from the screenshot: http://mooses.nl/uqm/tools/conved_examples/example.xml As you can tell by the screenshot, it's not very proper yet (didn't override a few toString()s.. :P) but as far as I know, it should work neatly. I've had a few enlightening conversations with the chmmr earlier today about pie. Contains some pretty extensive help and notes. As far as the XML specs go: I haven't done *anything* regarding those. The project XML files are basically my Conversation class parsed through XStream's serialization functions. There's some pretty horrible stuff in there; keep that in mind. But hey. it works... :) Todo: lots and lots and lots of things. :) Title: Re: UQM Tools Post by: chenjesuwizard on October 17, 2010, 12:00:47 am Had a little play around and worked out the basics, following your guide (which helped alot). I kinda understand it now. But it's still a bit confusing.
Title: Re: UQM Tools Post by: Megagun on October 17, 2010, 12:57:33 am Yeah, I know. It's not the most usable tool yet.
UQMConversationTool v0.02 alpha released: -Integration of UQMDialogtool within ConversationTool: dialogue strings can now be modified :D - This means that a project XML file can be used, transferred between people and then converted to a .txt file. Even though you'd need to create a new project to be able to edit a dialogue, the various fixes and changes I've made make ConversationTool a better UQMDialogTool than UQMDialogtool itself. :) -GUI cleanups: added tabs, native look & feel (consider enabling it; it makes things a lot easier), two settings panes (one for the tool, one for the working project), etc. -Lots and lots of fixes. For one, loading multiple conversation dialogue files is possible, and it'll ask you about an overwrite policy if there are any collisions.. -Added error console tab. Just because I could. heh. -Settings saving mechanism. Based on HashMaps which make it very comfortable for me to add in settings as I see fit. :) -Note: help dialogs are NOT updated. It's 0:50 here and I'm lazy. :) Production-ready-ability: low. Specs may still change, and I'm not willing to support the current output XML format in later versions of this tool. Binary (Java/zlib): http://mooses.nl/uqm/tools/uqmconversation.zip Sources (zlib): http://mooses.nl/uqm/tools/uqmconversation_src.zip Todo: lots and lots and lots of things. Amongst others: -Rework 'Statement editor' GUI. It's ugly and uses interface elements wrong (tabbedpane where a radiobutton group should be used).. -Allow multiple alien phrase responses in the ConversationOption editor. -Add pre and post-statements in the ConversationOption class + editor -Allow deletion of statements etc in all editors -Make the ConversationOption class use Functions and Statements internally -- drawback to this is that it'll make the XML even more ugly. oh-well.. -Implement a "Conversation Player". -lots and lots of other things. Title: Re: UQM Tools Post by: Megagun on October 17, 2010, 08:31:53 pm Yeah, I know. It's not the most usable tool yet.
UQMConversationTool v0.03 alpha released: -Conversation Simulator added. -Internal changes to Conversation nodes and options; these now use all the internal statement types. -Changes to the XML format. A lot cleaner now. :) -Allowing multiple alien phrase responses in the ConversationOption editor. -Bugfixes, small tweaks, ... -Note: help dialogs are NOT updated. Yeah, I am lazy. Production-ready-ability: average. Things should work nicely, but it's probably a bit clunky to use right now. Furthermore, there are a few features lacking, and a lot of the more core-game stuff (gamestates, if/then/else statements) aren't implemented and thus need to be done by hand using a CustomCode statement. Binary (Java/zlib): http://mooses.nl/uqm/tools/uqmconversation.zip Sources (zlib): http://mooses.nl/uqm/tools/uqmconversation_src.zip Screenshot of simulator: (http://mooses.nl/uqm/tools/convsim_thumb.jpg) (http://mooses.nl/uqm/tools/convsim.jpg) XML file for this conversation: http://mooses.nl/uqm/tools/conved_examples/picard.xml Todo: a few things... -Rework 'Statement editor' GUI. It's ugly and uses interface elements wrong (tabbedpane where a radiobutton group should be used).. -Allow deletion of statements, conversation options, functions and conversation nodes. -Allow moving of statements. Move up/move down, that sort of thing. -Allow adding statements to conversation options (Conversation Option Editor dialog) -Add statements: Set Gamestate, IF (+ IF GAMESTATE), ELSE -other stuff.. Title: Re: UQM Tools Post by: chenjesuwizard on October 18, 2010, 12:21:43 am Had a go, a few ideas:
- Have a way to delete functions and nodes - Have the init_encounter, main_node and end_encounter there on start up - Make it possible for one question to lead to any of multiple answers - Have the thing that sets whether you have a battle or not to be already on there Title: Re: UQM Tools Post by: chenjesuwizard on November 20, 2010, 06:40:45 pm Is this still going?
Title: Re: UQM Tools Post by: Megagun on November 20, 2010, 06:46:40 pm Not really, no.
Doing some work on p6014 at the moment and using the knowledge gained to improve the conversation editor later on. Title: Re: UQM Tools Post by: chenjesuwizard on November 20, 2010, 07:02:29 pm Okay. P6014 is definately more important! Good!
Title: Re: UQM Tools Post by: Megagun on September 16, 2011, 01:52:40 pm I've updated the Animation tool to show a hotspot pixel at the [0,0] coordinates in an animation (as requested by dczanik). I've also fixed a few bugs and made some minor further improvements. I'm not sure if anyone else is using that tool, but if you are, it might be worth it to upgrade to v0.3 :)
Binary here (http://mooses.nl/uqm/tools/uqmanimationtool.zip) As far as the Conversation editor stuff goes, I've been thinking about recreating a generic conversation editor from scratch with a much better interface that poops out a standardized XML file that various projects could make use of. This probably means that the existing conversation editor tool is going to be abandoned (but I don't think anyone was using that one, anyways). Title: Re: UQM Tools Post by: Elestan on September 17, 2011, 03:16:31 am If you're defining an XML format for conversations, you might look at http://www.w3.org/TR/ttaf1-dfxp (http://www.w3.org/TR/ttaf1-dfxp). It's the W3C standard XML format for timed text.
Title: Re: UQM Tools Post by: Megagun on November 08, 2011, 08:28:56 pm UQMAnimationTool v0.41 released. Binary here (http://mooses.nl/uqm/tools/uqmanimationtool.zip)
Changelog: +Added in-tool editing. W/A/S/D to move a frame up/left/down/right. Shift+W/A/S/D to move all frames up/left/down/right. +Added in-tool saving of files. +Added transparency helpers and selected frame highlighting, which should make editing/viewing easier +Added text at the bottom that displays the coordinates of the pixel the mouse is hovering on (as requested) +Added a button that sets the X/Y offsets for all frames in an animation +Keyboard shortcut: UP/DOWN arrow selects the next/previous frame in the animation +Keyboard shortcut: SPACE plays one loop of the animation +Keyboard shortcut: P plays/pauses the animation -Removed 'reload file' button -Removed ability to ignore duplicate lines (because that may cause things to break if you save later) *Bugfixes *Debug printout in case a file can't be found Title: Re: UQM Tools Post by: dczanik on November 09, 2011, 06:54:14 pm Damn you sir.
Damn you for not making this earlier! ;D This would have saved a ton of time if I had this earlier. I'm loving this version. It's really starting to feel like a real animation tool, instead of an animation player. This is a big deal to me. As probably your biggest user of this tool, some suggestions: 1. Sometimes there's blocks of files that need to have the same coordinates. I don't know how you would handle this, but I would just load up my editor and do a SEARCH/REPLACE to replace those lines. It's quicker than going line by line. But now, without the reload button I have to: click load file, click type of file .ani find the .ani file click the .ani file, click load. Go back to the frame I was looking at. Not a huge amount of time. But when you're talking about 120 lines, that can add up. It would be easier to just hit F5 to reload the file, or have some way to edit the file. 2. A Save icon: So I can tweak the file, hit save, move on to the next frame. 3. X,Y input boxes. So I can just type in a number to jump the thing over instead of moving something from one side to another. WASD is great for fine tuning, but for my high res stuff, moving an image over can be a little slow. As far as the XML stuff. One thing I'd like. Some way to associate animation to a sound file. Like a timed animation event. That way I can put in actual lip syncing in the game. I can also sell the dialog better. When Hayes finds out you sold all his crew to slavery have him show some emotion instead of just standing there like a statue. Have Fwiffo shake in fear when he talks about the "ULTIMATE EVIL". Stuff like that. Some aliens like the Orz probably work better without the lip syncing. But for the humans, Syreen I just see lip syncing helpful. It's not so bad at low res but you really notice it at higher resolutions. Title: Re: UQM Tools Post by: dczanik on November 09, 2011, 06:59:53 pm In addition you can change the "Change X,Y for all frames", to "Change X,Y for selected frames". Or at least an option for that. With these changes, I don't think there would even be a need to use a text editor after that.
Title: Re: UQM Tools Post by: Quinarbre on December 02, 2011, 04:45:54 pm Yeah, I know. It's not the most usable tool yet. UQMConversationTool v0.03 alpha released: -Conversation Simulator added. -Internal changes to Conversation nodes and options; these now use all the internal statement types. -Changes to the XML format. A lot cleaner now. :) -Allowing multiple alien phrase responses in the ConversationOption editor. -Bugfixes, small tweaks, ... -Note: help dialogs are NOT updated. Yeah, I am lazy. Production-ready-ability: average. Things should work nicely, but it's probably a bit clunky to use right now. Furthermore, there are a few features lacking, and a lot of the more core-game stuff (gamestates, if/then/else statements) aren't implemented and thus need to be done by hand using a CustomCode statement. Binary (Java/zlib): http://mooses.nl/uqm/tools/uqmconversation.zip Sources (zlib): http://mooses.nl/uqm/tools/uqmconversation_src.zip Screenshot of simulator: (http://mooses.nl/uqm/tools/convsim_thumb.jpg) (http://mooses.nl/uqm/tools/convsim.jpg) XML file for this conversation: http://mooses.nl/uqm/tools/conved_examples/picard.xml Todo: a few things... -Rework 'Statement editor' GUI. It's ugly and uses interface elements wrong (tabbedpane where a radiobutton group should be used).. -Allow deletion of statements, conversation options, functions and conversation nodes. -Allow moving of statements. Move up/move down, that sort of thing. -Allow adding statements to conversation options (Conversation Option Editor dialog) -Add statements: Set Gamestate, IF (+ IF GAMESTATE), ELSE -other stuff.. Maybe we'll have some time to elaborate on this baby now... I've got to admit I've never tested it, simply because I had never coded a dialog before. After a quick test : - I have a .txt where the first line is a #(...), this identifier and the corresponding entry are ignored. Most probably because I've played too much with changing the ANSI/UTF-8/CR/LF encoding of this particular file, but I thought I'd let know anyway. - The "disable-afterwards" button should probably be checked by default - Are the "functions used in node XXX" really necessary ? It seems to me you could (and should) replace something like Code: static void main_node (RESPONSE_REF R) { //START BODY GENERATE if (PHRASE_ENABLED (did_we_speak)) { Response (did_we_speak, genF_523217fe_5a4e_4065_a938_6956cbfd275d); } //END BODY GENERATE } //Functions used in main_node static void genF_523217fe_5a4e_4065_a938_6956cbfd275d (RESPONSE_REF R) { //START BODY GENERATE DISABLE_PHRASE (did_we_speak); NPCPhrase (HOWDY); toto (R); //END BODY GENERATE } static void toto (RESPONSE_REF R) { //START BODY GENERATE //END BODY GENERATE } with something like Code: static void main_node (RESPONSE_REF R) { //START BODY GENERATE if (PHRASE_ENABLED (did_we_speak)) { Response (did_we_speak, toto); } //END BODY GENERATE } static void toto (RESPONSE_REF R) { //START BODY GENERATE if (PLAYER_SAID(did_we_speak)) { DISABLE_PHRASE (did_we_speak); NPCPhrase (HOWDY); } //END BODY GENERATE } Title: Re: UQM Tools Post by: Megagun on December 02, 2011, 06:38:52 pm dczanik: I'll probably get around to implementing those suggestions soon, now that the new demo has been released :)
Quinarbre: You're right, the way I'm generating code isn't the best way ever thought of. The main reason why I'm doing things that way, if I recall correctly, was that it made writing the soure-code outputting code easier. Essentially, I loop through every conversation node, and ask it for a source-code representation of the conversation node. There's no further clever logic behind it, which makes things easy to code and quite fail-safe, yet produce really crappy code. As far as the conversation tools in general go: they're probably completely useless because of the crappy code they produce. Ideally, we'd have some file-based representation of a conversation that gets loaded and processed by the game, with some scripting (LUA? Python?) that's embedded in these files that is being executed and deals with advanced dialogue control ("if variable 1 is true and variable 2 is false, yet variable 3 is bigger than 200, enable this conversation option"). Unfortunately, that will take a lot of time, and will demand a certain quality standard of the tools which I'm not certain I can achieve. That is also mostly why I've given up on conversation tools: I just don't think I can make them work well enough in most situations for someone who's not very familiar with the game code, with a GUI that actually sort of makes sense. Title: Re: UQM Tools Post by: dczanik on December 02, 2011, 10:18:37 pm Megagun: I'd like to offer you an additional challenge. As you can see from my post:
http://forum.uqm.stack.nl/index.php?topic=5152.0 I'd like the chance to have animation data outside the code. I bet you could help us with some of that. Something that artists (non-coders) can use to set up animations. Right now, once a comm animation is set up it becomes a delicate balance of working with a programmer to get it to look just right. Most of the time, we're setting for 'good enough' because it's just too much of a burden of time for both sides. Without some fundamental changes, I don't see how we can change this. I'm hoping somebody has the skills to help us out. You keep impressing me with your stuff, so I hope you can find a way to help us. Title: Re: UQM Tools Post by: Megagun on December 02, 2011, 11:34:44 pm dczanik: Yeah, that animation problem sounded like something that needed fixing to me, too. If you can come up with a somewhat detailed description of what you want to do, I might be able to help you. I'm not exactly familiar with what you and the programmers you work with usually talk about when trying to get an animation to look just right.
Title: Re: UQM Tools Post by: dczanik on December 06, 2011, 09:11:41 am Well, my idea is to have everything inside an .XML file and your animation program reads the .XML file. The UQM reads the file too. So what we see in your tool is what we get. I've thought about how the animation file would work. I'm not too familiar with XML but I can take a stab at it.
There's a few types of animation, defined by <animationtype>. They are CIRCULAR, TALK, RANDOM, and YO_YO. CIRCULAR: animation is in a loop. RANDOM: Random frames get used. TALK: Used as a default for talking. It's really just RANDOM, but only fires when the character is talking. This goes away if a timed animation is set. YO_YO: Animation goes through the loop, then comes back in reverse. Think the Cylon eye, or the Knight Rider light. Additional options: Framerate: Frames per second (is this set by the game?) interval: For YO_YO and CIRCULAR: After the animation has played, the time you wait before it plays again. For example, blinking every 4 seconds. frametime: amount of time to hold that frame. Layer: Just like in Photoshop or traditional animation with plates. Different layers can be stacked to have animation behind animations. x_frame: X coordinates of the picture. y_frame: Y coordinates of the picture. Take for example this test of Hayes muttering his lines: For example: Take Hayes muttering this line: http://www.youtube.com/watch?v=EqDVPHN3rJA The COMMANDER.ANI would be: Code: <animation> <animationsubset> <name>BLINK</name> <animationtype>CIRCULAR_ANIM<animationtype> <animationlayer>1</animationlayer> <framerate>30</framerate> <interval>4000</interval> <frames> <animationframe> <framename>commander-001.png<framename> <x_frame>-65</x_frame> <y_frame>-17</y_frame> <frametime>3</frametime> </animationframe> <animationframe> <framename>commander-002.png<framename> <x_frame>-65</x_frame> <y_frame>-17</y_frame> <frametime>3</frametime> </animationframe> <animationframe> <framename>commander-003.png<framename> <x_frame>-65</x_frame> <y_frame>-17</y_frame> <frametime>3</frametime> </animationframe> </frames> </animationsubset> <animationsubset> <name>MOUTH</name> <animationtype>TALK<animationtype> <animationlayer>1</animationlayer> <framerate>30</framerate> <frames> <animationframe> <framename>commander-004.png<framename> <x_frame>-60</x_frame> <y_frame>-19</y_frame> <frametime>2</frametime> </animationframe> <animationframe> <framename>commander-005.png<framename> <x_frame>-60</x_frame> <y_frame>-19</y_frame> <frametime>2</frametime> </animationframe> <animationframe> <framename>commander-006.png<framename> <x_frame>-60</x_frame> <y_frame>-19</y_frame> <frametime>2</frametime> </animationframe> <animationframe> <framename>commander-007.png<framename> <x_frame>-60</x_frame> <y_frame>-19</y_frame> <frametime>2</frametime> </animationframe> <animationframe> <framename>commander-008.png<framename> <x_frame>-60</x_frame> <y_frame>-19</y_frame> <frametime>2</frametime> </animationframe> <animationframe> <framename>commander-009.png<framename> <x_frame>-60</x_frame> <y_frame>-19</y_frame> <frametime>2</frametime> </animationframe> </frames> </animationsubset> <animationsubset> <name>Light_BG</name> <animationtype>CIRCULAR_ANIM<animationtype> <framerate>30</framerate> <interval>0</interval> <animationlayer>1</animationlayer> <frames> <animationframe> <framename>commander-010.png<framename> <x_frame>-722</x_frame> <y_frame>-392</y_frame> <frametime>1</frametime> </animationframe> <animationframe> <framename>commander-011.png<framename> <x_frame>-722</x_frame> <y_frame>-392</y_frame> <frametime>1</frametime> </animationframe> <animationframe> <framename>commander-012.png<framename> <x_frame>-722</x_frame> <y_frame>-392</y_frame> <frametime>1</frametime> </animationframe> <animationframe> <framename>commander-013.png<framename> <x_frame>-722</x_frame> <y_frame>-392</y_frame> <frametime>1</frametime> </animationframe> <animationframe> <framename>commander-014.png<framename> <x_frame>-722</x_frame> <y_frame>-392</y_frame> <frametime>1</frametime> </animationframe> <animationframe> <framename>commander-015.png<framename> <x_frame>-722</x_frame> <y_frame>-392</y_frame> <frametime>1</frametime> </animationframe> <animationframe> <framename>commander-016.png<framename> <x_frame>-722</x_frame> <y_frame>-392</y_frame> <frametime>1</frametime> </animationframe> <animationframe> <framename>commander-017.png<framename> <x_frame>-722</x_frame> <y_frame>-392</y_frame> <frametime>1</frametime> </animationframe> <animationframe> <framename>commander-018.png<framename> <x_frame>-722</x_frame> <y_frame>-392</y_frame> <frametime>1</frametime> </animationframe> <animationframe> <framename>commander-019.png<framename> <x_frame>-722</x_frame> <y_frame>-392</y_frame> <frametime>1</frametime> </animationframe> </animationsubset> And for the voice data. The voice packs would override the TALK animation. Here we have the animation type: TIMED TIMESTAMP would be measured in something like milliseconds or something. The program would just hit the animation at certain time stamps. The command: TEXTFLIP would flip the text to the next screen. NAME is part of the text file that would show. file is the .OGG file. Code: <animation> <animationsubset> <name>BASE_ON_MOON</name> <file>coman027.ogg</file> <animationtype>TIMED<animationtype> <framerate>15</framerate> <layer>1</layer> <frames> <animationframe> <framename>commander-004.png<framename> <x_frame>-60</x_frame> <y_frame>-19</y_frame> </animationframe> <animationframe> <framename>commander-005.png<framename> <x_frame>-60</x_frame> <y_frame>-19</y_frame> <frametime>5</frametime> </animationframe> <animationframe> <framename>commander-006.png<framename> <x_frame>-60</x_frame> <y_frame>-19</y_frame> <frametime>5</frametime> </animationframe> </frames> <timedanimation> <timing> <timestamp>0</timestamp> <file>commander-004.png</file> <action>textflip</action> </timing> <timing> <timestamp>1000</timestamp> <file>commander-005.png</file> </timing> <timing> <timestamp>2300</timestamp> <file>commander-005.png</file> </timing> <timing> <timestamp>3300</timestamp> <file>commander-006.png</file> <action>textflip</action> </timing> <timedanimation> </animationsubset> </animation> The code just goes through all the <timestamp> items. 1. At 0, it shows the first frame, and shows the text. 2. At 1000 ms it brings up the next file. 3. At 2300 ms it brings up the next file. 4. At 3300 ms it brings up the next file, and flips to the next text screen. This is really top of my head stuff. I'm not sure how much more detailed you'd want it. Some stuff can be separated or combined. There's probably types of animation or stuff I haven't thought of just yet. There's definitely more data to the files, but the hopefully the artist won't ever have to open up the text file, your program would do it for them. I know UQM is messing with things like palettes and color tables. So that would have to be added in too. Title: Re: UQM Tools Post by: Megagun on December 09, 2011, 01:23:30 pm Outputting an XML like the one you described at the top should be fairly doable. I'll probably have to alter it a bit so that the references to frames don't copy any data like filename and offsets, as that would probably make coding it in the game a bit easier (load all frames specified in the global animation frame, then load all animation templates which references the global list of frames when needed)
Do you happen to know how the game displays different animation frames? I know that it hides/shows certain frames based on the animation, but do you know if the game does anything with the Z-Index of frames? Detail like that can be pretty important, as I will have to replicate it perfectly in my animation tool. Title: Re: UQM Tools Post by: Elestan on December 09, 2011, 03:40:06 pm Before branching out on your own, I'd suggest reviewing any standards that already exist for doing this sort of thing, like http://www.w3.org/TR/SMIL (http://www.w3.org/TR/SMIL), and the Timed Text specification I linked to above. There may already be libraries that you could leverage for using those, and at the least, it might turn up issues that could inform your own design. The whole software ecosystem is more efficient when we each build on each others' work when possible, instead of reinventing the wheel in every project.
Title: Re: UQM Tools Post by: dczanik on December 09, 2011, 08:36:58 pm Before branching out on your own, I'd suggest reviewing any standards that already exist for doing this sort of thing, like http://www.w3.org/TR/SMIL (http://www.w3.org/TR/SMIL), and the Timed Text specification I linked to above. There may already be libraries that you could leverage for using those, and at the least, it might turn up issues that could inform your own design. The whole software ecosystem is more efficient when we each build on each others' work when possible, instead of reinventing the wheel in every project. Eeegads. The table of contents alone is 23 pages. I'll have to sit down and read that later. I agree. No need to re-invent the wheel. But could that also be overkill for what we're trying to do? Spline animation, SVGs, Linking? Megagun: If you can implement it Megagun, and make it easier enough for the artists, then I don't mind at all. That could also make it easier for something like porting an HTML 5 version of the game. As far as I know, everything I covered in the above pseudo xml stuff would work for us. So I leave that stuff in your capable hands. The game doesn't do anything with Z-index of frames. Every comm image is just wiped out by the previous image. A Z-Index would be really useful to the 6014 team. It's one of the problems I thought the engine would have when doing the animation for the Lurg. So some animation conflicts with other animation. The programmers have done an amazing job trying to hide that wherever possible. I imagined the background throbbing continuously like a heartbeat, but with the arms and tentacles moving that would have messed things up too much. So things are done in an order. Title: Re: UQM Tools Post by: Megagun on December 10, 2011, 06:01:39 pm Thanks for the links, Elestan, but it would seem to me that this is indeed a bit overkill. Currently, all animations are baked into the binaries, and we (presumably) want to get them out of there as soon as possible. I think that using our own format would be the best idea here, as we only have a limited set of features we can support. Although something as you suggested may be very useful, I fear that we'll have to pick-and-choose which features to support from that (based on engine limitations), which would mean that we're using only a subset of the entire standard, which I must say I'm not too fond of.
Also, we'll have to deeply integrate this technology within the UQM engine. This isn't like using something like XMPP to provide realtime communication where you essentially have to tell a library to connect to something and then handle the "receive message" events manually. This technology needs to be integrated into the sound system, the graphics system, and (I guess) the resource loading system. Seems like too much work for what we're trying to do. Title: Re: UQM Tools Post by: meep-eep on December 10, 2011, 06:53:29 pm If you're defining an XML format for conversations, you might look at http://www.w3.org/TR/ttaf1-dfxp (http://www.w3.org/TR/ttaf1-dfxp). It's the W3C standard XML format for timed text. That's interesting... I did not know of that one. Worth looking into.Title: Re: UQM Tools Post by: Elestan on December 10, 2011, 07:12:19 pm Certainly, SMIL/TTML have way more than we need. But they can still be useful in two ways:
First, looking at how the existing standards have specified these features can help to inform the design. If there is particular terminology used in a problem domain, it will reduce confusion if we use the same terms for the same concepts instead of introducing new words (elements, attributes, etc) for the same thing. And if these specs actually are a superset of what's needed, it might be worth re-using the XML format by implementing just the subset that you need, rather than inventing a whole new set of tags. The more similar your approach is to existing standards, the less cognitive clash it will cause to those who know both. Second, if SMIL is capable of doing what you need, it's worth stepping back and asking whether you could just pull in an existing open-source SMIL library like Ambulant, and save yourself a bunch of work. Learning to use someone else's tech may be less fun than developing the tech yourself, but it's usually more productive in the long run. Title: Re: UQM Tools Post by: Quinarbre on December 11, 2011, 06:40:14 pm The game doesn't do anything with Z-index of frames. Every comm image is just wiped out by the previous image. More precisely, the animation frames are displayed in a fixed order, which is (last time I checked) the reverse of the one you define them in the LOCDATA structure. Every animation has a "neutral" frame (i.e. a copy of a portion of the base comm picture) which is displayed when the animation is inactive. Title: Re: UQM Tools Post by: Megagun on December 22, 2011, 07:58:39 pm I just released a new version of UQMAnimationTool. I've decided to put up the source code and .jar builds on the Project 6014 SVN repositories (for quicker updates/bugfixing), so grab it from there if you want to use it. Follow Project 6014 if you want to be notified of future updates to UQMAnimationTool.
I've experimented with SMIL a bit. Barely scratched the surface of SMIL possibilities, but it seems that it might be possible to create something neat with this. Proof of concept Starbase commander animation can be found here (http://mooses.nl/uqm/wip/hayes-smiltest.zip). I'll need to do some further testing/study for more interactive animations and a real proper way to integrate the various different kinds of animations into a nice and tidy SMIL file, but I think it might indeed be interesting to look at SMIL for the animation systems. Title: Re: UQM Tools Post by: dczanik on December 22, 2011, 08:17:30 pm Very Cool!
One feature that would be nice, if there's an error in the file, to have a checkbox to 'ignore all other errors'. Example: I wasn't sure if the UQM player played .SMIL files. So I tried to open the file int he player. :-\ 120 times I had to click OK The fact it's in the 6014 SVN is awesome. Now I know I'll the team always have the latest verison :) For those interested, I found a .SMIL player: http://www.ambulantplayer.org/ It's open source, offers browser plugins, multiple operating systems (Windows, Linux, and Mac) and other demos of what's possible using SMIL. Title: Re: UQM Tools Post by: Megagun on December 22, 2011, 08:41:31 pm One feature that would be nice, if there's an error in the file, to have a checkbox to 'ignore all other errors'. Whoops. Yeah, that's annoying. Fixed as per r2038 (http://code.google.com/p/project6014/source/detail?r=2038) by making all errors appear in one giant textual dialog box, which has the added benefit of being copy-paste-able. :)Example: I wasn't sure if the UQM player played .SMIL files. So I tried to open the file int he player. :-\ 120 times I had to click OK For those interested, I found a .SMIL player: Yep, I've been using that one to test my stuff with. Works quite well. There's also some kind of GUI editor for SMIL presentations called limsee2 (SMIL2.1 and below only; http://limsee2.gforge.inria.fr/), but I wasn't really able to get anything truly spectacular out of that, as it's a slightly odd tool (but probably quite impressive; I should definitively look into that, especially since it's Java-based and Open-source)http://www.ambulantplayer.org/ It's open source, offers browser plugins, multiple operating systems (Windows, Linux, and Mac) and other demos of what's possible using SMIL. Anyways, looking further into SMIL seems to reveal that there isn't any kind of randomize feature, so having animations that depend on UQM's RANDOM animation type may be impossible with SMIL, unless I'm not looking well enough. Title: Re: UQM Tools Post by: dczanik on December 23, 2011, 08:11:14 pm I got a chance to play around with this myself. I'm already excited about some of the possibilities this could bring.
Limsee2 has a really weird UI and I wasn't able to do much with it. I just hand coded the text files myself. I'm comfortable with HTML so it's not a problem. I do wonder about some technical hurdles. 1. Is this project really still active? Most of the stuff on this seems to be last documented in 2008. Has HTML5 replaced the need for this? 2. Fonts. I can put text into this thing pretty easily. However, it seems to go the way of the web, and not allow me to install the fonts I want. 3. Font graphics. I can put in individual graphics instead of the fonts, but that's hand coding every letter of every sentence. 4. Sound. This has sound levels in the SMIL file, but can we still use the set sound levels in the game? 5. Random animation. There is none, but that's not to say we really need it. 6. Translations. Possible, but things would have to change in the engine there too. 7. Lip syncing. Lip syncing is a pain. You're dealing with 1/10ths of a second. I spent about a half hour just trying to get an "Okay" lip synced properly. A timeline view where I can highlight certain parts and test the animation there would be ideal. I'd imagine a timeline view, where I can drag & drop certain mouth movements to fit the piece. A tree menu where everything is taken from the region areas. This is one of those things that just suck up my time because the idea of using it is so exciting. With all the possible features, there's a lot of stuff I can do with this that we've never thought about because it just isn't possible in the old system. For example, having a slow pan/zoom on the ship in the 6014 options menu. But until this is in the engine, it's just me playing around :) Title: Re: UQM Tools Post by: Elestan on December 23, 2011, 08:47:01 pm I got a chance to play around with this myself. I'm already excited about some of the possibilities this could bring. I'm glad to hear it. My hope is that UQM will evolve over time to leverage whatever free standards and open-source libraries are available and useful to it. SMIL Animations, TTML subtitles, XML data/save files, WOFF fonts, XLIFF localization files, etc. IMHO, all of these pieces of generic infrastructure shouldn't really be part of UQM's core, and it's better to outsource them. Quote Has HTML5 replaced the need for this? From what I understand, HTML5 has no timing component. When what you want is to have a combined stream of audio+video+subtitles, SMIL seems to be the primary applicable standard. Quote Limsee2 has a really weird UI and I wasn't able to do much with it. I just hand coded the text files myself. I'm comfortable with HTML so it's not a problem. The Limsee3 project (http://limsee3.gforge.inria.fr (http://limsee3.gforge.inria.fr)) might be of interest. Title: Re: UQM Tools Post by: Megagun on December 25, 2011, 12:39:55 am I've added some basic animation features to the Animation tool, plus an exporter that exports a SMIL file based on the loaded frames and added animations. See http://code.google.com/p/project6014/source/detail?r=2041 for more info
Unfortunately, experimenting with generating various 'complete' .smil animation files revealed a few things: 1) Ambulant reloads image files continuously. This causes animations to slow down quite a bit when playing them in ambulant, especially with a lot of simultaneous animations active. 2) Ambulant 2.2 doesn't seem to respond to SMIL's "prefetch" feature. For some reason, it tries to decode .png images using Ambulant's audio decoding routines, which obviously doesn't work and causes Ambulant to behave erratically. 3) A nightly build of Ambulant does seem to support prefetching (I don't get that audio error!), but it crashes quite quickly. 4) There aren't many other SMIL players around (on Windows); even players that supposedly support SMIL don't appear to at all. Now, I might've done something wrong somewhere which causes Ambulant to continuouly read files form my harddrive. Not entirely sure. Either way, we need to decide how we want to proceed. I think we have several options here: 1) Implement SMIL in p6014, either the entire thing or a small subset of it. UQMAnimationTool is dropped in favor of Limsee, but it'll be used to convert most data once to a format understandable by Limsee. 2) Use a SMIL-like file specification to define animations, but don't implement a full SMIL-player. We could use the current rendering/timing code but make it load the configuration from disk rather than having all that embedded in code. UQMAnimationTool is used for most/all animation work. 3) Use our own custom specification to define animation-files. UQMAnimationTool is used for most/all animation work. I'm guessing someone familiar with the core p6014 code will need to evaluate these three options. Option #1 might be the best-case scenario, but I wonder how long it'll take and what the repercussions are. Title: Re: UQM Tools Post by: Elestan on December 25, 2011, 06:50:45 am I think we have several options here: 1) Implement SMIL in p6014, either the entire thing or a small subset of it. UQMAnimationTool is dropped in favor of Limsee, but it'll be used to convert most data once to a format understandable by Limsee. 2) Use a SMIL-like file specification to define animations, but don't implement a full SMIL-player. We could use the current rendering/timing code but make it load the configuration from disk rather than having all that embedded in code. UQMAnimationTool is used for most/all animation work. 3) Use our own custom specification to define animation-files. UQMAnimationTool is used for most/all animation work. There's another option: Ambulant is LGPL licensed, so we could take the relevant library components of it, link them into p6014, and use them to do the animations, fixing bugs where necessary. That'll still be a chunk of work, but it might be less than the other options. Title: Re: UQM Tools Post by: Megagun on December 27, 2011, 03:28:35 pm There's another option: Ambulant is LGPL licensed, so we could take the relevant library components of it, link them into p6014, and use them to do the animations, fixing bugs where necessary. That'll still be a chunk of work, but it might be less than the other options. Title: Re: UQM Tools Post by: Elestan on December 27, 2011, 05:56:12 pm That's what I was thinking about when writing bulletpoint #1, but I think it'll still be a nightmare to do. Not only is it probably just a pain in general (the timing stuff needs to be integrated witch each other, as will the graphics/sound/resource stuff), but Ambulant is written in C++ whereas UQM is written in C. I don't know how hard it is to combine C and C++ (my knowledge and experience with both C and C++ is rather limited), but I wouldn't be surprised if it turns out that it's not easy at all. Heh...funny you should mention that. For the last six months, I've been submitting patches to the core to make it possible to link C++ code to UQM. It's getting pretty close at this point. Combining C and C++ is actually not that hard; it's kind of like mixing American English and British English. Mostly things are the same; you just have to be careful not to ask to bum a fag. That still doesn't mean it'll be easy to integrate the two, of course, but when the other option is writing your own SMIL engine (or other animation player) from scratch, I think it may be the easier choice. Title: Re: UQM Tools Post by: dczanik on December 29, 2011, 12:39:12 am Megan: I'm in favor of modifying UQM-Animation Tools to implement a partial SMIL file. The reason why? Because I think the chances of our requests on here have a better chance of getting implemented than on Limsee or Ambulant.
Limsee 3 was last updated 2 years ago (http://limsee3.gforge.inria.fr/public-site/news.html). :-\ UQM-Animation Tools was last updated yesterday. I've been trying out the latest version, and most of what's needed is already there. Right now, you've got the basics down to take the existing UQM animations and export them into a SMIL file. The biggest obstacle seems to be just implementing those .SMIL files into the engine. We don't need all the features. I'd rather have a partial implementation just so we can get the original animations up and running. Timing it with audio files, I can at least implement lip syncing into the game. It looks you can use the ambulant core in c++ to play the .smil animations, but is that something we would want with the bugs you talked about? I can find no other libraries that makes it easy to implement .SMIL files. |