new to C++

I'm thinking learning C++, and I figure it would be a "great" test to write my healing system for the mud, Achaea, in it. Basically I figure I could "interrupt" the incoming data from the mud and do what I would need to do based on it.

Does anyone have any suggestions for this?
Pro's/Con's?
Suggestions for tutorials specific to this sort of thing?

I figure if I did this, anyone with any kind of client could use my system.

Thanks, sorry for the newbie question!

C++ is a great language to learn, and is fairly easy to pick up if you already know C. So I'd definitely recommend learning it.

But I'm curious what you mean about C++ interrupting incoming data. Are you talking about writing a proxy that sits between your client and the MUD?

In that case, in addition to knowing C++ as a language, you'll need to read about sockets. It's a pretty ambitious project. You shouldn't start with it straight away, but with much smaller hello-world type things. Then you can write a program that opens a socket and talks to a clone of itself, sending ABCs back and forth. It's really important to get the basics right.

The problem about this kind of program is that it needs to be very, very precise and exact. Any kind of error can affect the data going to or from the MUD, sometimes subtly, sometimes so much that it will completely mess up your play experience.

Yeah, this was going to be more of a background learning project heh. Sorry to infer that I already knew C, I don't :/

That's ok. C++ and C are extremely similar. C++ has a lot of subtleties having to do with classes and templates but generally speaking if you know one you can program in the other. (This statement is very true in the C++ to C direction. A C programmer can also write "C++" but it won't take advantage of some of the stuff C++ gets for you.)


You should probably just google for C/C++ tutorials and see some small example programs. One of the most common mistakes is for someone to try to start too big, get in over their head, and come out feeling frustrated without having learned much. If you start small, you will learn more, faster and better.

So I would start with hello world programs. Figure out how to write stuff out in C++. Then figure out how to read stuff back in from the keyboard. Put those two together, and read/save files. All this is useful information for sockets, by the way.

Then you might want to think about sockets. First you might have to understand a bit about how sockets work in general. Actually, doing files the C way might be helpful: sockets are dealt with using the more traditional read/write bytes approach than the C++ way of hiding a lot in stream operators (the << and >> you will see).

To summarize, I cannot emphasize enough how important it is to start small and work your way up.

Yeah I just wish I could do something enjoyable as practice. Like when I went to go learn Lua, I translated my scripts and stuff from vbscript into lua, and that was an enjoyable way to learn it heh. Wish I could do the same for C++

Well, without knowing what you find enjoyable, I can't really give suggestions for what to start with. :) The application you suggested (a network proxy for MUDs) is not that complicated but will require that you understand something about sockets.

Why don't you think about some smaller things you might enjoy doing? Then we can talk more about how to actually go about doing them, or if it's feasible.

But there's no way around it: with a language like C/C++, which is inherently more syntax-heavy and complex than Lua (the beauty of which is in its syntactic and (apparent) conceptual simplicity), you are going to have to sit down and do homework at some point, like it or not.

Oh trust me, I never said I had a problem with doing the homework. I've definately been reading over my "C++ from the ground up" book I stole from a friend a couple years ago and never put to use *g*

Also, after some long term thinking (I know! It's premature at this stage), would it be easier not to act as a proxy, but rather just read what is being sent to mud and reply to the mud? Ah, I suppose I'll just cross that bridge when I get there heh.

Well, it's hard to answer your question without knowing what exactly you intend. Know that if you read what the MUD is sending, and just reply to it directly, then any kind of scripting/logic/whatever will have to happen in your program. If instead you act as a proxy, you can process the data sent to your player, and then do client-side scripting.

But again I don't really know what you intend to do, so maybe doing it all in C++ and having a "mini-client" is more appropriate.

Basically the idea is to wait for any incoming data, read that data, say

You have fallen to the ground.

then do something with that data, like sending stand to the mud. Then waiting for confirmation like,

You stand up.

A bit more complicated than that, but that's the general gist of what I'm hoping to do.

Ah. And are you writing this in C++, instead of using MUSHclient's system, as an exercise in learning C++, or because there is something about C++ that you think you need?

Another thing about making a proxy is that you can still play the game by using the client. If the C++ program stops all data and is in effect a mini-client, it won't let you do any further manual control -- unless of course you build that into the client.

I gather you don't want to use MUSHclient's triggers, or incoming packet handling, because this is a learning project, for you to learn C++, right?

My main comment here is that this is an ambitious project to start learning C/C++ with. Unless you are planning to make this your full client, as David says, you need to somehow route the data on to your real client (so you can see it and still walk and talk).

If you want to do something like write your own client, then you could look at my "tiny MUD client" as an example to get started:

http://www.gammon.com.au/forum/bbshowpost.php?id=2206

The frustrating thing about doing TCP/IP programming, unless you are used to it, is that most operations are not "atomic". For example, to connect a client to a server does not happen instantly, because the client starts a negotiation sequence with the server (SYN/ACK packets) which may or may not eventually establish a successfull connection.

Similarly, sending data out, or receiving it from the other end, happens at its own pace. Unless you use "blocking" protocols (which have their own problems) you basically initiate the transfer, and get notified later when it has succeeded.

The tiny client code above illustrates some of this, but you need to be aware that incoming data is not necessarily one line. So you need to do what MUSHclient does, and wait for an end-of-line (newline) character before attempting to process a line. However such a character does not even arrive in some cases (eg. when being asked the initial username/password).

well the idea behind it is so that I can continue to use Mushclient, for all of my regular stuff. But anything tied to curing would be included in this executable. So basically I could use it with mushclient as my client, but my friend joe could use it with zMud as his client. Would it be better not to "interrupt" the data sent/send to the client manually, and just let it go between the mud and client, and just read it as it comes in? I'm sure I'll have a better way of explaining what I mean when I actually learn what I'm talking about heh

Also the hope is to have some sort of graphical display for my character's status and other things I think would be neat. Long term goals, of course heh

OK, so your goal is to basically reproduce a (special-purpose) trigger system that lies in its own space, not relying on any particular client. Of course, the proxy would need to pass data through itself to the client, so that the client can still enter commands.

One suggestion I would make would be to use Lua to script your client, and then implement an API similar to MUSHclient's (you will need to talk to Nick about permission and stuff depending on how similar you make it), that way you can test the scripts in MUSHclient and then when you are satisfied, use them in the proxy.


As for "interrupting" the data, you will have to, because that is the nature of these things. You will need to interrupt it, do your trigger processing, and then pass the data on to the client. (You will also probably need a way of telling the client that you did something, maybe by adding something to the data sent to it.)

An idea like that, to have a "interceptor" between the MUD and the client would conceivably work, but be complex. You would need to maintain two data streams:



This is because the client needs to connect to your program, and not the MUD.

In the network code you need to handle things like:

• Client connects to your program
• Your program accepts the connection
• Your program connects to the MUD
• (A few seconds later) The MUD accepts the connection

Then, later on, either the MUD or the client might drop the connection, so you need to recover from that, one way or another.

Until that happens you are intercepting packets flowing each way, and handling them in the way you see fit, and then forwarding most of them to the other end.

Bearing in mind what I said before that an incoming packet from the MUD is not necessarily a single line, it might be multiple lines of output, and it doesn't necessarily end at a "natural" place (like the end of a line).



You also have a potential problem with a "go-between" program, namely this:

By having another program that intercepts data on the packet level, it is possible a message might arrive (inwards from the MUD) that seems to require some action "curing" the problem.

However in the outgoing packet stream, you might have a lengthy "tell" that you are in the middle of retransmitting back to the MUD. Thus you might send something like this:


tell Gore I think we might have to look around for another member for our group cure light wounds before we attempt to go into this cave.


In my example the long "tell" (being sent from client to server) is broken up by the intercepting program adding its own stuff (in bold in the example).



That might well simplify things a bit, but would not meet his goal of learning C or C++.

---

My suggestion is, if you want to learn C++, try a simpler project. If you want to write a curing system, write it for MUSHclient (or zMUD), don't try to do something complicated like this for a first project.

Good idea, I'll make a text editor or something instead.. after learning all the novice stuff..

Hmm... unfortunately, a text editor isn't necessarily the best first project, either! :-)

At least one good source for material is the CS106 series here:

http://cs106a.stanford.edu (Java)
http://cs106b.stanford.edu (C++)

The assignments have starter code and you can find the assignment specification in the handout section. These projects are much more suited for novice programmers.

Learning Java might not be such a bad thing, you know, because a lot of the concepts between Java and C++ are the same. (In fact, a lot of concepts are similar across all programming languages. A good programmer should be able to learn a new language in about a day, and be more or less "fluent" in it in less than a week. Of course, it takes longer than that to be truly good with it...)