Feature Suggestions

Could you make a small improvement to the Daily Reward plugin?
Currently, the system only saves completed hours toward MinDailyHours, causing players to lose their accumulated minutes whenever they disconnect or switch GameServers.
Example:
A player stays online for 59 minutes and then gets disconnected. All 59 minutes are lost because the system only saves completed hours.
The same issue occurs when switching to another GameServer, such as moving to the Market server to enter Blood Castle. Even though the player continues playing, all accumulated minutes toward the next full hour are lost.
Proposed improvement:
Allow the system to track and save MinDailyHours progress in minutes instead of only full hours.
This way, players can continue from where they left off after reconnecting or switching GameServers, without losing their accumulated playtime.
This would make the Daily Reward system more reliable and fair, especially since switching GameServers is a normal part of gameplay.

Moss is a bit ruined in season 22 version with the extra delay added, we need alternative method and the best one i can think is to add custom item cost in itempricesystem.xml  + to implement the price confirmation window where we can enable on high value items to avoid double purchases mistakes. If its too much trouble for global item support then allow jewels/miracle/rare tickets as cost option with durability config, that would do the job.

Hello, I would like to suggest an improvement to the Lock system, using MuDream’s Guest Access system as a reference.
I would like the Lock system with a viewer panel to include configurable guest access, allowing account owners to share access without revealing their main password and choose exactly which actions a guest can perform.
1. Access through a temporary password
The account owner should be able to create guest access through the in-game panel, similar to the one MuDream provides through the F10 menu. 
This process would include:
- Assigning a session name.
- Generating a temporary password, with a button to copy it.
- Allowing the guest to log in using the account’s username and the temporary password.
- Making the temporary password valid only for logging into the game, without granting access to the website or account management panel.
2. Separate permissions for each guest session
All operations controlled by the system should be disabled by default. 
The account owner would enable only the actions they wish to authorize, with separate controls for:
- Chat System: sending messages in general chats.
- Trade: trading with other players.
- Shop Sell: selling items to shops.
- Shop Buy: buying items from shops.
- Mix: using NPC item combination functions.
- Cash Shop: accessing the server’s XShop.
- Warehouse: accessing the account’s warehouse.
- Guild: allowing or restricting access to guild system functions.
- Friend: allowing or restricting access to friend system functions.
- Inventory: allowing or restricting move of items in inventory.
- Commands: allowing or restricting use of Command system
and more if i miss something we already have on current lock system.
This would allow owners to create different access permissions for different purposes—for example, a restricted session for farming and another with trading permissions.
3. Configurable access duration
Each guest session should have an adjustable duration in hours and an expiration date and time. Once that period expires, the guest password should no longer allow access.
4. Session management
The panel should include a Sessions tab where the account owner with master password (main password of the account) can:
- Maintain multiple guest sessions, each with its own settings.
- View each session’s name and expiration date and time.
- View a summary showing which permissions are enabled or disabled.
- Copy the password for each session.
- Delete individual sessions to revoke access.
5. Login priority for the account owner
If the account owner logs in using the main password while a guest is connected, the owner’s login should take priority. The system should automatically disconnect the guest and allow the owner to access the account immediately.
The goal is to let account owners retain control while sharing their characters with specific permissions for a limited time, reducing the risk of unauthorized actions involving their items and resources.
System reference and demonstration:
Guest Access Guide: https://mudream.online/about/main/guest-access#ga-how
Demonstration Video: https://www.youtube.com/watch?v=PoR6kxg2sIc

If a suggestion is used to create a plugin, could the creator of that suggestion receive a plugin discount considering how expensive they are? 
So far I've had 2 ideas partially or almost fully integrated/converted into a plugin. 
That would be a nice gesture to the users who contribute ideas here.  
cheers. 

If it's possible, can you increase MaxPlayerPerRoom="10" to for example 20?
In my server it's frequently asked question why only 10 and why we can't increase it as those who want to go there don't manage to make it in time because it's full

Hello IGC team,
We are developing a custom menu using LuaUI. The UI is designed on the 640×480 canvas, but its background images and icons become horizontally stretched when the game runs in different aspect ratios, such as 4:3, 16:10, and 16:9. We need to preserve their proportions while keeping the visual positions and mouse hitboxes aligned.
UI.ScreenWidth() and UI.ScreenHeight() return the LuaUI canvas size (640×480), not the actual game viewport size. In our tests, UI.Scale() also returned 0.50 at all three aspect ratios. Client-side Lua cannot use io.open to read the launcher’s LauncherOption.if file.
Could you provide a read-only client-side API such as UI.GetViewportSize(), returning the width and height of the actual game rendering area? An API returning the viewport aspect ratio would also work. The name is only a suggestion.
The returned dimensions should exclude the Windows title bar and window borders. If DPI scaling affects the values, it is fine to return logical dimensions, provided the width and height use the same units and their ratio is correct. Please document the units and when the API becomes available to LuaUI.
For example, the API should let Lua distinguish 1024×768 (4:3), 1280×800 (16:10), and 1280×720 (16:9). We can then adjust the background, icons, button positions, and mouse hitboxes together in Lua.
Our launcher sets the window size before the game starts, and the window cannot be resized while running. Therefore, being able to read the viewport size once after LuaUI initializes is sufficient for us. A resolution-change callback would be useful, but is not required for this request.
Does the current client already have an equivalent API? If not, would you consider adding one and providing a short Lua usage example? We only need to read the viewport dimensions; we are not requesting file-system access.
Thank you!

Hello, im getting plenty of reports from players who accidentally double click and purchase items twice and then ask for refund. 
Please add a confirmation window like Are you sure you want to buy this item? Yes/No  to avoid spending time on refunding players.

;---------------------------------------------------------------------------------------------------- IPConnectionLimit_General_Group = 10000 HWIDConnectionLimit_General_Group = 3 ;---------------------------------------------------------------------------------------------------- IPConnectionLimit_OffPlayer_Group = 10000 HWIDConnectionLimit_OffPlayer_Group = 3 My suggestion: Add a total limit
IPConnectionTotalLimit_Group = 10000 HWIDConnectionTotalLimit_Group = 3 Example. I wanna make a limit of 3 playable accounts per person. With the current system, players are able to run 3 windows + 3 off-level windows at the same time. 
With the "TotalLimit_Group" it will be possible to have a maximum of 3 online/off-level characters from the same hwid at the same time.

Hello,
I would like to suggest adding full client-side support for ItemSellPriceDivisor in Season 6.
Currently, this setting can be configured in:
Data/PriceSettings.ini
For example:
ItemSellPriceDivisor = 10
The GameServer already applies this setting correctly. When a player sells an item to an NPC, the amount of Zen received is correctly calculated according to the configured ItemSellPriceDivisor.
The only issue is that the Season 6 client does not reflect this setting visually. The player still sees the original selling price in the item tooltip, even though the actual amount of Zen received is different.
It would be great if changing ItemSellPriceDivisor automatically affected both the server-side calculation and the selling price displayed by the client.
This way, when the administrator changes this single parameter, the GameServer would continue calculating the correct amount as it does now, while the client would also display the correct selling price when the player sells an item to an NPC.
This would keep the client display fully consistent with the actual server-side selling price.
Thank you.

Server Season: Season 6

i dont see these drop rates configurations would it be hard to make these? also disabling/enabling option would be nice too since now i cant make a custom drops since boxes are hardcoded in exe

The recent change makes Dark Lord Summon reset the accumulated crown registration time when `ResetAccumulatedTimeAfterMove="1"` is enabled.
To be clear about what we are asking: we are not disputing the report, and we are not claiming the old behavior was correct. It was inconsistent with the rest of the option and the fix was the right call. What we would like to request is that the resulting rule — Summon not counting as a relocation for crown registration — be offered deliberately, as an option a server owner can switch on, rather than being unavailable entirely.
**Proposed configuration**
A separate flag under `CastleSiegeEvent`, evaluated only when `ResetAccumulatedTimeAfterMove="1"`:
```
ResetAccumulatedTimeAfterSummon = "1"
// 1 = Dark Lord Summon resets the accumulated crown registration time (current behavior, default)
// 0 = Summon is excluded from the reset; accumulated time is preserved
```
With the default set to `"1"`, no existing server is affected by the update in any way. Anyone who does not touch the configuration keeps exactly the behavior shipped in the fix. Only servers that deliberately set it to `"0"` opt into the alternative rule, with full awareness of what it does.
Since the reset now has a defined call site, we assume this amounts to a single configuration check at that point rather than any rework of the siege logic.
**Why we are asking**
Since the update went live we have received repeated requests from our players to make this possible again. Regardless of how the behavior originated, our community had built siege strategy around it and treats it as part of what a Dark Lord contributes to the event.
The practical impact is a balance one. A guild with fewer members cannot hold the Throne Room continuously against a guild with two or three times the roster — they lose the room, lose the accumulated time, and the siege is settled by headcount rather than by play. Being able to relocate their own Guild Master with Summon, keep the progress already earned, and return for the remainder gave outnumbered guilds a reason to contest the siege at all.
We understand completely that on other servers the same interaction is judged to be abuse, and the reset should apply there. That is precisely why we are asking for a switch rather than a change of default — one configuration line would let both communities run the ruleset they actually want, and neither has to lose anything.
We are happy to test the option on our server and report back before it goes into a general release.
Thank you for considering this.

Hello. We have the file ServerInfo.xml, where we can write our "connection IP"
<ServerInfo Password="WErt$4t3">     <Connection IP="127.0.0.1" Port="44405" Version="1.00.00" Serial="PoweredByIGCN800" /> Suggestion: add the ability to add an additional "Connection IP" list. Like:
       <Connection IP="127.0.0.1" Port="44405" Version="1.00.00" Serial="PoweredByIGCN800" /> <!--  <Connection2 IP="127.0.0.1" Port="44405" Version="1.00.00" Serial="PoweredByIGCN800" /> --> <!--  <Connection3 IP="127.0.0.1" Port="44405" Version="1.00.00" Serial="PoweredByIGCN800" /> --> <!--  <Connection4 IP="127.0.0.1" Port="44405" Version="1.00.00" Serial="PoweredByIGCN800" /> --> <!--  <Connection5 IP="127.0.0.1" Port="44405" Version="1.00.00" Serial="PoweredByIGCN800" /> --> And add in the launcher the possibility to change which "connection IP" will be used. By default, the first one will be used. Others can be commented out if not in use. 
The reason: in case of DDOS or any other network issues, players will be able to switch between connection ip. For administrators - less of a headache when we have extra protection in case of problems.

I would like to suggest add 3 extra function.
1) Function Party.DelMember - Gives the ability to delete a member from the party.
2) Function Party.ChangePartyLeader - Gives the ability to change party leader
3) Function Party.AddMember - Gives the ability to add players to the party.

Currently to adjust damage from Scripts gs needs to be restarted, this makes skill damage testing PVE PVP very lengthy and time consuming as needs to:
restart GS // run main login with all the characters to test PVE PVP // add buffs in-game etc
So reload for this would same a lot time, as new episode seasons comes with new combat power and other changes, which means needs to readjust damage game again almost every season

I would like to suggest adding a few extra functions. 

1) Function Guild.AddMember - Gives the ability to add a member to the guild.
2) Function Guild.DelMember - Gives the ability to remove a member from the guild.
3) Function Guild.AlianceCreation - Create an alliance between 2 guilds
4) Function Guild.AlianceDestroy - Destroy an alliance between 2 guilds
Any other function that can be useful in terms of guild? 🙂

I am writing to request the addition of new event-related callbacks. Currently, we only have callbacks for BC, CC, and DS events; the idea is to make callbacks available for all events, especially PvP events.

Please add a native pre-movement validation point for map access requirements that can evaluate Regular Level only, without adding Master Level. This is necessary for servers that keep Master Level and Master Skill Tree after character reset while still requiring players to rebuild their regular level before they can access higher-progression maps.
Current behavior and limitation
The current Lua API provides these movement callbacks:
onCharacterJoinMap onMoveMap onMapTeleport onTeleport onTeleportMagicUse They are asynchronous callbacks. They run after the game server has already accepted and completed the movement. Lua can then move the player back with Move.ToMap, but it cannot deny the original transition before entry. onUseCommand, onNpcTalk, and onItemUse are synchronous, but they cover only specific movement routes and cannot provide one authoritative validation point for all sources.
Requested native configuration
Add a map-move level validation mode to the MapMove / gate requirement system:
<MapMoveRequirements LevelRequirementMode="0" /> Proposed values:
0 = Regular Level only (Character.Level) 1 = Master Level only (Character.MasterLevel) 2 = Regular Level + Master Level (current combined behavior where applicable) A per-entry override would also be useful:
<Move ClientName="Ferea" MinLevel="400" LevelRequirementMode="0" /> With LevelRequirementMode="0", the native implementation should validate:
if (lpObj->Level < requiredLevel) { return false; } and must not use a combined value such as:
lpObj->Level + lpObj->MasterLevel  
Requested Lua callback
Please also expose a synchronous callback that runs before the C++ move is committed:
function onCheckMapMove(oPlayer, targetMap, targetX, targetY, gateNumber, moveSource) return 0 -- allow -- return 1 -- deny end  
Required execution contract
| Property | Requirement | | Type | Synchronous | | Timing | Before any map transition is committed | | Return 0 / nil | Allow native movement | | Return 1 | Deny native movement and keep the player in the current position | | Performance | Must be lightweight; no blocking I/O required | Required parameters
| Parameter | Description | | oPlayer | Player object | | targetMap | Final map number | | targetX, targetY | Final coordinates | | gateNumber | Gate index, or -1 where no gate is used | | moveSource | MAP_MOVE, COMMAND, GATE, NPC, ITEM, EVENT, SCRIPT, TELEPORT_MAGIC | | mapMoveEntryId (optional) | Native MapMove rule/entry ID if available | Why this matters
A native regular-level-only option enables the following valid configuration:
<Settings MoveToCharSelectWindow="0" ResetMasterLevel="0" ResetMasterSkillTree="0" /> The character can remain connected after reset and keep Master Level progression, but cannot use Master Level as a shortcut to enter maps such as Aida [2], Ferea, Raklion, Swamp of Calmness, Lost Tower upper floors, or Karutan [2] before rebuilding the required regular level. This improves player experience by removing the forced character-selection interruption while preserving progression integrity.
Compatibility expectation
The validation must apply uniformly to every native movement path:
Map Move UI /move and equivalent commands gates and portals NPC transfers teleport items event entry routes scripted Move.Gate / Move.ToMap operations, with an optional explicit bypass flag for trusted server-side events
teleport magic when it crosses a restricted area boundary
 
Temporary Lua workaround
Until a pre-move API exists, servers can use asynchronous callbacks to detect a forbidden destination and immediately return the player to a safe map. This is useful but not equivalent to a true deny because the player briefly enters the target map before correction. A native pre-move check or built-in LevelRequirementMode="0" is the reliable long-term solution.

Hello,
I would like to request a native API for temporary character profiles designed for events such as Battle Royale, survival arenas, class trials, ranked PvP and temporary progression modes.
The objective is to temporarily place a player into an isolated profile without modifying or risking the original character inventory, equipment, buffs, skills or attributes.
Current Lua functions allow item access, deletion, insertion, stat changes and individual buff removal, but they are not sufficient to safely recreate the original state after an event. A full Lua-side solution may cause item serial issues, loss of advanced options, duplicate items, incorrect durability, socket/Harmony problems and incomplete buff restoration.
Requested API:
local sessionId, result = PlayerEvent.BeginTemporaryProfile(oPlayer, { EventKey = "BATTLE_ROYALE", Snapshot = { Stats = true, Level = true, MasterLevel = true, MasterSkillTree = true, LifeManaShieldAG = true, Equipment = true, MainInventory = true, ExtendedInventory = true, MuunInventory = true, PentagramInventory = true, Buffs = true, Skills = true, CashShopEffects = true, ItemEffects = true, }, TemporaryProfile = { BaseStats = { Strength = 100, Dexterity = 100, Vitality = 100, Energy = 100, Command = 100, }, Level = 1, LevelUpPoints = 0, InventoryMode = "EMPTY_EVENT_INVENTORY", SkillMode = "WHITELIST", AllowedSkills = {}, BuffMode = "SUPPRESS", OriginalBuffTimePolicy = "ELAPSE", }, Restrictions = { BlockTrade = true, BlockWarehouse = true, BlockPersonalShop = true, BlockChaosMachine = true, BlockInventoryMove = true, BlockItemUse = true, BlockItemRepair = true, BlockTeleport = true, BlockNormalItemPickup = true, }, Recovery = { PersistSnapshotBeforeApply = true, RestoreBeforeCharacterSaveOnDisconnect = true, RestorePendingSessionOnLogin = true, RestorePendingSessionsOnServerStart = true, }, }) local result = PlayerEvent.EndTemporaryProfile( oPlayer, sessionId, "EVENT_FINISHED" )  
The native implementation should use an internal opaque snapshot. Lua should not be required to manually serialize and rebuild actual items.
The snapshot must preserve the exact original item state, including:
Original inventory slot and equipped position Unique item serial Item level and durability Skill, luck, additional option and excellent options Ancient/set options Harmony option type and value Socket options and bonus socket option 380 option, period item data, pet data, elemental/pentagram/errtel data Muun inventory and related items Any other internal item fields required for a bit-perfect restoration Buff restoration should preserve: Buff identifier Remaining duration Effect types and values Buff source / caster Cash Shop and item-generated effects Configurable time policy: ELAPSE, PAUSE or REMOVE
The API should also provide an isolated Event Inventory:
EventInventory.Clear(oPlayer, sessionId) EventInventory.AddItem(oPlayer, sessionId, itemInfo) EventInventory.TransferRewards(oPlayer, sessionId, { Destination = "GREMORY_OR_MAIN_INVENTORY" }) This is necessary so event rewards and temporary equipment do not mix with the player’s original inventory.
Required safety guarantees:
BeginTemporaryProfile must be atomic. EndTemporaryProfile must be idempotent. No original item may be deleted or recreated through Lua. The original profile must be restored after event finish, disconnect, server restart or unexpected crash. The GameServer must prevent item movement, trade, warehouse, chaos machine and similar actions while the temporary profile is active.
The system must prevent duplicate rewards and duplicate profile restoration.
Recovery should be automatically processed on player login and GameServer startup.
The API should provide clear result/error codes and server logs for create, restore, recovery and failure cases.
This feature would allow secure development of Battle Royale, survival arenas and temporary PvP modes without risking player items or permanent character data.
Thank you.

Requesting a config addition to allow DL dark horse usage with fenrir+guardian mounts

Add an object system in game that would trigger a popup window with an option to add custom text.
Example: Players click an object(Notice board) outside town, pop up comes up with a text about what area is this, what items drop in here etc, any relatable information(This is all customisable).
This can also be used as a good way to interact with players and guide them without them leaving the game. ( I just started paying, click on a notice board and it guides me to level up 50 levels and then I get xyz item reward etc, or that don't go west of the map because big monster will eat you etc.).
These objects can also be used as a part of the world. Click on a stone pop up window comes on and there's an info about specific event or some hidden extras. This opens for more potential custom content.

Hi!
Would be great if we had an option to change/add weather effects, fog colours and swimming on/off per map!
Effects such as: rain, snow,  heavy snow, sandstorm, leaf fall, water/bubbles etc. 
Fog colours similar to glow.bmd where we could change colours of the fog per map and perhaps distance when zoomed out with the 3D cam to hide the pop in distance?
This would help for more customs to be made and create more freshness to the game. 

Idea: 

Currently, item options stack based on equipped gear. I would like to propose a new "Total Cap" system as an optional feature. This would allow server administrators to define a global maximum limit (via configuration files) for specific item option IDs.
Example Use Case: For instance, an administrator could set a global cap of 25% for Automatic HP Recovery (ID 53). Once defined, the server would enforce this limit regardless of the total amount provided by the equipped items. The same logic could be applied to Damage Reflect Increase (ID 24) and other options, providing more flexibility in configuring specific server environments.
Implementation Goal: A configuration file where we can assign: OptionID -> MaxValue.
This addition would grant administrators greater control over balancing their server progression, offering an efficient way to fine-tune mechanics without needing custom source adjustments.

Hi, can you please add some kind of GM command that removes the /post/gpost messages by specific player? I really dont like anyone coming in my server saying whatever they want and me as an admin being helpless not being able to delete that message even if ban them, the message remains. Its very unfair as there are tons of troll players or even troll admins who join other servers just to create chaos in the chat.. 

Hello,
I would like to suggest add FailPenalty mode into CraftItem section of Trade BOT
// FailPenalty: In case of failure, different kind of penalties may be applied: // ~ -1: No penalty // ~ 0: Destroy item // ~ 1-15: Reduce item level by random number up to defined value Thanks

Hello developers, through this I would like to request the addition of a way to define where the item will be created, for example:
EventInventory GremoryCase CashShop Inventory Ground Currently, there is nothing that allows us to define where the item will be created, such as: https://github.com/srv-config/Configs-Preview/wiki/Item-Structures