I made so many people happy that when i register on PM - I keep getting spammed with summon requests to Par'Talucca :')
Printable View
Did I say I was ok with these not being fixed? No I didnt. BUT while we wait for pigs to start flying (aka for these twats to get their sh1t together and fix things), there are "ways" around said issues. I pointed them out incase you and or others were not aware of the ways around the bugs.
The DC when teleporting while walking is a security feature of the old ROHAN where there's no teleport feature. The game sees you cheating (as far as I know). Well I hope they will find a way to fix it.
as for the MR. I don't know if they take it seriously. Since they already introduce the Guild Battle system. For the mean time I'm going to grind my Dhan & Dekan to kill those pesty botters around. As I can kill them all I want when I'm in Assassin mode :)
For the GMs convenience,
Here's the list of bugs and suggestions:
*If I miss something mention it!.
- Murder Remission feature - Where you can reset your murder kill points.
- Diconnection when using teleport while walking.
- PK system - When attacking pink player(the one who first attacks you), You'll turn pink to. Pink players that killed you, won't show up on your vengeance list.
- Consignment shop - Still can't search the items needs to reconnect few more times.
- Option menu at the start of the client
- Fix the F.A.Q. Section - some are really confusing or the translation is not correct and brings issues.
- Dhan/Dekan Race sepearation - We know it is intended but could you give them more advantages or perks aside from the Assassin mode(a bit risky when your target is near a patrol)
- Magic Monster Attacks to Mages - This is being abuse right now, It should be balanced with other (Physical based class).
- Boss Drops - Give us durational epic item drops that the Bosses(high level) would drop to have something to fight for(PVP).
- Bot Users - We see them everyday, It's either have HK released or have a system to automatically detects them. We know that you guys are busy and won't have time to monitor the whole game 24/7, there's a feature like you did in the web portal login. Captcha Notices in areas with monsters, It will notify the player to enter a captha code in order to verify if they are using macros or not. This would Disconnect the players when not answered after a certain time.
Bro, pack that up in a ticket and send it in. the GMs don't give a **** about what is written in the forums. This is the only way they will even consider suggestions.
Sadly the game client is not moduilar and can't to do 3-part operation
(part 1) Login - HTTPS request to a web app which drives...
(part 2) Server selection - 50/50 Web call and stored procedure call to MSSQL which hands off to ...
(part 3) Game server connection from address obtained in part 2. This is what ultimately connects to the game client using a custom session.
The problem is that parts 1 & 2 happen in a web server. The transaction is ephemeral. Once the server hand-off happens, the http session ends and the socket is released for someone else to log in. The web session can not be passed on the actual game server component, and the http session must be released to accommodate as many players as possible. Hanging on to http sessions for several hours (or for some players days) is never a smart thing to do in client/server communications.
part 3 (the game server using a custom protocol) has no idea how to re-establish a destroyed web session and call the server selection web app without forcing another login.
I mean I don't see why they couldn't just create a new HTTPS request instance between being in-game and hitting a server-select button to create a new session while killing off the old one after the handshake happens. You can pass login credentials/authorization from the existing/prior session data and just pass it over in the middle of a splash/loading screen to hide the brief disconnect. If you really wanted to get fancy, you could also run a background client verification service on-load to the server-select screen as though the client was restarted to avoid any potential game hacks during the brief disconnected handover state. Though even then it's a little frivolous. It might not be modular but there are definitely ways around that.
My guess is they don't have an engine netcode programmer to implement this. Seems easy but I doubt there's any reasonably good API to do that kind of exchange; if there was, odds are we'd already have seen the feature years ago.
I think they just mean general game options, though (res change, etc. for splash screens), not just server selection. This would be a nice QoL feature and presumably wouldn't be too hard to implement given modern engines and manipulating GUI's on top of their existing graphics-scaling API's, though I know next to nothing about the game's client engine and what those screens are running on. Though if memory serves there's a cfg file which contains resolution data for the game, which begs questions why the splash/login/server select screens don't utilize this. Probably some ingrained and hard-coded resolution for splash screens if I had to guess, done just for low-res monitors to maximize compatibility. Likely one-layer/single-image and non-scalar, which would likely mean some script creation to parse the values in the cfg and scale the UI (the easy part), and more difficult, engine tweaks to execute the script and change the UI for displaying, which again, who knows if they even have any of those engine devs around these days.