26/01/2020 done:
* prepare an automated patcher to modify the very basic game files (#2) basing on some public database
It worked for all projects that were published so far. It's currently just a headless program that I need to write some pretty interface for.
26/01/2020 done:
* added server side validation for published projects
* published projects are now automatically approved on the forum. This also applies to any comments. Projects still need to be reviewed ofc, but the content is visible to everyone immediately
25/01/2020 done:
* implemented the new db format -> New database format in the editor and its possible benefits
* auto-save interval lowered from 15 mins to 5 mins
All changes in the editor are now saved incrementally, which means there will no longer be a case where your data is somehow lost -> if you remove all your work from a project and press save, the server will still keep your previous data. Basically speaking, a project is now just a log of your actions. One log entry could be adding an NPC, then another entry - removing the very same NPC.
There's no longer a need to "load" a project. Each project has a unique URL for editing, which also means you can modify multiple projects at once with multiple browser tabs.
The Russians are recompiling PW from sources (which are available online btw), so they can modify absolutely everything. I'm staying away from those sources, because the code is terrible as in any chinese MMO game, but I used them as a reference when developing that TAB-select hack for older PW versions.
Maybe those prices are somewhere in data files and I just haven't seen them yet. We'll have to see.
I originally suggested making everyone start at higher level (20 or 30), because those early levels are very tedious and in most cases you have to play them alone. Even if you come to the server with a friend, he'll probably pick another class and you won't be able to play together right away. I usually join a server just by myself and the first levels are unpleasant necessity that I need to go through. If we make everyone start at level 20 in archosaur, they will immediately see other players, because there's always someone in archo (whether high or low lvl). Also the quest chain and grinding spots would be also the same for all classes.
I guess people would also immediately notice the server is customized, because they probably expected to spawn in their corresponding cities.
Increasing XP rewards for culti quests 1-20 so that lvling up takes 20 minutes is also doable, but I wonder why would anyone want to go through that 
As for the starting gear - yeah, sure. We could provide some, as well as a bunch of potions, some coins for repairs, a pickaxe, etc. I was thinking we could give all that as a reward for some introductory quest. Same for veno books and some starting pet.
As far as I remember, PW has something like a character template for each class. We can play it just like any character, move it some spot on the map, give it some gear, level, culti, and son. Sky is the limit.
Closed.
Interesting
modify mobs outside arch to drop it
I like that the most. Giving everyone lvl4 craft is cheap, and using a 19 cave just for mats sounds like an overkill.
I did some bugfixing today.
12/01/2020 done:
* projects will only auto-save if there were some changes done (the revision counter in the project list won't go up by itself anymore)
* editing read-only projects will constantly give you a warning notification (not intrusive, but noticeable - it says your changes won't be saved anywhere)
* added version number to the bottom left corner of the screen
* loading a project from a pwmirage.com/map/?db=* url will now remove the ?db=* part from the url, hence showing you the actual project you loaded, not the one in URL
* cleaned up the map code
This would also allow for editing multiple projects at once (in different browser tabs, that is). Since most of the data would be stored server side, and the client will only need that last (unsaved) changeset, which can't be too big.
I already know the editor will need some major refactor in future and I'm currently trying to design it in a way that gives us the most features and benefits.
One issue with the current design is that object IDs are unique only in a specific project. When I add two different projects into the game, they can both add e.g. a completely different NPC, but with the same ID. Those projects didn't know about each other so far, so there was no way for them to pick a globally unique IDs. I'm currently using a cheap workaround in the backend to solve this problem, but it won't do in the long term.
One idea is to give each project a unique range of IDs to use. Currently the game has about 30k objects, and the highest ID is 30k-ish (because there are some holes). The highest ID allowed by game is 2bil, but in the editor we don't have any limitations. In the editor we could always allocate IDs greater than that, then in the backend, when applying the project onto the game files, check if it's > 2bil and pick a normal id for it instead. This would be also a nice indication of whether we're adding a new object, or modifying an existing one -> in the current project format it's quite hard to tell programatically. Also, to give each project a unique ID range, we could assign ids as follows: ID = 2bil + project_id * MAX_NEW_OBJECTS_IN_PROJECT.
Possible benefits of this? We could base our own projects on top of others' work. This is actually required -> we want to see content from other people that was approved and merged.
Then we have another problem that Entei has recently run into. When you do your changes thinking you're in project X, but it turns out you were in project Y, you most likely have to switch to project Y and do the same changes again. Due to autosave, project X also got all those unwanted changes and you might need to undo them manually. I imagine it can be a PITA.
Can we do better? Since projects need to be "stackable" anyway, we could consider each save (so about 5 or 15 minutes worth of changes) to be a sub-project of its own.
Then we end up with a project stack looking like this:
| Original PWI world |
| External, merged patch(es) made by everyone |
| External, non-merged patch(es) possibly from other people (applied manually) |
| Your changesets |
A changeset would be a list of modified objects. If you changed some NPC names, a changeset would contain IDs of all those NPCs as well as their new names.
After 5 minutes, the changeset gets uploaded to the server (because of auto-save), and a new, separate changeset is created.
All changesets would be stored both on the server, and locally in the browser. The user could browse all changesets and possibly revert various changes, restoring e.g. NPC's name from a certain timeslot. Or if we make a stupid change by mistake, we could just restore the state from 5 minutes before.
As for browsing changes, we could even have a nice GUI:
Since we store those changesets separately, they could be easily moved to other projects.
true. I was thinking of lower level dungeons tho
Just a rough idea. A quest to kill all monsters in a dungeon as well as all bosses within 30 minutes or so. This would probably require a full squad, but could reward you nicely. To avoid being abused with super-high-level players in party, this could be a one-time quest.
11/01/2020 done:
* if required, make changes to the editor (to be able to edit some additional stuff so that the new content is actually usable in game?)
Actually there is something important to be changed in the editor, but it's not urgent. I'll work on it as soon as I have some spare time
As for:
* setup some local development environment (so that I can modify a local test server easily, etc)
I can already test new changes very easily and the only improvement would be an automated patcher for the client, so we can consider this bullet done as well.
9/01/2020 done:
* parse files from the editor in C
* export the very basic game files (for both client and server)
The code is in place, the exported game files are not corrupted, have proper size and content, but I'll be testing them tomorrow and we'll see
In another thread there's an idea to put every player at lvl 20 from the very beginning and this means the three fb19 caves would be free to use. They're too short to be used as high level dungeons, but one of them could be perfect for this marriage cave (regardless of how strong the mobs would be).
Christmas is long gone but I like that Santa hat in the logo 
Here's a list of things to do:
I'm setting myself a deadline to finish stage #6 till the end of January. After that, I'll switch back to editor development (other maps, mob editor, etc)
So assuming everything goes well, a loose roadmap looks like this:
9/01/2020:
10/01/2020
12/01/2020
17/01/2020
24/01/2020
