SlayHorizon / godot-tiny-mmo

A tiny open-source web-based MMO / MMORPG built in Godot 4, with unique project organization.
Other
18 stars 4 forks source link

Visual sprite bug (again) #22

Closed WithinAmnesia closed 2 months ago

WithinAmnesia commented 2 months ago

image image This was after re-importing from a fresh repo clone and duplicating from fresh repo clone to setting it up again and both times it was the same error. I am not sure what is going on but now I'm concerned that this might be a reoccurring error that might affect not just my local computer but future builds on more people's computers.

This is after multiple builds having the same issue. Now I'm wondering if the repo is able to copy and paste properly or if there are consistency issues like in rocket engineering where it works 4/5 time but that 1/5 times is unknown why it does not work or it works on the test stand but not in field tests which is puzzling a lot.

Either way it would be a long shot of after 3 rigorous tests where it was repo cloned and fresh copy and paste and trying my best to isolate and make these versions unique and quarantined that there are these reoccurring visual sprite issues. Strange either way this is should be put into a known issues area or to watch again. The fact this has happened 3 times in the same spot across multiple clean new builds is cause for concern but it can be fixed.

I'm wondering if the build is being corrupted or there are a lack of clean files or something is not right with the build cleanliness going on (like over patched source files). If my pc is having issues with what should be easy copy and paste / extraction then how many other people will have the same or worse issues? Clean patching is tricky business indeed. I'm wondering if the knight visual sprite animation file is bugged or if there are re-importing issues going on?

I'll have a look at the sprites and try to isolate this issue again. It is strange and I think it can be fixed but I wonder if this will grow in scale if this kind of thing keeps happening if the project gets bigger naturally. Good data storage and build isolation is very useful to isolate bugs and protect builds from being too interdependent if bugs go unnoticed.

Back up local builds save from potential issues with github and other zip / sharing inconsistencies vs. solely relying upon github / an cloud server to be dependable forever which is rare so its best to have local backups in case the zips or sharing becomes problematic like what happened with Flare or other game dev projects that use tons of interdependent files hosted on Github. I would recommend doing a robust build and test local file storage system to isolate builds and have master builds hosted locally that can be tinkered with as need be to ensure the Github zip and other cloudfile hosting websites have a proper backup / to future proof.

image I use a NATO military and WoW hybrid hybrid patch / iteration system where I have 'Version 000.000.000' being Release.Prototype.Experiment or like 'Version 003.012.421' being 003 Release, 012 Prototype, 421 Experiment. I also have M.M.O.A.R.P.G. Version which is based upon the overall project / initiative and then the engine build / system used for the project / initiative. For example as in if there was a 'Main Battle Tank project / initiative' of say '003' and then the system of say Detroit 008 build version vs. Berlin 006 build version vs. Stockholm 010 build version. These are all competing different systems on the same project / initiative. This is sort of how western arms acquisitions can work in say 'Main Battle Tank 003 project / initiative' where there are multiple bids that may or may not be collaborative in nature. Many complex arms systems came about through this competitive / collaborative method and if it works for trillion+ dollar acquisitions programs then its good enough for keeping the build fields in line lol. Its compacts and works well for keeping complex things simple enough to read on one line.

Archiving and keeping clean records and isolating master builds helps when things get very complex and there are big problems. Backup backup backup everything. I had this what seems over kill archiving really save my self and others when big problems with deep rooted bugs that happened and were unnoticed until compounding problems led the team to be forced to tear into the core systems and rebuild after the 'rot' / bug section was cut out and rebuilt after a lot of effort. A way of going back to just before the bug is super great in saving a lot of work that is at risk of corruption. Or in Github's case bad zip or copy and paste or straight up missing public build files that are missing or corrupted but look the same on github but are not working in practice. Its data consuming to copy and paste the build for every iteration but if you get into really deep issues it save the day many times and the 'back up insurance' of disciplined and thorough backup builds pays for it self. Then tenfold vs. being stuck and having to kill potentially months of builds or be stuck months or year in retrofit hell at the worse of cases. Yet this can be rare but it has happened to myself multiple times enough to learn to backup backup backup lol. This is going well and things should be getting better bit by bit. Art is one thing but code is another lol. I'll try to keep this easier to read but depth of experience is important too for long term success. So is fun and good moral:-D!

WithinAmnesia commented 2 months ago

image I fixed the issue locally on my computer by deleting the knight animation sprites and redoing the animation frames. I'll try to make a pull request if that helps.

WithinAmnesia commented 2 months ago

Its 3 AM and I have a fix but its not patching correctly. It keeps not working after going through github and repo zipping its not amazing to use Github when it's wearing thin my patience. knight.zip Either way if that file is copy and paste into \common\resources\builtin\sprite_frames_collection to replace the old file added last where in the merge it works every time locally on my end. Yet once that file is patched then uploaded to github it just for what ever reason will not patch properly and Im not feeling like wrestling with github any more tonight. image I started at 11:30 PM ish and now its ~3:00 am and its been a struggle to patch 1 file to just function correctly after going through github. I'm not sure why github is being dumb but there is a fix. image I wish this was done in a pretty fashion but here we are.

WithinAmnesia commented 2 months ago

It works as run the demo as usual. Then open the knight.zip into \common\resources\builtin\sprite_frames_collection to replace the old knight.tres file and then the knight character animation should work. M M O A R P G (V 000 042) Godot-Tiny-MMO-Demo-0 0 11 Godot 4 3 NET+ Godot Tiny MMO (0)

SlayHorizon commented 2 months ago

This seems a bit off. Just to be safe, I renamed most of the resource files to snake_case to avoid any case sensitivity issues.

WithinAmnesia commented 2 months ago

This seems a bit off. Just to be safe, I renamed most of the resource files to snake_case to avoid any case sensitivity issues.

image It works well. The visual bug seems to be fixed for now. Good job too! I wonder what the underlying cause was? Either way its nice it works better now.