03SEP24 Bugfixes:

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   The DEVS are pleased to announce a collection of patches, bugfixes, and updates that will impact accessibility, performance, gameplay, and content. Access & Performance

Server Move Optimizations & Fixes

Issues: After the server move we experienced a few bugs for a few days, such as:
a temporary outage of the event queue processor after an unscheduled server reboot (meaning buildings etc hung in stasis for about an hour and a half)
the overnight data-dumps not refreshing
daily growth charts not updating
alliance strategic maps being out of date
Fix: The above have all been fixed.  

We’re not aware of any other issues relating to the new DB server except that outbound RL emails (such as password reset requests) may not be being sent.  It’s something we’re still investigating.

Sitters gaining temporary full access to sat accounts

Issue: It was possible for sitters to temporarily gain full administrative access to a sat account for a period of less than 1 minute, during the brief handover when the account was being sat and the sat player then logs in themselves, but before the sitter has been forcibly logged out of the account.  It only related to sitters and the people they sat under pretty edge-case conditions, and also only for a very limited period of time.

Fix: This issue has been fixed. 

‘This player does not exist’ on profile view

Issue: Some players experienced a temporary glitch for a couple of hours where their player profile showed as ‘This player does not exist’.   

Fix: This was part of our upgraded automated procedures for shutting down the semi-permanent output (player names, profiles etc) of banned players.  Obviously it was not intended to also affect non-banned players, and the bug was rectified within hours and profiles restored.

As part of this upgrade to the banhammer, banned players also have their player name automatically reverted to ‘Player [X]’ instead of what their name was before.  This applies historically, as well as for the future.

Editing URLs in order to do things that the UI does not allow

Issue: It was possible to edit the URL string to force a sovereignty claim on a square that was not permissible in the game User Interface. 

Fix:  This has been fixed.

Circumventing the next-city population requirement by using Capture and Settle in combination

Issue: It was reported in the forums that in the brief period between pressing the ‘capture’ button (after a successful siege) and the army capturing the conquered city, one could also dispatch settlers from a different city - which would leapfrog the city population requirements for the next city by one.

Fix:  This was apparently fixed many years ago (2012).  See last patchnote from TC: https://forum.illyriad.co.uk/06nov12-siege-exodus_topic4446.html 

If there is still a way of circumventing these requirements, please do open a petition with full details.

Faction Content Updates

Action Radii for all faction hubs have been set to 100 squares

Issue: Originally, each hub had its own Action Radius size, ranging from 100 to 1000 squares per radius, depending on the hub.

Fix: In anticipation of the first upcoming Faction AI rollout, we’ve decided to reset all of them to 100. This means that there will be more “dead zones” on the map where cities will not fall in any hub’s action radius, and cities will rank with fewer factions upon launch of the new system.  

The ‘old’ action radius for each hub has been reclassified as the maximum action radius for each hub, and now sets a limit on each hubs’ reach.  

Effective hub action radii will wax and wane with the power of each faction / hub.

Inter-Factional Relationships can now be asymmetric

Issue: Previously, all inter-faction relationship were symmetrical  eg. if ‘Council of Illyria’ was +10 to Triumvirate, then Triumvirate was +10 to the Council.  In our further development of Faction AI, we have found this to be too binary and we needed relationships to be able to be asymmetric.

Fix:  Faction relationship structures have been changed, and asymmetric relationships are now possible, the first one being directly below:

Adding an Inter-Factional Standing (IFS) between Virten and Kartur-Hhakral

Issue:  Multiple players pointed out that there needs to be an IFS between these Factions due to a simple description of the Kartur-Hhakral Faction’s single military unit:

The Kartur-Hhakrall are not sworn to fight for a clan or war chief, but to defend the crown of Virten. Their joy is to serve the finest monarch in the lands, and slay his enemies. Being well supplied by the master craftsmen of the royal armouries further increases their joy, as their natural strength and well honed skills are augmented by fine human crafted armour. Such well outfitted, intensively trained, heavy infantry are an extremely effective force on the battlefield.

Fix: Asymmetric faction relationships have been added as follows:
Kartur-Hhakral: +75 with Virten
Virten: +50  with Kartur-Hhakral
Thank you to Illy's loremasters for pointing out this appropriate and needed IFS!

With asymmetric IFS relationships now possible, look for additional tweaks to IFS relationships to accompany the first Faction AI rollout.
Gameplay Updates

Unit speed changes
The rollout of the non-cavalry unit speed changes was completed and went smoothly.  There are more changes to come to further address balance between unit-types and races. Stay tuned!

Assassins not targeting commanders in the unit pool

Issue: Since the launch of Illyriad, players have always been able to protect their at-home commanders by simply leaving them unassigned to an army. Even if assassins attacking the city overpowered the city’s assassin defense, they would not find commanders to assassinate if the commanders were left in the unit pool.

Fix:  This has been fixed, and assassins will now target commanders in the unit pool as well as those assigned to divisions.  

SC would like to give props to the unofficial Illy discord channel for making him aware of this issue in the first place.

Generic Runes/Glyphs targeting

Issue: When a rune or glyph is triggered by a military army, the rune prioritises diplomatic units attached to the army first. Players recognized this and optimized their direct-attacking armies to include low-upkeep diplo units, such as T1 scouts, to absorb the destructive powers of the rune, safeguarding all of their high-value attacking troops for actual combat.

This, however, was not the design intention of the rune -- it is supposed to indescriminateiy target and neutralize any unit "whose intentions are hostile." Since all units in an attacking army are unequivocaally hostile, its original targeting did not effectively capture the random and indiscriminate nature of the magic.

Fix: Troop types to be killed by generic glyphs are now randomised, which may be interpreted as a meaningful buff to the Rune school of magic.

We hope you'll enjoy these patches, updates, and bugfixes!

EDIT: typos

Edited by Illyriad Admin - 04 Sep 2024 at 05:42