Jump to content

United Kingdom Tinytimrob

R J Dennington
Programming Staff
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Tinytimrob

  1. A new update is now available for Spellmaster II (version 0.0.34 based on source code revision 120bd825484c). Patch notes for this version follow. Spellmaster II Preview Release 0.0.34 (29 July 2019) Spellmaster II core changes: Fixed the support links in the menu going to incorrect places.
  2. A new update is now available for Spellmaster II (version 0.0.33 based on source code revision 91d81105e9aa). Patch notes for this version follow. Spellmaster II Preview Release 0.0.33 (28 July 2019) This is a long-term maintenance update. In addition to fixing some minor bugs, the game engine has been updated to the latest version. There is also a Magic data set update included, but it is not too recent, being updated only as far as Dominaria (released in April 2018). There is a good reason for this. The data sets were previously scraped from magiccards.info using jsoup, but this site is no longer operating. The replacement service, Scryfall, has explicitly stated there will be no future support for scraping HTML pages from magiccards.info, which makes the current version of the card fetcher unusable. In order to continue to update the data sets, I will have to rewrite the fetcher to pull data from their JSON API instead, which annoyingly doesn't even have a matching set list. Because of this, when I eventually make that change, the entire card library will probably have to be rebuilt from scratch, and any decks people have built which make use of cards with no-longer-matching IDs will effectively have to be remade. What a nightmare! In the long term, in order to allow for Spellmaster II to see an actual public release, I am hoping to completely decouple the set data from SM2, meaning that datasets and SM2 builds will be updated separately. My plan is essentially for the launcher to update SM2 and then for SM2 itself to manage and update the locally stored card data. There are numerous advantages to doing this. In addition to avoiding shipping any Magic or Intryon content with the SM2 installation, it will be possible to update the set data more regularly (possibly by an automated script) because I will no longer be forced to issue SM2 updates simply for the addition of new set data. Compiling all of the GPQ archives for the set data also takes almost 30 minutes for the build server nowadays, making new builds quite slow to roll out, so after the decouple the compile of new SM2 builds should be pretty fast. The update to using Scryfall's API will probably happen at the same time as the decouple, resulting in a single big changeover. I'm honestly not sure when I will get around to this. Until then, there are likely to be no further updates to the set data. Anyway, here are the changes in this release. Spellmaster II core changes: Updated to GinENGINE version 0.4-alpha1. This is a major engine update with many new features and stability improvements. A lot of the netplay code has also been refactored in order to move common battle code to the engine core. Login can now also optionally be handled directly by Spellmaster II without having to use the GineverLauncher. This is a prototype feature not expected to see any serious use right now, but could allow for release of SM2 (or applications forked from it) in other app stores/launchers in future. Fixed broken buttons on spectator list. Fixed an issue where the game would crash if an unknown user group was found in the friend list data. Fixed a security-related regression introduced in GinENGINE version 0.3.1 (and thus in preview release 0.0.28) where the game would not bother to validate the SSL certificate of the gameplay server Minor visual tweaks to several menus and control screens. Game types are now implemented as netplay rulesets. Magic changes: Updated data set as far as Dominaria.
  3. A new update is now available for Robbit (version 27.0.0-DEV9.5, revision 5112). Patch notes for this version follow. Robbit "Fondant Fancy" Patch 27, Development Preview 9.5 (7 June 2019) This patch is intended to help improve the stability of the game. Installation of this patch is mandatory for playing online, but even if you don't play online I would recommend installing it anyway. Bug Fixes and General Changes Fixed issues with server load-unload loops caused by the IC2 energy net. Fixed an exception that could lead to map corruption when the server entered into automatic freeze recovery. Fixed some circumstances where pitch and yaw were improperly flipped when teleporting. The player's last /back position is now stored in the save data, meaning that it gets preserved in both single player (between sessions) and multiplayer (between server reboots). Reporting Bugs If you find any bugs, please report them on the Robbit issue tracker. This will help us to weed out and fix bugs faster and more efficiently. Thank you.
  4. Implemented in r5110. /back location is now saved to player.dat and persists in both single player and multiplayer even between server restarts.
  5. Fixed in r5109. Adjacent tile notification will no longer be triggered by default when IC2 tile is added to or removed from energynet. Having this as the default behaviour is just too buggy and causes large load-unload loops in many instances. Blocks which explicitly need the notification (which should be the minority) will now have to explicitly state this in their block constructor. Currently this is set only to the IC2 power cable, which uses the load-unload trigger for updating cable directionality. This change may be behaviourally breaking with IC2 in some places and might warrant future patches to fix bugs caused as a result of this change.
  6. Attempted a fix in r5108. Hopefully should resolve the problem. A little hard to test from here, so further testing might mean the issue gets re-opened.
  7. The player's /back location is not saved when server restarts. It would be nice to save this data.
  8. java.util.ConcurrentModificationException at java.util.TreeMap$PrivateEntryIterator.nextEntry(Unknown Source) at java.util.TreeMap$KeyIterator.next(Unknown Source) at net.minecraft.world.WorldServer.func_72920_a(WorldServer.java:679) at net.minecraft.world.chunk.storage.AnvilChunkLoader.func_75820_a(AnvilChunkLoader.java:420) at net.minecraft.world.chunk.storage.AnvilChunkLoader.func_75816_a(AnvilChunkLoader.java:212) at net.minecraft.world.gen.ChunkProviderServer.func_73242_b(ChunkProviderServer.java:292) at net.minecraft.world.gen.ChunkProviderServer.func_73151_a(ChunkProviderServer.java:347) at net.minecraft.world.WorldServer.func_73044_a(WorldServer.java:902) at net.minecraft.server.MinecraftServer.func_71267_a(MinecraftServer.java:413) at net.minecraft.server.MinecraftServer.func_71260_j(MinecraftServer.java:469) at robbit.servermonitor.ServerMonitor.restartServer(ServerMonitor.java:179) at robbit.servermonitor.ServerMonitor.run(ServerMonitor.java:305) Looks like two threads are trying to save the map data at the same time, which is causing CME. Probably fixable using synchronization.
  9. ADD sometimes doesn't get written to chunks if the server restarts while in the middle of world generation due to the freeze timer being too restrictive. This is most visible when the server enters automatic freeze recovery while generating sections of the nether. The most visible side effect of this bug is that blocks added to the nether worldgen system which have block IDs > 255 will not be correctly saved. As a result, it looks like random blocks of creosote/coolant are just all over the place in the newly generated chunks. I'm not really sure why only the ADD ends up being corrupted while everything else is still fine. This is kinda baffling to me. Probably shoddy implementation of the map saving system. A potential workaround to avoid the problem is to set a really long freeze timer, which would prevent nether generation from triggering freeze recovery. Another possible workaround might be to somehow reset the freeze timer during world generation, although this might require a more extensive rewrite of the chunk generation code.
  10. Confirming issue. Right now I'm not able to work on fixing this because I'm on vacation until second week of July.
  11. The new IC2 energy net introduced in 27 DEV7 can cause chunk load-unload loops on the server in some circumstances. This is most likely the result of TE lookups being made in sections of the map that aren't loaded, with those TE lookups being triggered by the unload of adjacent chunks. Some work was already done towards fixing this problem in DEV7.3, but the problem is evidently not completely resolved because the bug is still causing significant problems in some areas of the survival map (most particularly right now for people wandering near the Dovahkiin nether base) Further investigation is required to track down exact cause(s).
  12. A new website has been launched to try and help promote GIF more easily. Check it out! https://www.gifthegame.com/
  13. The official trailer for GIF is here! The trailer has been produced by Medessec with music by ZombieWizard PHD. If you're interested in checking out this game you should have a watch. Coming to PC, Android and iOS on April 26th!
  14. Hello everyone! I'm pleased to announce that we are pursuing a release date of Friday 26 April for the commercial release of GIF! As of right now the game is practically complete (with only a couple art assets missing) so we are about 95% certain we can comfortably meet this date. The game will be initially available to buy on Windows, Mac and Linux (via Steam), Android (via Google Play), and iOS (via the App Store). The retail price of the game will be $1.99 (about £1.69 in the UK). Any proceeds made from the sale of the game will be put towards funding the next project. All versions of the game will include the full single-player gameplay experience, including 3 zones with 25 levels each (so 75 in total), 25 unlockable skins, and full support for USB or bluetooth game controllers in addition to keyboard or touch controls. The PC version will also include integration with Steam services such as leaderboards, achievements and Steam Cloud. (The leaderboards are really my favourite feature in the Steam release, because they help to add a competitive element to the gameplay, letting you battle it out with your friends for the fastest times. Woop!) As you can see, we are currently targeting PC and mobile only. You may be wondering why a console release hasn't been announced, especially since I've mentioned that the game works fine on my Xbox a couple of times recently, so I would like to clarify now that we would definitely like a console release in future. The game has been programmed with a possible console release in mind too, so there isn't really any reason from our side as to why this wouldn't be possible. However, the publishing policies operated by Microsoft, Sony and Nintendo are not currently flexible enough to allow us to pursue any console release at this time. It is possible this situation could change in the future, so I wouldn't count out a console release down the line, but as of right now it doesn't seem like a realistic endeavour. I guess it depends how well the PC and mobile versions sell I have also been asked about whether we would be willing to release a DRM-free version of the game outside of the Steam store. The decision has been made not to pursue this option right now, because to release the game in that way the leaderboards would realistically have to be stripped out. It would also be much harder to issue updates and bug fixes to the game without using Steam. However, if there is a significant demand for a DRM-free version without the Steam functionality included, we will definitely look into that. We are nevertheless really excited to be able to finally announce the upcoming release of the PC and mobile versions of GIF! This is a huge milestone for us, and I'm very proud of everyone on the development staff for reaching this point. The production quality of the game is a lot higher than I could possibly have hoped for at the start of the project and I'm really happy with the way everything turned out in the end. So thanks to everyone who supported us and helped to make this happen! Look out for GIF, hopefully on sale from Friday 26 April!
  15. I did some digging today to figure out how I made this part of the uninstaller work. I was able to verify the issue more accurately and I think I finally came to an explanation. The data folder removal is performed using a custom component called "CleanupMainApplicationFolder". This component does nothing when installed, but has an uninstall action of removing the folder pointed to by the "P.REMOVEDATAFOLDER" property. The MSI trigger performs a custom action which sets the "P.REMOVEDATAFOLDER" property to the application install path immediately before the 'validate product ID' sequence, but only if REMOVEUSERDATAONUNINSTALL is set to 1. This is the default value, therefore it IS set during install (although the "P.REMOVEDATAFOLDER" property isn't used then, so this does nothing), but during uninstall it can be toggled off by the checkbox. If you don't have the checkbox ticked, the "P.REMOVEDATAFOLDER" property is never set, so it ends up being a null pointer. This results in nothing being removed. Thus, having the checkbox checked means REMOVEUSERDATAONUNINSTALL is set to 1, which in turn means P.REMOVEDATAFOLDER gets set to the install directory, which further in turn means that the uninstallation of the CleanupMainApplicationFolder component results in the installation directory being completely removed. Likewise if you have the checkbox unchecked, the REMOVEUSERDATAONUNINSTALL is set to 0, so P.REMOVEDATAFOLDER is never set (and thus is null), and thus the folder null is removed instead (which isn't valid, so nothing happens). All seems OK so far, the logic makes sense, and we know this works sometimes. So we move on now and keep digging. The component ID in the installer for the CleanupMainApplicationFolder component is set out like this: <Component Id="CleanupMainApplicationFolder" Guid="*"> And herein lies the problem. This instruction is supposed to auto-generate a unique component GUID. But for some reason, despite the other GUIDs in the file which are asterisked like this ending up unique, this one does not generate uniquely. Instead, the GUID of A9E06F23-F202-52C8-BBAF-DA1B58DC870E is generated for both GineverLauncher and Robbit Launcher 3 MSI files, which seems contrary to proper behaviour. (This was verified by using the WiX dark tool to decompile the MSI files currently available for download on the website.) I currently have no idea why this happened, since these GUIDs are supposed to be globally unique, so this seems like it is probably a bug or oversight in the WiX toolkit. Either that, or I misunderstood how these GUIDs are allocated. Either way, the auto-allocator is apparently unreliable. As a result, the cleanup component of both launchers installs with the exact same GUID. Unfortunately, this breaks the uninstall behaviour. Here are some example behaviours: Install GineverLauncher. Uninstall. GineverLauncher folder is cleaned up properly. Install Robbit Launcher 3. Uninstall. Robbit Launcher 3 folder is cleaned up properly. So we can see everything works fine if you only have one launcher installed. Awesome. Now we try with two installed... Install GineverLauncher. Install Robbit Launcher 3. Uninstall Robbit Launcher 3. Robbit Launcher 3 folder IS NOT CLEANED UP PROPERLY (and the GineverLauncher folder isn't touched either) Uninstall GineverLauncher. GineverLauncher folder is cleaned up properly. (the Robbit Launcher 3 folder is still present) Install GineverLauncher. Install Robbit Launcher 3. Uninstall GineverLauncher. GineverLauncher folder IS NOT CLEANED UP PROPERLY (and the Robbit Launcher 3 folder isn't touched either) Uninstall Robbit Launcher 3. Robbit Launcher 3 folder is cleaned up properly. (the GineverLauncher folder is still present) So it seems that whichever launcher is uninstalled last is the only one that gets cleaned up correctly, regardless of original installation order. For the one uninstalled first, the cleanup routine completely fails. So I previously thought this issue only affects the Robbit Launcher, but apparently I was wrong. Hypothesis as to why this behaviour happens: It seems that both program installs are adding 1 installation of the cleanup component. MSI is treating them both as the same component and tracking how many installs of the component there are. The component is only considered uninstalled when every single installation is removed. The cleanup also only happens at the point at which the package is considered uninstalled. So on installation of the first package, some installation counter is incremented. We now have 1 copy of the cleanup package installed. Uninstalling it at this point results in no copies installed any more, so the folder is removed. When you install a second package, the installation counter is now at 2. Therefore if you run one of the uninstallers at this point, this only decrements the counter back to 1 installation remaining, which is not enough to trigger the cleanup. Potential fix: I think this could easily be fixed by just manually inputting a GUID for this component for each installer, and then rebuilding the setup files. This would result in these components having completely separate GUIDs, and therefore there is no risk of clash. Unfortunately this will not fix the issue for the small number of users who already have the launcher installed. I'm also not sure what would happen if someone were to subsequently try installing (or uninstalling) using a "fixed" installer while they have an installation from an "unfixed" version present. This will have to be tested at some point to find out. *sighs profusely at WiX*
  16. This is the original version of AudioLoop, built against Shaltif's Xtreme Music and Sound (SXMS) 3. Provided for historical reference purposes only. Build date: 15 June 2008
  17. AudioLoop v2.0, originally bundled with builds of Crimson. Provided for historical reference purposes only. Build date: 27 August 2008
  18. AudioLoop v2.1, originally bundled with builds of Crimson. Provided for historical reference purposes only. Build date: 27 December 2008
  19. Alpha version of AudioLoop v2.2, previously never released. Provided for historical reference purposes only. Build date: 23 August 2009
  20. This is the legacy version of Athena 3, built on 29 September 2013 using source code revision 20. It is licensed under GCL version 2. The original source code can be found at https://hg.ginever.net/public/athena-3/. Athena 3 is provided for archival purposes only. It is strongly recommended to use Athena IV instead where possible (or, alternatively, some other tool).
  • Create New...