Jump to content

Pinned post for suggestion


can_snoxd
 Share

Recommended Posts

I think we are missing 2 pinned post on this forum https://ko4life.net/forum/10-private-server-development/

 

One for bug report/fixing focused on 1.298 or any version since there are many people works on v1453 as well (more eyes are better)

Second pinned for Item and new content suggestions request , i will do my best to cover new content but i dont know what people needs

Edited by can_snoxd
Link to comment
Share on other sites

Ahh...I see what you mean. You want it to be like some kind of Issue Tracker, i.e. JIRA, GitHub interface, TFS, Kanban etc..

You definitely bring up a good point, but the main problem I can see with this, is that we are not working in this community on some unified project, i.e. like it was at the time with the snoxd-project. That being said, reporting issues should be reported in their corresponding topics (ideally in the format you suggested). Reason is; the people in the KODev scene are usually using custom files and every issue could be caused for a different reason or by the owner's mistake.

Coming back to versioning thing:

13 hours ago, can_snoxd said:

as main bug reports for v1298 and v1453

There are plenty of versions that people are using, especially for versions 2XXX and above. The Tag/Prefix system in this forum pretty much covers this, because if you report in the Private Server Development section an issue for example in a v1298 client you are working on, sometimes the same patch/fix can be applied to other versions as well if that fix wasn't already applied.

13 hours ago, can_snoxd said:

And this topic as new content request suggestion that way it would be easier to know what people needs

Regarding this, we can give it a try. Maybe we can pin this in the Releases section and create a notification message there that shows up: "Looking for something and can't find it? feel free to suggest in the following topic your ideas: [Link to the topic you created]". What do you think?

@ReesesPieces also brings up a good point. We need to be careful with pinning many topics, because the idea behind is to make it easy for new members to know what's going on and also for us to have quick access or as a reminder. Otherwise people just don't bother reading the pinned topics, because it would be too overwhelming for new members to read much and then they just won't bother reading the actual important topics.

  • Like 1
Link to comment
Share on other sites

4 hours ago, Gilad said:

hh...I see what you mean. You want it to be like some kind of Issue Tracker, i.e. JIRA, GitHub interface, TFS, Kanban etc..

You definitely bring up a good point, but the main problem I can see with this, is that we are not working in this community on some unified project, i.e. like it was at the time with the snoxd-project. That being said, reporting issues should be reported in their corresponding topics (ideally in the format you suggested). Reason is; the people in the KODev scene are usually using custom files and every issue could be caused for a different reason or by the owner's mistake.

Thats why i said v1298 and v1453 only , we have 1298 binary files quite stable and openko project along with v1453 source code , even if we cant make a general bug report thing , we at least need an bug report for database only none of those versions has stable database. Our communty has more than enough people for testers and devs can make a stable database everyone can use we just need to snipe bugs first

 

4 hours ago, Gilad said:

Regarding this, we can give it a try. Maybe we can pin this in the Releases section and create a notification message there that shows up: "Looking for something and can't find it? feel free to suggest in the following topic your ideas: [Link to the topic you created]". What do you think?

Yes that would be great , i have tons of stuff i can reverse engineer from clients but i dont know what people needs most if people point out what we need most i can share that instantly

 

4 hours ago, Gilad said:

@ReesesPieces also brings up a good point. We need to be careful with pinning many topics, because the idea behind is to make it easy for new members to know what's going on and also for us to have quick access or as a reminder. Otherwise people just don't bother reading the pinned topics, because it would be too overwhelming for new members to read much and then they just won't bother reading the actual important topics.

That was my point when i said we only need v1298 and v1453 bug report because i know people from higher versions like v2xxx gonna ask in that topic about bugs i dont know and they are gonna pile up there without question , i see your point now. I think we must do a database bugfix sticky topic rather than general bug report because

 

Database stuff is easy to solve and most new devs uses updated databases from our releases they wont miss anything if they wont look every page of that sticky topic.

Link to comment
Share on other sites

On 9/22/2020 at 3:27 PM, can_snoxd said:

Thats why i said v1298 and v1453 only , we have 1298 binary files quite stable and openko project along with v1453 source code , even if we cant make a general bug report thing , we at least need an bug report for database only none of those versions has stable database. Our communty has more than enough people for testers and devs can make a stable database everyone can use we just need to snipe bugs first

I like your enthusiasm, but I still have difficulty in understanding where this is going and I believe it's hard to maintain in community forums. Sure we can pin this topic in the Source Projects section, but I truly believe this is one of the things that also belongs to GitHub tbh, just like the OpenKO project, like if you change some database script, people can see what you changed in the script, so they know exactly what has been modified based on X version of the database.

Just adding to that, have you ever looked into how Migration Scripts works? For example Django using Python or Ruby on Rails environment, you never change the database directly, you create and publish migration scripts that alter/update/delete the content or database structures that accumulate into incremental changes all together. That way it's also easy to revert back or give someone a plain database and they just need to run the migration scripts in one go to bring the database into the current state that everybody has. You are probably asking why? There are many reasons, the main reason is that you don't have to dump every time your current state of database and force everyone to use yours, but also it's easy to see what you changed in case there is a need to debug some issue.

On 9/22/2020 at 3:27 PM, can_snoxd said:

Yes that would be great , i have tons of stuff i can reverse engineer from clients but i dont know what people needs most if people point out what we need most i can share that instantly

I'll look into that this weekend.

I would also be happy to hear other members opinions (@ReesesPieces, @Yoshikage, @Flash, @ForcePower, @TomatoDePotato, @Janek).

  • Love 1
Link to comment
Share on other sites

I think we could make a pinned topic of the things we need to fix on database and client v1298 because we have original untouched files & database and they are good for starters but they still have so many thing bugged that are fixed and common. We could, no SHOULD Update the database/server files/client to resemble old v1298 game with most functionality working.

 

Like for example untouched files have bugged skills, procedures, are missing client files, items, zones, effects etc. Those thing are long fixed by devs but yet not released as one compete set.

 

I would be willing to spend time on such project, but we (KO4Life devs) would have to agree on what to add and what not.

 

As for v1453 there are no stable files that are trustworthy and stable, so for me this is a NO.

  • Like 2
Link to comment
Share on other sites

On 9/22/2020 at 10:24 AM, Gilad said:

Ahh...I see what you mean. You want it to be like some kind of Issue Tracker, i.e. JIRA, GitHub interface, TFS, Kanban etc..

You definitely bring up a good point, but the main problem I can see with this, is that we are not working in this community on some unified project, i.e. like it was at the time with the snoxd-project. That being said, reporting issues should be reported in their corresponding topics (ideally in the format you suggested). Reason is; the people in the KODev scene are usually using custom files and every issue could be caused for a different reason or by the owner's mistake.

Coming back to versioning thing:

There are plenty of versions that people are using, especially for versions 2XXX and above. The Tag/Prefix system in this forum pretty much covers this, because if you report in the Private Server Development section an issue for example in a v1298 client you are working on, sometimes the same patch/fix can be applied to other versions as well if that fix wasn't already applied.

Regarding this, we can give it a try. Maybe we can pin this in the Releases section and create a notification message there that shows up: "Looking for something and can't find it? feel free to suggest in the following topic your ideas: [Link to the topic you created]". What do you think?

@ReesesPieces also brings up a good point. We need to be careful with pinning many topics, because the idea behind is to make it easy for new members to know what's going on and also for us to have quick access or as a reminder. Otherwise people just don't bother reading the pinned topics, because it would be too overwhelming for new members to read much and then they just won't bother reading the actual important topics.

So far I have mainly seen fixes for the public 1299 files which is unstable for production to begin with and due to majority of us working on private sources, most of these issues doesn't exist.


To be very honest, I don't believe that anyone wishing to launch a KO server in 2020 will go with these public files at this point, but will rather look into private, up to date solution, so for the actual case use besides learning is really non-existent.

The contributions would really have to stand out, and I feel like there just isn't enough interest (and proper ASM knowledge) going around at this point, as you are very honestly, the only one here knowledgable enough with ASM, but your input (and also from others) can be equally obtained by properly asking a question on the forum. I'm afraid there won't be a sufficient reach or so called interest in this "contribution" system.

My 2 cents

 

Best,

Flash

  • Like 1
Link to comment
Share on other sites

5 hours ago, Yoshikage said:

I think we could make a pinned topic of the things we need to fix on database and client v1298 because we have original untouched files & database and they are good for starters but they still have so many thing bugged that are fixed and common. We could, no SHOULD Update the database/server files/client to resemble old v1298 game with most functionality working.

Definetly yes

5 hours ago, Yoshikage said:

Like for example untouched files have bugged skills, procedures, are missing client files, items, zones, effects etc. Those thing are long fixed by devs but yet not released as one compete set.

Thats what im aim for , 1298 server files are pretty stable atm but database is knida messy

5 hours ago, Yoshikage said:

I would be willing to spend time on such project, but we (KO4Life devs) would have to agree on what to add and what not.

I have 2 versions in my mind , first my jpko project modified if people want to use that they can other one is updated vanilla version with no custom edits just fixes

5 hours ago, Yoshikage said:

As for v1453 there are no stable files that are trustworthy and stable, so for me this is a NO.

We have v1453 source code , its far better state than v1298 on coding. I can update this alone as my secondary project since soo many people asking me to do it. Since it works on usko assets and jpko exe (gilad said our exe is jpko not simillar to usko) i say its pretty trustworthy

 

3 hours ago, Flash said:

So far I have mainly seen fixes for the public 1299 files which is unstable for production to begin with and due to majority of us working on private sources, most of these issues doesn't exist.


To be very honest, I don't believe that anyone wishing to launch a KO server in 2020 will go with these public files at this point, but will rather look into private, up to date solution, so for the actual case use besides learning is really non-existent.

The contributions would really have to stand out, and I feel like there just isn't enough interest (and proper ASM knowledge) going around at this point, as you are very honestly, the only one here knowledgable enough with ASM, but your input (and also from others) can be equally obtained by properly asking a question on the forum. I'm afraid there won't be a sufficient reach or so called interest in this "contribution" system.

My 2 cents

 

Best,

Flash

Those files was messy when they started as well , who knows maybe we switch to openko in the future when we make it stable enough instead of binaries. 

Edited by can_snoxd
Link to comment
Share on other sites

On 9/24/2020 at 9:13 AM, Yoshikage said:

I would be willing to spend time on such project, but we (KO4Life devs) would have to agree on what to add and what not.

Exactly why this all belongs to GitHub and should be version-controlled, so everyone can see what has been changed and review together until everyone accepts to merge. I personally don't want to start working on a project like this due to different priorities in life right now, however I'm gladly willing to contribute to the logistics of it and reviewing things.

By version-controlled I mean, every part of the unified project should be maintained in a separated repository on GitHub:

  • Database should be exported into scripts including the contents, despite the fact that there are other solutions out there, but they usually cost money. Another manageable way to version-control the database in a maintainable way is using the integrated Visual Studio SSDT solution for database schema development, however it doesn't include the content/data of the database. The data/content of the database itself needs to be managed separately and could be generated into scripts, so we can review what has been changed. This might sound a little complicated, but it really isn't once a proper setup is set on GitHub. Dumping .bak files to GitHub every change is not manageable and maintainable.
  • Client TBLs should be exported into some format that will be maintainable to see the changes (diffs) and capable of being imported back into TBLs, i.e. csv or even better make a simple tool to export/import into JSON format. Other files/content in the client should be rarely modified to avoid adding custom stuff. That being said, every change to the client files should be added into a patchXXX.zip
  • Server Files .ini files should also be version-controlled.

Doing all that, brings the ability to collaborate and conveniently agree what can be added and what not without too much confusion, because everyone can see exactly what's going on. KO4Life already have a GitHub page for these kinds of things. That being said, I can create the repos and give both of you full control on the repositories if you are willing to work on that.

On 9/24/2020 at 3:06 PM, can_snoxd said:

We have v1453 source code , its far better state than v1298 on coding.

Only problem with source projects, people are not investing their time to learn how to code and usually just looking for a working solution, hence most people stick to v1298, since it is the most stable version so far (in comparison to other versions of course).

On 9/22/2020 at 3:27 PM, can_snoxd said:

Yes that would be great , i have tons of stuff i can reverse engineer from clients but i dont know what people needs most if people point out what we need most i can share that instantly

It's active now. Please see here and let me know if this looks ok:

 

  • Love 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...