Cavemanon/SnootGame
24
Fork 18
Code Issues 4 Pull Requests 1 Projects Releases 9 Wiki Activity

WIP: Fixes #3 - Image Gallery #14

Closed
dagoddamnlazysnake wants to merge 18 commits from feature/ISSUE-3_CG_Gallery into Patchy-Patch5
pull from: feature/ISSUE-3_CG_Gallery
merge into: Cavemanon:Patchy-Patch5
Conversation 47 Commits 18 Files Changed 20 +338 -68
dagoddamnlazysnake commented 2021-06-13 06:26:26 +00:00
First-time contributor
Copy Link
  • cg gallery wip vol1: gallery data init, gallery screen
* cg gallery wip vol1: gallery data init, gallery screen
dagoddamnlazysnake added 1 commit 2021-06-13 06:26:27 +00:00
dagoddamnlazysnake commented 2021-06-13 06:30:46 +00:00
Author
First-time contributor
Copy Link

Please let me know if this level is abstraction is acceptable, I'm not sure if writers mess around with the code and how easily usable is has to be.

I've also added some TODOs where assets are needed (buttons and such).

Some more questions/pointers:

  • CG files to add can now be listed by hand, using the filename. For unlocking a CG, the persistant data for renpy is the same as time filename.
  • Should all files under CG be added?
  • Are all CG files the same resolution?
  • The vertical scroll now goes on forever, needs fixing before merge.
Please let me know if this level is abstraction is acceptable, I'm not sure if writers mess around with the code and how easily usable is has to be. I've also added some TODOs where assets are needed (buttons and such). Some more questions/pointers: * CG files to add can now be listed by hand, using the filename. For unlocking a CG, the persistant data for renpy is the same as time filename. * Should all files under CG be added? * Are all CG files the same resolution? * The vertical scroll now goes on forever, needs fixing before merge.
dagoddamnlazysnake changed title from WIP: Image Gallery to WIP: Issue #3 Image Gallery 2021-06-13 06:44:59 +00:00
MichaelYick commented 2021-06-13 22:44:56 +00:00
Member
Copy Link

Not gonna lie, the code and work looks great so far. Checked it out and its pretty good even in an unfinished stsage. The writers never touch the code base thus this level of abstraction is acceptable.

CG files to add can now be listed by hand, using the filename.

See quote 3

For unlocking a CG, the persistant data for renpy is the same as time filename.

Seems cool enough, im assuming to unlock something it'd just be as simple as writing
persistent.imagename = True.

Should all files under CG be added?

Ideally yes as to minimize work needed when implementing new CGs (also gives anons some nice extra artwork that we may throw in).

Are all CG files the same resolution?

This is an assumption that can be granted. They're always 1920x1080. Though, for future proofing, it may be wise to have it not be dependent on the size of the CG and be able to figure it out.

If you don't mind writing a bit of documentation for the code (I for one am not familiar with OOP in python) so newfrens can easily pick up the code base to fix and play around with, that'd be great. If you simply don't have the time, I can draft something up to the best of my understanding and you can correct it for accuracy.

The Main Menu is going to need a bit of reworking to get this all in one place. I rather not resize the buttons as the artists will scream about them losing quality, so I think its best to replace Help & About with a screen that just has the word "Extras" on it and from there, Help, About, Gallery, and maybe more stuff can be found.

In other news, i'll get the artists onto the missing assets. Here is a filler for the blank asset I just made, it might be fine enough to be final.

btw, where does "make_button" come from? Is this just a default renpy method that I simply don't know about that can be applied to other objects or am I missing something here?

Not gonna lie, the code and work looks great so far. Checked it out and its pretty good even in an unfinished stsage. The writers never touch the code base thus this level of abstraction is acceptable. >CG files to add can now be listed by hand, using the filename. See quote 3 >For unlocking a CG, the persistant data for renpy is the same as time filename. Seems cool enough, im assuming to unlock something it'd just be as simple as writing `persistent.imagename = True`. >Should all files under CG be added? Ideally yes as to minimize work needed when implementing new CGs (also gives anons some nice extra artwork that we may throw in). >Are all CG files the same resolution? This is an assumption that can be granted. They're always 1920x1080. Though, for future proofing, it may be wise to have it not be dependent on the size of the CG and be able to figure it out. If you don't mind writing a bit of documentation for the code (I for one am not familiar with OOP in python) so newfrens can easily pick up the code base to fix and play around with, that'd be great. If you simply don't have the time, I can draft something up to the best of my understanding and you can correct it for accuracy. The Main Menu is going to need a bit of reworking to get this all in one place. I rather not resize the buttons as the artists will scream about them losing quality, so I think its best to replace Help & About with a screen that just has the word "Extras" on it and from there, Help, About, Gallery, and maybe more stuff can be found. In other news, i'll get the artists onto the missing assets. Here is a filler for the blank asset I just made, it might be fine enough to be final. btw, where does "make_button" come from? Is this just a default renpy method that I simply don't know about that can be applied to other objects or am I missing something here?
unknown.png
23 KiB
unknown.png
MichaelYick commented 2021-06-13 23:44:16 +00:00
Member
Copy Link

here's the buttons our artists got

here's the buttons our artists got
extrasbutton.png
10 KiB
gallerybutton.png
11 KiB
extrasbutton.png gallerybutton.png
MichaelYick changed target branch from master to Patchy-Patch5 2021-06-14 00:48:52 +00:00
MichaelYick commented 2021-06-14 00:49:52 +00:00
Member
Copy Link

we're going to start using other branches other master for versions of the game as to keep master stable and able to be easily fell back upon. Update this PR accordingly when you can.

we're going to start using other branches other master for versions of the game as to keep master stable and able to be easily fell back upon. Update this PR accordingly when you can.
dagoddamnlazysnake commented 2021-06-14 18:36:15 +00:00
Author
First-time contributor
Copy Link

Oh, I'm just now seeing this. Thanks for the feedback and assets.

In regards to

Ideally yes as to minimize work needed when implementing new CGs (also gives anons some nice extra artwork that we may throw in).

Can be done, however I'd liek to point out that if we can follow a convention, ie.: prefix files to be included (or excluded) in the gallery with something like "cg_", then loading them into the gallery can be done without any hassle.

Oh, I'm just now seeing this. Thanks for the feedback and assets. In regards to > Ideally yes as to minimize work needed when implementing new CGs (also gives anons some nice extra artwork that we may throw in). Can be done, however I'd liek to point out that if we can follow a convention, ie.: prefix files to be included (or excluded) in the gallery with something like "cg_", then loading them into the gallery can be done without any hassle.
dagoddamnlazysnake commented 2021-06-14 18:39:27 +00:00
Author
First-time contributor
Copy Link

As for documentation and stuff, sure I can do that. Is there a shared folder liek a google drive or something somwhere?

make_button is a part of Gallery, for which a pretty decent quickstart guide can be found here: https://www.renpy.org/doc/html/rooms.html#image-gallery

As for documentation and stuff, sure I can do that. Is there a shared folder liek a google drive or something somwhere? make_button is a part of Gallery, for which a pretty decent quickstart guide can be found here: https://www.renpy.org/doc/html/rooms.html#image-gallery
MichaelYick commented 2021-06-14 21:55:22 +00:00
Member
Copy Link

Cool, didn't realize this was a built in functionality. I'd put documentation as code comments if I were you. Someone picking up the source should just be able to work with it.

Cool, didn't realize this was a built in functionality. I'd put documentation as code comments if I were you. Someone picking up the source should just be able to work with it.
MichaelYick commented 2021-06-14 22:30:07 +00:00
Member
Copy Link

Can be done, however I'd liek to point out that if we can follow a convention, ie.: prefix files to be included (or excluded) in the gallery with something like "cg_", then loading them into the gallery can be done without any hassle.

As in the file name will have some prefix to it? That sounds like a lot of code refactoring and file name changes that i'd prefer not to do (as to minimize bugs introducted). Anywho, If you think that your system would be better than simply importing the entire cg folder, then go ahead and just write documentation on how to use it. Though, it'd be nice just to not have to deal with editing a file every time a new CG gets introduced that we want in the gallery.

> Can be done, however I'd liek to point out that if we can follow a convention, ie.: prefix files to be included (or excluded) in the gallery with something like "cg_", then loading them into the gallery can be done without any hassle. As in the file name will have some prefix to it? That sounds like a lot of code refactoring and file name changes that i'd prefer not to do (as to minimize bugs introducted). Anywho, If you think that your system would be better than simply importing the entire cg folder, then go ahead and just write documentation on how to use it. Though, it'd be nice just to not have to deal with editing a file every time a new CG gets introduced that we want in the gallery.
dagoddamnlazysnake commented 2021-06-15 06:40:49 +00:00
Author
First-time contributor
Copy Link

As in the file name will have some prefix to it? That sounds like a lot of code refactoring and file name changes that i'd prefer not to do (as to minimize bugs introducted). Anywho, If you think that your system would be better than simply importing the entire cg folder, then go ahead and just write documentation on how to use it. Though, it'd be nice just to not have to deal with editing a file every time a new CG gets introduced that we want in the gallery.

Of course I'd do the refactoring of existing file names, as there is no other way to guarantee backwards compatibility. That said, there are some minor issues with just listing all of the files, namely:

  • The gallery is divided into n (currently 3) columns, and if the amount of files is not divisible by it, then the grid component crashes. The two solutions I currently have for this are filling the remaining space with invisible images - easy to do but a bit hacky. Or ditching the grid and manually dealing with x and y alignment. A better solution, but it will take more time to implement.

  • The other issue is that some cgs are way out of the 1920 * 1080 ballpark. In these cases (in all cases actually) I can scale and crop the image, but that might look retarded without the ability to manually override these things (like the cropped up part can just be a piece of the sky for a BIG image then the crowd of students outside the school).

If any of the listed solutions sounds like something preferable/better usable with your current workflow, please let me know. Otherwise I'll just implement the least hacky and most scalable solution.

I'd put documentation as code comments if I were you.

Can do. Is it alright if I start using type hints and annotations as well? The latter might make it a bit harder for newcomers to pick it up, but it can be a tremendous help with debugging in the longrun.

> As in the file name will have some prefix to it? That sounds like a lot of code refactoring and file name changes that i'd prefer not to do (as to minimize bugs introducted). Anywho, If you think that your system would be better than simply importing the entire cg folder, then go ahead and just write documentation on how to use it. Though, it'd be nice just to not have to deal with editing a file every time a new CG gets introduced that we want in the gallery. Of course I'd do the refactoring of existing file names, as there is no other way to guarantee backwards compatibility. That said, there are some minor issues with just listing all of the files, namely: * The gallery is divided into *n* (currently 3) columns, and if the amount of files is not divisible by it, then the grid component crashes. The two solutions I currently have for this are filling the remaining space with invisible images - easy to do but a bit hacky. Or ditching the grid and manually dealing with x and y alignment. A better solution, but it will take more time to implement. * The other issue is that some cgs are way out of the 1920 * 1080 ballpark. In these cases (in all cases actually) I can scale and crop the image, but that might look retarded without the ability to manually override these things (like the cropped up part can just be a piece of the sky for a BIG image then the crowd of students outside the school). If any of the listed solutions sounds like something preferable/better usable with your current workflow, please let me know. Otherwise I'll just implement the least hacky and most scalable solution. > I'd put documentation as code comments if I were you. Can do. Is it alright if I start using [type hints](https://docs.python.org/3/library/typing.html) and [annotations](https://www.geeksforgeeks.org/function-annotations-python/) as well? The latter might make it a bit harder for newcomers to pick it up, but it can be a tremendous help with debugging in the longrun.
MichaelYick commented 2021-06-15 07:41:00 +00:00
Member
Copy Link

The two solutions I currently have for this are filling the remaining space with invisible images - easy to do but a bit hacky

I don't see too much of a problem with this, I can see how it may be manual and a bit annoying, but it seems to be an easier to maintain (due to low barrier of entry) to work with. Maybe even have the code automatically correct by adding invisable images to fill it out. Easy code to maintain, easy code to write. Yes, its hacky, but dealing with null data isn't something that seems TOO bad.

Or ditching the grid and manually dealing with x and y alignment

If you think that the slower solution of manually dealing with X/Y cords is better, then go ahead, but I do think that it'd be harder to maintain due to the possible brittleness of the code (if the code breaks, it'll be a nightmare to fix and may take just as long if something goes really wrong). If you can acconut for that brittle code, then go right ahead.

The other issue is that some cgs are way out of the 1920 * 1080 ballpark

Yeah I forgot about the panning cgs. I can see the problem now. Do you think that you could make it where, in those cases, they may have a special flag for being displayed with a pan? Seems like it might be a bit frustrating to code, but it'll be close to how the actual game displayed the images. Other than that, maybe using Ren'py's im.Scale and renpy.check_image_attributes in combination to scale the stuff down to fit on screen would be ideal (though, that may cause aspect ratio issues, but we just need it to be "close enough" to be good).

Is it alright if I start using type hints and annotations as well?

Sure, but please do put the PEP abstracts for both in as to have a "why" for what these are. Personally, having nice comments on what an unfamiliar thing is makes working with code much easier. Attracting amneture talent and manpower is a bit of a goal due to the nature of this project, so making sure they are able to easily learn from the code and understand the code would be ideal. They're simple after reading the abstracts and should be able to easily educate noobies.
https://www.python.org/dev/peps/pep-0484/#abstract
https://www.python.org/dev/peps/pep-3107/#abstract

Anyway, good work as usual. Hopefully a good solution is found in the end.

>The two solutions I currently have for this are filling the remaining space with invisible images - easy to do but a bit hacky I don't see too much of a problem with this, I can see how it may be manual and a bit annoying, but it seems to be an easier to maintain (due to low barrier of entry) to work with. Maybe even have the code automatically correct by adding invisable images to fill it out. Easy code to maintain, easy code to write. Yes, its hacky, but dealing with null data isn't something that seems TOO bad. >Or ditching the grid and manually dealing with x and y alignment If you think that the slower solution of manually dealing with X/Y cords is better, then go ahead, but I do think that it'd be harder to maintain due to the possible brittleness of the code (if the code breaks, it'll be a nightmare to fix and may take just as long if something goes really wrong). If you can acconut for that brittle code, then go right ahead. >The other issue is that some cgs are way out of the 1920 * 1080 ballpark Yeah I forgot about the panning cgs. I can see the problem now. Do you think that you could make it where, in those cases, they may have a special flag for being displayed with a pan? Seems like it might be a bit frustrating to code, but it'll be close to how the actual game displayed the images. Other than that, maybe using Ren'py's im.Scale and renpy.check_image_attributes in combination to scale the stuff down to fit on screen would be ideal (though, that may cause aspect ratio issues, but we just need it to be "close enough" to be good). >Is it alright if I start using type hints and annotations as well? Sure, but please do put the PEP abstracts for both in as to have a "why" for what these are. Personally, having nice comments on what an unfamiliar thing is makes working with code much easier. Attracting amneture talent and manpower is a bit of a goal due to the nature of this project, so making sure they are able to easily learn from the code and understand the code would be ideal. They're simple after reading the abstracts and should be able to easily educate noobies. https://www.python.org/dev/peps/pep-0484/#abstract https://www.python.org/dev/peps/pep-3107/#abstract Anyway, good work as usual. Hopefully a good solution is found in the end.
MichaelYick added a new dependency 2021-06-16 09:26:11 +00:00
#29 Fixes #19 - Extras menu
dagoddamnlazysnake added 3 commits 2021-06-16 17:09:58 +00:00 
This should be the last commit directly to master BESIDES branch merges.
dagoddamnlazysnake commented 2021-06-16 17:12:08 +00:00
Author
First-time contributor
Copy Link

Updated with the mess of loading all files. This is now very unclean and untidy, didn't have much time.

Also, the gallery needs to be paginated since loading all images at once causes the app to freeze for multiple seconds.

Updated with the mess of loading all files. This is now very unclean and untidy, didn't have much time. Also, the gallery needs to be paginated since loading all images at once causes the app to freeze for multiple seconds.
dagoddamnlazysnake added 1 commit 2021-06-16 19:54:17 +00:00
dagoddamnlazysnake commented 2021-06-16 19:56:47 +00:00
Author
First-time contributor
Copy Link

Either I'm retarded, or the ren'py parser does not actually support type hinting. For now I've done a TypeScript kinda deal with comments.

Either I'm retarded, or the ren'py parser does not actually support type hinting. For now I've done a TypeScript kinda deal with comments.
MichaelYick commented 2021-06-16 22:36:16 +00:00
Member
Copy Link

that works too

that works too
dagoddamnlazysnake added 1 commit 2021-06-17 16:36:35 +00:00
dagoddamnlazysnake added 1 commit 2021-06-17 16:53:07 +00:00
dagoddamnlazysnake commented 2021-06-17 16:54:09 +00:00
Author
First-time contributor
Copy Link

Added pagination.

@PrincipalSpears Will probably need button designs for prev/next page, and end/start if you guys want that too.

Added pagination. @PrincipalSpears Will probably need button designs for prev/next page, and end/start if you guys want that too.
dagoddamnlazysnake added 1 commit 2021-06-17 16:55:19 +00:00
dagoddamnlazysnake added 1 commit 2021-06-17 18:31:12 +00:00
dagoddamnlazysnake commented 2021-06-17 18:32:40 +00:00
Author
First-time contributor
Copy Link

Added unlocking cgs via a global function, with an example on script.rpy:362.

New known issue: Cgs are only shown as unlocked after restarting the game (for some reason).

Added unlocking cgs via a global function, with an example on script.rpy:362. New known issue: Cgs are only shown as unlocked after restarting the game (for some reason).
dagoddamnlazysnake added 1 commit 2021-06-17 18:38:53 +00:00
MichaelYick changed title from WIP: Issue #3 Image Gallery to WIP: Fixes #3 - Image Gallery 2021-06-18 01:57:42 +00:00
MichaelYick added this to the Patchy-Patch5 Release milestone 2021-06-20 04:28:56 +00:00
MichaelYick commented 2021-06-21 22:07:55 +00:00
Member
Copy Link

maybe make the example a comment instead of an in script modification, we did away with the massive "script.rpy".

Any updates on this feature, how close is it to being done?

maybe make the example a comment instead of an in script modification, we did away with the massive "script.rpy". Any updates on this feature, how close is it to being done?
dagoddamnlazysnake commented 2021-06-22 06:13:50 +00:00
Author
First-time contributor
Copy Link

maybe make the example a comment instead of an in script modification

Yeah, were gonna remove that before submitting the PR for merge/code review.

Any updates on this feature, how close is it to being done?

Extras screen redo is a hard dependency, so I would finish this after that gets merged.

Although currently still only the 1920 * 1080 images are shown correctly, so I'd have to know if the scale n crop method that I've described above is acceptable (for the thumbnails on the paginated gallery page). I have no idea about panning the bigger images when opened, but I'm willing to bet that ren'py has a default way to show them. And then there's the issue of the cgs only unlocking after restaring the application.

Also the unlocks have to be put in one by one, for which I would need a list or something.

All in all, I'd say a few days, but due to work and exams my time is very limited till the 29th. If this is an unacceptable timeframe, feel free to put someone else on the issue.

> maybe make the example a comment instead of an in script modification Yeah, were gonna remove that before submitting the PR for merge/code review. > Any updates on this feature, how close is it to being done? Extras screen redo is a hard dependency, so I would finish this after that gets merged. Although currently still only the 1920 * 1080 images are shown correctly, so I'd have to know if the scale n crop method that I've described above is acceptable (for the thumbnails on the paginated gallery page). I have no idea about panning the bigger images when opened, but I'm willing to bet that ren'py has a default way to show them. And then there's the issue of the cgs only unlocking after restaring the application. Also the unlocks have to be put in one by one, for which I would need a list or something. All in all, I'd say a few days, but due to work and exams my time is very limited till the 29th. If this is an unacceptable timeframe, feel free to put someone else on the issue.
MichaelYick commented 2021-06-22 18:35:39 +00:00
Member
Copy Link

Extras screen redo is a hard dependency, so I would finish this after that gets merged.

We got a PR for that open: https://git.snootgame.xyz/Cavemanon/SnootGame/pulls/29

scale n crop method that I've described above is acceptable

Guess its better to get it out for review than ponder if its good or not, yeah go ahead.

I have no idea about panning the bigger images when opened, but I'm willing to bet that ren'py has a default way to show them

The script has panning in it, maybe looking there and referencing the documentation could be worthwhile

And then there's the issue of the cgs only unlocking after restaring the application.

Looking at the code, maybe its an issue of loadGallery not being ran with the addGalleryItem. Due to this, I don't think the game is being updated until loadGallery is ran again (upon a restart)

All in all, I'd say a few days, but due to work and exams my time is very limited till the 29th. If this is an unacceptable timeframe, feel free to put someone else on the issue.

Don't worry man, we're not really on a big time crunch. Around the 29th would be good and hopefully will hit the Patchy-Patch5 deadline. If it doesn't and it goes over a few days, big whoop, better late than never. Hopefully the UI redesign will be done soon enough so this can be integrated into that and we can get everything pushed and done with.

>Extras screen redo is a hard dependency, so I would finish this after that gets merged. We got a PR for that open: https://git.snootgame.xyz/Cavemanon/SnootGame/pulls/29 >scale n crop method that I've described above is acceptable Guess its better to get it out for review than ponder if its good or not, yeah go ahead. >I have no idea about panning the bigger images when opened, but I'm willing to bet that ren'py has a default way to show them The script has panning in it, maybe looking there and referencing the documentation could be worthwhile >And then there's the issue of the cgs only unlocking after restaring the application. Looking at the code, maybe its an issue of loadGallery not being ran with the addGalleryItem. Due to this, I don't think the game is being updated until loadGallery is ran again (upon a restart) >All in all, I'd say a few days, but due to work and exams my time is very limited till the 29th. If this is an unacceptable timeframe, feel free to put someone else on the issue. Don't worry man, we're not really on a big time crunch. Around the 29th would be good and hopefully will hit the Patchy-Patch5 deadline. If it doesn't and it goes over a few days, big whoop, better late than never. Hopefully the UI redesign will be done soon enough so this can be integrated into that and we can get everything pushed and done with.
MichaelYick commented 2021-07-01 15:18:30 +00:00
Member
Copy Link

Do you have any time you'd be free to finish this up? Not really urgent, but it'd be nice to know. If not, that's fine (real life comes before internet meme games), just state what issues are left to clean up and I'll give a go at it.

Do you have any time you'd be free to finish this up? Not really urgent, but it'd be nice to know. If not, that's fine (real life comes before internet meme games), just state what issues are left to clean up and I'll give a go at it.
Caliber commented 2021-07-02 02:12:56 +00:00
First-time contributor
Copy Link

Minor thing, but for the sake of not having to locate and copy-paste something everywhere a CG is called, why don't you just modify renpy to call your new function every time we use show to load a new CG? The function you want is defined in exports.py, in the renpy folder that is for some reason not present in the repo. Seems to work with a custom-defined print statement well enough.

This way, the effort required by anyone else to impl. this should be exactly 0.



Minor thing, but for the sake of not having to locate and copy-paste something everywhere a CG is called, why don't you just modify renpy to call your new function every time we use `show` to load a new CG? The function you want is defined in `exports.py`, in the renpy folder that is for some reason not present in the repo. Seems to work with a custom-defined print statement well enough. This way, the effort required by anyone else to impl. this should be exactly 0. ![](https://messhole.net/bullshit/1.PNG) ![](https://messhole.net/bullshit/4.PNG) ![](https://messhole.net/bullshit/3.PNG)
MichaelYick commented 2021-07-02 03:14:32 +00:00
Member
Copy Link

why don't you just modify renpy to call your new function every time we use show to load a new CG?

Well, not inherently a bad idea, we'd be working with a custom version of renpy at that point and that might cause issues (correct me if im wrong).

also, we'd have to set it up to detect if the show/scene function to test if an image is actually a cg or not, not too bad, but it'll take a little bit of time.

>why don't you just modify renpy to call your new function every time we use show to load a new CG? Well, not inherently a bad idea, we'd be working with a custom version of renpy at that point and that might cause issues (correct me if im wrong). also, we'd have to set it up to detect if the show/scene function to test if an image is actually a cg or not, not too bad, but it'll take a little bit of time.
Caliber commented 2021-07-02 09:20:58 +00:00
First-time contributor
Copy Link

Well, not inherently a bad idea, we'd be working with a custom version of renpy at that point and that might cause issues

I'm unsure what sort of issues it would cause, given the game ships with whatever version of renpy you bundle it with. It's not really something users need to or are even supposed to install, so modding it shouldn't pose any issues, though I cannot say that authoritatively.

also, we'd have to set it up to detect if the show/scene function to test if an image is actually a cg or not, not too bad, but it'll take a little bit of time.

The simplest solution I can think of, given we already have a script that reads through everything in images/cgs/ would be to just push everything it runs into to an array (python calls them lists?) and store that somewhere accessible, so we can just do if filename in cgslist: and the rest of the function can follow normally.

I don't suspect this project requires much thought about scope given how simple most of it is so far, so dumping it in global probably isn't a bad idea.

> Well, not inherently a bad idea, we'd be working with a custom version of renpy at that point and that might cause issues I'm unsure what sort of issues it would cause, given the game ships with whatever version of renpy you bundle it with. It's not really something users need to or are even supposed to install, so modding it shouldn't pose any issues, though I cannot say that authoritatively. > also, we'd have to set it up to detect if the show/scene function to test if an image is actually a cg or not, not too bad, but it'll take a little bit of time. The simplest solution I can think of, given we already have a script that reads through everything in `images/cgs/` would be to just push everything it runs into to an array (python calls them lists?) and store that somewhere accessible, so we can just do `if filename in cgslist:` and the rest of the function can follow normally. I don't suspect this project requires much thought about scope given how simple most of it is so far, so dumping it in global probably isn't a bad idea.
nutbuster commented 2021-07-02 13:05:17 +00:00
Member
Copy Link
def seen_image(name):
    """
    :doc: image_func

    Returns True if the named image has been seen at least once on the user's
    system. An image has been seen if it's been displayed using the show statement,
    scene statement, or :func:`renpy.show` function. (Note that there are cases
    where the user won't actually see the image, like a show immediately followed by
    a hide.)
    """
    if not isinstance(name, tuple):
        name = tuple(name.split())

    return name in renpy.game.persistent._seen_images # @UndefinedVariable

@Caliber, No need for fancy stuff. Just do renpy.seen_image(cg_name) for checking if the cg has been seen or not - the rest should be very straight forward and requires zero hassle with the script's script.

``` def seen_image(name): """ :doc: image_func Returns True if the named image has been seen at least once on the user's system. An image has been seen if it's been displayed using the show statement, scene statement, or :func:`renpy.show` function. (Note that there are cases where the user won't actually see the image, like a show immediately followed by a hide.) """ if not isinstance(name, tuple): name = tuple(name.split()) return name in renpy.game.persistent._seen_images # @UndefinedVariable ``` @Caliber, No need for fancy stuff. Just do `renpy.seen_image(cg_name)` for checking if the cg has been seen or not - the rest should be very straight forward and requires zero hassle with the script's script.
Caliber commented 2021-07-02 17:05:18 +00:00
First-time contributor
Copy Link

Just do renpy.seen_image(cg_name) for checking if the cg has been seen or not - the rest should be very straight forward and requires zero hassle with the script's script.

Well fuck, I guess that's what I get for not reading the fucking manual. I should have guessed they had something like this built in when everyone realized they had basic support for image galleries. Thanks for pointing this out.

The problem of determining whether or not it's a CG still stands though. But... that's pretty easily fixable with this, given the other resources we already have.

> Just do `renpy.seen_image(cg_name)` for checking if the cg has been seen or not - the rest should be very straight forward and requires zero hassle with the script's script. Well fuck, I guess that's what I get for not reading the fucking manual. I should have guessed they had something like this built in when everyone realized they had basic support for image galleries. Thanks for pointing this out. The problem of determining whether or not it's a CG still stands though. But... that's pretty easily fixable with this, given the other resources we already have.
dagoddamnlazysnake commented 2021-07-02 18:37:41 +00:00
Author
First-time contributor
Copy Link

Sorry for the absence, was busy putting together the sing project lol. I'll finish this up during the weekend, preferably saturday.

Sorry for the absence, was busy putting together the sing project lol. I'll finish this up during the weekend, preferably saturday.
dagoddamnlazysnake commented 2021-07-02 18:41:07 +00:00
Author
First-time contributor
Copy Link

As for monkeypatching the lib show func, I'd actually recommend against it. If nobody wants to go through the scripts we still run a macro in some ide, or grep and replace. Though as the saying goes, you can do something by hand in an hour, or spend a day failing to automate it.

Edit: Although, there might be a way. If show is a legit func (I was so far assuming it's markup for the renpy interpreter), I'm sure we can do a HoF that returns it while unlocking a gallery item. Though that might end up with retarded syntax. I'll see.

As for monkeypatching the lib show func, I'd actually recommend against it. If nobody wants to go through the scripts we still run a macro in some ide, or grep and replace. Though as the saying goes, you can do something by hand in an hour, or spend a day failing to automate it. Edit: Although, there might be a way. If show is a legit func (I was so far assuming it's markup for the renpy interpreter), I'm sure we can do a HoF that returns it while unlocking a gallery item. Though that might end up with retarded syntax. I'll see.
nutbuster commented 2021-07-02 21:45:05 +00:00
Member
Copy Link

Well fuck, I guess that's what I get for not reading the fucking manual.

The manual is terrible to begin with.

The problem of determining whether or not it's a CG still stands though. But... that's pretty easily fixable with this, given the other resources we already have.

For the most part all of the important CG images are all in one directory, with others key ones are also easy to find. (images/CG, images/animation & images/NotForKids!)

> Well fuck, I guess that's what I get for not reading the fucking manual. The manual is terrible to begin with. > The problem of determining whether or not it's a CG still stands though. But... that's pretty easily fixable with this, given the other resources we already have. For the most part all of the important CG images are all in one directory, with others key ones are also easy to find. (images/CG, images/animation & images/NotForKids!)
dagoddamnlazysnake commented 2021-07-03 09:04:01 +00:00
Author
First-time contributor
Copy Link

So I went a round with a custom scene/show or monkeypatch. A serious issue is, and this goes for seen_image as well, that displayables and images are pretty different. Calling "scene X with Y" is a shorthand for show, and just calling "scene X" without X having been manually defined does work, BUT it's not loaded to images. Try renpy.list_images, and you won't find "stairs" or "a04" in there, since these aren't manually defined with renpy.image.

A lot of this is just syntactic sugar for the interpreter. The string is just parsed via renpy.displayable, as far as I can tell, and matched with the first file that has a name like that (ie.: spaces and underscores are interchangeable, mostly). Likewise, renpy.get_showing_tags will not list it either, whether loaded by "scene X with Y", or calling renpy.scene(X) and renpy.with_statement(Y) under the hood either.

As such, I'd recommend getting a proof-of-concept proto in the patch that does indeed work, and it can be niceified later on. For now I'll just focus on resolving the conflicts, putting the screen in place (and tidying up its layout), and fixing the issue with differently sized images, preferably with transitions. That said, the current version will only work with the cgs folder automatically, I can add a mnually defineable extension to it, but I'll need a list of such files for that (preferably relative path to game/images/).

So I went a round with a custom scene/show or monkeypatch. A serious issue is, and this goes for seen_image as well, that displayables and images are pretty different. Calling "scene X with Y" is a shorthand for show, and just calling "scene X" without X having been manually defined does work, BUT it's not loaded to *images*. Try renpy.list_images, and you won't find "stairs" or "a04" in there, since these aren't manually defined with renpy.image. A lot of this is just syntactic sugar for the interpreter. The string is just parsed via renpy.displayable, as far as I can tell, and matched with the first file that has a name like that (ie.: spaces and underscores are interchangeable, mostly). Likewise, renpy.get_showing_tags will not list it either, whether loaded by "scene X with Y", or calling renpy.scene(X) and renpy.with_statement(Y) under the hood either. As such, I'd recommend getting a proof-of-concept proto in the patch that does indeed work, and it can be niceified later on. For now I'll just focus on resolving the conflicts, putting the screen in place (and tidying up its layout), and fixing the issue with differently sized images, preferably with transitions. That said, the current version will only work with the cgs folder automatically, I can add a mnually defineable extension to it, but I'll need a list of such files for that (preferably relative path to game/images/).
dagoddamnlazysnake reopened this pull request 2021-07-03 09:08:30 +00:00
dagoddamnlazysnake commented 2021-07-03 09:08:50 +00:00
Author
First-time contributor
Copy Link

accidentally clicked the close btw dont mind me xd

accidentally clicked the close btw dont mind me xd
Caliber commented 2021-07-03 09:50:26 +00:00
First-time contributor
Copy Link

I'd recommend getting a proof-of-concept proto in the patch that does indeed work, and it can be niceified later on.

I'll try my hand at getting this working, then.

I am very new to git despite programming for way long, is there some sort of etiquette that I should be following when I make a PR or is it fine for me to just copy-paste shit from other PRs that would obviously be conflicting, for the sake of making it work, or is there some way to make a PR for a PR? I will have to steal what's present in this one since it's all ancillary to anything I would change.

> I'd recommend getting a proof-of-concept proto in the patch that does indeed work, and it can be niceified later on. I'll try my hand at getting this working, then. I am very new to git despite programming for way long, is there some sort of etiquette that I should be following when I make a PR or is it fine for me to just copy-paste shit from other PRs that would obviously be conflicting, for the sake of making it work, or is there some way to make a PR for a PR? I will have to steal what's present in this one since it's all ancillary to anything I would change.
nutbuster commented 2021-07-03 09:59:23 +00:00
Member
Copy Link

I am very new to git despite programming for way long, is there some sort of etiquette that I should be following when I make a PR or is it fine for me to just copy-paste shit from other PRs that would obviously be conflicting, for the sake of making it work, or is there some way to make a PR for a PR? I will have to steal what's present in this one since it's all ancillary to anything I would change.

You can just remote add & pull @dagoddamnlazysnake 's branch - work on that and then either PR into his branch (requires waiting for him to accept the PR & merge naturally) or just make a new PR

> I am very new to git despite programming for way long, is there some sort of etiquette that I should be following when I make a PR or is it fine for me to just copy-paste shit from other PRs that would obviously be conflicting, for the sake of making it work, or is there some way to make a PR for a PR? I will have to steal what's present in this one since it's all ancillary to anything I would change. You can just remote add & pull @dagoddamnlazysnake 's branch - work on that and then either PR into his branch (requires waiting for him to accept the PR & merge naturally) or just make a new PR
👍 1
dagoddamnlazysnake added 22 commits 2021-07-03 10:43:16 +00:00 
Reviewed-on: https://git.snootgame.xyz/Cavemanon/SnootGame/pulls/30
Reviewed-on: https://git.snootgame.xyz/Cavemanon/SnootGame/pulls/35
# Conflicts:
#	game/screens.rpy
#	game/script.rpy
dagoddamnlazysnake commented 2021-07-03 10:45:06 +00:00
Author
First-time contributor
Copy Link

@Caliber @nutbuster Was this issue handed to someone in my absence? I'm fine with that, took my time afterall, however I'm pretty clsoe to finishing it up now. Only the panning and actual unlocking should remain.

@Caliber @nutbuster Was this issue handed to someone in my absence? I'm fine with that, took my time afterall, however I'm pretty clsoe to finishing it up now. Only the panning and actual unlocking should remain.
Caliber commented 2021-07-03 10:48:18 +00:00
First-time contributor
Copy Link

@dagoddamnlazysnake The way you worded your whole last comment sounded like you meant for me to try making a functional version of what I was bitching about with the automatically-marking-images-as-seen thing. Was that not what you intended?

@dagoddamnlazysnake The way you worded your whole last comment sounded like you meant for me to try making a functional version of what I was bitching about with the automatically-marking-images-as-seen thing. Was that not what you intended?
dagoddamnlazysnake commented 2021-07-03 10:51:23 +00:00
Author
First-time contributor
Copy Link

@Caliber I'm sorry for any confusion, I meant to address in general whoever is responsible for making this decision in regards to the patch and milestones.

Edit: Though I don't see these as musually exclusive. I can dish out a prototype to keep the deadline, and someone else can make a easier to use version of it.

@Caliber I'm sorry for any confusion, I meant to address in general whoever is responsible for making this decision in regards to the patch and milestones. Edit: Though I don't see these as musually exclusive. I can dish out a prototype to keep the deadline, and someone else can make a easier to use version of it.
Caliber commented 2021-07-03 10:55:22 +00:00
First-time contributor
Copy Link

@dagoddamnlazysnake it wouldn't be a bad idea to have two heads on it at once, especially given you seem to know more about renpy specifically than I do. I will share what I have here rather than make a whole new commit or anything official and see where it goes from there.

@dagoddamnlazysnake it wouldn't be a bad idea to have two heads on it at once, especially given you seem to know more about renpy specifically than I do. I will share what I have here rather than make a whole new commit or anything official and see where it goes from there.
dagoddamnlazysnake added 1 commit 2021-07-03 11:40:40 +00:00
dagoddamnlazysnake commented 2021-07-03 11:43:21 +00:00
Author
First-time contributor
Copy Link

Added basic ass panning for gallery items, and "better" unlocking. I say that in quotes because for the life of me I cannot figure out why it won't unlock the image without restarting the application.

In any case, all that's left is putting in the unlock for each cg, then I'm done unless there are more requests.

Added basic ass panning for gallery items, and "better" unlocking. I say that in quotes because for the life of me I cannot figure out why it won't unlock the image without restarting the application. In any case, all that's left is putting in the unlock for each cg, then I'm done unless there are more requests.
dagoddamnlazysnake added 1 commit 2021-07-03 12:28:49 +00:00
dagoddamnlazysnake changed title from WIP: Fixes #3 - Image Gallery to Fixes #3 - Image Gallery 2021-07-03 12:29:11 +00:00
dagoddamnlazysnake commented 2021-07-03 12:29:19 +00:00
Author
First-time contributor
Copy Link

Requesting review.

Requesting review.
dagoddamnlazysnake added 1 commit 2021-07-03 12:29:44 +00:00
dagoddamnlazysnake added 1 commit 2021-07-03 12:33:56 +00:00
Caliber commented 2021-07-03 14:05:45 +00:00
First-time contributor
Copy Link

Alright, managed to get a proof of concept up and running. That was a lot more clusterfuck-y than I thought it would be, though only because renpy is fucking braindead in how it handles scope. I assume it's for security, but between the dogshit documentation I tried to skim through and the relative obscurity of the engine itself, I had basically no luck figuring out why rpy scripts and the game's regular assets somehow have different global scopes.

This solution is hacky as fuck but I could not find a better way. It does work 100% though.

The long and short of it is that there's at least one properly global variable accessible to both the virtual rpy scope and the regular outside python world. I decided to just shove everything into config for the time being, because evidently that exists in both scopes somehow, despite everything else not. I am mostly experienced with PHP and JS so maybe this is just some python-specific thing I have yet to learn but this seems fucking retarded to my brain. I would have had this done in like 2 seconds if it were not for the autism of whoever created renpy.

The only base-game file changed was exports.py inside the game folder as mentioned above, inside the show function, and all that was added was this. This can go anywhere inside the function before the return statement(s)

    if hasattr(config,"updateGallery"):
        config.updateGallery(name)

Here's all the changes run through meld for visibility. Actual code is attached. I cannot attach files.


Alright, managed to get a proof of concept up and running. That was a lot more clusterfuck-y than I thought it would be, though only because renpy is fucking braindead in how it handles scope. I assume it's for security, but between the dogshit documentation I tried to skim through and the relative obscurity of the engine itself, I had basically no luck figuring out why rpy scripts and the game's regular assets somehow have different global scopes. This solution is hacky as fuck but I could not find a better way. It does work 100% though. The long and short of it is that there's at least one properly global variable accessible to both the virtual rpy scope and the regular outside python world. I decided to just shove everything into `config` for the time being, because evidently that exists in both scopes somehow, despite everything else not. I am mostly experienced with PHP and JS so maybe this is just some python-specific thing I have yet to learn but this seems fucking retarded to my brain. I would have had this done in like 2 seconds if it were not for the autism of whoever created renpy. The only base-game file changed was `exports.py` inside the `game` folder as mentioned above, inside the `show` function, and all that was added was this. This can go anywhere inside the function before the return statement(s) ``` if hasattr(config,"updateGallery"): config.updateGallery(name) ``` Here's all the changes run through meld for visibility. ~~Actual code is attached.~~ I cannot attach files. ![](https://messhole.net/bullshit/5.PNG) ![](https://messhole.net/bullshit/6.PNG)
MichaelYick commented 2021-07-04 00:45:12 +00:00
Member
Copy Link

sorry about my absence yesterday, my little bro's computer had a stroke and died.

Reviewing now and game doesn't start from SDK's GUI. Nor does it compile from SDK gui. (seems to be a path issue, check traceback I attached)

Starting from the terminal in the project folder works, but not having the SDK to be able to start is a pretty big problem for quality of life (i.e if people wanna mod the game, they'd have to use the terminal, winfrens suffer).

Also, going through chapter one, there were some small preformance hiccups when a cg was triggered. I was skipping through everything though, so this issue might not be everywhere. Everyone should check this out on their own

gallery itself still is missing thumbnails to each of the image until restart.

thumbnails are stretched, maybe it is just wise to crop them instead. Hell, it might be worth it to just manually crop this stuff for the gallery. I regret not saying to do that before lmao.

scroll bar is still massive.

Panning works! Hurrah!

Images are in a bit of a non-sequiental order. Might be worthwhile for them to fill automatically (if you wish to do that)

So far this is all I can see, basically everything else works good.

sorry about my absence yesterday, my little bro's computer had a stroke and died. Reviewing now and game doesn't start from SDK's GUI. Nor does it compile from SDK gui. (seems to be a path issue, check traceback I attached) Starting from the terminal in the project folder works, but not having the SDK to be able to start is a pretty big problem for quality of life (i.e if people wanna mod the game, they'd have to use the terminal, winfrens suffer). Also, going through chapter one, there were some small preformance hiccups when a cg was triggered. I was skipping through everything though, so this issue might not be everywhere. Everyone should check this out on their own gallery itself still is missing thumbnails to each of the image until restart. thumbnails are stretched, maybe it is just wise to crop them instead. Hell, it might be worth it to just manually crop this stuff for the gallery. I regret not saying to do that before lmao. scroll bar is still massive. Panning works! Hurrah! Images are in a bit of a non-sequiental order. Might be worthwhile for them to fill automatically (if you wish to do that) So far this is all I can see, basically everything else works good.
traceback.txt
1.8 KiB
dagoddamnlazysnake commented 2021-07-04 05:38:31 +00:00
Author
First-time contributor
Copy Link

I'll check on these, unfortunately can only do so in the evening (family matter - around 10 hours from this post). I'll add some insight on each concern, so somebody can try and fix them if need be.

Compile from the SDK: Could you confirm which part of the path is incorrect on your end? I'm guessing the manual addition of /game/, not sure if that's there runtime. Though that needs to be there designtime, so maybe an isDEV flag for it? My other guess would be something with the slashes, some OS might require backslashes.

Hiccups with unlocking cgs: This could be due to having to reload the entire gallery for this stuff to take effect. Haven't noticed on my end, but I'm not running a potato setup so it can definitely do that on lower end machines. Adding to persistene.cggallery is easy, and so is adding to galleryItems since these are both arrays essentially. The problem is g:Gallery(), since you can only set up a button/image once, and you can only do them in sequential order. What I'd try first is changing the static unlock from "True" and "False" to an actual expression in persistent, then changing that instead of calling loadGallery from unlockCg. It might also fix having to reset the game for the img to show. Though it still might need Caliber's config hack to work.

Manual overrides for crop and ordering: Can be done more or less easily, just adding a big ol ifelse or switch to cg and manipulating the displayable. Ordering them however would require a list in which to order them. I'm sorry but I have so little freetime that it would take days for me to go through it all. In any case, for this the best solution seems to be adding a sortGalleryItems function that's called at the end of load (or after load), and sorts galleryItems. Its items are identifiable by filename.

Scrollbar: Yeah, that can be removed. I put it there for testing purposes and forgot to remove. Just delete the `scroll="viewport" bit from the screen definition.

I'll check on these, unfortunately can only do so in the evening (family matter - around 10 hours from this post). I'll add some insight on each concern, so somebody can try and fix them if need be. Compile from the SDK: Could you confirm which part of the path is incorrect on your end? I'm guessing the manual addition of /game/, not sure if that's there runtime. Though that needs to be there designtime, so maybe an isDEV flag for it? My other guess would be something with the slashes, some OS might require backslashes. Hiccups with unlocking cgs: This could be due to having to reload the entire gallery for this stuff to take effect. Haven't noticed on my end, but I'm not running a potato setup so it can definitely do that on lower end machines. Adding to `persistene.cggallery` is easy, and so is adding to `galleryItems` since these are both arrays essentially. The problem is `g:Gallery()`, since you can only set up a button/image once, and you can only do them in sequential order. What I'd try first is changing the static unlock from `"True"` and `"False"` to an actual expression in `persistent`, then changing that instead of calling `loadGallery` from `unlockCg`. It might also fix having to reset the game for the img to show. Though it still might need Caliber's config hack to work. Manual overrides for crop and ordering: Can be done more or less easily, just adding a big ol ifelse or switch to `cg` and manipulating the displayable. Ordering them however would require a list in which to order them. I'm sorry but I have so little freetime that it would take days for me to go through it all. In any case, for this the best solution seems to be adding a `sortGalleryItems` function that's called at the end of load (or after load), and sorts `galleryItems`. Its items are identifiable by filename. Scrollbar: Yeah, that can be removed. I put it there for testing purposes and forgot to remove. Just delete the `scroll="viewport" bit from the screen definition.
dagoddamnlazysnake changed title from Fixes #3 - Image Gallery to WIP: Fixes #3 - Image Gallery 2021-07-04 05:40:54 +00:00
MichaelYick commented 2021-07-04 20:50:59 +00:00
Member
Copy Link

Compile from the SDK: Could you confirm which part of the path is incorrect on your end? I'm guessing the manual addition of /game/, not sure if that's there runtime.

OSError: [Errno 2] No such file or directory: '/home/joybuke/Documents/ComputerScience/Projects/Snoot/renpy-7.4.2-sdk/game/images/cgs/'

this was in the traceback

Manual overrides for crop and ordering

Yeah just manually crop and do an if else, nothing complex but maintainable.

If you wanna do the "sortGalleryItems", go for it, its not urgent to have it all sorted, but it'd be nice.

>Compile from the SDK: Could you confirm which part of the path is incorrect on your end? I'm guessing the manual addition of /game/, not sure if that's there runtime. OSError: [Errno 2] No such file or directory: '/home/joybuke/Documents/ComputerScience/Projects/Snoot/renpy-7.4.2-sdk/game/images/cgs/' this was in the traceback >Manual overrides for crop and ordering Yeah just manually crop and do an if else, nothing complex but maintainable. If you wanna do the "sortGalleryItems", go for it, its not urgent to have it all sorted, but it'd be nice.
dagoddamnlazysnake commented 2021-07-05 06:06:11 +00:00
Author
First-time contributor
Copy Link

Still couldn't figure out having both not hiccupy unlock and it not requiring restart.

Still couldn't figure out having both not hiccupy unlock and it not requiring restart.
Caliber commented 2021-07-05 06:43:49 +00:00
First-time contributor
Copy Link

I looked through renpy's docs again but I can't find anything to just wipe and regenerate a screen. Do you think it would be possible to do some weird hack solution by defining the coordinates with the generator script and then using show and hide or whatever the UI equivalent is on menu open so you can change whatever it references and shoves into whatever coordinates, given you can't just find some way to force reflow every time you open it?

I looked through renpy's docs again but I can't find anything to just wipe and regenerate a screen. Do you think it would be possible to do some weird hack solution by defining the coordinates with the generator script and then using `show` and `hide` or whatever the UI equivalent is on menu open so you can change whatever it references and shoves into whatever coordinates, given you can't just find some way to force reflow every time you open it?
coolestskinnieinthejungle commented 2021-07-06 03:54:06 +00:00
Member
Copy Link

might be able to hop in and assist with this since i got my other channel of patch5 work all finished (except final review). let me know if i can help with this - i'll try to reread the thread when im not at work and get a bit more up to speed.

might be able to hop in and assist with this since i got my other channel of patch5 work all finished (except final review). let me know if i can help with this - i'll try to reread the thread when im not at work and get a bit more up to speed.
coolestskinnieinthejungle modified the milestone from Patchy-Patch5 Release to Monster-Update-6 2021-07-09 04:21:45 +00:00
coolestskinnieinthejungle commented 2021-07-21 17:41:51 +00:00
Member
Copy Link

this issue is pretty much done - any objections to closing it

this issue is pretty much done - any objections to closing it
MichaelYick commented 2021-07-27 21:27:21 +00:00
Member
Copy Link

aye, this still breaks renpy's gui compiler and loader. traceback is still the same. Someone should put a check in here to see if you're using the gui version to prevent a break, seems like an easy work around.

aye, this still breaks renpy's gui compiler and loader. traceback is still the same. Someone should put a check in here to see if you're using the gui version to prevent a break, seems like an easy work around.
traceback.txt
1.8 KiB
nutbuster commented 2021-07-30 22:34:44 +00:00
Member
Copy Link

Closed because of #55 was merged

Closed because of #55 was merged
nutbuster closed this pull request 2021-07-30 22:34:44 +00:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
bug
Something is not working
Critical Priority
Absolutely urgent issues that must be delt with before others can even be considered.
duplicate
This issue or pull request already exists
enhancement
New feature
help wanted
Need some help
High Priority
Bugs that cause crashes, major story errors, or other massively negative issues. Features that are a must-have inclusion or else the game won't be as good.
Low Priority
Minor or easy to miss errors. Features that'd be nice, but can be done with out.
Medium Priority
Errors that stick out, but aren't fatal to gameplay. Features that are in decent demand or would improve gameplay by a signifigant amount
Meta
for all the other fun stuff about the project thats not code
needs more info
Something is wrong
question
refactor
Cleaning up the cruft
wontfix
This won't be fixed
bug
Something is not working
Critical Priority
Absolutely urgent issues that must be delt with before others can even be considered.
duplicate
This issue or pull request already exists
enhancement
New feature
help wanted
Need some help
High Priority
Bugs that cause crashes, major story errors, or other massively negative issues. Features that are a must-have inclusion or else the game won't be as good.
invalid
Something is wrong
Low Priority
Minor or easy to miss errors. Features that'd be nice, but can be done with out.
Medium Priority
Errors that stick out, but aren't fatal to gameplay. Features that are in decent demand or would improve gameplay by a signifigant amount
Meta
for all the other fun stuff about the project thats not code
question
More information is needed
wontfix
This won't be fixed
No Label
Milestone
No items
No Milestone Monster-Update-6
Projects
Clear projects
No project
Assignees
Clear assignees
Cereal Jingo Jluminate Legalo Map MapAnon MichaelYick Mod Nerd Nio nutbuster ReleaseSmith Sl1 TheNerd writerdev
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Depends on
#29 Fixes #19 - Extras menu
Cavemanon/SnootGame
Reference: Cavemanon/SnootGame#14
No description provided.
Delete Branch "feature/ISSUE-3_CG_Gallery"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?