Spaceroom furniture and custom mugs

[tw4449]

Hola. So, I've got a few graphics I want to submit for possible inclusion in a future official update. Multimokia graciously pointed me this direction for making a post here and hopefully getting the ball rolling.

I've included the flat PNGs of the spaceroom I've made as an example of the furniture I want to submit, which I can split into separate sprites of course. I also have a bunch of customized mugs that probably could be included as is.

I'm leaving this here, hoping one of you great people can help with whatever is needed to make this a reality. I'm totally illiterate with coding (despite repeated efforts to learn), so I'll definitely need assistance.

tw4449 MAS graphics submissions.zip

I'm totally new to GitHub, so I've probably broken etiquette in this post in some way or another. Patience is appreciated as I figure this strange new world out.

[LordBaaa]

I have been working with @tw4449 to organize and group there assets. I have a plan to make Interior Decoration Mode to allow users to decorate the room in game easily with the individual assets in the images above . I have some of the basic functions down but don't have an alpha version just yet so give me some time and I'd be happy to submit a pull request with these changes in mind

[ThePotatoGuy]

I'm already working on this as well. Link your branch here.

[tw4449]

I... don't know how to do that. Or what a branch is. Forgive my noob-ness. 😅

[multimokia]

Not you, but @LordBaaa

[tw4449]

Oh good. Thanks. 😂

[LordBaaa]

I need to collect my bits so when it is ready i'll put it here.

[Mcmanybucks]

The perspective on the couch and coffee table is a bit off, but nice work.

[tw4449]

@Mcmanybucks Yeah, I noticed that after I finished it. The room is proportioned weird (the tiles converge way too fast for as large as the room is supposed to be according to the size of the windows and calendar). I'm planning on fixing that in the version I make into sprites (this is an example so people generally know what I'm submitting). Nice catch, though.

[LordBaaa]

Took longer then I was hoping as I have been busy with other things but I should be linking my code later today. I have one more problem I solved in my head that I need to fix and then the first working alpha version will be ready. Note that this is NOT my best work yet. It’s just getting it working and then it will be refined and formatted more properly so take it with a grain of salt.

[LordBaaa]

Here is my first commit https://github.com/LordBaaa/MonikaModDev again a lot of sloppiness cause was just getting it working. Obviously the code is mostly a modified version of the scrollable lists but I have some other things planed for placement of the furniture in the room. I also borrowed some of this code from a submod I have been working that uses the lists. Oh also furniture used is from night time mode.

[LordBaaa]

I'll see about committing tomorrow. I just added code for sub_objects. Aka the pillows on the couch and the book, magazines, pen glass and stuff on the table. At this point you can turn it on or off. But soon will be able to choose each sub_object on each main MAS_Furniture object. And it only processes the sub_object code once until it is updated again so no overhead in normal processing

[ThePotatoGuy]

I haven't had time to look at your code, but this is the primary criteria that we are intending the room decoration feature to have:

User Provided Images

1. Images to use in this activity should be loaded from a directory where users can drop images. This is likely to be the characters folder using a different extension, but is not set in stone yet.
2. Only PNG-type images are allowed. This requirement may make it easier to just use a new directory for room dec images.

Data Structure

1. The data associated to each image used in room decoration should be tied to the MASBackground representation of the room. This is so we can have different room layouts based on the bg.
2. Image data that should be saved to persistent:
   • coordinate position - location of the image in the view
   • zorder - 5, 6, or 7
   • dimension (either factorscale or width/height) - size of the image
3. MASBackground should be modified to save/load all image data associated with an instance of this class.

Room Decoration Activity

1. The activity will be launched from the Extras menu.
2. The activity should have two ways of selecting an image to moved:
   1. a list of selectables via something like the sidebar, but larger. This screen should also be hidable so the user can see the entire room clearly.
   2. clicking on the actual image itself in the room. This would require making images translucent until the mouse hovers over them
3. Images added to the room should use the zorder we have provided (5,6,7). The development to prepare for this (moving bg zorder) has been done in #5347.
4. Users should be able to adjust the zorder of an image via mouse (lower/higher)
5. Users should be able to move images around via mouse (Drag renpy displayable class).
6. Users should be able to resize images via Mouse (likely using factorscale, or width/height)
7. Users should be able to hide Monika (via emptydesk) or hide both Monika and the desk.
8. Users should be able to undo all of their actions while in the activity via an Undo button. There should be a corresponding Redo button as well. (The stack should be isolated to each launch of the activity).

Rendering

1. To save on performance issues with multiple images and screens, when the user quits the activity, all images selected by the user should be compiled (via Composite) to a single image. This image will be shown at zorder 5. Images on zorder 6 and 7 should have their y-pos adjusted to make up for the zorder change at compile. Images will have to be rendered via sprite strings similar to the sprite system, however we probably can do without DynamicDisplayable.
2. Night sprites should be handled by the system instead of forcing the user to include both. This has yet to be investigated. We currently do not have a definitive way to do this. If its absolutely not possible to apply the night filter to a sprite dynamically, then we will have to require that decoration images should be packaged into a zip-like file that contains the day and night versions of a sprite.

So if you PR your code, it will likely be merged into a separate branch where these criteria will be applied. Anything that is deficient in your code will be added/removed/changed to fit the criteria.

This list is also not completely definitive. It is likely that more criteria will appear as development continues.

[LordBaaa]

Well that certainly is a lot of things to accomplish however a lot that were always planned on my part. I have a way to apply the night filter. I wanted to do it dynamically with Monika but in past tests for handling so many images and more so the changing of poses it lost performance. I need to look more closely at how LiveComposite vs Composite for performance. But anyway to just composite night filter and all that just once I have an effective way of doing that. All I will say is give me time to show what I can do. I have a plan and it is working, I hadn’t worked on it in a few days but I came back today and accomplished what I had planned in the mean time. It’s rough to get it working but it is getting more refined.

[LordBaaa]

Oh and it possible to generate a LiveComposite (Fixed type) and then use it directly in game as an Image type without DynamicDisplayable and outside of init time. It is also possible to use Fixed inside of LiveComposite. I didn’t exactly those two things earlier today for the newer code with sub_objects attached to the main MASSelectableFurniture class I am using now. This is intended to allow the user to not only choose for example the table in the images provided by @tw4449 but to choose what is on it and group that as one piece. Atm this is simply intended to keep groupings created in the picture together however this could be adapted to simply group any objects together for moving things. I mean say you have your shelf all decked out but you want to move it somewhere else. You don’t want to have to move each extra thing on the shelf to, no you want it to be able to be grouped. Like I say atm through the sub_objects attribute of my class. I also was going to adapt the json system for adding new decorations, including default positions/zorder and sub_objects intended to be attached

[LordBaaa]

Made some progress on Drag and DragGroup. The functions were documented but how to make them work pythonically in a screen was not. Fortunately I remembered me calling other screen function equivalents and was able to find what I needed to use it. That will be coming soon.

[LordBaaa]

On my break I have been writing in my head and I think I can use a lot of the code I was already writing for sub_objects for drag. Like actually for the most part both the list and the drag sections should be able to use the same class I was writing

[LordBaaa]

Once again have been busy so haven’t been able to work on it as many days as I’d like buuuut, almost almost almost ready to commit a prototype that integrates Drag and LiveComposite from the MAS_Furniture Class (obviously change this later but I am a starting the couch and table so yeah). Also yeah the plan is for them to use a common object and thus the changes will be reflected in the scrollable menu and Drag. One note though is it is rather slow. I believe this just due to the sheer number of other graphical things going on at the same time as Drag. From my teats any drag is slow. May need to look at making mas_drawmonika and ms_sitting more efficient, and I have an idea of how to do so by directly accessing Fixed returned from LiveComposite children and reassigning them as opposed to running through all the individual functions and evaling a joined list over and over

[ThePotatoGuy]

dont change anything in the sprite system because i am changing it already

[LordBaaa]

Okay. But just as a test for speed I redirected mas_drawmonika to only return a static image to all DynamicDisplayables, hide spaceroom and even set weather to static image and the Drag was still supper slow. I ran just a basica screen language drag and it lags real bad. Any ideas? Like any loops that are going that might be slowing to down. I ran into a similar problem with the night mode I was working on.

[LordBaaa]

Hmm so maybe it was just me. I went through and loaded up several old versions and with a fresh 0.10.7 install it isn't slow. This is a pretty old install perhaps there was some old code still at play or something I changed and just didn't even realize. Although when I copy over some stuff from my old install it lags so yeah definitely something in there. I wonder what it is

[LordBaaa]

Okay well anyways good news is it is not laggy there was just something else at play. I am trying to find out what it is, might be helpful for other people as well. Now that I know it can run smoothly I’ll jeep working on it tomorrow. A lot of today has been trying to figure out why it was slow

[LordBaaa]

OMG! After all this it came down to environment.txt. Apparently I had set the render to Angle/DirectX in the past. I just copied all my .txt docs from my old install cause I didnt want to sift through to get just monika's msgs. My brand new install seems to use OpenGL as default and it works well. So yeah any one who uses drag DON'T use Angle/DirectX! My god that was so unnecessary.

[LordBaaa]

Drag Menu Demo.zip Here is a demo vid of what I have been working on. Don't mind that she has 0.9.5 facial feature. That is a submod of mine. This IS 0.10.7! Also sorry for the zip. I am lazy and didn't feel like uploading to youtube.

[LordBaaa]

I also commited my latest code. But as I have said before please just give me a little time before you judge me or change my code to much. This is all just a test and getting it working. It will be better and get rid of like excess code and stuff very soon now that I have the jist of it working.

[tw4449]

I've got a question about how one of the planned features will be implemented, namely #5 and #6 under Room Decoration Activity as @ThePotatoGuy posted a week back. It mentions being able to drag and scale sprites. How exactly is this intended to work? I can foresee a few significant issues from an aesthetic standpoint.

(Please read the following in the pleasant tone I intend, I don't mean to step on anyone's toes)

First, moving any furniture will seriously screw with the perspective of the room. As @Mcmanybucks helped point out, it's already difficult enough to get the furniture to look right when it's in one place. The way the furniture has to be angled, it would look totally wrong if moved beyond a certain boundary, let alone to the other side of the room. In the next version of the room I'm working on for formal submission, the angle of the couch is even more pointed to the left, and would be completely out of place if moved even slightly to the right. @LordBaaa is working on a possible solution of giving furniture certain "bounds" it can be moved within, but the narrow area you could move the furniture and still maintain the perspective kinda makes it pointless. @ThePotatoGuy's idea seems to be being able to move any piece of furniture anywhere in the room, but the art doesn't allow it.

Second, assuming that the perspective thing gets worked out, the next major issue is the beams of light in the daylit room. A fully functional furniture dragging system would have to account for the furniture's shadow if it crosses the light, regardless of placement. Again, the aesthetics demand it, or else it looks weird. @LordBaaa does have a possible solution for this, though it's somewhat complicated in terms of both coding and art (if I grasped it correctly). Also if we implement lighting like I have in the night rooms, anything under it would have to have its shadow move accordingly if either the furniture or light was moved. If they're fixed in place, I can do separate sprites and shadow combinations for each piece of furniture that would be under the light, but if either move, it again looks bad.

(Related sidebar. From my tinkering, I've determined there really needs to be 3 sprites for every object: daylit room, cloudy room, and night room. When the weather changes from sunlight to clouds, the room dims noticeably. In my first experiments, I found that if the furniture isn't likewise dimmed, it just looks too bright and out of place. That's another coding step, but I'll have the sprites to do it).

Third, for the resizing option, that will require higher-resolution versions of each sprite, otherwise they'll pixelate as you increase their size. All the work I've done so far has assumed the same resolution as the room, which frankly isn't very high-res. I mean, it's doable, but I'd have to start from scratch on almost everything to make it higher resolution. Graphics-wise, it's not as simple as taking a lower resolution image and "smoothing it out." You lose a lot of detail by the time we get to the resolution of the spaceroom. I would literally have to recreate all of it.

My suggestion, barring some brilliant solution, is that only certain objects be movable or scaleable, and only within certain constraints. Namely, wall decorations. Paintings, the like, within bounds on the wall remaking those in high-res wouldn't be that hard. As for furniture, I believe it's easy enough to have different pieces of furniture you can choose and interchange, but they'd have to be set in a specific place. I know that's disappointing compared to the idea of being able to place any furniture anywhere, but I don't know if a 2D game can do it. Not without some super-complicated coding and art gymnastics, that I'm not sure are realistically possible.

...and I'm done. 😅

[LordBaaa]

As @tw4449 said I have/already had planed some ideas for this. I had kinda glanced at image-map as a solution for boundaries. if I remember correctly it can easily tell where your mouse is and act if your are/aren’t in bounds. I realized that the things wouldn't be able to move much but there would be some “valid” areas and maybe some alternate areas from where it was originally but not much. Kinda like a game where you go into a room and see all the interact-able areas. I wanted to do the same except with a green squares marking the valid spaces Also for the second bit the ideas is a kinda ratio mask. Where again boundaries if the table (which seems the most problematic) were in the light and then were to be moved I could make something that would kinda crop the top light color and let the floor light show again. would be a little complex but I’m pretty sure I can do it.

[ThePotatoGuy]

I'm going to answer this quickly because its late:

moving any furniture will screw with perspective

Room decoration is not planned to be a restricted format, it is planned to be open-ended in the same way the sprite system lets you throw in any layers you want as long you fill out the json appropriately. This is the best way to ensure that a feature lives beyond its container's shelf-life. AKA, if development stops on the mod, users can still add more clothing/hair/acs because the system was built to be robust enough to handle additional content without us (the dev team) needing to verify it x,y,z works with the system.

We want to apply this same train of thought to the room decoration. Users drop images in a specific folder, the game finds the images and files into a database internally. Those images are now selectable in the room decoration activity and users can move them around as they see fit in the bg until its exactly how they like it. This includes dragging around, scaling up/down, changing zorder, etc. No need for someone (the dev team) to verify if x,y,z works with the system.

lighting

I have already solved the main lighting issue in the image-based-sprite-gen branch. We can now programatically apply filters and colors (MatrixColor-based) to sprites on the fly. As for beams of light, we can always separate the light beams and make them a separate layer that gets layered ontop of the room deco zorders. However this is not currently planned. Neither do we have plans to make legitimate raycasting to determine actual shadows. We don't need realistic environments, just need sprites to look ok. A simple eclipsed-shaped shadow at the bottom of a sprite is enough to handle most cases.

resizing and pixelation

Since images are user-dependent, this is a non issue. We just use whatever resolution was given to us. We could even add a button to give images blur if desired. There's a lot of stuff builtin to renpy and pygame that we can leverage.

I'm going to mention again, we didn't need a solution that was hyper-realistic and solved every problem. We wanted a simple way to drop user-provided images into the game and allow them to be customizable within user preference. If you ever used WeeWorld, that's the room concept we are aiming for. Specific zoreders for images to exist on, and you can pick where you want to put them as well as scale. (Rotation maybe, too)

demo video

looks like Draggable is pretty responsive. That looks good. For UX reasons, having ways to move images around via keyboard keys or arrow-shaped buttons is desired, but as I mentioned before, these will be things we will do ourselves if not implemented.

[LordBaaa]

Well I’ll just say that the button thing wasn’t listed but yeah I can do that to. Be like whatever you selected last you can then use arrow keys for fine adjustment. Also what is UX?

[LordBaaa]

Oh and scale/rotation is planned (I have a plan.) I have a little problem atm with hovered code they gave as an example as you need it to return True to update but doing this progress whatever it is your doing. Like example that will close the talk menu if you in it when you hover over a Drag with hovered equaling a function. I’m sure I’ll figure something out though. I can’t imagine they would design it like that to break the game, but I’m using an example of there’s so yeah. Also you can left or right click a drag so I was thinking right click could control scale/rotation

[LordBaaa]

MAS_Decoration v.0.1.5 committed. Removed a lot of unnecessary old code and made a few optimizations as well as redirected code to be MAS_Decoration instead of MAS_Furniture.

[LordBaaa]

Adding decoration via json system coming very soon! Been working on it all day and it works but obviously polish is in order plus I need to make it so the drag list is append. (Before I just defined the drags as a test)

[LordBaaa]

0.1.6 coming very soon! position data as well as selected (Aka visible) is now stored in persistent for decorations, decorations are added via json and when drags are finished position is used in live composite and saved to persistent. Removed a lot of old code as now have moved to json imports. Oh and yeah drags are now defined from DECORATIONS_SEL_MAP and persistent position data when the are generated

[LordBaaa]

0.1.6 is here! Change Log:

• Left Code that affects other files in this file for the time being for faster changes until final code is decided.
• Added adding Decorations Through Json system
• Removed ALOT of old code to use json system instead.
• When Selection is closed Drags turn into LiveComposite until screen is called again,
• Added saving Decoration data to persistent so it can be reconstructed as Drags/LiveCompostite on next load.
• Added proper restore/cancel functionality in the section menu. (Restore and Cancel basically just restore to what you started with)

Coming Up:

• Actually proper indents and doc strings (Soon TM)
• Furniture stays on screen on next load if you have furniture shown.
• Distinction between night/day version of sprites.
• Move call to extra's menu
• Refining sub_objects/pose_map code and implementing things for decorations that need to take more then one layer like shadows on certain things.

Slight Bug I just found:

• If you hide one of the decorations when you select it resets both items positions based off of persistent data since it hasn't been updated yet. This will be fixed in the next build

[LordBaaa]

Hmm so it seems the latest build was not committed? also I just had a data failure of where it was stored so it seems I might have lost some progress. Looking at my backup it looks pretty recent and maybe even in the time frame of when I tried to upload it before. Once I get all of what I have straight I'll see about committing again.

[LordBaaa]

Okaaaay so seems I was very lucky. I happened to be working on another mod today and copied my full directory to work on it. Now some code is new now and some stuff has changed but the part that was missing (the newest code for this) was part of that copy! So yeah I didn't loose it! It just so happened that where I stored it before it failed today for no real reason.

[LordBaaa]

Okay now V.0.1.6 has been committed for real this time

[LordBaaa]

I am not dead btw! I am working on the code rn. I have just been kidna busy with.... other world events. But v.0.1.7 shouldn't be far from being here. I will be able to put more time in now.

[LordBaaa]

V.0.1.7 Uploaded

• Added staying on restart.
• Added day/night separation for each weather.
• Added more json options:
  1. specify weathers that there are images for the object. @tw4449 for example has different furniture for def vs rain.
  2. ignore_night & ignore_day, this allows you to tell the weather to not look for its weather extension in the files and to just default back to def day/night. This is a per weather attribute
  3. w_same_map this allows you to easily say one weather is equal to another in terms of decorations. Once again referencing @tw4449 snow, overcast and thunder all use the rain room and so does his furniture and so the way it is set up you can simply go "w_same_map" : {"rain" :["snow","overcast","thunder"]} and those three will now use the full_composite from rain for those weathers to

Other Fixes:

• Fixed the bug of having object reset if one was hidden
• Fixed if you removed object json and hid another object error of no key

Coming Up:

• Actually proper indents and doc strings (getting in the habit more)
• Move call to extra's menu
• Adding the ability to move sub_objects as drags and then still be able to move there parent drag and have the go with. (This shouldn't be to awful hard because of the way I set things up)
• Hiding monika
• Looking into Resizing

[LordBaaa]

Making some progress on resize. Using some modified Drag code to try and do it

[ThePotatoGuy]

Make a PR to the room-deco branch. This will be the primary branch for continued development.

[LordBaaa]

Okay. I have cleanup and adjustments to make before I do though. I am doing it now