• Content count

  • Joined

  • Last visited

  • Days Won


Alexgopen last won the day on April 30

Alexgopen had the most liked content!

Community Reputation

2069 Rare


About Alexgopen

  • Rank

Contact Methods

  • Skype
    maybe if you ask but probably not

Profile Information

  • Gender
  • Location
  • Interests


  • Acc1
  • Acc2

Recent Profile Visitors

5016 profile views
  1. Crackling Sound?

  2. Poll Wurm Veteran Status

    Wtf is a kingess
  3. Accolade PVP [Old Ele] [Highly Modded] 100x100x

    Bump come play on old elevation again Ps aus should put old elevation in the thread name bc idk if many people know this even exists
  4. Accolade PVP [Old Ele] [Highly Modded] 100x100x

    this server is pretty neat
  5. Reduce boot volume

    even better example
  6. Reduce boot volume

    Make boots take up less volume. It's completely out of line with the rest of the armor pieces. pic related
  7. I've done some testing lately and have come to the conclusion that Valrei is highly imbalanced in favor of Magranon. Read on for an explanation. This imbalance can be attributed to 3 major factors 1. Layout of the map's Buff/Trap/Slow tiles: The valrei map's special tiles are not very evenly distributed. For example, Fo and Libila are both pretty well boxed in by trap/slow/hostile tiles, while Magranon starts right next to a strength tile to start off scenarios with a significant buff. 2. Imbalanced edge crossing connections: I checked the Wurm Unlimited code to determine all of the possible edge crossing connections. To my surprise, a lot of them were 1-way only. After drawing all of the connections, it became apparent that Magranon has a much wider range of connected tiles that he can access from his edge of the map, as compared to either Fo or Libila. The result of this wider spread of edge crossings is that Magranon can access more tiles in fewer moves than either Libila or Fo. 3. Imbalanced deity characteristics in the new combat system: The starting stats for the 3 main gods are imbalanced, highly in favor of Magranon. This was very easy to test, as the Wurm Unlimited code has a method for simulating fights between gods for testing purposes. By simulating 1,000,000 fights between Lib v Mag, Lib v Fo, and Fo v Mag, I was able to see that Libila and Fo are fairly evenly balanced, but Magranon is stronger than both Libila and Fo and has a win rate of about 60:40 or better versus either of these gods. 1000000 fights completed between Libila and Magranon. Libila won 39.1482% of fights, Magranon won the remaining 60.8518%. 1000000 fights completed between Magranon and Libila. Magranon won 60.8139% of fights, Libila won the remaining 39.1861%. 1000000 fights completed between Libila and Fo. Libila won 50.782% of fights, Fo won the remaining 49.218%. 1000000 fights completed between Fo and Libila. Fo won 49.6064% of fights, Libila won the remaining 50.3936%. 1000000 fights completed between Fo and Magranon. Fo won 37.014% of fights, Magranon won the remaining 62.986%. 1000000 fights completed between Magranon and Fo. Magranon won 63.1285% of fights, Fo won the remaining 36.8715%. In summary, Valrei is in dire need of rebalancing. The map layout and edge crossings favor Magranon. This could partially explain why historically MR/Magranon won valrei most often. With the addition of the new deity stats and combat system, Valrei has become even further imbalanced in favor of Magranon.
  8. View spin bug

    Me and several others that I talked to have noted that we often get some sort of bug that spins our view out sometimes when we click ingame. This can lead to getting turned around suddenly and walking the wrong direction off of a dirtwall, or interferes with your ability to block arrows in pvp. Most often this seems to happen after tabbing from a different window into wurm, but can also happen randomly when just playing wurm the whole time. An example of this bug happening can be seen in the video below. I was trying to block arrows by keeping the enemy archers on the left side of my screen, but my view kept bugging out and spinning me sometimes when I clicked.
  9. Old Elevation

    Would it be possible to get the map of the server at its initial state? Like the clean start version of it, or does this no longer exist?
  10. Permission System PVP Bugs

    bump, updated the original post with bugs that are confirmed to still exist. The old original post has been left as well because many of the old bugs reported there have not been tested since, and may or may not still exist.
  11. Affliction is considered to not be a reputation controlled homeserver. HotS are supposed to be able to raid other HotS on Affliction without any reputation system preventions or penalties. This also means that we are not subject to the protection of the Disruptive Players rule, and that if people use alts in our kingdom on our homeserver it's allowed, and our only option is then to force them out ourselves. However, Affliction in fact actually IS a reputation controlled homeserver. This is probably a bug, because the GMs do not consider it to be one. We still suffer reputation penalties for unlawful actions, and can reach negative reputation, at which point we will suffer 5x skill loss if we die. This means that the reputation system is preventing us from dealing with nuisances on our homeserver, even though it is required for us to deal with them ourselves, since we are not protected by the Disruptive Players rule. [13:20:09] Your reputation is -13. Please either fix this so that we do not suffer reputation loss for unlawful actions on Affliction, or consider it a reputation controlled homeserver (as it currently actually is) so that we can be protected by the Disruptive Players rule. Examples of specific actions that can cause reputation loss on Affliction are catapulting other players or guards.
  12. you used to be able to have kids but they removed it
  13. Having to build epic structures AGAIN

    final int getNextBuildTarget(int difficulty) { difficulty = Math.min(5, difficulty); final int start = difficulty * 3; int templateFound = -1; for (int x = start; x < 17; ++x) { if (this.epicTargetItems[x] <= 0L) { templateFound = x; break; } } if (templateFound == -1) { for (int x = start; x > 0; --x) { if (this.epicTargetItems[x] <= 0L) { templateFound = x; break; } } } if (templateFound <= -1) { return -1; } if (templateFound < 3) { return 717; } if (templateFound < 6) { return 714; } if (templateFound < 9) { return 713; } if (templateFound < 12) { return 715; } if (templateFound < 15) { return 712; } return 716; } epicTargetItems is an array of longs of size 18 containing the wurmids of the epic structures already built on the server. This is not a dynamic array, it is never increased beyond size 18, and it is never checked at any indices beyond 0-17. There are 6 different types of epic structures, and you are required to build 3 of each type. You can easily see that here, in the if (templateFound < 3) etc checks, it's determining which type of item template id it should use to tell you which type of epic structure to build. templateFound starts at a default value of -1, and it only changes from this if it finds an entry in the epicTargetItems array where there there does not exist a valid wurmid. The epicTargetItems array is only checked from indices 0-17, so if we build any additional epic structures, like you say, then they would never even be counted and we would forever after have to continue building more epic structures, filling up the server. In normal circumstances, after checking the epicTargetItems array for invalid wurmids (or the default value of 0), if the array is filled in all 18 indices with valid wurmid (as it should be in our case, where we already built all 18 of our epic structures), then it would leave templateFound set to -1, and the method would return -1. This would result in generateNewMissionForEpicEntity rerolling a new mission type to try to create a new mission, and it would attempt to roll a new mission up to 10 times, until a new mission is actually created. What seems to be happening here, is that templateFound is being incorrectly set to something other than -1 (the value it should be when all 18 epic structures area already made and in the epicTargetItems array), and greater than 15. This results in execution passing all of the if statements, and returning 716, the item template id for spirit gate. This is likely due to the new difficulty system being used to determine the starting index for checking the epicTargetItems array for some reason. This doesnt make much sense to do, and in our case, the mission is difficulty 5, so it would've started by checking indices 16,17 in the first for loop, then indices 14,13,12,11,10,9,8,7,6,5,4,3,2,1,0 in the second for loop. From the start this is quite obviously wrong as it's never checking index 15, and it makes no sense to check different parts of the epicTargetItems array in different order and direction based on mission difficulty. As a result, something is going wrong in the check of the 18 indices of epicTargetItems, templateFound is getting set to something other than -1 (but greater than 14), when it should be -1 if all 18 epic structures are found in that array, and execution of this method reaches the bottom, where it returns 716 for spirit gate, despite all of the epic structures being already built. To fix this, return 716 should be contained within an if statement such as if (templateFound < 18){ return 716; } return -1; //something went wrong, generate a different mission type And the default value of returning -1 because something went wrong should be returned afterwards. (no available indices for unbuilt epic structures could be found) Please fix this or we will have to continually build more and more epic structures on all of our servers to complete missions, when they will never even be considered as targets for future missions (as they will not be part of the epicTargetItems array, or if the game does attempt to add them to this array of size 18, you will get an ArrayIndexOutOfBounds error and potentially crash the server) and they will never be counted towards the total required number to build. We are currently being made to build pointless epic structures forever, because templateFound doesn't get set correctly ever since the difficulty of the mission was factored into the checking of the epicTargetItems array.
  14. Having to build epic structures AGAIN

    I can literally take a GM on a tour of our server to show you all 18 (3 of each type) of our epic structures that we already built, to show that we are not supposed to get these missions anymore. It will take awhile to get around to all of them but if that's what it takes, so be it. Or even just check the Affliction twitter for when we built all 3 of our spirit gates: Additionally, a mission reset on affliction is needed.
  15. On affliction we had already completed building all of our epic structure missions, so we were not supposed to get these missions anymore. We were just now given a mission to build one of these again, when they had all already been completed. Additionally, in the past these would have to be built in the northwest, northeast, southwest, and southeast. The new mission states to build it just in the "east". No "build epic structure" mission has ever requested a structure to be built anywhere other than a corner (northwest, northeast, southwest, and southeast). The bugs are as follows: 1. We are not supposed to receive this mission. We already built all of our spirit gates on affliction. 2. The requested build location seems to be wrong. These have always been built in the NE/NW/SE/SW. 3. Also the last time we had to build these spirit gates, there was a bug with the tile checking where it would not find nearby marsh unless it was on one specific tile, a few tiles out to the northwest. I ended up having to figure this out through the WU code, as it would start the tile search for marsh in the northwest, but never work its way through the rest of the search area because of incorrect for loops. I don't know if this ever got fixed, and when we ran into this bug while building our spirit gates last time, we ended up having to show it to enki and have him paint an extra tile to marsh because the rest of the marsh tiles around the slabbed area were not being counted.