OSD 600 Lab 1 – Lucas Verbeke

Daggerfall Unity is a modern port of the 1996 PC game The Elder Scrolls 2: Daggerfall to a modern engine that runs cross platform. A lot of the issue with old PC games is that playing them on modern machines comes with a lot of hassle with you having to install DOS box or some other sort of emulator just to get them to run not to mention the issues that come up with modern sound and graphics cards. That is where Daggerfall Unity come in they have taken the original assets from the game (witch are free to download) and put them into Unity. What this allows is Higher resolutions, better lighting, further draw distances and most importantly Mod support. I think this project is a great opportunity to introduce a new audience to a classic game that has a lot to offer.

OSD600 Lab 6 – Lucas Verbeke

For this lab we were asked to grab a partner and try and find the source of a bug in brave. The bug is that when you enter a URL that has a space in it it will assume that it is not a URL and do a search instead.

cbf6fe2fbc9a54e31be1899867efdcad

In order to solve this issue we had to take a look at other browser and see how they handle the same problem. The solution that was best is to find the spaces in the URL and replace them with a %20.

Once the code had been added and we had tested to ensure it worked all that was left was to modify the tests so that our new case was included.

OSD600 Release 0.2 – Lucas Verbeke

I spent a lot of time trying to fix a bug in brave and it got to the point where I had given up and I was back to square one with no project to contribute to and not much time left to get my release done. That is when I found that I could contribute to a game that has given me hours of entertainment and that game was Space Station 13 or more specifically the vgstation13 version. A good introduction to SS13 can be found here but for those who are busy SS13 is a multiplayer sim like game where you and a group of other people fulfill roles to keep the station running or try and destroy it. I think project is a good fit for me because I am familiar with the games systems which can be somewhat complicated making it difficult for someone without prior knowledge to test it.

SS13 was made in Dream Maker and to work on it you must first install the Byond client that looks like this

If it looks like it is from 2003 that’s because it is and the Dream Maker editor is not any better but is the only way to edit and compile the code your code.

Now that we are familiar with the game and client lets get to building and fixing the code. To start off once you have cloned the repo you have to compile the game to make sure it works and on my modern PC it took 13 mins to compile it. Once it is compiled you can launch the local server that takes roughly 3-4 mins to initialize then you can test your changes. The thing is for every little tiny change you make you have to do this so its best to be very careful about the changes you make before going in to test them out or you will be loosing a lot of time. Also we need to make sure that we have the ability to test everything so we need to give ourselves admin powers. To do this we must make a byond account and edit the admin file to include our username followed by game master.

The bug itself was this one here that I think made for a good introduction to the code. The gist of it is that when the names of the item is in the microwave it doesn’t take into account that there is already an s at the end of the item name. First thing was to make sure I could actually reproduce the bug and that it hadn’t been fixed previously. To reproduce the bug I went to the admin panel spawned in a microwave and soybeans and this is the result I got.

It’s still here and it doesn’t make the game unplayable but it is something that gets on my nerves and it needs to be fixed.

So to fix it I did a search for the microwaver and found the microwave.dm file that contained the output message I was looking for. Next step was to find the file for the soybeans and any other items that ended with an S and add it to an exception list where I could manually set the names to have proper grammar and formatting. Dream Maker is strange to me it doesn’t use any sort of brackets for if statements instead opting to use tabs. I have historically been awful with my spacing so this was something I had to pay extra care to.

Here you can see it says 2 bunches of grapes if it were a single it would be 1 bunch.

I thought that this bug would of been harder to tackle but as it turned out lots of what was needed was in place it just needed someone to come and put all the pieces together. Most of my time spent on this one was getting the Dream Maker IDE set up and actually finding the file that I needed to edit as well as understanding the code was a bit of a challenge as before starting on this project I had never heard of Dream Maker. But I think it all worked out well and I am excited to take on a larger bug for my next release.

OSD600 Lab 4 – Lucas Verbeke

In this lab we were inrtroduced to JavaScript testing with ECMAScript and were tasked with getting a better understanding of how tests work and the general idea of open standards.

first off we need to clone and run test262.

Once I did that I noticed that I had 4 failed and 201 passed tests but after consulting with other students I found out that that is common occurrence.

next it was time to try to improve the array reverse test and the way to do that was to replace the if (reverse !== x) with assert.sameValue thus simplifying it.

This lab has helped me get a better understanding of tests and open standards something which I had no knowledge of before hand.

OSD600 Lab 5 – Lucas Verbeke

All that we had to do for this lab was to add a night theme based on the local time of day. To do this we used suncalc to get the local time of sunrise and sundown.

When completing this lab my approach was to set the current time and date and if it is later then the sundown or if it is earlier then the sunrise time. Once the time is checked the appropriate map is set.

Here is how the code looks

d916dbc333b260bb5174904d2db6895f

The map I chose was CartDB dark Matter

36bed5b419c1990a2e64a450b92ac6e0

The map I wanted to use was Thunderfprest Transport Dark

f7544f11b0a8ab9749ebd55dfbe413a4

But I needed an API key and to do that I need to sign up for an account and that ain’t going to happen today.

While I’m at it I want to change the daytime map because I found this map it looks really nice and I want to use it.

99c49738628978eeaa57a4322868fc3e

That was a lot of screenshots I guess now would be a good time to go into some of the issues I had.

The first one was me having a brain fart

if(hour >= sunCalc.getTimes(new Date(), lat, lng).sunset.getHours() && hour < sunCalc.getTimes(new Date(), lat, lng).sunrise.getHours())

Instead of having an or I had an and that was causing it to show the day map in the early hours of the morning. I really should of realized that when the clock goes past midnight it will be less then the sunset time.

Next was the order that I included suncalc was giving me errors with npm. This took much longer then it should of to fix than it should of and when I finally found it I felt like a real dummy.

Time to look at how my solution works.

Current eastern standard time is 3:00am and the map looks like this

6539fe50b342c1be218f8e7df1f84a29.png

Nice and dark and easy on the eyes now lets take a peek at the daytime map

c7df13f5cffdea6caf826c9cf252d5bc

like getting hit with a flash bang.

In summary I don’t have much experience in JavaScript and I think this is a great opportunity to dive in and see what I can learn.  From the lab I have learned just how easy it can be to implement features that seem complicated from the outside. When I started I thought that checking the sunrise and sundown times for each time zone would be a complicated time consuming task but as it turns out someone else already had done it for us and all I had to do was import it and the maps have also been already made. I guess it takes a village to make a browser based geolocation game.

OSD600 Release 2 – Lucas Verbeke

Release 2 is a big step for me in release 1 we worked on other students project but in this one we will be working on live projects that people actually use. This is kinda scary because up to now if my stuff doesn’t work its just a bad mark but now it will be put up to real scrutiny. I think that is where lots of my hesitance to start this release comes from there is a lot of anxiety and fear of my code being rejected.

All that aside it is time to be brave and find a project to work on. To start this I looked through the recommended projects and saw Brave which I am familiar with as it is the browser I like to use on my phone. I don’t have any experience with Android development but they have a desktop browser that I was unfamiliar with. It turns out Brave include many features that I find attractive such as a pre installed ad script and cookie blocker that in today’s age of bitcoin mining is very useful.

Now comes the time where I start to investigate the project and get a feel of how things work and the best way to do that is to see how they communicate. Their main forms of communication are GitHub, Discord, and a Forum but the most use comes from the GitHub itself. The GitHub Is very active with new bugs coming in every hour or so and people replying in the comments which means shows me that this is very much still active and will be a good project to work on.

First things first was to take a look at the CONTRIBUTING.md and get it installed on my machine. With a few simple commands I had all the files and dependencies that I needed to get it up and running.

Now that it is working it is time to see what doesn’t work and get to fixing it but that is for the next blog post.

OSD600 Lab 3 Lucas Verbeke

This lab required us to take a look at and reproduce a bug in visual studio code. To start off with we tried this bug witch stated that searching in files with more then 200 files open would return spawn ENAMETOOLONG. After making a folder with 200 files inside searching was working just fine so the next course of action was to install all the extensions he said he had to see if that may have been the issue. After installing them all one buy one to see if one was the culprit with no success we tried increasing the number of files all the way up to 800 files and it worked just fine. So that issue seemed to be a bust we decided to try out some other ones starting with this bug. The issue states that creating a folder with {} surrounding it would provide no search results and after trying out ourselves it proved to be true. Now that we finally found a working issue we could get started on fixing it witch seemed to be easy because the person who filed it gave some ideas of what could be causing it. The code in question was located in the patternInputWidget.ts file but to our surprise the code he suggested was the issue had since been removed so that was a bust. It doesn’t seem like that file is the issue but instead I think that it is in this file but I can’t pin down the exact origin of the issue.

OSD600 Release 1 Lucas Verbeke

In release 1 we had to make an API that would accept phone numbers either through the URL or a file then upload it to a GitHub repository file issues and fix issues in other students projects.

When creating the app I chose to use Node.js and Express because I have never used Node and I thought it would provide a good experience to get familiar with it. Building the app was not overly complicated but as I had never used Node before it tool longer then it really should have. After a slew of silly mistakes I got it to working it had many issues but the basic functionality was there and that was good enough for me to upload it to GitHub. At this point my experience with GitHub was exactly zero so some help from a friend who took OSD600 last semester was much appreciated. Next was to find all the flaws in my project and file them as bugs that was simple enough as there were many issues in my code that needed to be fixed.

Now that my repository was up it was time to turn my attention to the second half of release 1 and fix issues in other peoples code. I started with this repo so I forked it and followed the instructions in the readme but when I went to test it it wouldn’t work. I tried everything I could to get it to work on my computer from reinstalling node to testing it on different computers around the house with no success. It was time to move on and at this point I had gotten a pull request on mine so I decided to take a look if there was anything I could work on his in return. That is when I found this issue that seemed like would be simple to solve all it took was removing any non numeric characters and then measuring the length to make sure it was a proper phone number length this wasn’t the best solution but I would fix it later on. The second pull request I made was a bug that I noticed where either not passing a file or passing a file that was the wrong format would crash the whole thing. So I made a new branch and started working on getting it fixed along with improving the fix for the first bug. I will freely admit that it is not the most graceful solution but it works and that’s good enough for me.

This project was a good learning experience and helped me a lot with getting familiar with GitHub.

OSD600 Lab 2 – Lucas Verbeke

For this lab we were tasked with installing vs code as a standard user and a developer.

Standard instillation is simple you just run the installer and you are off to the races. Once you have it installed you can install extensions easily through the application.

Installing it as a developer is a little more complicated as I am not very familiar with github but this will be a good exercise to learn the ins and outs.

First step was fork and clone the project locally and once that’s done I need to install all of the prerequisites.

Most of these I am familiar with like Node, Python, and Git but Yarn is new to me so I did a bit of research into its purpose and use. The website describes Yarn as a “package manager for your code” that allows you to “share code with other developers from around the world”. Basically my interpretation would be that it makes sure that everyone who has the code has the same packages so that there are no errors.

Once all the prerequisite programs are installed all you have to do is type yarn to get all of the dependencies and then type yarn run watch to run to build it.

As part of the lab we were asked to take a look at related technologies one of these that stuck out the most to me was Electron. Electron is a program that allows you to build desktop applications the same way you would make a web app. Developed by GitHub it uses chromium. Also it works on Windows, Mac, and Linux without any modification.