--- Log opened Sun Feb 24 12:24:31 2008
12:24 -!- dooglus_ [n=dooglus@par69-10-88-178-227-1.fbx.proxad.net] has joined #synfig
12:24 -!- Irssi: #synfig: Total of 15 nicks [1 ops, 0 halfops, 0 voices, 14 normal]
12:24 -!- dooglus [n=chatzill@r6ac156.net.upc.cz] has quit ["ChatZilla 0.9.81 [Firefox 2.0.0.12/2008020121]"]
12:24 -!- Irssi: Join to #synfig was synced in 35 secs
12:25 -!- You're now known as dooglus
12:25 < dooglus> I'm logging again now
12:26 < dooglus> the DNS hasn't updated everywhere yet, but I am logging.
12:26 < pabs3> cool
12:27 < dooglus> irssi settings I use:
12:27 < dooglus>   "fe-common/core" = {
12:27 < dooglus>     autolog_path = "~/irclogs/$tag/${0}-%Y-%m-%d.log";
12:27 < dooglus>     autolog = "yes";
12:27 < dooglus>   };
12:27 < dooglus> that's copied from ~/.irssi/config
12:30 < pabs3> thanks
--- Log closed Sun Feb 24 12:33:16 2008
--- Log opened Sun Feb 24 12:33:33 2008
12:33 -!- dooglus [n=dooglus@par69-10-88-178-227-1.fbx.proxad.net] has joined #synfig
12:33 -!- Irssi: #synfig: Total of 14 nicks [1 ops, 0 halfops, 0 voices, 13 normal]
12:33 -!- dooglus_ [n=dooglus@par69-10-88-178-227-1.fbx.proxad.net] has joined #synfig
--- Log opened Sun Feb 24 12:33:40 2008
12:33 -!- dooglus_ [n=dooglus@par69-10-88-178-227-1.fbx.proxad.net] has joined #synfig
12:33 -!- Irssi: #synfig: Total of 15 nicks [1 ops, 0 halfops, 0 voices, 14 normal]
--- Log closed Sun Feb 24 12:33:44 2008
12:33 -!- dooglus_ [n=dooglus@par69-10-88-178-227-1.fbx.proxad.net] has quit [Client Quit]
--- Log closed Sun Feb 24 12:33:48 2008
--- Log opened Sun Feb 24 12:33:56 2008
12:33 -!- dooglus [n=dooglus@par69-10-88-178-227-1.fbx.proxad.net] has joined #synfig
12:33 -!- Irssi: #synfig: Total of 14 nicks [1 ops, 0 halfops, 0 voices, 13 normal]
--- Log closed Sun Feb 24 12:34:01 2008
--- Log opened Sun Feb 24 12:34:13 2008
12:34 -!- dooglus [n=dooglus@par69-10-88-178-227-1.fbx.proxad.net] has joined #synfig
12:34 -!- Irssi: #synfig: Total of 14 nicks [1 ops, 0 halfops, 0 voices, 13 normal]
12:34 < dooglus> I think I just set the IRC box up to automatically run irssi when rebooted
12:34 -!- Irssi: Join to #synfig was synced in 22 secs
12:35 < dooglus> apparently it wasn't down for long at all recently, but the IP address changed and the DNS didn't update, so I couldn't connect to it.  with this irssi-on-reboot in place I won't need to, it'll keep on logging as soon as it's back up
12:35 < dooglus> "screen -d -m irssi" seems to be what I needed to run from the boot script
12:38 < pabs3> ddclient is useful for keeping dns up to date (for mine.nu/etc domains)
12:39 < dooglus> did Yoyobuae say whether studio worked after his changes?
12:40 < dooglus> I think rincevent.net is a static IP - but he's just changed ISPs I think
12:40 < dooglus> so it'll change this once, then stay still again
12:42 < pabs3> hmm, he didn't, but he did say the bmp renderer works, I'm assuming he didn't test it from the command line
12:45 < dooglus> I'm building it on Windows here
12:45 < dooglus> I reinstalled everything and it seems to be working now
12:46 < dooglus> except I can't 'svn ci' at all
12:46 < pabs3> forgot yr pass?
12:47 < dooglus> no, it doesn't ask for a pass
12:47 < dooglus> it just hangs
12:48 < dooglus> says something about 'authentification realm' but doesn't prompt for a password
12:48 < dooglus> I have nothing to check in now anyway - my commit was going to be very similar to Yoyobuae's
12:49 < pabs3> did you check out with https?
12:50 < dooglus> no, I didn't check out at all
12:50 < dooglus> I just copied my linux working dir
12:51 < dooglus> which is http
12:58 < pabs3> ah, I thought you could only commit over https
13:00 -!- Zelgadis [n=zelgadis@87.103.170.67] has quit [Read error: 113 (No route to host)]
13:06 < dooglus> I don't think that's the case
13:07 < dooglus> but I very rarely commit using that svn working directory, so maybe it's changed
13:15 -!- Zelgadis [n=zelgadis@87.103.170.104] has joined #synfig
13:18 -!- TMM [n=hp@c5147518c.cable.wanadoo.nl] has joined #synfig
13:38 -!- TMM [n=hp@c5147518c.cable.wanadoo.nl] has quit [Remote closed the connection]
13:40 -!- TMM [n=hp@c5147518c.cable.wanadoo.nl] has joined #synfig
13:48 -!- TMM [n=hp@c5147518c.cable.wanadoo.nl] has quit [Remote closed the connection]
13:49 -!- TMM [n=hp@c5147518c.cable.wanadoo.nl] has joined #synfig
15:13 < dooglus> the windows build finihed
15:13 < dooglus> it still crashes a lot
15:13 < Zelgadis> dooglus: is it possible to make synfig not crash when it fails to make autosave?
15:14 < dooglus> Zelgadis: yes, I guess so.  I didn't know it did crash - I guess I've never seen it fail to autosave
15:14 < dooglus> why would autosave fail?  disk full?
15:14 < Zelgadis> take a look at screenshots in #1837445
15:16 < dooglus> Zelgadis: does the parent of those directories exist?
15:17 < dooglus> I see the 'UNABLE TO CREATE' messages
15:17 < Zelgadis> C:\Documents and Settings\ exists
15:17 < dooglus> it can't make a folder called 'Synfig' inside a Russian named folder - but does the Russian named folder exist already?
15:18 < dooglus> yes, but what about the next level down?
15:18 < Zelgadis> Yes it exists
15:18 < Zelgadis> but it incorrectly interprets russian characters
15:18 < Zelgadis> I think it tries to read them as unicode
15:20 < Zelgadis> but windows not stores filenames as unicode
15:31 < dooglus> what if you set HOME to be somewhere else?
15:31 < dooglus> create c:\home for example
15:31 < Zelgadis> I'll try now
15:31 < dooglus> then set HOME to c:\home
15:31 < Zelgadis> how to set HOME in windows?
15:32 < dooglus> settings > control panel > system > advanced > environment variables > new ...
15:32 < dooglus> or something like that
15:34 < Zelgadis> HOME = c:\home
15:34 < Zelgadis> Everything OK
15:34 < Zelgadis> No error mesages
15:34 < dooglus> I looked at the Glib source - it uses HOME on Windows if it exists
15:35 < Zelgadis> synfig(564) [20:34:06] info: Created directory "c:\home\Synfig"
15:35 < Zelgadis> synfig(564) [20:34:08] info: Created directory "c:\home\Synfig\tmp"
15:35 < Zelgadis> everythimg works fine
15:35 < dooglus> what if you set HOME to c:\Document and Settings\russian name\
15:37 < Zelgadis> I've got same errors: Unable to create...
15:37 < Zelgadis> when set HOME dir as you said
15:37 < dooglus> ok
15:37 < dooglus> so you have a workaround at least
15:38 < Zelgadis> Yes. I don't need this workaround, but it could be included to installer somehow
15:39 < Zelgadis> I'll write this as comment to bug
15:39 < Zelgadis> maybe atrus do womething
15:39 < Zelgadis> *something
15:39 < dooglus> the problem is, what if 2 different users on the same machine use synfig?
15:39 < Zelgadis> Oh...
15:39 < dooglus> they should have different places to store their settings
15:40 < dooglus> that's why their Docs&Settings folder was being used
15:40 < Zelgadis> yeah, but it's better than nothing
15:40 < dooglus> each user can set their own HOME value, of course
15:40 < dooglus> but can the installer do it for them?  I doubt it
15:41 < Zelgadis> you right.
15:41 < Zelgadis> setting HOME dir override settings place for ALL applications. - I forgot that
15:42 < Zelgadis> But can synfig not crash if it fails to write to dir?
15:43 < dooglus> yes, it can switch to trying to use some other folder I guess
15:43 < dooglus> but how can we know which folder the user can write to?
15:43 < Zelgadis> I noticed interesting thing. If there are no changes made to document - then it isn't crashes - just error in terminal
15:43 < dooglus> or do you mean just give up trying to save backups?
15:43 < Zelgadis> Yes, just give up
15:44 < Zelgadis> backups and settings
15:45 < Zelgadis> I see Error "Unable to save C:\Documents and Settings\...\Synfig\recentfiles" if no changes are made to document
15:46 < Zelgadis> It seems synfig not crashes when failed to save settings
15:52 -!- rubikcube [n=kvirc@dslc-082-082-094-128.pools.arcor-ip.net] has joined #synfig
15:53 < pabs3> hmm, no entry in the Feb challenge by rore yet :(
15:54 < pabs3> anyone have an idea for the March challenge?
16:15 < Zelgadis> night all
16:17 -!- Zelgadis [n=zelgadis@87.103.170.104] has quit ["????!"]
16:27 < pabs3> KiBi: any idea if rore is working on a splash?
16:28 < KiBi> pabs3: Asking her, one mom.
16:28 < KiBi> pabs3: Not right now at least, she has no laptop, and here with me in Brussels.
16:28 < pabs3> ah, we were going to close the challenge this weekend
16:28 < KiBi> pabs3: not yet, lack of time
16:29 < KiBi> ah, ok
16:30 < pabs3> lets make it monday, just in case she has time & ideas for it
16:52 < rubikcube> I guess this has been asked before, I don't want it to sound like a flame, but want to know the answer nevertheless: What are the reasons of not merging synfig(studio) more with inkscape?
16:55 < pabs3> no-one has done it
16:55 < pabs3> or tried to do it
16:58 < rubikcube> I recognize it would have to be able to do a lot more than what is natively supported by svg, which would make it probably impossible to fully include it there
16:59 < rubikcube> but I simply miss the easiness of inkscape in synfig (ok, I'm used to the one and just learning the other)
16:59 < pabs3> there is a partial svg converter: http://synfig.org/Converters
17:01 < rubikcube> yes I know, but I was thinking more in a general way, like having the same shortcuts for basically the same tools and such
17:01 < rubikcube> but that's much more of a vision than a clear way to go (provided it is useful and anyone is willing to do the work at all)
17:02 < pabs3> someone to do the work is the main thing. atm we only have one developer (dooglus) and a few people submitting the occasional patch
17:27 < dooglus> rubikcube: what do you mean by 'merging'?
17:28 < rubikcube> implementing the non-svg parts as a plugin or similar on top of inkscape.
17:28 < rubikcube> I don't know if this is doable with less efforts than a complete rwrite though
17:28 < rubikcube> s/rwrite/rewrite/
17:31 -!- Yoyobuae_ [n=Yoyobuae@201.224.135.156] has joined #synfig
17:31 -!- Yoyobuae_ is now known as Yoyobuae
17:34 < pabs3> anyone got a favourite for the Feb challenge?
17:41 < KiBi> rore might be interested in a brick-oriented splash screen :]
17:41 < KiBi> (Brussels...)
17:41 < KiBi> pabs3: She might be doing some stuff tonight.
17:41 < KiBi> I'll keep you posted.
17:41 < pabs3> cool :)
17:43 < rubikcube> Can I setup the lower dialog buttons (like Add keyframe, duplicate keyframe, ...) so that they show only the icon and not the text (or the text only as a tooltip?)
18:02 < dooglus> rubikcube: that's a GNOME preference
18:03 < rubikcube> somehow GIMP can do it... but maybe I should also just get a gnome configurator...
18:22 < dooglus> I think it comes with one
18:23 -!- pabs3 [n=pabs@d122-105-74-150.per9.wa.optusnet.com.au] has quit [Read error: 110 (Connection timed out)]
18:28 < rubikcube> what comes with it? I don;t have gnome installed here
18:29 -!- genete [n=Genete@84.122.52.120.dyn.user.ono.com] has joined #synfig
18:40 < genete> hi
18:41 < genete> is there IRC log for today?
18:42 -!- pixelgeek [n=chatzill@c-71-59-140-184.hsd1.or.comcast.net] has joined #synfig
18:43 < genete> hi pixelgeek :)
18:43 < pixelgeek> Wha - let me resume from hibernate first!
18:43 < pixelgeek> Hi genete !
18:44 < genete> I'm catching the logs but it seems that there is not log for today :(
18:44 < Yoyobuae> try the color logs
18:44 < genete> ah, a few minutes ago synfig.org was down. Now is up
18:47 < cizra> Can I somehow loop an action?
18:48 < cizra> S'pose I have an object that oscillates between two places. I want it to do it for a long time and I'm too lazy to set up the waypoints manually.
18:48 < cizra> Can it be automated?
18:48 < genete> cizra: Try this: http://synfig.org/Time_Loop_Layer
18:51 < cizra> Thanks.
18:52 < genete> Also you can do funny thing converting any parameter to Time Loop. See this: http://synfig.org/Convert#Time_Loop
18:59 < cizra> I absolutely didn't understand how to do it, though.
18:59 < cizra> I created a new Time Loop layer. What next?
18:59 < cizra> How do I tell it to swallow that object movement?
19:00 < genete> cizra: are you talking about Time Loop Layer?
19:00 < pixelgeek> encapsulate the layers you want with the movement
19:01 < pixelgeek> and put the timeloop above it
19:01  * cizra plays around
19:02 < cizra> I have one (compound, encapsulated) object. It has a bunch of defined waypoints. So I now encapsulate this object with the time loop?
19:02 < pixelgeek> yes
19:02 < cizra> Or is there some special "movement layer"?
19:02 < cizra> Yes to which question?
19:02 < cizra> You're like my old English teache.
19:03 < cizra> When asked if A or B was true, she would answer "emm.. yes!".
19:03 < pixelgeek> If you already have the movements in the compound encapsulated object, with the waypoints, you can just add the time loop layer
19:03 < genete> the final encapsulation would look like this: Encapsulate(Time Loop, Stuff)
19:03 < genete> Where Stuff can be encapsulated or whatever
19:03 < pixelgeek> yes to the first, I hadn't seen the 'or' when I replied.  
19:04 < cizra> Hehe, ok
19:04 < pixelgeek> (Actually 'yes' to both :D )
19:04 < pixelgeek> :P
19:04  * cizra  tries
19:06 < cizra> Why's the preview so ugly now? The resolution went really really low )=
19:07 < genete> Caret Menu -> View ->toggle Use Low Res.
19:07 < pixelgeek> There's a simple example you can download from http://synfig.org/Walk_Cycle
19:08 < cizra> No, the preview is still as ugly.
19:08 < cizra> (although the editing-time picture is nicer now
19:08 < pixelgeek> Do you have a sif file you can share?
19:09 < cizra> yes
19:09 < cizra> http://perpetuum-immobile.de/~elmo/RST.sifz
19:09 < genete> ah preview! You can modify the preview size, By default it is 50% of the real resolution
19:09 < genete> also the frame rate can be changed
19:10 < genete> it is set to 1/2 of the fps of the project
19:10 < cizra> ooh, nice
19:14 < genete> dooglus: your commit r1800 is satisfiying my feature request number 1801356 ;) Thanks
19:16 < pixelgeek> cizra: I think we usually say sniffed 'on' LAN rather than 'in' LAN (certainly 'on the wire')
19:16 < cizra> Thanks
19:16 < pixelgeek> although 'in the Local Area Network' does sound more correct)
19:16  * pixelgeek scratches head
19:16 < cizra> Much appreciated.
19:16 < pixelgeek> It's looking good
19:17 < pixelgeek> Where's the timeloop come in?
19:17 < cizra> Me foreign, me poor speaking english
19:17 < cizra> Well, the first time the blue and green boxen talk to each other
19:17 < cizra> The TCP packet must move then a couple of times
19:18 < factor> I am not foreign , still speak bad english
19:18 < cizra> Then, later on, when the action begins again, it must oscillate for a long time.
19:20 < Yoyobuae> which box is the server and which the client =)
19:21 < cizra> It's said on 21th second.
19:21  * pixelgeek English, speak bad American
19:22 < pixelgeek> green is client, blue is server
19:22 < pixelgeek> I think many people would expect it from left to right...
19:23 < Yoyobuae> oh, so you want to show the SYN, SYN|ACK, ACK packets
19:23 < Yoyobuae> ?
19:24 < cizra> yes
19:24 < pixelgeek> what's the easiest?  Striped gradients?
19:24 < cizra> It was visible, before I started mucking around with that time loop layer.
19:24 < pixelgeek> drawing rectangles?
19:25 < cizra> Fetch that sifz again.
19:25 < cizra> I undid a couple of times.
19:25 < cizra> hm..
19:25 < cizra> "undid" doesn't sound right...
19:25 < cizra> Sounds like I'm undoing someone's pants or something.
19:25 < cizra> Anyway, fetch that file again. Now it has a nice packet going to and fro.
19:25 < pixelgeek> No the timeloop is there.
19:26 < cizra> That's the point. It fucked something up.
19:26 < cizra> The current version (which is really the old version) has no time loops and works reasonably well.
19:26 < pixelgeek> Hang on - synfig just crashed
19:27 < Yoyobuae> if you change the duration for time loop to 'EOT' then timeloop has no effect (assuming the other parameters are zero)
19:27 < Yoyobuae> just type in 'EOT' in the Duration
19:28 < cizra> What's the shortcut for "redo"?
19:28 < pixelgeek> It looks like your time loop is repeating the first second of action - you know before you have any packets drawn
19:30 < cizra> Probable.
19:32 < cizra> Moving the start time to 4s made it make exactly one pass.
19:35 -!- TMM [n=hp@c5147518c.cable.wanadoo.nl] has quit ["Ex-Chat"]
19:39 < Yoyobuae> cizra: what version are you using?
19:41 < cizra> 0.61.07, Debian standard
19:42 < timonator> :)
19:42 < Yoyobuae> http://members.lycos.co.uk/yoyobuae/RST_timelooped.sifz
19:43 < Yoyobuae> i set a few waypoints on the time loop layer's parameters
19:43 < cizra> Thanks!
19:44 < Yoyobuae> but i think you dont want the ACK packet looped =)
19:44 < Yoyobuae> you can add one more packet at 7seconds
19:45 < Yoyobuae> remove the waypoints at 6s in time loop layer, and set them instead at 7s
19:45 < cizra> Erh
19:45 < cizra> Actually I don't want to touch the SYN...ACK sequence.
19:45 < cizra> It works perfectly.
19:45 < cizra> I want to loop the last animation.
19:46 < Yoyobuae> you meant after the "server", "client" labels appear, right?
19:46 < cizra> See it? Where the narration says "Suppose we have an open connection".
19:46 < cizra> yes
19:47 < Yoyobuae> oh, i see XD i didnt see that part of animation
19:47 < cizra> Well, now you did.
19:48 < genete> cizra: Insert a TIme Loop Layer inside the TCP packet layer over the rectangle
19:49 < Yoyobuae> genete: he already did, but he needs only a part of the animation looped
19:49 < genete> Then set the Lock Keyframes Button to "None"
19:50 < genete> At frame 0f in animation edition mode set the Duration to EOT
19:50 < genete> it would let the animation like the original
19:50 < genete> then go to frame
19:50 < genete> 21s
19:51 < cizra> (encapsulate (encapsulate timeloop rectangle) text) -- like this?
19:52 < genete> The time loop layer can be inside the TCP packet layer
19:52 < genete> you don't need to encapsulate it again
19:52 < cizra> So, (encapsulate timeloop TCP_packet)
19:53 < genete> no
19:53 < Yoyobuae> TCP_packet(time loop, Packet text, Packet box)
19:53 < cizra> OK
19:53 < genete> TCP packet(Time Loop, packet text, packet box)
19:53 < genete> :)
19:53 < cizra> Okie
19:53 < Yoyobuae> oh actually that doesn't work XD
19:54 < Yoyobuae> the TCP_packet origin parameter is animated too
19:54 < cizra> Lock Keyframes Button.. Found it, but what does it do, in general?
19:54 < genete> right
19:54 < genete> then you need to encapsulate the TCP packet layer
19:55 < Yoyobuae> it inserts waypoints to keep the previous and/or next keyframes fixed
19:55 < cizra> Auugh.
19:55 < cizra> I'm confusde.
19:56 < genete> cizra: youd movement is acomplished by the TCP packet paste canvas layer so it should be under a TIme Loop layer
19:56 < factor> huh tcp synfig encasulate?
19:56 < factor> did I miss something
19:56 < factor> encapsulate
19:56 < factor> a new layer I am not aware of 
19:56 < Yoyobuae> factor: it's a composition cizra is working on
19:56 < cizra> OK, so encapsulate(TCP_packet, time_loop)
19:56 < factor> cool
19:56 < cizra> Like this?
19:57 < genete> no
19:57 < factor> sounds neat
19:57 < genete> time loop avobe
19:57 < cizra> Does the order matter?
19:57 < genete> yes!
19:57 < cizra> ?!?
19:57 < Yoyobuae> time loops ONLY affect what is under it
19:57 < genete> layers affects from top to bottom
19:57 < cizra> Well, now I know.
19:58 < cizra> OK, now what? Keyframes button set.
19:58 < cizra> What did it do, anyway?
19:58 < cizra> The time loop has no "duration".
19:58 < cizra> It has z depth, start time and end time.
19:58 < cizra> Did you mean to set end time to EOT?
19:59 < Yoyobuae> oh, the parameters had a little name change a while ago XD i forgot about that
20:00 < cizra> Oh my.
20:00 < cizra> I got a time offset now.
20:01 < cizra> The packet travelling loop is offset by several seconds now.
20:03  * cizra got rid of the "start time". Now it's OK
20:04 < cizra> Ok, looks mighty fine..
20:04 < cizra> .. except that I haven't actually managed to get the latter part to loop.
20:04 < cizra> How to do that?
20:05 < genete> cizra: I'm trying but I'm getting strange things  .... lol
20:06 < Yoyobuae> try again: http://members.lycos.co.uk/yoyobuae/RST_timelooped.sifz
20:07 < cizra> Nope
20:07 < cizra> Doesn't show the packet at all.
20:08 < Yoyobuae> hmm, the thing is that your version is a bit different
20:09 < cizra> Hey, I've got an idea
20:09 < cizra> Let's leave the current TCP packet alone.
20:09 < cizra> Let it die of loneliness.
20:09 < cizra> Let's get another packet!
20:10 < cizra> I understand this would be easy to animate?
20:10 < Yoyobuae> it's pretty much the same though
20:11 < cizra> Hm, if you say so.
20:11 < Yoyobuae> by the way, what parameters does your time loop layer has
20:11 < cizra> Anyway, can you come up with a solution that keeps oscillating forever?
20:11 < genete> cizra: your packet travels vertically too. only a little but enough to make the loop weird
20:11 < cizra> start time 0, end time 1 (your version)
20:11 < cizra> genete: I can fix that
20:12 < cizra> It was intended, but it's not important.
20:12 < genete> I'll write a recipe to follow and paste here. Please be patience
20:12 < cizra> I'm all patience!
20:12 < genete> :)
20:13 < cizra> (should have been "patient", in case you missed the sarcasm)
20:15 -!- TMM [n=hp@ip565b35da.direct-adsl.nl] has joined #synfig
20:18 < genete> cizra: ready to go?
20:19 < cizra> yep
20:19 < genete> Encapsulate TCP packet
20:19 < genete> Over TCP packet layer insert a Time Loop layer
20:19 < genete> The Time Loop layer has tree parameters: Link Time, Local Time and Duration
20:19 < genete> At frame 0f set waypoints to the parameters like this:
20:19 < genete> Link Time = 0f
20:19 < genete> Local Time = 0f
20:19 < genete> Durtion = EOT (end of time)
20:19 < genete> At frame 21s create waypoints for the parameters to be:
20:19 < genete> Link Time = 21s
20:19 < genete> Local Time = 21s
20:19 < genete> Durtion = 2s
20:19 < genete> To avoid the keyframe locking set the Keyframe Lock button to "Keyframe Lock set to none". Do this before insert the waypoints.
20:19 < genete> Since frame = 21s the TCP packet layer animation would repeat for a duration of 2 seconds.
20:20 < genete> and the waypoints fro frame 21s must be Constant interpolation
20:20 < cizra> 21:19 < genete> The Time Loop layer has tree parameters: Link Time, Local Time and Duration
20:20 < cizra> incorrect
20:20 < cizra> It has Z depth, start time and end time.
20:20 < genete> forget Zdepth
20:20 < Yoyobuae> Actually, his Time Loop Layer doesnt have Link Time, Local Time and duration parameters
20:21 < genete> cizra: sorry, you have an old TIme Loop layer version
20:21 < cizra> Apparently
20:22 < cizra> How to add waypoints for the time layer?
20:22 < cizra> Oh, figured out
20:22 < genete> Mmm I don't remember how to use the old version...
20:22 < genete> And cannot test it 
20:22 < Yoyobuae> instead of:
20:23 < Yoyobuae> 	<genete>	Link Time = 0f
20:23 < Yoyobuae> 	<genete>	Local Time = 0f
20:23 < Yoyobuae> 	<genete>	Durtion = EOT
20:23 < Yoyobuae> do:
20:23 < Yoyobuae>  Start Time = 0f
20:23 < Yoyobuae>  End Time = EOT
20:23 < Yoyobuae> instead of:
20:23 < Yoyobuae> 	<genete>	Link Time = 21s
20:23 < Yoyobuae> 	<genete>	Local Time = 21s
20:23 < Yoyobuae> 	<genete>	Durtion = 2s
20:23 < Yoyobuae> do:
20:23 < Yoyobuae>  Start Time = 21s
20:23 < Yoyobuae>  End Time = 23s
20:23 < Yoyobuae> i think that's how it works
20:23 < genete> right
20:23 < genete> and the waypoints at 21s to be Constant
20:24 < cizra> Why is there 2 sets of waypoints in 2 rows (there's room for 3 rows)?
20:25 < Yoyobuae> which layer?
20:25 < cizra> Why did the packet disappear after 21st second?
20:25 < cizra> Time layer, I suppose
20:26 < genete> cizra: each paramameter has it own row for its own waypoints. Don't understand your question though
20:26 < cizra> OK.
20:26 < cizra> I got the answer.
20:27 < genete> brb
20:27 < cizra> I set the waypoints according to Yoyobuae. However, now the packet doesn't appear at 21s.
20:27 < dooglus> hi y'all
20:28 < dooglus> having fun with the various versions of time loop?  :)
20:28 < Yoyobuae> cizra: could you upload the file you just edited
20:28 < Yoyobuae> dooglus: yeah, totaly confused XD
20:28 < dooglus> Yoyobuae: thanks for the windows fixes by the way
20:29 < dooglus> Yoyobuae: I built them earlier today, but it's still very unstable.  just drawing a circle and zooming in on it a few times was enough to crash it
20:29 < cizra> Done. Get from the same old place.
20:29 < dooglus> Yoyobuae: I don't know what it was like before - is it any less stable now?
20:29 < Yoyobuae> dooglus: yeah i'm getting the same
20:30  * pixelgeek just got 1811 compiled
20:30 < Yoyobuae> dooglus: it wasn't like this before. Maybe there are GUID objects which didn't produce an error, and thus not corrected.
20:30 < pixelgeek> fell over on the second circle
20:31 < pixelgeek> (thanks for the patches Yoyobuae, by the way!
20:32 < pixelgeek> 8 circles and then fell over.  
20:33 < pixelgeek> I'm thinking it's a little (!) less stable
20:33 < dooglus> Yoyobuae: any idea how to find out why it's crashing?
20:33 < dooglus> i installed gdb today but couldn't get studio to run in it
20:34 < Yoyobuae> dooglus: nope, XD
20:34 < cizra> Post-mortem?
20:34 < cizra> I've never figured out when crashing programs leave stack traces...
20:34 < dooglus> cizra: is that a program?
20:34 < cizra> No, it's a technique
20:35 < cizra> Analyzing a crash after it has happened.
20:35 < dooglus> ok
20:35 < cizra> Anyway, Yoyobuae, you got the upload?
20:35 < pixelgeek> dooglus: what happens when you rung gdb synfigstudio.exe?
20:35 < Yoyobuae> cizra: yeah im trying  to fix it
20:36 < genete> Yoyobuae: remember that there is not backward compatibility (or is there?)
20:36 < cizra> OK
20:36 < pixelgeek> mine complains it can't find the symbols - not surprising as I haven't been building with debug turned on
20:37 < genete> Yoyobuae: try to save as older versions and see what happen.
20:37  * genete building now ;)
20:37 < Yoyobuae> genete: nothing happens, the parameters are the same no matter what version i choose to save in =/
20:37 < genete> ok
20:37 < Yoyobuae> genete: i looked into the SIF file to confirm
20:39 < genete> I said: dooglus: your commit r1800 is satisfiying my feature request number 1801356 ;) Thanks
20:40 < dooglus> genete: I remembered your request at the time, but couldn't find it.  I've closed it now.
20:40 < genete> :)
20:41 < dooglus> pixelgeek: it tells me "the application asked the runtime to terminate in an unusual way" or some such
20:41 < dooglus> pixelgeek: after attempting to connect to an existing studio instance and failing
20:42 -!- AkhIL [n=AkhIL@90.188.195.134] has quit [Remote closed the connection]
20:43 < dooglus> the old timeloop can only loop the beginning of an animation I think
20:43 < dooglus> http://synfig.org/Time_Loop_Layer_(v0.1)
20:43 < cizra> dooglus: That would be fine
20:44 < cizra> If I created a new packet, with the animation in the beginning
20:44 < cizra> then looped it
20:44 < cizra> then made it appear in the 21st second,
20:44 < cizra> would that work?
20:44 < dooglus> yes
20:44 < genete> You can have a new packet looping from the beggining but make it visible only from frame 21s
20:45 < genete> that sure would work ;)
20:45 < cizra> my idea.
20:45  * cizra tries it
20:45 < genete> yes that's what you said before
20:47 < cizra> I didn't mean "You stole my idea!". I meant "Hey, I think the same."
20:48 < genete> NP
20:49 -!- AkhIL [n=AkhIL@90.188.195.134] has joined #synfig
20:52 < pixelgeek> pabs - suggestion for the challenge "March is Monster Month"
20:53 < cizra> OK, I drew a packet, made it move once (0 - 2 seconds).
20:53 < cizra> How do I loop it? Put a time layer above it, then ..?
20:54 < genete> cizra: then encapsulate both time loop and packet
20:54 < cizra> What to put into the start time and end time? Start time is supposedly 0, but end time? Does it mean the end of the piece which must be looped over ..
20:54 < cizra> .. or is it the end when the looping itself should cease?
20:54 < genete> pixelgeek: can you specify the challenge a little more?
20:54 < cizra> Encapsulated them already. Doesn't loop.
20:54 < pixelgeek> The old time loop loops indefinately
20:54 < Yoyobuae> start time = 0, end time = 2s
20:55 < pixelgeek> genete: I was leaving it vague - but draw or animate your own monster
20:55 < cizra> Nope. still doesn't loop.
20:55 < dooglus> cizra: upload it again, and I'll take a look
20:55 < cizra> Hey, wait, it does!
20:56 < dooglus> you're welcome
20:56 < genete> pixelgeek: I'm rebuilding studio and it seems there are new tool icons, right?
20:56 < Yoyobuae> make sure you're not animating the time loop parameters though
20:56 < pixelgeek> from how long ago?  dooglus  re-enabled several that were defaulted off
20:57 < pixelgeek> but mainly shuffled them around so they don't fit in a nice 4x4 array now ;)
20:57 < dooglus> ha
20:57 < dooglus> they fit in a nice 5x3 array now
20:57 < genete> I think I was only 10 or 15 commits old.
20:58 < genete> ok
20:59 < Yoyobuae> cizra: you'll need to adjust Start/End time on time loop if the loop doesn't start when you want it too (at 21s second i suppose)
20:59  * pixelgeek has width enabled
21:01 < genete> Yoyobuae: he wants the loop from the beggining and he would animate the layer visibility from time 21s
21:02 < Yoyobuae> the thing is that with Start=0s and End=2s, the loop's begining should be at 0s, 2s, 4s, 6s, ...., 20s, 22s, etc. 
21:02 < Yoyobuae> it skips 21s
21:02 < Yoyobuae> hmm, maybe simple add Time Offset -21s on the paste layer Time Loop is in
21:02 < genete> pixelgeek: I like the "March is moster Month". It can be funny :)
21:03 < Yoyobuae> Time Offset= -21s  i meant XD
21:03 < cizra> Ahhh! Works!
21:04 < genete> three hurrahs!!! Hip hip Hurraaahh!!! Hip hip hurraaah!! Hip hip hurraaah!! 
21:05 < genete> ;)
21:09 < cizra> er.. *blushes*
21:11  * genete worries about rore's feb entry :(
21:16 < genete> dooglus: Can a "new" rotate layer affect to the vertices of the blines only?
21:19 < factor> wonder if she is doodling
21:20 < factor> she is prolly having too much fun as fosdem
21:23 < Yoyobuae> genete: wait a sec, ONLY the vertexes? what about tangents?
21:24 < genete> Yoyobuae: (now that dooglus is not listening) tangents would have special behavior on that layer... :)
21:25 < genete> I'm thinking on a feathered rotation layer
21:25 < Yoyobuae> genete: feathered? how?
21:26 < genete> the rotation amount falls down to 0 when the vertice is far away from the center
21:26 < genete> following a certain rule
21:26 < Yoyobuae> like a twist effect =)
21:26 < genete> that I have not defined yet :)
21:26 < genete> maybe
21:26 < genete> but only for vertices / tangents ducks
21:27 < genete> Yoyobuae: I still thinking on implement bones on synfig :)
21:27 < Yoyobuae> anyway, IF you're suggesting modifying the vertex values itself it might be better using converts for it
21:28 < genete> nop
21:28 < genete> the vertices would continue like normal vertices
21:28 < Yoyobuae> but then a few new converts are needed to be able to process a bline, transforming it, and producion a new bline
21:28 < Yoyobuae> the "source" bline will remain editable
21:29 < Yoyobuae> s/producion/producing/
21:29  * dooglus is listening again
21:29 < genete> Shhhh....
21:29 < dooglus> I had noticed that loading a 0.1 timeloop into the SVN version didn't convert it properly
21:30 < dooglus> and was trying to fix that
21:30 < dooglus> the 0.1 version loops time from (-duration) to 0 before (start time) and from 0 to (duration) afterwards
21:30 < dooglus> whereas the current version loops from 0 to (duration) always
21:31 < dooglus> (if 'link time' is 0, that is)
21:32 < genete> Yoyobuae: the  conversion you mentioned, can be done with current synfig verison or do i need to edit the sif file?
21:32 < dooglus> factor: last I heard rore was in belgium, man, belgium
21:32 < Yoyobuae> "but then a few new converts are needed to be able to process a bline" =)
21:33 < genete> Yoyobuae: yup new ones
21:33 < genete> Yoyobuae: but I fell that converters are not so flexible. I want something easy to use and intuitive.
21:34 < genete> s/fell/feel
21:35 < dooglus> I think the 0.1 timeloop behaviour was probably a bug, but I need to allow it as an option when converting from 0.1 to 0.2 timeloops
21:35 < dooglus> so what should the parameter be called?
21:35 < dooglus> I was thinking "Reverse Before Local Time" - but it's not a reversal really
21:35 < Yoyobuae> well,what i had in mind is a sort of template.  you link the "source" bline somewhere, and you get the "result" bline to link back into your shape
21:36 < genete> dooglus: "Make it simetrical" 
21:36 < dooglus> I like
21:36 < dooglus> do you mind if I use that spelling, or did you patent it?
21:36 < genete> with the correct spelling of course ;)
21:37 < genete> dooglus: it is free ;)
21:37 < genete> simmetrical?
21:38 < genete> lol
21:39 < genete> synnetrical
21:39 < genete> oops
21:39 < genete> symmetrical
21:39 < genete> phew!
21:39 < dooglus> so just "Symmetrical" is the param name, and it defaults to being on, unless you load an old .sif
21:39 < genete> :)
21:41 < genete> dooglus: the change I did from 150 to 1000 in layerparamtreestore.cpp was not restored when rebuild. 
21:42 < Yoyobuae> do you means the change remains?
21:42 < genete> yes
21:42 < Yoyobuae> do: svn revert -R synfig-studio
21:43 < genete> I changed the values from 150 to 1000, didi "make" and "sudo make install" and today I've svn up
21:43 < genete> and did not update
21:43 < Yoyobuae> svn always tries to keep local changes
21:43 < dooglus> genete: the changes you make to your local copy aren't thrown away when you update
21:43 < dooglus> genete: maybe they're valuable
21:43 < dooglus> genete: if you want to throw them away, you use 'svn revert' to explicitly do so
21:44 < genete> so only when they enter in conflict with yours then they are merged
21:44 < genete> I have automatic scripts for rebuild
21:45 < Yoyobuae> svn up only deals with files that need updating
21:51 < dooglus> if there's a conflict, both sets of changes stay in your file, and the build fails until you edit the files by hand
21:51 < dooglus> (or 'revert')
21:51 < dooglus> what to do about windows?
21:53 < genete> dooglus: about windows?
21:56 < dooglus> genete: I put mutex locking around all refcount operations
21:57 < dooglus> genete: this seems to have made the windows build much less stable, for some reason
21:57 < dooglus> genete: I've no idea how to find out what's going on
21:57 < genete> oh, I cannot help on that :(
21:59 < Yoyobuae> how about allowing mutex locking be switched by an environmet variable, for now at least
22:02 < Yoyobuae> also, i didnt replace all instances of "GUID" with "synfig::GUID". I was assuming that if no errors occurred, the compiler was using the correct one.
22:02 < Yoyobuae> but i could be wrong XD
22:03 < dooglus> Yoyobuae: I just committed a change to ETL/handle that means it won't use the mutex code on Windows
22:03 < CIA-27> synfig: dooglus * r1812 /synfig-core/trunk/src/synfig/savecanvas.cpp: Move more code inside the 'try' block in an attempt to have studio not crash when it can't write auto-save files.
22:03 < CIA-27> synfig: dooglus * r1813 /synfig-core/trunk/src/modules/lyr_std/ (timeloop.cpp timeloop.h): Add an extra 'symmetrical' parameter to the 'time loop' layer to better be able to convert the 0.1 version of the layer.
22:03 < CIA-27> synfig: dooglus * r1814 /synfig-studio/trunk/src/gtkmm/ (renderer_ducks.h renderer_ducks.cpp): Use #defined colour values.
22:03 < CIA-27> synfig: dooglus * r1815 /ETL/trunk/ETL/handle: Using mutexes around accesses to refcounts seems to make the Windows build much less stable for some reason, so let's not do it for now, until we can find out why.
22:03 < dooglus> Yoyobuae: can you tell me whether it makes things more stable again?
22:04 < dooglus> Yoyobuae: it should do, unless something in your patch is causing the trouble, which I doubt.
22:07 < Yoyobuae> oh, nvm i forgot that code is inside ETL. Environment variable can't be used there, or at least shouldn't
22:22 -!- mwiriadi [n=mwiriadi@203-59-174-181.dyn.iinet.net.au] has joined #synfig
22:24  * pixelgeek marked 1811 as unstable in my dir - so as not to load it by accident
22:31 < dooglus> pixelgeek: fancy trying a new build?
22:31 < dooglus> 1815 is hopefully back to regular levels of instability
22:32 < dooglus> I'd like to know whether 1812 fixes the crash for Russian profile names
22:37  * pixelgeek already building dooglus' Waterloo
22:39 < pixelgeek> Which coincidentally is close to where rore is right now...
22:39 < rubikcube> is the particle template V2.3 supposed to work with the latest stable?
22:42 < Yoyobuae> rubikcube: all of genete's particle templates use Time Loop Convert, which is only available since r1226. latest stable version is r878
22:43 < Yoyobuae> the compatibility list: http://synfig.org/Convert#Which_Value_Types_can_use_which_Convert_Types.3F
22:43 < Yoyobuae> errr.. wrong link XD
22:44 < Yoyobuae> http://synfig.org/Convert#Compatibility
22:44 < rubikcube> Yoyobuae: ok, thanks, so I'll just not try that out and wait for a version which doesn't segfault there :-)
22:46 < rubikcube> it complained about a duplicate element, but nevermind
22:49 < genete> duplicate is also a new feature since last stable
22:50 < rubikcube> help/about says I have .61.07...
22:54 -!- lasse [n=lasse@kek1.kyla.fi] has quit [Read error: 110 (Connection timed out)]
23:05 < rubikcube> hmm, I can't do no real random movement unless I use the svn version?
23:06 < genete> nop: http://synfig.org/Convert#Compatibility
23:08 < rubikcube> as I suggested above, that table doesn't seem quite up-to-date (or my version reports a wrong number), but that's why i asked :-)
23:08 < rubikcube> how stable is svn generally?
23:10 < rubikcube> oh no, the table is ok, but quite unintuitive...
23:10 -!- omry [n=omry@bzq-84-108-20-56.cablep.bezeqint.net] has quit [Remote closed the connection]
23:11 -!- omry [n=omry@bzq-84-108-20-56.cablep.bezeqint.net] has joined #synfig
23:11 -!- omry_ [n=omry@bzq-84-108-20-56.cablep.bezeqint.net] has joined #synfig
23:11 -!- omry_ [n=omry@bzq-84-108-20-56.cablep.bezeqint.net] has quit [Read error: 104 (Connection reset by peer)]
23:11 < genete> 0.61.07 is 878 so everything later is the svn version
23:12 < rubikcube> yes, I just found out the meaning of the numbers :-)
23:16 < dooglus> would it help if the table was inverted?
23:16 < dooglus> what was your problem in understanding it?
23:17 < dooglus> can you suggest a way of re-writing "Here's a list of the ValueNode types that have been added, along with the subversion revision number in which they first appeared" so that it makes it clearer that the numbers are subversion revision numbers?
23:17 < genete> yeah! it is a wiki!!! :)
23:17 < Yoyobuae> i'm gonna post my idea on the discussion area =)
23:18  * rubikcube is diving into mediawiki's formatting already
23:24 < rubikcube> http://synfig.org/Convert#Compatibility
23:25 < rubikcube> the simplest change I could think of within a few minutes
23:30 < genete> rubikcube: I've learnt something new from you! :) the <hr> code inside a table is new to me. :)
23:31 < rubikcube> wikimedia states you also use ---- instead, but that doesn't seem to work within tables
23:32 < rubikcube> IMHO the proper way would be a nested table, with the release in the left of two main columns, everything else as one (2xN) subtable per release
23:39 < genete> hey guys! I need your opinion!!
23:39 < genete> http://i85.photobucket.com/albums/k74/Genete/synfig/Theballom3.gif
23:39 < genete> does the wakl cycle look fine?
23:40 < genete>         walk   ^
23:42 < genete> the child is supposed to walk by his grandfather's hand (not yet drawn)
23:43 < rubikcube> the ears are a bit big :-)  and the legs seem to move along the hip instead of just rotating there.  But I don't think that one will really notice it, as long as there are more interesting parts visible (like faces/eyes, something interesting happening)
23:44 < genete> rubikcube: thanks for the feed back. The child design is fine for the animation porpouse
23:45 < genete> the interesting thing would happen with the grandfather...
23:45 < rubikcube> it "feels" right, although it's not anatmically correct, but I guess that's fine
23:46 < genete> and the most important thing: I'm enjoying a lot making the animation :)
23:46 < Yoyobuae> my suggestion: http://www.synfig.org/Talk:Convert#Compatibility_.28Yoyobuae.27s_table_format_suggestion.29
23:46 < rubikcube> hehe, of course ! :-)
23:46 < rubikcube> Yoyobuae: even better\
23:47 < genete> Yoyobuae: so that's a wiki... It is up to you guys :)
23:48 < Yoyobuae> i think it needs a bit more space between columns
23:53 < rubikcube> Is there a way to disconnect from an exported value, but keep a copy of the connected properties?  I.e. when object A is connected to a radial composite (which was exported from object B), I don't want them to be linked together anymore, but I want to keep object B's vector in radial composite form instead of setting it back to simple xy coordinates
23:54 < Yoyobuae> you can disconnect, then convert to radial composite again
23:55 < rubikcube> of course this was only a simple example
23:56 < Yoyobuae> added a bit more width to the table. should i put it in the Convert page?
23:56 < rubikcube> I was thinking about exporting a more complex, deeply layered coordinate representation.  That couldn't be converted back by a simple click
23:56 < pixelgeek> dooglus: 1815 crashed at 8 circles
23:56 < genete> Yoyobuae: I think so.
23:57 < genete> rubikcube: Maybe this one helps you? http://synfig.org/How_do_I#Copy_a_complex_convert_combination_between_parameters_of_different_layers.3F
23:57 < Yoyobuae> rubikcube: actually once 2 values are exported and connect, they are no longer 2 values, but a single one
23:57 < Yoyobuae> you could do as the link genete posted says
23:57 < dooglus> pixelgeek: is 1815 less stable than pre-1800 builds?
23:58 < pixelgeek> and then 120 without blinking.....  it's still random
23:58 < rubikcube> genete, Yoyobuae: thanks a loT!
23:58 < Yoyobuae> another way to duplicating a convert combination is to duplicate the object that contains it
23:58 < Yoyobuae> but the value needs to be unexported when you duplicate
23:59 < pixelgeek> It seems to fall over easier if I actually drag out a non-zero radius circle instead of just clicking as fast as I can
23:59 < pixelgeek> Is it the dragging that triggers the circle bug?
--- Log closed Mon Feb 25 00:00:08 2008