Load warp list from warpinfo.tbl

[stevewgr]

Description

Note that warp list information is loaded from SMDs. This isn't great and makes editing difficult, especially because it's in binary format.

Tasks

• [ ] Add warpinfo.tbl to ko-assets where its content matching the ones with our existing SMDs
• [ ] Load warpinfo.tbl in the client
• [ ] Implement listing warp info based on what is in the tbl
• [ ] Remove from the server sending over warp info to reduce packet size

[xGuTeK]

For now i wont share it but i mark as completed, i will mark as completed to nobody doing it

anyway we need to rewrite server files

[ko4life-psko]

I remember doing this in another project I helped out couple of years ago, where I wrote a parser to the map files in the client that collects all objects that has events and generate SQL queries to create records for WARP_INFO, as well as for K_OBJECTEVENT. I might look it up and share, but as I mentioned privately to @stevewgr, I'm currently quite busy to work on a fun project on the side, so I'm only helping in the background in case of any questions.

Keep up the good work!

For now i wont share it but i mark as completed, i will mark as completed to nobody doing it

anyway we need to rewrite server files

You could also assign yourself to this ticket instead of closing, to not give the wrong assumption as if it's already fixed. I will leave this up to you and @stevewgr.

[xGuTeK]

I did this to for object event and renengevt too. You didn't have to write a prasser old source have own functions to read it u can easlily add it to database from smd. Client format have too much object position like trees etc and its not needed to store in database. Old ko servers 1098 loaded it from database too.

And good point about assign :)

[ko4life-psko]

You didn't have to write a prasser old source have own functions to read it u can easlily add it to database from smd.

I unfortunately did. There was a discrepancy in the data between the server SMDs and client files (Zones.tbl and *.OPDs). Therefore parsing the client files to check every object-event 100% guarantees that positions, events and ids are exactly the same in the client, server and db.

Client format have too much object position like trees etc and its not needed to store in database.

Trees are not object-events. I suggest checking N3ShareMgr.cpp for more context.

Old ko servers 1098 loaded it from database too.

That I know, and for w/e reason Mgame decided in later versions to hard-code the data inside the binaries -> SMDs.

[xGuTeK]

this data from beginig was in smd but some version maybe tw or kr decided to make it loaded from db thats why old 1098 have it

there is no such file with that name

if u mean object like warps gates etc its loaded from smd too and now i loading it by database and this kind of object need to have same position in client

[ko4life-psko]

there is no such file with that name

Sorry, not N3ShareMgr.cpp, rather N3ShapeMgr.cpp. I suggest namely checking this: https://github.com/ko4life-net/ko/blob/0a716c9d/src/engine/N3Base/N3ShapeMgr.cpp#L227-L230

As well as this: https://github.com/ko4life-net/ko/blob/0a716c9d/src/game/GameProcMain.cpp#L2782-L2799

Coming from this enum: https://github.com/ko4life-net/ko/blob/0a716c9d/src/game/GameDef.h#L1445-L1453

Note that later versions have added more object-events:

enum ObjectType
{
    OBJECT_BIND       = 0,
    OBJECT_GATE       = 1,
    OBJECT_GATE_LEVER = 3,
    OBJECT_WARP_GATE  = 5,
    OBJECT_BARRICADE  = 6,
    OBJECT_ANVIL      = 8,
    OBJECT_ARTIFACT   = 9,
    OBJECT_NPC        = 11,
    OBJECT_ANIM       = 50
};

I believe Anvil will be relevant for this project soon.

if u mean object like warps gates etc its loaded from smd too and now i loading it by database and this kind of object need to have same position in client

Yes, this is what I said above.

[xGuTeK]

Anvil is not needed so far I think that we will fix the loading of some new files first and a few client fixes and then you will have to rewrite the whole server files and then do anvil. And it seems to me when we make an anvil, a lot of people will start to be a leecher and start working privately

[JanekCode]

Anvil is required many work? I didnt see that. Ok so jest move will be a server files?

[xGuTeK]

it isn't present in this version, so it requires a lot of work

lets move this conversation to discord

[stevewgr]

Great discussion and Anvil is definitely something we'll need to look-out for sooner or later. However I agree with @xGuTeK that it's currently not in priority, since there are more important things to accomplish before we add new implementations, like fixing missing implementations in the UI system and everything else that is currently in the backlog.

@ko4life-psko, as for the warp gates parser, if you could share with us when you find time, that would be super helpful. I can probably write one too, but just to save the effort. I also agree with your approach. It's better to generate this data based on client files. This helps keep things synced and prevent unnecessary debugging, in case Event ID was wrong in SMD in comparison to client.

@xGuTeK, I also agree with @ko4life-psko about keeping tickets open unless the fix is in the master branch. If you agree, could we open this ticket so we have a better overview on the current state of things?

[xGuTeK]

Stave i have opd reader and we dont need that praser ;)

[stevewgr]

anyway we need to rewrite server files

@xGuTeK, curious question, maybe I'm missing something, but what do you mean rewrite the server files? As far as I saw from the 1310 server files binaries in the decompiled code, not much was changed on the architecture level. It's just added functionality. Even structures look the same, just with new fields. Of course for Anvil we'll have to implement the UI system, as well as writing the Upgrade handler, but that's for another topic. I believe a rewrite is not needed here.

[xGuTeK]

Like u told some of duplicated shit and stupid logic here and think we should rewrite some functions and whole thing go clean it will be better and also add support to linux some other database server i think its better to rerwrite and deleted unesecary code

[stevewgr]

Like u told some of duplicated shit and stupid logic here and think we should rewrite some functions and whole thing go clean it will be better and also add support to linux some other database server i think its better to rerwrite and deleted unesecary code

Ahh...I see what you talking about. That's refactoring, not rewrite. I got scared for a second haha... 😨 Yes, that for sure we'll do, but functionality wise the server files are okay to work with I would say.

[stevewgr]

@xGuTeK, could you please write here an update what's the current progress and whether we should expect for a PR?

[stevewgr]

Note that we don't want to do this in the database just to reduce transmission over the network of warp info. I'm saying this, because I noticed in newer clients they changed to use warpinfo.tbl. This said, I suggest we implement it as per official and load warpinfo.tbl.