Gammon Forum : Programming : General : new to C++

Register forum user name Search FAQ

Gammon Forum

Entire forum

Programming

General

new to C++

new to C++

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2

Posted by

Gore (207 posts)

Date

Thu 08 Feb 2007 12:40 PM (UTC)

Message

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!

Posted by

David Haley USA (3,881 posts)

Date

Reply #1 on Thu 08 Feb 2007 05:44 PM (UTC)

Message

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.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Gore (207 posts)

Date

Reply #2 on Thu 08 Feb 2007 11:41 PM (UTC)

Message

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

Posted by

David Haley USA (3,881 posts)

Date

Reply #3 on Fri 09 Feb 2007 12:33 AM (UTC)

Message

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.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Gore (207 posts)

Date

Reply #4 on Fri 09 Feb 2007 02:32 AM (UTC)

Message

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++

Posted by

David Haley USA (3,881 posts)

Date

Reply #5 on Fri 09 Feb 2007 03:19 AM (UTC)

Message

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.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Gore (207 posts)

Date

Reply #6 on Fri 09 Feb 2007 03:47 PM (UTC)

Amended on Fri 09 Feb 2007 03:49 PM (UTC) by Gore

Message

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.

Posted by

David Haley USA (3,881 posts)

Date

Reply #7 on Fri 09 Feb 2007 03:52 PM (UTC)

Message

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.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Gore (207 posts)

Date

Reply #8 on Sat 10 Feb 2007 12:30 AM (UTC)

Message

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.

Posted by

David Haley USA (3,881 posts)

Date

Reply #9 on Sat 10 Feb 2007 02:51 AM (UTC)

Message

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.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #10 on Sat 10 Feb 2007 03:36 AM (UTC)

Message

Quote:

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.

...

Sorry to infer that I already knew C, I don't

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).

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Gore (207 posts)

Date

Reply #11 on Sat 10 Feb 2007 12:55 PM (UTC)

Amended on Sat 10 Feb 2007 01:01 PM (UTC) by Gore

Message

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

Posted by

David Haley USA (3,881 posts)

Date

Reply #12 on Sat 10 Feb 2007 04:05 PM (UTC)

Message

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.)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by Nick Gammon Australia (22,975 posts) bio Forum Administrator

Date Reply #13 on Sat 10 Feb 2007 07:47 PM (UTC)

Message

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:


Incoming from MUD    --> your program --> to normal client

Outgoing from client --> your program --> to MUD

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).

Quote:

... anything tied to curing would be included in this executable ...

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).

Quote:

One suggestion I would make would be to use Lua to script your client ...

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Gore (207 posts)

Date

Reply #14 on Tue 13 Feb 2007 07:29 PM (UTC)

Message

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

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

45,499 views.

This is page 1, subject is 2 pages long: 1 2

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )