search

DarkCastleMUD / DarkCastle

Dark Castle is a text-based MUD (multi-user dungeon) that was originally based on DIKU MUD around 1995. It has been running since then.
https://www.dcastle.org/
GNU Lesser General Public License v2.1
12 stars 11 forks source link

Fixed some typos, removed files that are being gitignored and touched up vscode configuration #194

Closed jonjelinek closed 2 years ago

jonjelinek commented 2 years ago

Fixed typo in funnybootmessages Removed leaderboard.txt and onlinewho.txt so .gitignore rules are respected as these files are generated during runtime Touched up vscode configurations to include more options and recommend extensions on initial load up

jhhudso commented 2 years ago

Not sure I agree with all of these vscode changes because there are two ways of running DC. The traditional method is to be in the lib/ directory. The other method is to pass -d and a directory where lib can be found.

I use the traditional method when I want to test DC with what a non-immortal whom has git checked out DarkCastle might have access to. Also I use this method when I want DC to start up as fast as possible in valgrind because the git version of lib contains very few mobs, rooms, objs, etc. There are more errors when running DC like this without all the real DC mobs, rooms, objs because there are VNUM references in code to files not included in git. Eventually I'll add a function to replace missing VNUMs with a placeholder mob/room/obj or depending on the missing VNUM choose to upload it to git too.

I use the -d method when I want to start a debug version of DC against an rsync'd copy of the real DC 6969 or 6666 with all players, objs, rooms, mobs, etc. This does take longer to boot -- especially in valgrind -- but allows me to test issues with real player files, non-shared rooms, objs, mobs, etc.

So both methods need to remain because they serve different purposes for debugging.

Most of the other things you suggested in this PR I agree with and will try to merge Tuesday.

jonjelinek commented 2 years ago

I debated on separating out these changes to their own PRs as the .vscode config could have easily been in their own.

When you get a chance to review today, please note that I did not remove your original configuration run methods. I suspected you were using them as you described above and only moved them down the list with an updated name indicating which -d dir they were targeting.

image

I added two new options at the top of the list:

(gdb)(../lib) Build and Launch (gdb)(../lib) Debug Build and Launch

These two options will build the project using 32 threads. This was mostly for me as I noticed on my laptop attempting to build with the current default of 128 threads caused noticeably longer build times. We may be able to grab the number of cores a system has and just use cores*2 threads for builds in the future, but I wasn't able to figure that bit out for this PR.

There is also a player check for a player named Dummy in ../lib which is just a modification of your Julian test below.

(gdb)(../lib) showplayerxp ../save/D/Dummy