and a mini-game in itDPC should have posted this as a preview for 10, have people theorize like crazy
View attachment 5196670
Plenty of people would correctly guess it's a dream or drug trip though. But still
Shouldn't Cinderella and Sally be considered side girls ?
I thought so too, especially "Cinderella", since she was introduce smoothly from chapter 9, especially if we play Other Path.
Well there are nine or more months of unknown in between where the diary left off and MC being born. It kind of depends on how extreme Lynn's parents are. And I meant that Lynn's parents are assholes who would treat her like shit over the scandal, not that the high society would see Neil and Lynn as the assholes for causing a scandal.
Iris is part of the MG path, so its Maya/Josy specifically Josy's path as the only way you can meet her is by having the date with Josy and getting her ILY.
It's still very much possible that Iris will attend the faculty event, so that we can see her on any route. I won't be surprised however that on non-Josy routes, we will get the same situation as we currently have with Bianca: We can't do more with her than just talk.
While your right Iris could be at the faculty even since it only for teachers, staff and special guest Im going to assume this is a Josy path only event with Iris when Josy takes MC home
IDK its close, hard to tell there's a reddit post somewhere out there where a guy guesses cup size but it looks way too off
we knew she was coming back eventually and its pretty common for a girl not to be featured in one episode to get heavily featured in the next
DPC should have posted this as a preview for 10, have people theorize like crazy
View attachment 5196670
Plenty of people would correctly guess it's a dream or drug trip though. But still
WOoo JosyYou must be registered to see the links
I've worked on static renders all week, powering through some canon and branched scenes. Among others, I've worked on Josy, Maya, DIKs, and the Pink Rose.
It's going well, and I will mostly work on static renders next week as well.
I updated one of my PC slaves to Windows 11 this week, but I had to revert it to Windows 10 after experiencing black screen-to-restart crashes when rendering with DAZ. I thought the issue was driver-related, but it persisted after multiple attempts to update everything conceivable. I decided to keep it on Windows 10 until I replace it altogether in the future. While doing this, I thought about a topic that affects me weekly, but I don't often discuss - time thieves.
I want to share some behind-the-scenes insights on how these time thieves impact development and how I work around them. The three time thieves I've dealt with recently are Windows 11 upgrades, DAZ alpha bugs, and render queue depletion.
Windows 11
The Windows 11 upgrades are necessary, but they often come with unexpected issues, such as the one I described above. Currently, I have three PC slaves still running Windows 10, two of which I plan to replace with new PCs soon. The rest of my PCs are rocking Windows 11 without issues.
While I couldn't create a game without PCs, PC maintenance can steal quite a bit of time when everything isn't going smoothly. The systems must be nearly identical in all aspects that affect DAZ for slave rendering to function properly.
DAZ alpha bugs
The DAZ alpha build is being updated almost weekly now, and since there are plenty of quirks and bugs with it, I'm very keen on updating it regularly on my end to see if bugs are fixed.
This week, I upgraded to the latest version, and a new bug was introduced that caused several assets not to load at all and even crashed DAZ altogether. Those bugs steal time, but the biggest DAZ alpha bug at the moment - the time thief - is something I call the "DAZ alpha undo bug".
There's a tool in DAZ called the Translate tool, which you use to move objects around in the viewport, such as characters, items, and so on.
View attachment 5197428
For reasons I haven't quite figured out yet, DAZ can decide to undo many of the steps you've made in your current work if you use the translate tool in a certain way. And not only that, DAZ can also continue to move things around that you didn't move at all, causing the entire scene to be wasted. And to make matters worse, you can't redo anything that DAZ undid, so you lose your work the moment the bug kicks in. I have to restart DAZ whenever it happens. It's a really annoying bug that improved somewhat with the previous update, but it didn't disappear altogether. To combat it, I save my work frequently before using the translation tool - it has become a reflex. That way, I can restart the software and continue fast if the bug happens. DAZ has become faster when loading files, so not a lot of time is wasted, but I wish the bug would be fixed soon.
Render queue depletion
When I speak of a render queue, I mean a folder of .duf files (one .duf file is equivalent to an image or animation file before it is rendered) that are specified in DAZ so that they should be rendered.
View attachment 5197429
As PC slaves complete their current queue, I add more .duf files to them and specify them in DAZ. I try my best to spread the work out evenly among my systems, and always have a pool of files waiting for PCs that finish their work.
When a PC finishes its render queue, I supply it with new files. Every second between the PC completing its queue and me adding more files to it is wasted time. I try to plan around this by calculating when the PCs complete their work, but it happens that a PC is done in the middle of the night or at a time when I'm busy working. I wish there were a way to add files to the render queue while the PCs are rendering, but at the moment it's not possible, and I will have to live with this time thief during development.
We're talking about 1-8 hours of wasted time per PC when this happens, depending on how fast I can spot it happening. One way I combat this is by having large render queues per PC. Let's say a queue on one PC takes 1-2 months to complete rendering; then 1-8 hours of wasted time is small in comparison.
Time thieves aren't anything new to me; they have occurred throughout my years as a developer in various ways, and they are a pesky part of development. What's important is to find ways forward and to minimize the time they steal.
I hope none of this made you worry in any way; it wasn't my intention. Development is progressing smoothly, and PCs are producing animations and static renders at a steady pace.
Have a nice weekend
Dr PinkCake
anim madame pussylickYou must be registered to see the links
I've worked on static renders all week, powering through some canon and branched scenes. Among others, I've worked on Josy, Maya, DIKs, and the Pink Rose.
It's going well, and I will mostly work on static renders next week as well.
I updated one of my PC slaves to Windows 11 this week, but I had to revert it to Windows 10 after experiencing black screen-to-restart crashes when rendering with DAZ. I thought the issue was driver-related, but it persisted after multiple attempts to update everything conceivable. I decided to keep it on Windows 10 until I replace it altogether in the future. While doing this, I thought about a topic that affects me weekly, but I don't often discuss - time thieves.
I want to share some behind-the-scenes insights on how these time thieves impact development and how I work around them. The three time thieves I've dealt with recently are Windows 11 upgrades, DAZ alpha bugs, and render queue depletion.
Windows 11
The Windows 11 upgrades are necessary, but they often come with unexpected issues, such as the one I described above. Currently, I have three PC slaves still running Windows 10, two of which I plan to replace with new PCs soon. The rest of my PCs are rocking Windows 11 without issues.
While I couldn't create a game without PCs, PC maintenance can steal quite a bit of time when everything isn't going smoothly. The systems must be nearly identical in all aspects that affect DAZ for slave rendering to function properly.
DAZ alpha bugs
The DAZ alpha build is being updated almost weekly now, and since there are plenty of quirks and bugs with it, I'm very keen on updating it regularly on my end to see if bugs are fixed.
This week, I upgraded to the latest version, and a new bug was introduced that caused several assets not to load at all and even crashed DAZ altogether. Those bugs steal time, but the biggest DAZ alpha bug at the moment - the time thief - is something I call the "DAZ alpha undo bug".
There's a tool in DAZ called the Translate tool, which you use to move objects around in the viewport, such as characters, items, and so on.
View attachment 5197428
For reasons I haven't quite figured out yet, DAZ can decide to undo many of the steps you've made in your current work if you use the translate tool in a certain way. And not only that, DAZ can also continue to move things around that you didn't move at all, causing the entire scene to be wasted. And to make matters worse, you can't redo anything that DAZ undid, so you lose your work the moment the bug kicks in. I have to restart DAZ whenever it happens. It's a really annoying bug that improved somewhat with the previous update, but it didn't disappear altogether. To combat it, I save my work frequently before using the translation tool - it has become a reflex. That way, I can restart the software and continue fast if the bug happens. DAZ has become faster when loading files, so not a lot of time is wasted, but I wish the bug would be fixed soon.
Render queue depletion
When I speak of a render queue, I mean a folder of .duf files (one .duf file is equivalent to an image or animation file before it is rendered) that are specified in DAZ so that they should be rendered.
View attachment 5197429
As PC slaves complete their current queue, I add more .duf files to them and specify them in DAZ. I try my best to spread the work out evenly among my systems, and always have a pool of files waiting for PCs that finish their work.
When a PC finishes its render queue, I supply it with new files. Every second between the PC completing its queue and me adding more files to it is wasted time. I try to plan around this by calculating when the PCs complete their work, but it happens that a PC is done in the middle of the night or at a time when I'm busy working. I wish there were a way to add files to the render queue while the PCs are rendering, but at the moment it's not possible, and I will have to live with this time thief during development.
We're talking about 1-8 hours of wasted time per PC when this happens, depending on how fast I can spot it happening. One way I combat this is by having large render queues per PC. Let's say a queue on one PC takes 1-2 months to complete rendering; then 1-8 hours of wasted time is small in comparison.
Time thieves aren't anything new to me; they have occurred throughout my years as a developer in various ways, and they are a pesky part of development. What's important is to find ways forward and to minimize the time they steal.
I hope none of this made you worry in any way; it wasn't my intention. Development is progressing smoothly, and PCs are producing animations and static renders at a steady pace.
Have a nice weekend
Dr PinkCake
It's the special guest part where I think she belongs to. With similar events in the real world, they usually mean the greatest investors in the college, (local) celebrities (if they give it the time of day) and often even clothing designers if important people at the event wear specially designed clothing. I've got a feeling that at least one of the guests at the event (probably Jill or Jade) will dress clothing designed by Iris or her company and thus she will be invited (if she already wasn't invited because of her status).
Oh I agree. I was just commenting on Falcon's comment that " Iris is part of the MG path, so its Maya/Josy specifically Josy's path as the only way you can meet her is by having the date with Josy and getting her ILY. ". I'm just saying that Josy's path probably isn't the only way to meet her in episode 12, although (like with Bianca) it is almost certainly the path where we will get the most contact with her.
Windows 11 - > +2 monthsYou must be registered to see the links
I've worked on static renders all week, powering through some canon and branched scenes. Among others, I've worked on Josy, Maya, DIKs, and the Pink Rose.
It's going well, and I will mostly work on static renders next week as well.
I updated one of my PC slaves to Windows 11 this week, but I had to revert it to Windows 10 after experiencing black screen-to-restart crashes when rendering with DAZ. I thought the issue was driver-related, but it persisted after multiple attempts to update everything conceivable. I decided to keep it on Windows 10 until I replace it altogether in the future. While doing this, I thought about a topic that affects me weekly, but I don't often discuss - time thieves.
I want to share some behind-the-scenes insights on how these time thieves impact development and how I work around them. The three time thieves I've dealt with recently are Windows 11 upgrades, DAZ alpha bugs, and render queue depletion.
Windows 11
The Windows 11 upgrades are necessary, but they often come with unexpected issues, such as the one I described above. Currently, I have three PC slaves still running Windows 10, two of which I plan to replace with new PCs soon. The rest of my PCs are rocking Windows 11 without issues.
While I couldn't create a game without PCs, PC maintenance can steal quite a bit of time when everything isn't going smoothly. The systems must be nearly identical in all aspects that affect DAZ for slave rendering to function properly.
DAZ alpha bugs
The DAZ alpha build is being updated almost weekly now, and since there are plenty of quirks and bugs with it, I'm very keen on updating it regularly on my end to see if bugs are fixed.
This week, I upgraded to the latest version, and a new bug was introduced that caused several assets not to load at all and even crashed DAZ altogether. Those bugs steal time, but the biggest DAZ alpha bug at the moment - the time thief - is something I call the "DAZ alpha undo bug".
There's a tool in DAZ called the Translate tool, which you use to move objects around in the viewport, such as characters, items, and so on.
View attachment 5197428
For reasons I haven't quite figured out yet, DAZ can decide to undo many of the steps you've made in your current work if you use the translate tool in a certain way. And not only that, DAZ can also continue to move things around that you didn't move at all, causing the entire scene to be wasted. And to make matters worse, you can't redo anything that DAZ undid, so you lose your work the moment the bug kicks in. I have to restart DAZ whenever it happens. It's a really annoying bug that improved somewhat with the previous update, but it didn't disappear altogether. To combat it, I save my work frequently before using the translation tool - it has become a reflex. That way, I can restart the software and continue fast if the bug happens. DAZ has become faster when loading files, so not a lot of time is wasted, but I wish the bug would be fixed soon.
Render queue depletion
When I speak of a render queue, I mean a folder of .duf files (one .duf file is equivalent to an image or animation file before it is rendered) that are specified in DAZ so that they should be rendered.
View attachment 5197429
As PC slaves complete their current queue, I add more .duf files to them and specify them in DAZ. I try my best to spread the work out evenly among my systems, and always have a pool of files waiting for PCs that finish their work.
When a PC finishes its render queue, I supply it with new files. Every second between the PC completing its queue and me adding more files to it is wasted time. I try to plan around this by calculating when the PCs complete their work, but it happens that a PC is done in the middle of the night or at a time when I'm busy working. I wish there were a way to add files to the render queue while the PCs are rendering, but at the moment it's not possible, and I will have to live with this time thief during development.
We're talking about 1-8 hours of wasted time per PC when this happens, depending on how fast I can spot it happening. One way I combat this is by having large render queues per PC. Let's say a queue on one PC takes 1-2 months to complete rendering; then 1-8 hours of wasted time is small in comparison.
Time thieves aren't anything new to me; they have occurred throughout my years as a developer in various ways, and they are a pesky part of development. What's important is to find ways forward and to minimize the time they steal.
I hope none of this made you worry in any way; it wasn't my intention. Development is progressing smoothly, and PCs are producing animations and static renders at a steady pace.
Have a nice weekend
Dr PinkCake
