Using Visual Studio 2019 to debug commands

I've come here with this question because I can't seem to make "non-gamers" understand what I'm asking for. Nick, I know you have extensive knowledge of this code and no one will dispute your developer prowess so I'm hoping you'll have an answer for me.

Here is a link to the question I asked on MS Forums:
https://docs.microsoft.com/en-us/answers/questions/523213/trying-to-debug-a-mud-game.html

Here is a link to the question I asked at cplusplus.com:
http://www.cplusplus.com/forum/general/279593/

I hope you all will understand what I'm looking and have a way to address it.

Thanks

I understand your question, but you don't have to run the .exe from a DOS prompt.

Just run in "debug" mode from inside Visual Studio. It should just then run (and you would see the output in the output window). You can then place breakpoints where required and the code would stop at that place.

The responses you got off-site appear to be saying the same thing. If that isn't clear please explain in what way it isn't.

To put the above question into context on this forum, it was:

I’m using Visual Studio 2019 to build a MUD (a text based game popular in the early ’90’s). I’m trying to figure out a way to “play the game” and watch the code execute while I’m doing it. And by “play the game” I mean enter a command like “cast ‘acid blast’ goblin”, set a break point in the code where that command is initiated and then step through the code line-by-line and see the output as it shows in the game. Yes, I realize I might have to step through 90 lines of code before I see output but that’s the point. I want to see how a particular command is executed.

The problem I’m running into is the game as it is runs from an executable created when the code compiles. I run the .exe file from a DOS prompt and the game runs in the background. I connect to the game from a MUD client and play the game that way. I can enter “cast ‘acid blast’ goblin” in the game client but I can’t see the code at that point. I need a way to start the game from VS and be able to enter commands and watch the code while it executes in VS.

Do you guys know how to do that?

OK that's a little clearer to me but I still don't know how to enter a command. On MUSHClient I just type "cast 'acid blast' goblin" at the input. Where do I do that in the debugger?

You seem to be misunderstanding how MUD games work. The thing you compile in Visual Studio is the server. You still need a client (such as MUSHclient) to use it, regardless of whether you are using a debugger or not.

So, you start the server in Visual Studio (in debug mode if you want to enter breakpoints).

Then you start MUSHclient as usual, and connect to your server which you are debugging (eg. localhost port 4000). Then in MUSHclient you type "cast 'acid blast' goblin" in the usual way. If you have your breakpoint set up correctly the the server will stop at the appropriate line, and you can step through and see what is happening.

This, I think, has been the downfall of my entire line of questioning. I understand the server side/client side of the game. I know MUSHClient is the client side. However, I use the .exe file created during compile to start the server side which runs in a dos window. I don't know how to "run" the game in VS. This is what I've been trying to figure out this whole time. When I run the executable I connect to 127.0.0.1 port 4000 (as you said) with MUSHClient. But I can't see the code this way because the game is running in a dos window. How do I start the server in VS as you're suggesting?

One of the menu items in VS is "debug" (F5). That runs the code in its debugger. You don't run the .exe from the command line, you run it from inside VS.

I did not realize that the debugger ran the program in the background. Very helpful. Thanks Nick

I've tried what you suggested but I am still having no luck. When I run the debugger it runs the entire code and then exits immediately. So there's no game running on the server side.

https://d.pr/i/yIT4qQ

What I envision needs to happen is to start the game in VS using debugger which starts the server side (but doesn't immediately close). Then opening a DOS window to "connect" to the game somehow and use that as the client to interact with the game. Am I thinking about this right?

Of course, if that is the case then I should be able to use MUSHClient to connect to the server side code running in VS, right?

Your problem is almost certainly that you are debugging in the wrong directory. There is a configuration option for what directory to use when running/debugging.

Here is where you change it (I think - untested):





So, you change "$(ProjectDir)" to wherever you normally launch the server from.

If there are arguments you usually put on the command line (when running from a DOS window) such as the port number, put that into "Command Arguments" section.

Then opening a DOS window to “connect” to the game somehow and use that as the client to interact with the game. Am I thinking about this right?

Not quite. Forget about a DOS window. You run the debugger in Visual Studio which (after you get the directory right) will sit there seemingly doing nothing. Any messages you normally see in the DOS window will appear in the message part of Visual Studio.

Then you connect to the server using MUSHclient in the usual way.

Now if you want to debug a particular part of the code find that line in Visual Studio and put a breakpoint on it. Then execute the thing in MUSHclient that would send the code through that line. You should then see the breakpoint in Visual Studio (and MUSHclient will become unresponsive because it is waiting for a response) and you can look at variables and things.

An alternative is to run the code exactly how you used to (in a DOS window) and then use Visual Studio debug menu "Attach to Process" which you can see in reply #11.

That then finds the process (I think it gives you a list of running processes and you choose the right one). Assuming you have debug information in the .exe file (because you did a debug build) then you should be able to debug, the same as if you started the debugger inside Visual Studio in the first place.

However I think it is easier to start from inside Visual Studio, assuming you keep making changes to the code. Change the code, recompile, hit F5 to start debugging, and connect with the client. Pretty simple really.

If you've set up the client to reconnect with the right player name and password when you hit <Enter> then the whole debugging session can start up in seconds.

I changed the path to the directory containing the .exe file that runs the mud. Still didn't work. Closes out immediately.

From your link in your earlier post: https://d.pr/i/yIT4qQ

It doesn't close *immediately* - it closes after logging quite a few lines. What lines did you see this time?

Have you ever run the suggested startup with --creatdirs in it?

Yeah sorry. I realize I could have been a lot more helpful in the last post.

So I added the "--createdirs" command line argument like you suggested. That worked but then it closed right after that.

https://d.pr/i/SmRJSi

But this is what happens when I start the mud outside of VS. I do 'dawn --createdirs' which creates all the directories. Then I'm back at the prompt where I type 'dawn' and that's what actually starts the mud. (There are pics of all this in the start up doc I sent you for reference).

BTW, how do you post images here?

You don’t post pictures here unless you are an administrator. Too much abuse for me to worry about tracking down. (It has always been like that). I suggest https://imgur.com/ with an image marked “private” so people don’t browse to it.

As for what you did, OK, now you need to remove “--createdirs” from the command line, and it should run. You just do --createdirs once to make the directories.

It said so on the image you posted:

“Start the mud normally to continue.”

BTW, you don't need to take a screenshot of text like you did, and then worry about how to find somewhere to host that image.

Just copy and paste the actual text you saw. That's easier isn't it? Then I can copy and paste lines of interest rather than having to retype them.

Put text you copy and paste into code tags.

I think we're getting close. check out the two files below. The first one is the one I ran through VS. The second one is the one I ran through a regular cmd prompt. When you get the end of each file at line:



it says they both compiled and basically "work." But when we get to:



VS closes out and the regular command prompt starts the mud as intended.

VS debugger



Command line prompt

Well, you have a debugger, time to start debugging.

I notice you are using two directories for some reason:

C:\Dawn Of Time\dawn

and

C:\Dawn Of Time\DAWNTEST

Is there a reason for this? If you can get the command-line version running in "C:\Dawn Of Time\dawn" then that eliminates the possibility that it is something about the directory.

A possible explanation is that debuggers tend to zero out memory, whilst the executables don't. So, a variable somewhere might be considered zero in one case and <some random value> in the other. In other words, a bug in the code.

C:\Dawn Of Time is the original directory I started with. I kept it running since it was a working version I could refer to while trying to figure this all out. I used dawn and DAWNTEST for testing. Basically, just booting from scratch to try different trouble shooting techniques. Testing in those directories works just fine, though.

I'm not entirely sure I follow you on the debugging part, though. The code works. It builds and compiles with no warnings nor errors. And if it will boot from the command line it should boot from VS. I do get the part about VS processing the code differently. But the VS output clearly states the boot was successful, it just closes out instead of continuing to run in the background.

I'll do a compare on the two outputs from top to bottom and see if I can find any differences there.

I can see quite a few differences. For example, what happened to the ":: Free stringspace =607349." message?

You need to put a breakpoint at (say) the message ":: PlatformID: WindowsNT v6.2.9200 []" (or the code that generates it) and then follow on to see why the "Free stringspace" message doesn't appear.

… the boot was successful, it just closes out …

Yes but it does that for a reason. The is where your debugging skills need to get to work. Working out this will help with whatever debugging you are planning to do on commands.