I know this isn't game related, and I know it has been 5 years since I posted here. That being said, I'm not going to get into the "what I've been up to" or anything. I just wanted to give some notice for fixing what I have found to be a very bad One Note bug, and it looks like the same bug has been effecting people for around 7 years minimum with no fix from Microsoft. So here's the deal:
Symptom:
Microsoft One Note hijacks all print jobs. Removing the One Note application, removing the One Note printer, and setting your physical printer as the default does nothing, and One Note still pops up every time you hit Print. In my case, One Note also could not recognize any of the files, which means after it hijacks all my print jobs, it then wont display them or allow me to access them.
Remedy:
1. Go to Control Panel -> Programs and Features -> Remove "One Note" application.
2. Go to Control Panel -> Devices and Printers -> Remove "One Note" printer.
3. Go to Control Panel -> Device Manager -> Remove "One Note" from under printers.
4. Go to Control Panel -> Devices and Printers -> Mark your physical printer as Default.
Step 3, is the one I have not seen on any other sites or fixes. Upon investigating, I found that One Note was actually installing physical printers as well under the "Device Manager" settings. Before removing the Device Manager versions of One Note, it wont matter if you change your default, or uninstall the program, One Note will still hijack your print jobs. You must remove the ones from Device Manager.
Sorry for this not being about Game development, I will give a new update on all that at some point, as I still dabble in the field. Thanks for checking this post out, hope it helps someone else.
Thursday, August 8, 2019
Saturday, May 3, 2014
The May Updates
It's been a while since I posted a blog, not that it seems anyone reads these; I think I post them more to help my creative process to be honest. Regardless of why, you're getting a new one now so it doesn't matter!
To begin I want to touch on Extinction Plan. My hope was to have a working tablet version ready by this week. As it stands, it's impossible to do. The models for the Androids are too intensive to run in multitude on a tablet. I will have to redo the models in their entirety as they need to shed about 90% of their tri's. Now, this is something I'll have to do anyways with the models in the future in-order to streamline the game, but since it's working fine on computer's it's not at the top of my list of objectives. All of that said, I did get the code running on a tablet; just at sub-5 frames per second. Not even close enough to really feel I met my goal. So for now, the project is scrapped. It was ambitious and will probably happen eventually, but for now its just not worth the time it would take just to redo it for a mobile version.
Extinction Plan is getting a v3.9 update soon. I was hoping to have it done by now but I decided to try some different approaches to the lighting and I think I found a look that fits how I want the feel of the game to be. Extinction Plan now features pretty low-quality sound effects, but they can easily be swapped out once I make some better ones myself. I just really need to start pushing it towards a "complete" project and stop messing around with some of the smaller aspects. Alpha version 4.0 should be done by June; and it will be considered my last Alpha release. The rest of the updates will be a Beta phase. As I polish the game through Beta I plan on starting work on some new content that will be available with the "final version". My original goal was to have 5 levels done by June 19th, and while I wont hit that mark I plan on having a decent amount done for the release.
Raiders is going to be getting a new prototype update soon (in the next week hopefully) and development on that is set to start back up for May. So far the project is slow to come together, but Spencer and I plan to really put our heads together to make something come alive with it. The potential is there, it's just a matter of figuring out the most efficient way of bring it to the table.
As for any of the other projects we have worked on, or were working on, May is already going to be busy trying to polish the two titles for June; so I'm just not sure there will be any time left to focus until after mid-June. While I wish I had all the time in the world I don't; and since mid-June is the end of the line for free-work time, something has to get produced or else the dream comes to an end.
Thursday, April 17, 2014
Extinction Plan v3.8.1 Minor Update
I decided to just fix the menu updating issues that popped up in v3.8. The issues popped up when I, for some reason, removed the camera from the menu scene. This was causing anything displayed on the GUI to be overlayed on-top of themselves without clearing between renders. I added a camera, and it was fixed. In the meantime I made sure to fix the issue with the character name not updating when the player resets their data. Again, it was simply a matter of calling the new name into render when the button is clicked.
If you are interested in snagging the newest version, you can follow the link HERE
If you are interested in snagging the newest version, you can follow the link HERE
Wednesday, April 16, 2014
Extinction Plan v3.8 Alpha Released
Extinction Plan Alpha v3.8
A Fusion Bunny Production
Developed by: Joseph Dart Jr
Click here to get the download for Windows (x86_x64), Linux (x86_x64 Universal), and Mac (x86_x64 Universal)
Opens in a New Window
----------------------------
So I finally got around to releasing the v3.8 Alpha of Extinction Plan! This was one of the largest updates to the game since 3.0, and not only adds some basic player upgrades, but completely changes the overall style of the gameplay. Extinction Plan now works off of a wave system. 5 waves of enemies, each one with a higher number of consistent enemies (when one dies one spawns), ending with 15 spawned total. Each wave lasts one minute, and then the next is started automatically. The exception to this rule is every 6th wave, which is now a boss wave. When the 6th wave begins you will be required to clear all of the remaining enemies before the boss will appear. After the boss is defeated the enemy spawning starts over with tougher enemies.
When the player defeats an enemy they receive a single experience point to use towards upgrades, in which 50 experience are necessary to purchase each. The current upgrades simply involve the players movement speed, and overall health. Upgrades are obtained at the start of the game, and any experience which is unused is lost once the game starts. This prevents players from hoarding their experience. Currently, there is no cap on the upgrade amounts. With update 4.0, the amount of upgrades available will be exponentially higher, and the upgrades themselves will be capped at a certain amount. If you no longer wish to have a severely upgraded player, I made it so you could reset all of your data inside the new "Player Options" sub-menu of the main-menu.
The main menu has been changed with a placeholder logo and a couple sub-menu systems. The "Player Options" sub-menu allows you to reset your character data or rename your character. Simply type the new name into the space provided and hit the save icon next to the input field. Resetting your player data will automatically reset all of your statistics to their default states, so be sure to only go this route if you are sure you want to start over from scratch. A warning with a secondary "Are You Sure" type button will appear to keep you from accidentally performing this task. If you still go through with it and feel you have made a bad choice, there is no way to recover your data.
When you die you are now presented with some statistics about your performance. I'm hoping to increase the information provided, namely the amount of enemies killed per-wave so you can see where you may have not performed as well and can adjust your performance better in the future. The death menu allows you to return to the main menu, in which case you can start a new game and buy upgrades with any collected experience. If you happen to quit unexpectedly, do not worry, the game automatically saves experience as it is collected so it will all be waiting for you when you return. Wave progress is not saved, so you will always have to start a new game if you exit the program.
A pause menu has also been added. It pauses the gameplay and allows you to go back to the main menu or quit the game entirely. This is achieved by pressing the "Esc" key, and no longer removes you from the game entirely. If you need to take a break and don't want to lose your place, use this menu. A minor bug is already apparent in the pause menu that it allows you to still shoot a rocket while paused. The rocket will not move, but will spawn and then start moving as intended once the game is un-paused. This is already fixed, but since it does not effect gameplay I don't see a purpose for releasing a fix solely for that issue.
The enemy mother-ship no longer spawns enemies, but will instead shoot projectiles at the player every second. These projectiles will come directly at the player regardless of distance from the mother-ship and have a 5m blast radius. Wave 12 mother-ship also randomly chooses a position within a 50m range of itself and drops a projectile from the sky straight down. This was done to keep the player on alert and moving, even if they were somewhere the mother-ship could not specifically hit them at. This range may be increased, or the way the projectiles are spawned may change in future releases; testing will tell.
A Fusion Bunny Production
Developed by: Joseph Dart Jr
Click here to get the download for Windows (x86_x64), Linux (x86_x64 Universal), and Mac (x86_x64 Universal)
Opens in a New Window
----------------------------
So I finally got around to releasing the v3.8 Alpha of Extinction Plan! This was one of the largest updates to the game since 3.0, and not only adds some basic player upgrades, but completely changes the overall style of the gameplay. Extinction Plan now works off of a wave system. 5 waves of enemies, each one with a higher number of consistent enemies (when one dies one spawns), ending with 15 spawned total. Each wave lasts one minute, and then the next is started automatically. The exception to this rule is every 6th wave, which is now a boss wave. When the 6th wave begins you will be required to clear all of the remaining enemies before the boss will appear. After the boss is defeated the enemy spawning starts over with tougher enemies.
When the player defeats an enemy they receive a single experience point to use towards upgrades, in which 50 experience are necessary to purchase each. The current upgrades simply involve the players movement speed, and overall health. Upgrades are obtained at the start of the game, and any experience which is unused is lost once the game starts. This prevents players from hoarding their experience. Currently, there is no cap on the upgrade amounts. With update 4.0, the amount of upgrades available will be exponentially higher, and the upgrades themselves will be capped at a certain amount. If you no longer wish to have a severely upgraded player, I made it so you could reset all of your data inside the new "Player Options" sub-menu of the main-menu.
The main menu has been changed with a placeholder logo and a couple sub-menu systems. The "Player Options" sub-menu allows you to reset your character data or rename your character. Simply type the new name into the space provided and hit the save icon next to the input field. Resetting your player data will automatically reset all of your statistics to their default states, so be sure to only go this route if you are sure you want to start over from scratch. A warning with a secondary "Are You Sure" type button will appear to keep you from accidentally performing this task. If you still go through with it and feel you have made a bad choice, there is no way to recover your data.
When you die you are now presented with some statistics about your performance. I'm hoping to increase the information provided, namely the amount of enemies killed per-wave so you can see where you may have not performed as well and can adjust your performance better in the future. The death menu allows you to return to the main menu, in which case you can start a new game and buy upgrades with any collected experience. If you happen to quit unexpectedly, do not worry, the game automatically saves experience as it is collected so it will all be waiting for you when you return. Wave progress is not saved, so you will always have to start a new game if you exit the program.
A pause menu has also been added. It pauses the gameplay and allows you to go back to the main menu or quit the game entirely. This is achieved by pressing the "Esc" key, and no longer removes you from the game entirely. If you need to take a break and don't want to lose your place, use this menu. A minor bug is already apparent in the pause menu that it allows you to still shoot a rocket while paused. The rocket will not move, but will spawn and then start moving as intended once the game is un-paused. This is already fixed, but since it does not effect gameplay I don't see a purpose for releasing a fix solely for that issue.
The enemy mother-ship no longer spawns enemies, but will instead shoot projectiles at the player every second. These projectiles will come directly at the player regardless of distance from the mother-ship and have a 5m blast radius. Wave 12 mother-ship also randomly chooses a position within a 50m range of itself and drops a projectile from the sky straight down. This was done to keep the player on alert and moving, even if they were somewhere the mother-ship could not specifically hit them at. This range may be increased, or the way the projectiles are spawned may change in future releases; testing will tell.
Monday, April 14, 2014
Raiders: A Lost Art - Prototype 02
Raiders: A Lost Art _Prototype v02
Released 04/13/2014
Download Available through Google Drive: HERE (Roughly 8MB/Zip Format)
----------
After a couple weeks of working out some of the major bugs in Raiders I finally released the second prototype. Unfortunately I had to strip some of the professions menu's, although the initial source code is still there. I simply didn't want to rewrite the crafting professions source code without also converting the inventory system over to work with the player save system. Once this is completed there will be no persistent script anymore and therefore I will be able to create a main menu system.
The process took longer than I wanted, but in the end I rewrote almost all of the scripts from the ground up, a task I felt was necessary for the systems to function properly and efficiently. I stripped thousands of lines of code from the main GUI script, and rewrote the remaining 2000 to utilize methods for every task. All of the characters now run off the same 200 lines of code, and only access the other code when the player calls on it. Not only does this reduce the strain on processing and memory, but it created a much more efficient way for players to interact with their characters without requiring any change confirmations. In prototype 01 you had to confirm every change that you desired to make by hitting a button in a separate menu; in prototype 02, changes are made instantly. I hoped that this would stop players from accidentally canceling changes they were making by pressing a different button before confirming the change.
One of the major discoveries I made while working with the GUI was finding a way to display a characters Health on the battle GUI based on which characters had been placed on the battlefield and in what order. I needed the health to be rendered in correlation to the character's information pane, and also be able to update accordingly. The way it works now is that the system registers which character was just placed, and then adds that characters placed clone as a specific object in an object array. Because the object is added to the array at the same integer location as the button, it is easy to pull the information from the object and have it render in the proper location. Much of this will be changed over time as my GUI improves to utilize character portraits and graphical buttons instead of text-based ones.
The enemy attack was another major discovery for me. Instead of using my normal cooldown timer based attack script that the characters use, I rewrote the AI script from the ground up. The enemy now chooses a target after 3 seconds of the fight starting and then attacks that target 9 seconds later. This process repeats using method invokes every 15 seconds. 3sec -> Target -> 12sec -> Attack -> 18sec -> Target -> 27sec and so on and so forth. The enemy now turns to face its target, and will also follow them as they move around the battlefield. This targeting system works off of a public method, and so a character could interfere with this targeting system and force the enemy to target them specifically. I thought this would make sense for tanks to be able to taunt the enemy, allowing healers to focus on a couple characters if the player was crafty enough.
I certainly made more changes than this and if you are interested in reading any of them you can check the download link provided. It not only includes access to the Raiders prototype 02, but it contains an online changelog where you can see a more detailed breakdown of all the updates the game has undergone this release, as well as any known bugs and a link to a form you can submit any bugs you may find while playing. I also gave a link to the Fusion Bunny Productions email address in case you simply want to leave feedback or have a non-bug related inquiry.
Released 04/13/2014
Download Available through Google Drive: HERE (Roughly 8MB/Zip Format)
----------
After a couple weeks of working out some of the major bugs in Raiders I finally released the second prototype. Unfortunately I had to strip some of the professions menu's, although the initial source code is still there. I simply didn't want to rewrite the crafting professions source code without also converting the inventory system over to work with the player save system. Once this is completed there will be no persistent script anymore and therefore I will be able to create a main menu system.
The process took longer than I wanted, but in the end I rewrote almost all of the scripts from the ground up, a task I felt was necessary for the systems to function properly and efficiently. I stripped thousands of lines of code from the main GUI script, and rewrote the remaining 2000 to utilize methods for every task. All of the characters now run off the same 200 lines of code, and only access the other code when the player calls on it. Not only does this reduce the strain on processing and memory, but it created a much more efficient way for players to interact with their characters without requiring any change confirmations. In prototype 01 you had to confirm every change that you desired to make by hitting a button in a separate menu; in prototype 02, changes are made instantly. I hoped that this would stop players from accidentally canceling changes they were making by pressing a different button before confirming the change.
One of the major discoveries I made while working with the GUI was finding a way to display a characters Health on the battle GUI based on which characters had been placed on the battlefield and in what order. I needed the health to be rendered in correlation to the character's information pane, and also be able to update accordingly. The way it works now is that the system registers which character was just placed, and then adds that characters placed clone as a specific object in an object array. Because the object is added to the array at the same integer location as the button, it is easy to pull the information from the object and have it render in the proper location. Much of this will be changed over time as my GUI improves to utilize character portraits and graphical buttons instead of text-based ones.
The enemy attack was another major discovery for me. Instead of using my normal cooldown timer based attack script that the characters use, I rewrote the AI script from the ground up. The enemy now chooses a target after 3 seconds of the fight starting and then attacks that target 9 seconds later. This process repeats using method invokes every 15 seconds. 3sec -> Target -> 12sec -> Attack -> 18sec -> Target -> 27sec and so on and so forth. The enemy now turns to face its target, and will also follow them as they move around the battlefield. This targeting system works off of a public method, and so a character could interfere with this targeting system and force the enemy to target them specifically. I thought this would make sense for tanks to be able to taunt the enemy, allowing healers to focus on a couple characters if the player was crafty enough.
I certainly made more changes than this and if you are interested in reading any of them you can check the download link provided. It not only includes access to the Raiders prototype 02, but it contains an online changelog where you can see a more detailed breakdown of all the updates the game has undergone this release, as well as any known bugs and a link to a form you can submit any bugs you may find while playing. I also gave a link to the Fusion Bunny Productions email address in case you simply want to leave feedback or have a non-bug related inquiry.
Sunday, March 30, 2014
Raiders: A Lost Art - Prototype 1
So the 2-Week Coding Project came to a close last night, and I spent a little extra time getting everything done to have the first prototype in working order earlier. I posted the release in the Fusion Bunny Productions Google Drive.
Raiders: A Lost Art - Prototype 1 : Download Here (Opens in a new window)
There are still quite a bit of things I need to accomplish, and I'll be adding a log to show what bugs I am currently aware of, and what has been fixed already; this will also give you a good indication of what has been added to the next release so you know what to expect.
Raiders: A Lost Art - Changelog : Check The Log Here (Opens in a new window)
I also wanted to give players a way to submit bug/error reports this time, so I created a form that players can submit detailing any issues they encounter. I can also always be reached at my email, but that doesn't guarantee that the issue gets submitted right away. You are also free to post the issue on our Facebook page, but like the email, it wont get put into the bug report right away.
Raiders: A Lost Art - Bug/Error Report Form : Submit Report (Opens in a new window)
Fusion Bunny Productions - Email : Submit Email (Opens in a new window)
Fusion Bunny Productions - Facebook Page : Check Out Our Facebook (Opens in a new window)
I will still be posting updates on the progress, but it will not be the daily updates that I've been releasing the past 2-weeks. Be sure to look out for more releases, and updates as they come rolling out in the next few days!
Raiders: A Lost Art - Prototype 1 : Download Here (Opens in a new window)
There are still quite a bit of things I need to accomplish, and I'll be adding a log to show what bugs I am currently aware of, and what has been fixed already; this will also give you a good indication of what has been added to the next release so you know what to expect.
Raiders: A Lost Art - Changelog : Check The Log Here (Opens in a new window)
I also wanted to give players a way to submit bug/error reports this time, so I created a form that players can submit detailing any issues they encounter. I can also always be reached at my email, but that doesn't guarantee that the issue gets submitted right away. You are also free to post the issue on our Facebook page, but like the email, it wont get put into the bug report right away.
Raiders: A Lost Art - Bug/Error Report Form : Submit Report (Opens in a new window)
Fusion Bunny Productions - Email : Submit Email (Opens in a new window)
Fusion Bunny Productions - Facebook Page : Check Out Our Facebook (Opens in a new window)
I will still be posting updates on the progress, but it will not be the daily updates that I've been releasing the past 2-weeks. Be sure to look out for more releases, and updates as they come rolling out in the next few days!
Saturday, March 29, 2014
2 Week Coding Project - Day 14 : Rebuilding the Raid Scripts
So, after taking a closer look at all the scripts pertaining to actual combat (CharacterScript, PerformsAttack, HasHealth, and Fight_GUI) I realized just how much I needed to change. From a coding standpoint, almost nothing was done in a way that would tie into the Main GUI. Because of this I spent most of the day trying to rewrite all of the scripts as efficiently as possible; and I think I got the brunt of it done. The only thing left to really do is to make sure the character's can be placed on the board, and that all the scripts tie into the Fight GUI's calls. Because I wanted to be efficient, I created uniform scripts for all the characters that check to see what value the character script has been given, and then they generate the proper information from there.
What this means is that now if you click on your character once it's placed on the battlefield, you can bring up a specialized menu for that character; which is minimal at the moment. Pretty much telling you what class and role that character is, and allowing you to perform its special attack. When you press the Special Attack button, it sends the current class and role as integers to the Character Script, which then interprets it and sends it along to the PerformsAttack script. The PerformsAttack script then checks the variables to see which ones coincide with an attack action and then sets that attack into motion.
The HasHealth script was updated so that it checks the integer value of the correct "characterLevel" PlayerPrefs file and then creates the right amount of health based on that value using a level multiplier. I wanted to get the level multiplier working for all the character attack scripts as well, but for now they are all uniform aside from the special attack. The enemy works in a similar fashion, it is given a bonus level and then that is taken into account when calculating its health pool. Because of this, it will be easier to create "hard mode" versions of the dungeons.
I need to create the enemies attack pattern still. I also need the characters to be movable when they are selected one at a time. For now the whole group moves as a unit, which is obviously not the way I want it to be. Both are simple to do in theory, but will take me a while to get done. That being said, with the rest of the fleshing out that some of the scripts need done, I'm going to say that I should have the prototype working as intended (for the first prototype at least) and that I will still try and release it by Sunday night; hopefully by midnight. I'm a little disappointed it's going to take me at least an extra day to finish the prototype; but when I look back at everything I learned, created, and replaced, I realize it was a large undertaking for a 2 Week Project. I'm just happy that it's coming together finally and I'll have something to show for all my work. It really has been a great experience.
What this means is that now if you click on your character once it's placed on the battlefield, you can bring up a specialized menu for that character; which is minimal at the moment. Pretty much telling you what class and role that character is, and allowing you to perform its special attack. When you press the Special Attack button, it sends the current class and role as integers to the Character Script, which then interprets it and sends it along to the PerformsAttack script. The PerformsAttack script then checks the variables to see which ones coincide with an attack action and then sets that attack into motion.
The HasHealth script was updated so that it checks the integer value of the correct "characterLevel" PlayerPrefs file and then creates the right amount of health based on that value using a level multiplier. I wanted to get the level multiplier working for all the character attack scripts as well, but for now they are all uniform aside from the special attack. The enemy works in a similar fashion, it is given a bonus level and then that is taken into account when calculating its health pool. Because of this, it will be easier to create "hard mode" versions of the dungeons.
I need to create the enemies attack pattern still. I also need the characters to be movable when they are selected one at a time. For now the whole group moves as a unit, which is obviously not the way I want it to be. Both are simple to do in theory, but will take me a while to get done. That being said, with the rest of the fleshing out that some of the scripts need done, I'm going to say that I should have the prototype working as intended (for the first prototype at least) and that I will still try and release it by Sunday night; hopefully by midnight. I'm a little disappointed it's going to take me at least an extra day to finish the prototype; but when I look back at everything I learned, created, and replaced, I realize it was a large undertaking for a 2 Week Project. I'm just happy that it's coming together finally and I'll have something to show for all my work. It really has been a great experience.
Subscribe to:
Comments (Atom)