ULTRAPORTAL 0.2.0 has been shipped, yippee! Now I’ll wait for the lovely shipwrights to approve it. I hope you all have a lovely day and have a good time coding.

Also, the image is from the section about hte Twist Gun on the (currently offline) Thunderstore page of ULTRAPORTAL 0.2.0

Been a while. Honestly, these past two weeks I’ve been taking more and more breaks. Working on this project has proven to be unhealthy and that I should take some time to myself so I remain mentally stable.

To be fully transparent: this is just a quick checkin before I can hopefully publish 0.2.0. I won’t be working on the update much longer since it’s in a state where I believe it is stable enough to publish. So, let’s go.

I’ve added a small bit of sandbox compatibility to portals! Now they can be moved around and modified with the sandbox arms. You can now move them, rotate them using the alter arm and freeze them! This makes it easier to temporarily add them into sandbox maps.

I also fixed a bug with the Twist Gun, where it wouldn’t rotate the player sometimes, and changed a feature on it where only one portal could teleport you.

And you can now fire the portal gun with a raycast, yay!

Thanks for reading and happy coding.

So, another 8 hours, huh? Well, I suppose it’s best to get into it.
First off, I’d like to talk a bit about some backend changes I’ve made to ULTRAPORTAL. The mod now has a new DLL known as UltraPortal.Shared, which allows me to make scripts that I can add onto Unity objects, making mod development easier in the future. I’ve also reorganized the scripts in the main project, just so it’s easier to understand where the essential scripts are.

In other news, we’ve got new portal animations and a lot of bugfixes that I honestly… forgot qwq.
But, hey, as I said: portal animations! Yay! Also portals can produce audio now, sick!

The main other thing I can think of right now is that I did a lot of configuration changes, so, you can view those in the screenshots (I’m honestly too tired to explain them, sorry…)

Oh, right! Large enemies can no longer be teleported through portals, since trying to fix it seems like a huge pain I just decided to make it.. not do that!

I probably did a lot more that I’m honestly just forgetting (I should really write this stuff down), because of exams and other stuff going on in real life. I hope you find this devlog satisfying enough, though.

Release date update thingy!!!! I think I’ll be good to ship ULTRAPORTAL sometime this week, probably on Wednesday or Thursday, who knows! From now on I will be sending friends builds so they can toy around and catch some bugs early, I might also implement one or two features, but, that’s about it. Hopefully the next time we see each other will be with a “I shipped ULTRAPORTAL, yayayaya!!!” devlog.

Thank you for reading!

Most of my time was spent fixing bugs related to portals, like passing through them being extremely unstable. Luckily, portals seem to function pretty darn well now, which I’m really happy about.

The other big feature that I implemented was portal resizing! Now you can scale portals up and down however you please and make some…. cursed creations.

Also, my friend made some updates to the portal graphics that are absolutely incredible. Please, if you read this, give it up for Rose Warbug. He’s an absolutely incredible artist!

Oh, wow, 2.5 hours, jesus christ. And I barely remember what I worked on! Oh, right, it was bugfixes that kept adding more bugs, how fun.

But anyways, time to change the topic. We got new portal gun textures! Yippee! Thanks to my awesome friend Rose Warbug we finally have upgraded textures for the portal gun. Heck yeah!

Ok it’s like 12:30AM and I’m super tired so I’m gonna go now, gn!

Wow, ok, 15.5 hours.. Uh, well as always I don’t really know how time passed by so fast, so let me just recap the most important changes since last time…

There’s a new portal gun type! The Twist Gun is a brand new type of portal gun that spawns at first unassuming portals, until you decide to traverse through them and notice that gravity suddenly changes. Yeah, I built a motion sickness gun. Next feature, lol.

The mirror gun now also has a fun alternative fire! It’s similar to the twist gun, except it’s like 10x easier to wrap your head around. The Flipped Mirror lets you shoot a mirror that turns the world upside down when you pass through it.

There’s also lots of new stuff to configure, like individual portal colors for each portal gun! As I added the Twist Gun, I noticed that differentiating between portals became extremely difficult, which was only backed up by my friends who playtested the mod. So, now you can customize each portal individually, yay!

You can also now fully disable portal borders, a long requested feature I constantly forgot about until now!

And, yeah, I guess that’s all I can remember right now. Well, ok, I am also working on SFX right now but that’s a different topic for a different day. For now, I’m going to go, because it’s 1AM my time. Cheers!

What’s one more week to ya?
Ok, so, jesus christ I logged four and a quarter hours. How? Well, I did tons of work on 0.2.0, and also just lots and lots of testing… So, anyways!

Lots of work was done in the process of creating 0.2.0, which is still ongoing mind you.
First of all, portals now no longer require a weird hack that disables entire colliders in a scene to let players pass through a ground/ceiling portal, now it just works by disabling specific components on the player and re-enabling them when the traveling is done. Oh, and enemy traversals work too, now, I just toggle the property “detectCollisions” on the Rigidbody of an EnemyIdentifier and then we’re all good to go.

But some other fixes have also been made, such as increasing the size of the portal gun projectile to stop certain bugs from happening, fixing portals in the cybergrind, and fixing a bug where a mirror projectile teleported enemies even if no mirror was spawned.

Now I have some bugs on my internal bugtracker, and on the GitHub isuses page, that I need to work on. Most important is a portal duplicating bug that one of my friends found. And making a raycast variant of the portal guns. Anyhow, that’s all for now, see you soon though with 0.2.0. :)

ULTRAPORTAL 0.1.5 is out! I am honestly so glad to finally be done with this update, because 0.1.6 will mainly just be sound effects and possibly a few bugfixes, and afterwards I will take a break for a bit. Also, change of plans, 0.1.6 will probably be the release I end up shipping, I don’t think I’ll get a response in time if I wait any longer than that.

Small update on 0.1.5: Rooms will now be forced to stay active if a portal is inside the room! With the addition of this feature it should now be way harder to accidentall clip out of bounds, given that portals will (hopefully) never lead you into an out of bounds area. Hooray!

Okay, so, I’ve been doing lots of work on making a new update for the mod, 0.1.5 (also known as Alpha 1.5) and, oh boy, it’s been quite a ride so far.

I started developing the patch when I saw an issue on the GitHub repository reporting that holding the portal gun in the middle weapon position didn’t render it correctly, and I managed to fix that bug pretty quickly. Alongside it came some weird bugs when changing the gun position in the settings, but those were also resolved quickly.

Then it came time to fix a pretty severe bug, in 0.1.4 I had introduced a keybind to destroy portals on the map, but I hadn’t tested it extensively, so there was a bug that caused the player to fall out of bounds if you closed portals as the player travelled through them. I fixed it, and made it show a little error message if a portal couldn’t be closed. This, however, quickly developed into the idea of making the portals explode if there’s something travelling through them on destruction, which lead to me adding a brand new style bonus “+SAFETY HAZARD”. This style bonus gets applied if enemies get exploded by the portal. And of course, all the colors of the explosion and style are configurable.
This is what took up most of my time, to be honest, a lot of the backend wasn’t built to support this and so I had to rewrite some stuff.

Now, I also wanted to fix that portals couldn’t stick to surfaces. This also caused me to have to rewrite parts of the mod, because I now had to account for the fact that portals could change orientation and get destroyed. But now that is all worked out and we’re here.

I’ll be doing some more work on this update before publishing the final build, but I hope this gives a good insight into what I’ve been up to.
Thank you for reading and have a nice day! :)

Welp, in this hour that was logged coding I made two updates for ULTRAPORTAL. I’m gonna try to quickly recap what they are, since I don’t have a lot of time to write this devlog.
So, Alpha 1.3 was up first, and it was essentially a huge bugfix update focused on making portals work better with players and enemies, and I’d like to think that I succeeded in that. Portals function way smoother now and there’s also a nice bit of extra customization. And Alpha 1.4 was basically the same, it was focused on adding more configurations to the mod, this includes more color settings and a new button to despawn portals.

And that’s about it! Happy coding!

Ok, I mainly did some work on the main mod. I have successfully completed patch 0.1.2 (also known as Alpha 1.2). Let me quickly walk you through the changes it makes to the mod.

• Fixed a bug where dying could softlock you if you had never equipped a portal gun in a level
  This was an issue caused by some objects in the portal/mirror gun not being initialized. If this bug triggered, you would get the regular death screen, but pressing R or any other input didn’t do anything.

• Fixed portal guns being accessible even if they were disabled through the config menu.
  In the mod there’s a setting to enable/disable the portal guns. It’s there so users can play ULTRAKILL normally, as if the mod was never enabled. Issue is… my first implementation was not tested well at all. So I fixed it! Now the portals even despawn if you disable the portal gun. Cool, isn’t it?

• Fixed being able to switch to portal guns when game is paused.
  You could previously press the keybind to load the portal gun in your gun holster while the game was paused.

• Fixed a bug where you could teleport enemies through portals that hadn’t been summoned yet.
  While this bug never happened to me, I noticed it as I was looking through my code again. Decided to quickly fix it before anybody noticed…

• Tweaked portals to hopefully improve portal transitions.
  This is very technical, and honestly, I don’t feel like elaborating on it. But basically I added a new trigger in the portals that disables certain security checks if you’re inside it.

oh and I also made the README a bit prettier, although I messed it up because I used local file paths instead of links to the githubusercontent stuff. That’s annoying. Will be fixed in the next update though, maybe I’ll make a small patch with more configs or sth tmr. We’ll see.

Thank you for reading. :3

So… I made this Flavortown page a bit late, oops. I kind of got sucked into creating this silly mod for ULTRAKILL which adds a portal gun, and, yeah. Here we are. Now I’m writing in social studies quickly whipping up this devlog before I have to go. For clarity: I will not be discussing development of ULTRAPORTAL 0.1.0 or 0.1.1 here, I will only be documenting updates 0.1.2 / 0.2.0 and further. Once 0.2.0 is done I will ship.

18 minutes? Surely I must’ve done more than fix kicking.. maybe the time I spent testing the Messaging App and updating the README heavily played into this time. But that’s small stuff. I have made one final fix, which should hopefully mark the demo app as complete.. kicking! Previously, as you may have seen in my previous devlog, kicking didn’t refresh the users list on the server-side, now it does. This should hopefully prevent the app from getting rejected for bugs. Guess we’ll have to wait and see though. Time to ship! Thank you to everyone who has read even one line of these devlogs.

Well, what can I say.. the demo is done? At least everything I thought to test is functioning well, so… might ship this project really soon. It’s been fun! Been super cool to make my own wrapper library for the C# UdpClient. Who knows, maybe I can actually use this project for games or something, I mean I got package and RPC Handling implemented. Of course, I would like to clean up the codebase sometime, but, who knows when I’ll get to that.
So the final bits of polish I added since last devlog was getting rid of duplicate “x left the chat.” messages when a user got kicked and adding a “x GOT KICKED” message to the server client.
Happy coding :D

It’s an exciting day, I was out in the city all day, but I luckily still managed to snag some time (very late at night) to work on the folklore demo! Now I have the Fraction demo fully implemented and working! Is the code pretty? Debatable, if Java had Macros it’d certainly have way smaller duplicates, but that doesn’t matter right now. I don’t really know what much to add, except that I had several issues with designing the Fraction GUI, before just settling for the horizontal layout. While struggling with this I thought of another Good Kid reference: “Oh, Java, can you tell me there’s an issue? I’ve seen it clouded all around you.” ok that wasn’t that good. but neither were my No Time To Explain puns! Anyhow, I guess I’ll finish this devlog up then. Next up I’m definitely gonna make a demo window for the Misc.java stuff (so gcd, lcm, factorial, double equality, roots, logarithms), then vectors and then the dreaded functions. This is gonna be fun, huh? Ah, well, I hope future me doesn’t suffer when making the Function window. See ya!

It’s been a while I’ve been out in IntelliJ, I get a little anxious when my Main class doesn’t get accepted.
There, that’s my horrible rendition of the intro of “No Time To Explain” by Good Kid. And man, I have no time to explain how annoying it was to get the demo project running in folklore (ok ill stop with the good kid puns lol). I don’t even really know how to structure this, because all of this hour was spent on me figuring out how to insert a demo project properly and then messing around with the file structure of folklore and the module settings in IntelliJ, but hey, we made it, I knew we’ll be ok (not a pun! it’s a reference!!! no, i should actually stop? ok fine). Right now the demo project doesn’t do much, it spawns a Fraction from folklore and prints out the decimal values. Now it’s time for me to make a small GUI app to show off the features in folklore and then I might be able to submit this and get some cookies. Guess we’ll see! Also, if someone actually reads these, please give me feature ideas! I’d love to work on this more, but I don’t know what to do TwT

I swear to god I always have the weirdest bugs with the weirdest solutions in this project. Anyways! Almost 4 hours elapsed, let’s see what I managed to do in that time…

New stuff / fixes

Server Menu

The server application no longer just blocks inputs to the startup window, instead it now shows a window similar to the client interface, except you can’t message. But to make up for that, if you are the server, you can kick clients! Why? It means more features, which means more time to work on this project. So there’s that.

Force Disconnect Package

So, this plays directly into the moderation feature. The issue was that I couldn’t find a way to force a remote UdpClient to disconnect, hence I had to make a little workaround. The ForceDisconnectPackageis built into UdpClub now and it automatically disconnects a client from the server. Beware though, it doesn’t work on servers.

No more duplicates (i hope)

I fixed a major bug that has been plaguing the demo project since I got the Client UI to work, duplicate names in the users list. And I finally figured out how to fix it, I tried everything from locking the memberList variable (since it might be an issue with multi-threading), but to no effect. However, delaying the function by 50ms seems to do the trick. I figured this out when I was debugging the project and couldn’t replicate the bug at all, whereas it would constantly appear without the debugger. Why? I have no idea lmao.

Look at the attachments

I put a few neat things in the attachments this time around, first off the obvious, the server UI. But I also put in the new code for adding a member with locking (just in case) and timeouts, and a demonstration of what kicking looks like!
Have a nice day and happy coding!

Time for debugging!

After having loads of fun using the UdpClub demo with my friend who lives all the way in America, I had made a realization that I should’ve made long ago… the error handling is practically non-existent. That’s a pretty major issue if you ask me. So I finally did something about it. Now, whenever PackageHandler has an error, it throws an exception and keeps running. This is mainly so applications don’t freeze when an error such as a SocketException occur. I could handle this better, and I probably will. But for now this rudimentary system is very helpful for me. Especially since it lets the demo run more consistently.

Few changes since I last checked in an hour ago.. So what’s new?

I figured out markdown!

So.. turns out you can use markdown on here? An extension that was showcased in the show and tell made me aware of this. It’s super cool, tbh. Gonna be using this way more.

Features

Join / Leave messages

Now, when a user joins or leaves the server, a little message is sent into the chat! Making it feel less empty and also letting you sort of timestamp when someone leaves/rejoins. Neat, isn’t it? I think it is. If you feel another way, well then I quite frankly don’t know what to tell you. Moving on!

General messenging

As the previous header, and the screenshot that I definitely put a lot of thought into, may imply… messenging works! Now you can send messages to other clients and have a little chat. Well, ok, not really in this case, I don’t wanna engage in port-forwarding right now, so I have only tested it on localhost with myself, but it works pretty darn well from what I’ve tested, except one bug where the user list duplicates an entry, dunno where it’s wrong, but I’ll fix it eventually!

RunOnServer parameter in RpcPackages

This was originally intended to be a bug fix for the Leave Message duplicating before I figured out the actual cause, but since I feel like somebody will find utility in it, might as well leave this little scrappy feature in. Enjoy, potential users of this library, you can now force a server to never run an RPC.

Small fixes in the client logic

During testing I had an issue where the server froze up a few times. The cause? C# throws an exception when you try to invoke an Action that hasn’t been subscribed to, and somehow my code doesn’t output that exception (maybe cuz it’s running on a different thread? idk). In any case, that is fixed now, and the server runs as well as it can. How good is that? I have no idea. Gotta do more testing.

Alrighty, small check in again.. I managed to implement users syncing, so now when you connect to the server, you get a small RPC call that gives you a list of every user that is currently connected to the server. Now I just need to make it, so that on the backend, the user leave message is properly communicated. Maybe I should switch it from an RPC to a Package then. Who knows. For now, I do mainly wanna get messaging working, because that’s the main selling point of this app.

Ok, ok. So, I didn’t want to deal with the termianl for the demo project anymore, so I kinda just.. rebuilt the entire thing in Windows Forms. Right now very little works, you can start a server instance and a client instance. The client can input their username and then the main messaging UI loads. Nothing crazy, just took a bit because Rider’s UI builder doesn’t like me. But, hey, soon I can build some logic for sending messages, sending the user list to new clients (right now if the user “test” logged in after “avery”, only “avery” would see both users in the user list). I also need to implement leaving, because right now that doesn’t have any implementation at all… Also a server UI.. After that? Not sure. Maybe I can add moderator operations to the server UI. Guess we’ll see. I am also kinda writing this in a rush, so excuse me if my sentence structure changes mid-sentence. See you and happy coding!

Alrighty, so, I’m a bit hazey on what I actually did in this almost hour and a half timeframe, so here goes nothing.
I simplified the invokation of RPCs! Now you just have to run RpcManager.BroadcastRpc(…) to run your RPC on the network. It’s nothing special, practically just a wrapper that makes an RpcPackage and throws it through PackageHandler, but it’s nice to have nonetheless. In bigger news, I got kind-of sick of always having to reference “typeof(MyPackage)” when making a package class, so, I made the GenericPackage class, which acts as an abstraction layer on top of the regular BasePackage. It allows you to create packages way quicker and easier, since now you only have to specify your packet’s class name once, and the GenericPackage does the rest! It’s so nice to have, especially since a large bug I had in the demo project was because I wrote “typeof(AuthPacket)” instead of “typeof(AuthReturnPacket)” in my AuthReturnPacket class, making it so the AuthReturn never got interpreted. The new package structure, using the generic package class, is so much cleaner (see second screenshot). Don’t worry, though, you can still manually create a class on top of BasePackage if you’d like, nobody’s stopping you. And that’s about it, I think. Super fun working on this project for a bit and I’m getting a tad bit closer to shipping. I also hope I can show this project off at the Show and Tell tonight, guess we’ll see. See ya!

We got a logo now! Whipped up this cool little network of circles, because I thought it’d fit the project really nicely. Also I fixed a bug where every RPC in the project would get called if you called a single one. i.e. if you had the RPCs “UserJoinMessage”, “UserLeaveMessage” and “UserEmojiReact” and you called the RPC for “UserJoinMessage” it would actually trigger all 3 RPCs. That is now fixed, silly me. Also I have swapped a few more debug-prints for the DebugPrintln function. Yay! Happy coding and thanks for reading!

RPCs work! I repeat, they fully work! I have freaking done it! I am so happy with myself for managing to fix RPCs so quickly - only took me 24 minutes, huh. I have also made some changes to some not-so-relevant parts of the source code, like replacing lots of the aforementioned statements that I wrapped in “#if DEBUG” to use my DebugPrint/DebugPrintln functions. But, back to the main course, I managed to figure out a nasty bug in parsing RPCs that would cause the network thread to hang indefinitely because of an unhandled exceptions (thanks, Rider Debugger for pointing that out to me..)
And.. yeah! I guess it’s time to clean up some code, write the demo project and maybe look into more parameters? Who knows! What I know for sure is that I’m gonna blast Good Kid music now. Cheers!

Another day, another… four hours of work? Damn. I didn’t even realize. Alright, well, here’s what I spent my time doing today, and what I will continue to do because I want this project to freaking work.
So! I worked on a little demo project, because I planned on shipping an initial release of UdpClub soon. But there’s a slight issue with that, the app I want to make for my demo is a basic messaging app between multiple clients, only issue is that I want to include things like a welcome message when a user joins and some other stuff where an RPC with a parameter would be lovely. Only issue is… I can’t do that. For something as simple as a welcome message I just simply want to be able to call an RPC and have it invoke everywhere. Annoyingly, I was too lazy to implement that when my mind understood the awful code I wrote! Now I have to dive back in and debug it. And that’s what I’ve been doing! Well, ok, I did also work on the basic demo project, but who cares about that. Anyhow, during these four hours of debugging my code I have noticed how incredibly fragile the system is and how badly I want to remake it to be way clearer to debug and use, so, uh… RPC rewrite today? Maybe? Who knows. Though, today I will probably only get RPCs with one parameter working and like.. replace all my manual #if DEBUG /* print */ #endif statements with an abstraction, which I called “DebugPrint”. Anyways, that’s basically all. Let’s hope that I can get this resolved ASAP when I’m home and not bothered by school, the new NullReferenceException is definitely promising… Cheers!

Not a lot of changes for right now, but that’s mainly, because I spent my time making an EXE for SWP so the ship doesn’t get rejected again.
But, I implemented a small feature.. loopbacks! A loopback lets you specify if the RPC Package should return to the sender once the client sends it to the server, this is useful so there is less confusion about if you should run the RPC function locally as well, or if the package comes from the server-side. It also has practical usages, but I can’t think of any examples off the top of my head.
Next up is (hopefully) documentation and cleanup of the existing RPC handling code. Let’s see how that goes.
Happy coding and thank you for reading!

… so I spent 3 hours implementing RPCs (Remote Procedure Calls), and boy oh boy… it’s a mess, like most things in this!
So, let’s dive into it, shall we?
At first I began with writing a RPC Attribute class, plain and simple, afterwards a small RPCManager to ensure that I can easily call RPCs from anywhere. Then followed a small RPC Package to make it easy for the server to communicate that the clients should execute a function, all well and good… Until it came to implementing how you’re supposed to run the function. Granted, I took the easy way out: only allow static methods. But I don’t want that to be the case forever, I want this to eventually run on object instances too, but that’s gonna take a bit for me to do. Probably past the time limit of this whole Flavortown thing, so, screw it. Anyways, so after implementing all that, I was met with an issue: RPCs weren’t registering. So, what did I mess up? Well I had the call to subscribe my RPC to the RPCManager in the RPCAttribute constructor, should work, right? Well, the developers of roslyn (the C# compiler) decided to throw me a giant “F**k you,” because the constructor for an Attribute is never called until you somehow reference the RPC via MethodInfo.GetCustomAttributes() and whatnot… suffice to say it took me a bit to figure out.
But, hey, I finally did it. Now you can register static functions are RPCs with a specific ID and you can easily call ‘em through the server, now all I have left to do is make the communication system with the RPCPacket work in a way that a client can request to execute a RPC to the server and then the server can spread that message to other clients.. and I should definitely get parameters working. But, I think first I’ll focus on cleaning up this steaming mess of redundant calls and whatnot, and heavy documentation, right now only god and I know what this code does, not very sustainable.

Anyhow, happy coding!

The first release of SWP is live and you can download it now at https://github.com/averyocean65/swp/releases/tag/v1.0.0

The release features all the functionality shown off so far and then some! Since the last devlog I added line-wrapping and a save confirmation dialog that shows up when you close a tab. So happy that I can ship this project now. Happy coding!

Changelog:

• added keybinds for different actions (new file, opening files, saving file, closing file, cycling files)
• added “about window”
• added error dialog if file saving is cancelled
• opening files now allows you to select multiple files
• various other hotfixes

Ok, so, first check-in on SWP.. I got a bit carried away and kinda implemented the whole thing in one commit… Bad idea? Yes! But, hey, here we are. Guess I’m not thinking too properly since I’m constantly anxious about my driving exam tomorrow - seriously, every time I think about it I feel my heart skip a beat and my back run cold. Anyhow, the fundementals of the editor are working, and all in a little over an hour and a half.. I’d say I’m quite impressed with myself. The code quality is certainly lacking, but that can be fixed up later on. For now, I’m going to rest before my heart actually explodes lol. Cheers!

Another really short patchlog:

• Moved Function classes to new package
• Completely refactor FunctionPart system to make use of inheritance rather than one do-it-all class
• Documented Misc class
• Added Misc.combine(double a, double b, Operator operator)

Have a nice day and happy coding!

Short check-in: I added more stuff to functions and finally converted the library to use doubles in every class rather than floats. Hooray! Probably gonna ship this soon, so, hopes are up!

I wrote the world’s messiest codebase, but at least it compiles. Now I do have to take a break from programming because my right hand is starting to hurt from the excessive abuse of Rider shortcuts. I did a ton of stuff and honestly if you care about it, I’d just check the git commit history for today. Goodnight and thank you for reading, happy coding!

Okay, so I made a few updates. First off, I extended the functionality of my Function class, particularly the “FunctionPart” record with the addition of “FunctionPartType,” which is an enum that determines how the x-variable is treated when sampling the value of a FunctionPart. Right now there’s a few modes for the “FunctionPartType” with more coming sometime, such as: Ln, Log, Sqrt, general root, and of course, no modifications. Along with these features I added new functions to “Misc” for taking custom roots outside of Sqrt and Cbrt, as well as a logarithm function that allows you to input a custom base. And last, but not least, I added a function to calculate the factorial value of a number, why? Just for fun! It’s nice to have these little functions sometimes, so why not add ‘em?
I also did a bit more, but I don’t really have the time to write about it all, especially because I feel like everybody is looking at my screen and I really don’t want anybody in real life to find my online username.

Anyhow! Next up I wanna refactor the entire library, because I noticed that Java seems to prefer doubles a lot more than floats. Why didn’t I use doubles from the get-go? Stubbornness, I’m used to using floats from previous projects and so I really didn’t wanna give up my old habits, but, putting float conversions everywhere is starting to get extremely annoying. So next devlog will probably be about a migration to a new system!

And that wraps it up, I think. I’m gonna go now. I hope that, whoever has read this, had a nice time seeing my progress. Have a good day and happy coding!

gotta make this quick, sorry..

• Added IPEndPoint to BasePackage
• Added two new test packets to Test projects
• Fucked up with the gitignore for packages and whatnot (gonna fix that immediately tmr)
• Updated PackageHandler to include new functions for sending packets
• update predicate for finding correct BasePackage constructor w/ correct new parameters and debugging stuff
• more prolly

thanks for reading!

I feel like one of the best programmers of all time right now - my complex workaround for making a dynamic package library somehow worked on the first try! I managed to finally make it so you can easily initialize a UdpClientApp or UdpServerApp and send packages from it! And it just… works! As long as you make a registry for the packages which adds them to PackageHandler.Packages using PackageHandler.RegisterPacket(…) but that’s beside the point. What I mean to say is that, the fundemental principle of my application is done, a more simplistic way to send and parse data packets over a network. Can it be optimized? 100%. Will I optimize it? Perhaps, we’ll see how much time I have for that until I ship the project. For now though, I will happily enjoy this win and dance around like a silly goober to “Na Na Na (Na Na Na Na Na Na Na Na Na)” by My Chemical Romance. See ya, and thank you, you lovely individual, for reading this!

Oh, also, if you care to check out what I made and you can’t find the GitHub repo, you can find the project source code at: https://github.com/averyocean65/UdpClub/

Ok, I got bored of fractions and decided to start on implementing the function system. It may not be the most intuitive system, as you may see from the first screenshot, but I can tell you one thing. It freakin’ works! I am so happy to see that this system works first-try without a hitch, seriously! By the way, the third image shows the polynomial from the tests (graphed in GeoGebra). I am excited to see how I can implement this function system into some personal projects when I finish this library, speaking of which… where to next? Well, I’m honestly not sure, I thought about doing complex numbers, but I don’t know if I can faithfully implement them given that I know nothing about them except for (sqrt(-1) = i) and (i^2 = -1), oh and Euler’s expression (e^(pi*i) + 1 = 0). So that probably doesn’t suffice. I could definitely add some functions to my function class, like creating derivatives, making anti-derivatives, calculating integrals (would require anti-derivatives), finding spots where the function equals 0, limits, basically whatever algebra I was taught in my high school career. Though finding intersections for the x-axis would cause issues with trigonometric functions, hm. I guess I’ll have to figure it out later, for now, I’m celebrating because my function class works!

Alright! I’ve managed to do quite a bit! First off, I started implementation of a device for the Apron runtime… the CPU! This is a core part of the project and I’m happy to be starting on it so early. Right now it doesn’t do much, though. You can dynamically allocate how many registers the CPU should have and read/write to them, but there’s still lots to be done. For example, I haven’t really started on the “execute_instruction” feature of the CPU and I’m just now realizing that I should probably make a general device class to comply with my usual OOP standards and in-case I want to add other components later on. Speaking of future-proofing, I made a integer-splitter class to make working with instructions much easier when I do get to writing the instruction-runner! Right now it can split a uint16_t and uint32_t into a collection of uint8_t variables. These are, strange as it may be, collected through the parameters rather than the return value, this is just so I can avoid working with arrays, because those have been a bit of a pain in previous attempts at this kind of project. Anyhow, speaking of instructions… I did a slight bit of documentation on how instructions should be parsed, just so I don’t create inconsistencies later on in the project lifespan. I suppose that is all for now, I got an English exam to severely panic over. See you later and thank you for reading!

Got the basic instruction class working with a few sample instructions shown in the runtime main file. This is probably going to be one of the last devlogs I post today, since I wanna write some music before I go to bed. Thank you to whoever reads this, you’re awesome!

I got the basics of DLL communication working for my third project: “Apron.” Now I can begin working on the basics of the runtime, which reads machine code and executes functions based on it. Then I can write the assembly compiler and hopefully ship this project. Should be a fun project!

… so turns out the fix for the communication issue between the Client and Server was simply because the client was using the IP EndPoint used in “UdpClient.Receive(…)” to communicate messages, which apparently doesn’t work for sending stuff to the server - the more you know! Thanks C#.

Anyhow, the issue is fixed now using a simple if-else statement lol. Took me about 3 minutes to figure out.

I also worked on a package class as well as a PackageMap, I also took baby steps in creating the PackageHandler. Now, unfortunately, I am not sure how to build a modular system for building and identifying packets, so I’ll have to get back to my mental drawing board until something comes to mind.

I added the equality function to my fraction class! Right now it throws an IllegalArgumentException when you don’t give it a fraction, but I hope to expand it to accept numerical inputs too, which will make the code in my fraction test class look just a bit nicer. Alongside this I also added my own float equality function, since I couldn’t find anything outside of the “==” operator, which I have been told is unreliable. Maybe I’m wrong though, who knows! I’ll definitely test using the regular operator soon.

I got all the basic arithmetic operations (addition, subtraction, multiplication and division) up and running alongside their respective unit tests and some extra functions like inversing a fraction, which actually came in really useful when doing division. I guess this goes to show how little I remember about fractions from school, since I had to look most of this stuff up lol. Guess that’s what I get for staying loyal to decimal numbers. Thanks for reading!

Just in time! Managed to implement fraction simplification, which was actually quite a fun challenge. I managed to find an implementation of the GCD/HCF and LCM in my files from a previous project from computer science class, which actually gave me the inspiration to make this. I know this progress is quite insignificant and not worthy of a devlog, but screw it. See y’all later and thank you for reading!

Okay, quick check-in that I’m typing in the midst of AP English. I wrote an extremely basic fraction class! It’s, as stated earlier, not complete at all since it doesn’t feature basic arithmetic operations yet as well as having no special features such as minimizing the fraction.
Hopefully I can get some of those basic functions up and unit tested within the hour. Guess we’ll see what the next 20 minutes bear.
Thank you for reading!

Making a library with Maven was jarring to say the least. I had difficulty figuring out how to have my IntelliJ project compile into a Java library file. Luckily after some research and with help from the lovely JetBrains docs (https://docs.gradle.org/current/samples/sample_building_java_libraries.html) I was able to figure it all out.
Excuse me if this devlog is poorly written, I am tired and just want to go to bed so I cba to write something cohesive.

Goals for tomorrow: outside of working on my other project (UdpClub), I want to use the little free time I have at school to work on some fundamental classes for this project, such as a fraction class and maybe even the first steps of making a function framework to build and chart out things like polynomials.

Good night, everybody and happy coding!

I finally got a basic framework running to send data between a server and client via the UDP protocol. I am extremely happy to see that I got it up and running from only an hour of work. Unfortunately there is a bug in the package handling, as the server and client should constantly send packages to each other, so I have to do some debugging to see what’s going wrong. Very strong start though! Hope I can get the Package and Package Manager classes implemented tomorrow if I manage to iron this bug out.