Add certain fang/fullbody images to the gallery. #186

New Issue

GManon · 2022-10-17T00:53:39Z

GManon commented

2022-10-17 00:53:39 +00:00

Although these images aren't technically CG I feel like it would be nice to include them on the gallery since they are only seen once. These images are:

fanganonuitar.png

fanganonhug.png

fangarm.png

fangguitar.png

kissu1.png

kissu2.png

Of course since these are not CG you'd also have to compose in the backgrounds, but that is easy to do and very feasible in-engine.

Although these images aren't technically CG I feel like it would be nice to include them on the gallery since they are only seen *once*. These images are: fanganonuitar.png ![](https://git.snootgame.xyz/Cavemanon/SnootGame/raw/branch/Patch7/game/images/fang/fullbody/fanganonguitar.png) fanganonhug.png ![](https://git.snootgame.xyz/Cavemanon/SnootGame/raw/branch/Patch7/game/images/fang/fullbody/fanganonhug.png) fangarm.png ![](https://git.snootgame.xyz/Cavemanon/SnootGame/raw/branch/Patch7/game/images/fang/fullbody/fangarm.png) fangguitar.png ![](https://git.snootgame.xyz/Cavemanon/SnootGame/raw/branch/Patch7/game/images/fang/fullbody/fangguitar.png) kissu1.png ![](https://git.snootgame.xyz/Cavemanon/SnootGame/raw/branch/Patch7/game/images/fang/fullbody/kissu1.png) kissu2.png ![](https://git.snootgame.xyz/Cavemanon/SnootGame/raw/branch/Patch7/game/images/fang/fullbody/kissu2.png) Of course since these are not CG you'd also have to compose in the backgrounds, but that is easy to do and very feasible in-engine.

MichaelYick commented

2022-10-17 06:22:36 +00:00

I think it'd be a good change, but it'd have to be a screenshot rather than the actual image, defeating a bit of the dynanmic nature of the gallery.

GManon commented

2022-10-17 06:26:39 +00:00

I mean, nothing is stopping you from saving those screenshot inside the CGs folder.

MichaelYick commented

2022-10-17 06:31:22 +00:00

yeah, but if we do some other touch ups and they involve those scenes, we'll have to take the screenshot again.

GManon commented

2022-10-17 06:44:56 +00:00

True, that's why I suggested using image compositions at first.
I feel like the gallery should focus more on it's end functionality (That is, displaying images that aren't 'sprites') rather than how dynamic it is.

Besides fang_tail had to be 'coded in' so what's so bad about manually adding another entry to the gallery_items list?

True, that's why I suggested using image compositions at first. I feel like the gallery should focus more on it's end functionality (That is, displaying images that aren't 'sprites') rather than how dynamic it is. Besides fang_tail had to be 'coded in' so what's so bad about manually adding *another* entry to the gallery_items list?

MichaelYick commented

2022-10-17 07:04:37 +00:00

I guess we could do more hard coding, but that seems like it'll get out of hand really quick if we add more image compositions or wish to reuse the code. Might just be better to make a proper system.

i'll let @nutbuster give his input on this, I did not do much for the gallary except review and test the code.

I guess we could do more hard coding, but that seems like it'll get out of hand really quick if we add more image compositions or wish to reuse the code. Might just be better to make a proper system. i'll let @nutbuster give his input on this, I did not do much for the gallary except review and test the code.

MapAnon commented

2022-10-17 16:12:53 +00:00

That functionality is likely to already a be necessity when switching languages, otherwise the game gets horribly bloated with multiple slightly differing full-res images. Having manual entries isn't so bad, it's just inconvenient for us. Fortunately, with that we have more control over each CG being displayed, like putting unique titles for CG's rather than filenames.

MichaelYick commented

2022-10-18 02:09:12 +00:00

be necessity when switching languages

I'm talking about wani, not exit.

Having manual entries isn't so bad

if we're going to go proper manual entries, then can we please just put them in a TOML, YAML, or JSON file and have the gallery system parse them in?

I don't know why this wasn't done before, I should probably murder nutbuster for that one.

>be necessity when switching languages I'm talking about wani, not exit. >Having manual entries isn't so bad if we're going to go proper manual entries, then can we please just put them in a TOML, YAML, or JSON file and have the gallery system parse them in? I don't know why this wasn't done before, I should probably murder nutbuster for that one.

MapAnon closed this issue

2022-10-19 05:17:49 +00:00

MapAnon reopened this issue

2022-10-19 05:17:57 +00:00

MapAnon commented

2022-10-19 05:19:48 +00:00

For christ's sake, this ui makes no sense. Why is close issue right next to the comment button?

nutbuster commented

2022-10-19 05:43:37 +00:00

if we're going to go proper manual entries, then can we please just put them in a TOML, YAML, or JSON file and have the gallery system parse them in?

I vote for JSON if we have to do an accompanying plain text file instead of just hard coding it in, although ideally it should aim for the actual 'image' made by Ren'Py.

> if we're going to go proper manual entries, then can we please just put them in a TOML, YAML, or JSON file and have the gallery system parse them in? I vote for JSON if we have to do an accompanying plain text file instead of just hard coding it in, although ideally it should aim for the actual 'image' made by Ren'Py.

MichaelYick commented

2022-10-19 05:56:28 +00:00

For christ's sake, this ui makes no sense. Why is close issue right next to the comment button?

filtered

ideally it should aim for the actual 'image' made by Ren'Py

what does this even mean?

btw TOML > YAML > JSON in order of preference

> For christ's sake, this ui makes no sense. Why is close issue right next to the comment button? filtered >ideally it should aim for the actual 'image' made by Ren'Py what does this even mean? btw TOML > YAML > JSON in order of preference

nutbuster commented

2022-10-19 06:12:20 +00:00

ideally it should aim for the actual 'image' made by Ren'Py

what does this even mean?

Whenever you make an 'image' of any kind in Ren'Py, it stores it as an Image, this includes a lot of things like composites, making the dark versions of the snoot characters, even the anonflip counts.
So when we make the entries it should refer to the final name for those composites.
like

image big blending = Composite(
        (1920, 1080),
        (0, 0), "big ending",
        (0, 1080-126), "the ending"
    )

If we wanted that image, we should append 'big blending' to the JSON or TOML file, which I have changed my mind on with preference of TOML > JSON > YAML

> >ideally it should aim for the actual 'image' made by Ren'Py > > what does this even mean? Whenever you make an 'image' of any kind in Ren'Py, it stores it as an `Image`, this includes a lot of things like composites, making the dark versions of the snoot characters, even the anonflip counts. So when we make the entries it should refer to the final name for those composites. like ``` image big blending = Composite( (1920, 1080), (0, 0), "big ending", (0, 1080-126), "the ending" ) ``` If we wanted that image, we should append `'big blending'` to the JSON or TOML file, which I have changed my mind on with preference of `TOML > JSON > YAML`

MichaelYick commented

2022-10-19 20:50:20 +00:00

If we wanted that image, we should append 'big blending' to the JSON or TOML file

Wouldn't this need to be defined somewhere? I'm guessing there's going to be something like definitions.rpy to define all the complex stuff?

>If we wanted that image, we should append 'big blending' to the JSON or TOML file Wouldn't this need to be defined somewhere? I'm guessing there's going to be something like `definitions.rpy` to define all the complex stuff?

GManon commented

2022-10-19 21:38:27 +00:00

If we wanted that image, we should append 'big blending' to the JSON or TOML file

Wouldn't this need to be defined somewhere? I'm guessing there's going to be something like definitions.rpy to define all the complex stuff?

That's usually the standard in renpy projects as opposed to having them all over different files like it is now.

As for the yaml/toml/json debate keep in mind that Python natively supports only json, so if you want to use yaml or toml you'll have to include a third party library to the game build.

> >If we wanted that image, we should append 'big blending' to the JSON or TOML file > > Wouldn't this need to be defined somewhere? I'm guessing there's going to be something like `definitions.rpy` to define all the complex stuff? That's usually the standard in renpy projects as opposed to having them all over different files like it is now. As for the yaml/toml/json debate keep in mind that Python natively supports only json, so if you want to use yaml or toml you'll have to include a third party library to the game build.

MichaelYick commented

2022-10-20 04:04:44 +00:00

if python has first party support for json, then it seems like it'd be the better pick.

GManon commented

2022-11-16 15:53:02 +00:00

This has been fixed

GManon closed this issue

2022-11-16 15:53:10 +00:00

Sign in to join this conversation.

No Milestone

No project

No Assignees

4 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Cavemanon/SnootGame#186