Discussion on VSRO 188 CGObj::GetTID() GetDataPermanent Error Patch within the SRO PServer Guides & Releases forum part of the SRO Private Server category.
SR_GameServer.exe original file can only create up to 50,000 objects, if more than 50,000 objects are created in the game, it will show CGObj::GetTID() GetDataPermanent Error.
If you have added customized object, Itemdata or Chardata, it is very easy to get the pet summon bug.
The solution I've come up with so far is to increase the size of the object's memory.
As above ASM operation code
0x1D0 is a fixed size, the memory size of an object is 0x1D0(464), the number of objects can be adjusted.
So you only need to change the number of objects 0xC350 (50000) and memory size 0x1620100.
For example, to increase the number of objects to 5 times 250,000 objects
0x1D0 * 0x3D090(250000) = 0x6EA0500
Object Size = 0x1D0
Number of Objects = 0x3D090(250000)
Memory Size = 0x6EA0500
Patch:
Code:
0054D609 B8 90D00300 mov eax,0x3D090 ; Maximum number of objects 50000
0054D61C C746 20 90D00300 mov dword ptr ds:[esi+0x20],0x3D090 ; Maximum number of objects 50000
0054D654 68 90D00300 push 0x3D090 ; Maximum number of objects 50000
0054D662 C700 90D00300 mov dword ptr ds:[eax],0x3D090 ; Maximum number of objects 50000
0054D6D8 81FB 0005EA06 cmp ebx,0x6EA0500 ; (OBJ MaxNum * 0xID0)
That way, it is already being laggy before it reaches 50k, I believe it will be more laggy if we increase it and go over 50k, thanks for sharing anyways, it might be useful to someone ♥
Use SRO_VT_SHARD
declare @minLevel int = 1 -- Minimum mob level.
declare @MaxLevel int = 110 -- Maximum mob level.
declare @MaxSpawnCount int = 9 -- Spawn rate (Max. 10 )
update Tab_RefNest
set dwMaxTotalCount = @MaxSpawnCount
from Tab_RefNest as A
inner join Tab_RefTactics as B
on A.dwTacticsID = B.dwTacticsID
inner join _RefObjCommon as C
on B.dwObjID = C.ID
inner join _RefObjChar as D
on C.Link = D.ID
where D.Lvl between @minLevel and @MaxLevel and CodeName128 like 'MOB%' and Rarity = 0 and dwMaxTotalCount > 0
Some monsters (I don't know which ones, or if the 100.000 is the limit) crash the GS if you spawn too much of them so be careful.
Amazing thanks so much, been looking for something like this
Quote:
Originally Posted by *Deadly
That way, it is already being laggy before it reaches 50k, I believe it will be more laggy if we increase it and go over 50k, thanks for sharing anyways, it might be useful to someone ♥
Actually not. It's only laggy at high object counts if there are a high number of players spread across the map, all at different points/ranges surrounding all of the monsters - aka if there are a large number of MOB/NPC/COS objects surrounding real player characters.
You may notice that when you spawn a huge number of objects in one location, the GameServer has a high delay, but when you move a decent distance away from those objects & nobody else is around them, the effect is minimal and there is essentially no delay above normal.
Joymax was actually smart (I hate to say it) with the AI system/implementation of resource management with the object data. If there is no player character in range of the npc/mob object, all actions such as animations, pathfinding movements, etc. are disabled and essentially the object is frozen in place until a character/pet comes in range of it. (I don't know if this is also the case in WorldIDs higher than 1 or dungeon regions, but I doubt it would be any different). This saves a ton of resources on the server-side and helps prevent unnecessary loads.
This is why you'll tend to see much lower object counts causing much higher delays on live servers compared to development/test environments.
- But yes, I would 100% say you should NEVER use this release in a live environment to prevent such stuff, only for testing - it's very risky otherwise. Those limits are there for a reason. Joymax did not design the architecture to support stress on the modules past a certain point. Similar to how exceeding the 3500~4000 real player limit will/may cause weird issues & delays over time, violating and exceeding the mob type object count will have a similar effect.
Even if you don't experience additional delays, the chances you'll run into a runtime error/random crash is significantly higher. Better to be safe than sorry - just because you can do something doesn't mean that you should.
This.
I get a runtime error once I spawn more than 100.000 monsters. I let the spawns at 93k and I'm loving it so far!
Also, speaking of monsters- have you noticed that, if you stand still around the (passive) monsters they will slowly walk out of your character distance and you're left alone?
I think this is so you don't stand still in one spot.
Or perhaps some anti-bot feature.
A little annoying, wish I could remove that.
Use SRO_VT_SHARD
declare @minLevel int = 1 -- Minimum mob level.
declare @MaxLevel int = 110 -- Maximum mob level.
declare @MaxSpawnCount int = 9 -- Spawn rate (Max. 10 )
update Tab_RefNest
set dwMaxTotalCount = @MaxSpawnCount
from Tab_RefNest as A
inner join Tab_RefTactics as B
on A.dwTacticsID = B.dwTacticsID
inner join _RefObjCommon as C
on B.dwObjID = C.ID
inner join _RefObjChar as D
on C.Link = D.ID
where D.Lvl between @minLevel and @MaxLevel and CodeName128 like 'MOB%' and Rarity = 0 and dwMaxTotalCount > 0
Some monsters (I don't know which ones, or if the 100.000 is the limit) crash the GS if you spawn too much of them so be careful.
Result:
Maybe, try 75,000 - 100,000.
Usually there are new Itemdata and Chardata added, or the map has a Christmas tree set. This will cause a TID ERROR
I've been tracking this code, and since it creates blocks on startup to determine the size of the object memory blocks, this is the only way I can do it for now.
I'm sure he'll be useful, after all no one uses the original VSRO 188 these days.
Maybe, try 75,000 - 100,000.
Usually there are new Itemdata and Chardata added, or the map has a Christmas tree set. This will cause a TID ERROR
I've been tracking this code, and since it creates blocks on startup to determine the size of the object memory blocks, this is the only way I can do it for now.
I'm sure he'll be useful, after all no one uses the original VSRO 188 these days.
Hello dear,
Why change size?
I can open game server -> 1 2 3 4 5 6 7 8 9 (Solution)
The performance is better than changing the size
The files version is quite old, so it doesn't make sense to exceed the limit. If we had used it as 64 bit, it would have made sense to exceed the limit.
[Selling] 188 Million gil on ODIN from me private. you can get 10-188 million Gil 12/16/2015 - Final Fantasy Trading - 0 Replies Hello i selling private 188 Million Gil. you can get 10-188 million gil per buy from me if there is no more gil i am sold out. Send me an pm if you want gil and a price what you will give me. Or you can post here in this topic.
Paying with Paypal.
VSRO 188 CGObj::GetTID() GetDataPermanent Error Patch
