- I didn't bother, I just improved the random generation code though it might cause some slight lag since it iterates through all pokemon species everytime it generates a new quest.
- Just I'm about to be finished with the registry pattern implentation, I suddenly got hit by roadblock. I can't precompute all of the quests, namely the ability quest. I just found out that the ability is not bound to the specie but to the pokemon itself. I'm not even sure how I can validate that part.
- I could probably make the quest class even more generic and have subtypes like PrecomputableQuest in which it can precompute eligible species then the rest which can't be. I'm also inclined to not bother since I already wrote all of the code that doesn't precompute anything.
- Ok so I've recieved an issue on github that some quests aren't working and after a few brainstorming sessions later I caved in to the precomputation idea. Network be damned.
- I just decided to finish the mod by today. My subconscious said to finish it now and I just followed along. Let's see how long this takes me, hopefully it doesn't take a 20 hour coding session.
- For a long time I was looking for a way to not blockentities, I thought I had it but the blockstate swtiching requires both a ticker and a reference to the player whos using it. Well at least I don't have to do any fancy data load/save this time.
- 10 hours in, 4 energy drinks and 3 cups of tea deep. Let's keep going since I'm almost finished.
- 16 hours in, 6 energy drinks and 5 cups of tea deep. One last thing left, fabric dedicated server being a lil bitch.
- It's finally feature complete.
- I didn't include the time I was remodelling and retexturing the block, didn't feel right to include it. I also having way too much fun messing with scammers that I just kinda ran out of time to work for today.
- Weirdly enough, I don't feel any sort of burnout, maybe the case for yesterday was just caffeine withdrawal.
- I've checked on the cobblemon discord and there was no mention of evolution stages, I guess I'll do a reverse search instead if I really can't find an elegant solution.
- I did a quick review of my gui code... and it's a mess. I believe I built it to be reliable though so I'm plenty sure it won't need to be touched for a long time.
- I can really feel the burnout but I'm almost done so I'll limp along.
- The biome quest is really not as easy to implement and the command for checking the spawn rates aren't being helpful.
- The biome quest implementation is becoming way too darn complicated, Mostly because I'm trying to find a way that doesn't require multiple looping in the isEligible() method because the gui code invokes that every render tick. I think I'll just precompute it. Network bandwidth and memory be damned. I just tested precomputing the pokemon species for the jungle biome and it was 331 species. Fuck it we ball.
- Well I finally figured out why the data wasn't saving, it was just a dumb shit reason such as not marking it dirty when setting new values.
- Ok not just that, there's another issue.
- Just doing progress, I don't really have much to say.
Deviating a bit from the requirements, might take a while reimplement but no issues ahead.nvm, it was the the expected implementation, I realized after reading the reqs again.- Yeah it's just alot of things, I'm feeling burnout so I'll take a dayoff and use that time to do some errands.
- Another round of internal changes, hopefully that's the last one.
- Finished the localizations and the config. Just as when I thought I had the momentum I hit a brick wall. I there was no good documentation around automated loading of data resource using codecs. I'll just go with the classic method.
- It's pretty late as I write this, I'll probably just try to do some initial implementation before I clock out. I already have the structure planned anyway.
- I finally managed to make the networking crap work. I discovered that I actually did this before in my first mod and just didn't remember because I was copying the networking code back then. Well at least I understand how it works now.
- Got the reroll working but the screen needs to be refreshed manually. I guess it's time, it's inevitable anyway. Time to learn codecs. The fabric docs ahas a surprisingly good and elaborate tutorial on how it works.
- I think I figured it out to change everything again. Starting with switching the enum to a registration pattern, then setting up a codec dispatch, then making a codec for each quest.
- After 4 hours I finally fucking did it. I integrated codecs in everything except the networking stuff on the menu, I just encode and decode via nbt and put into the bytebuf for now. I'll do the refresh screen packets and attempt to use the stream codec there.
- I'll probably rewrite my personal mods to use codecs too because they seem pretty neat.
- Fuck no, I'm not gonna redo that work for streamcodecs. I'll just bridge it via nbt, slightly inneficient but should be fine because PlayerQuestContainer objects aren't being sent constantly anyway.
- I guess I finally completed the reroll functionality with validation and animation.
- Brain is feels too melted with all the programming from the past few days that I forgot what I did yesterday, luckily I have logs.
- I thought menus have an integrated solution for sending data. Well it doesn't so I'll end up doing networking stuff. I'll probably ditch the menu if it still didn't prove useful later on.
- I don't know how to do network stuff in architectury and I'm not sure what to do because the docs uses a deprecated method.
- Ended up adjusting 60% of the classes just to account for the quest reward and the number of finished quests for every player.
- Ok so I checked a few example mods on how do they do they're networks, timinc mods integrates with cobblemons networking stuff which I can't figure out, oritech didn't use the architectury api to do networking and they just have a different implementation for each. Most mods don't have custom packets, and I can't find a mod that uses architectury api netowrking stuff.
- Didn't have much time today since I had to assist and mentor some college students on their web dev project.
- So yeah, neoforge saved data is kinda confusing.
- Finally after hours of reading, and mucking I finally have persistent quests... for neoforge. I'll have to do fabric next. I haven't even tested multiplayer for that yet but I have some trust in my code.
- Wait if both neoforge and fabric world saving uses nbt, and they have the same set of methods then I could probably just bridge those. What I don't understand is why Architectury doesn't do that if it's (I think) simple?
- Now I realized why, because it wasn't different in the first place. I was just led astray by the docs and have been meandering for the past few hours. but atleast it's done.
- I had to be a bit funky with strings and components because I can't figure out how to do text formatting to lang files and even conditional replacement. I ended up just implementing my own, if I find the canon solution for it then I'll be replacing my implementation but so far i haven't found it.
- Woke up way too late.
- On doing serializations for the quests, had many red herrings and failed implementations.
- Some quests are just hard to implement, since I can't find a way to get certain types of data.
- Okay yeah I need a codec for each subclass and have it as part of the Type enum, the current way of serializing is ass.
- Sending data to the client menu was easy... suspiciously too easy, something may break without me knowing.
- I've been reading more about unifiying the neoforge and fabric world saving, I should be able to do it now but I don't think I have enough time to finish it today.
- Ok so I figured out why the button is not working.
- I need to attach data to a player, there's multiple ways to do this. If I were only doing this on NeoForge or just Fabric, it'll be easy since they have provided solutions for saving data in their own ways, but we're doing multiloading and architectury api doesn't have anything for that. I could maybe create a common interface class and have each side implement it in their own ways but that would be coding and maintaining twice. I could also make mixins and save via the the player entity class. That would be irresponsible but I know how to make good mixins that don't break anything. I'll defer this decision for a bit to focus on the other things.
- Solution A: Save via data attachment on the player, using fabrics and neoforges data attachment apis or use cardinal components for fabric.
- Solution B: Save via mixng into the player class. Bonus is that it can be synchronized easily, simple implementation, and same implentation for both loaders. Data can be persisted through Minecrafts NBT save/load system. I don't actually need to make an effort in syncing it and I can just fetch it from the server via menu on demand.
- Solution C: Save via data manager, fetch the data via hashmap of erverplayer uuid. Persist data on the world/level data.
- Implementing the quest types is surprisingly complex. I have to make the quest extensible, the problem is that quests don't have the same requirements like some uses enumerated values like biome and type, and some uses numerical like size and weight. In theory I could make an abstract subclass that just implements those parts like IntQuest and EnumQuest. I've checked possible implementations, class reflections save on the type enum, maybe factory function or a builder. I even thought of just designing it it a way that I could use anonymous classes and lambdas. I thought I should just use singletons and have a separate questclass instance like how blocks and blockstates work but no. I need to keep the implementation simple for easy maintenance.
- I think I'll just make the enum have a createRandom factory function and make a class for each quest. Verbosity is not always bad.
- Started the quest implementation, will continue the serializers and persistence tomorrow.
- Not sure where to get info for some quest type like biome, the pokemon does not save data where it spawned from. I could probably mixin it though.
- Prepared quest widget textures and just planning out how everything would look before I start coding it.
- Blackout, I have a solar backup power and storage ready anyway. Sucks to not have AC though.
- I think I've done all the needed UI components, except for the submit button which doesn't respond to clicks for some reason.
- Finished the rest of the non-quest related components, maybe a few missing features, I'm not what those are but I can always add those later.
- Dissected the provided ui image for procedural rendering purposes.
Bonus: Built a makeshift smoker on my break, will use it for kielbasa next week. I'll probably integrate a battery powered esp32 with DS18B20 temp sensor, using eletronics to compensate for my lack of cooking experience.
- Woke up, straight to the computer and rawdogged coding for the whole day, no breakfast, no lunch. Though I'm currently eating baked beans as I write this line.
- Rendering out the gui components to match the pc gui isn't that hard, just really time consuming. I'd love to have some convenience features of kotlin to java.
- Making the pfl block to be a 2 block is somewhat confusing but managable.
- The hard part is sending the party data from the server to the client screen, I think I'll end up doing a lot of complicated networking code in the next few days.
- I WILL NOT FUCKING SLEEP UNTIL I RENDER THE PARTY SLOTS ON THE RIGHT SIDE OF THE UI.
- Well I did manage to render majority of the components, I'll finish the rest tomorrow and then I'm gonna take a break because my brain felt soupy after today.
- Created a placeholder block that has menu and screen functionalities.
- Heavily relying on the architectury api documentation because they do things just a tad bit different though still familiar.
- The screen registration with arch api does not work so I'll have to do split reg. If arch api didn't prove much useful in the end then I'll just split reg everything.
- Majority of the time was setting up the template so I could have a standard pattern for the mod to ease up maintenance.
- Had a hard time importing cobblemon on the fabric-side, looked around and found the cobblemon mdk that the cobblemon team had prepared. If I saw that much earlier, the development of MHM mod would have been so much easier.
- Decided to use the kotlin dsl for gradle cuz I like the strict syntax (it's good for consistency). Dedicated a lot of time to learn it first.