[Fizban]

For large changes I usually use UltraEdit Studio to do the actual coding in and Filezilla to transfer files between my pc and the server. Though for small changes i just use pico server-side via PuTTy.

[Errigour]

Me, how do I edit files? I use midnight commander. If I had anyone working an a mud with me I would probably put a copy of the running mud on a different server in a directory that they could ssh to. I believe you can use midnight commnder with ssh but thats probably what I would recommend for anyone edting files and stuff. ctrl+o gives you a command prompt to grep -n "string" *.c if you need to find strings. forunetly with midnight commander you can paste into it and you can highlight and move stuff around in the file but you cant copy out of it so. I run into some problems on that aspect of programming. if you use youe shells F1 threw F6 you can use the ctrl+insert to copy i believe and shift+delete deetes anything highlighted. also if anyone knows anything about hex midnight commander comes with F+3 file viewer that you can select to view the hexidecimal aspect of some files and even edit the hex values
whic some people find useful. I still can't even cheat on rom save files.

relik muD
relik.ath.cx port:2001
I could use some help if anyone likes
what they see and wants to be a part
of a circlemud base mud.

Welcome to Necromium!
necromium.com port:4000
I play here frequently, Its
one of the coolest circlemud
base games Ive seen.

[noodles]

Reading this thread brings back a lot of memories about a variety of different ways in which I have edited source, and the environment and ways in which myself and my fellow coders have had to work.

Initially I worked on an LP MUD and the typical workflow was to edit files locally in whichever editor was available from wherever a coder was logged in, pasting in the file when the changes were complete. There was also an FTP server (which was pretty standard) and coders could upload files through that. This was cumbersome however as development had to be done communually on either the main game server, or the development server. The coder could easily make a typo which would introduce problems, requiring some way of reverting the changes (which hopefully they had manually backed up). Or the changes could clobber concurrently made changes by a fellow developer. Both of these situations occurred often.

This drove the MUD source code to be provided to coders, who could work on a local copy of the MUD. Development was now much more convenient. The problem of unreliable changes being put in place was lessened, but the clobbering problem remained.

Now I work on a MUD written in C. The code base is stored in a distributed version control system, where a central branch is used for the live version of the MUD. A process monitors the central branch and when a change is committed a new MUD server is automatically built.

The process runs a set of unit tests exercising the reliability and the stability of the compiled code. If there are failures, the changes are reverted and a notification email containing the relevant details (including the name of whomever checked it in) is sent to the developers mailing list. If the unit tests pass, it next runs the functional tests. These simulate use of the server by players, doing everything from creating new users, attempting different forms of movement through to staging combat and so forth. If this fails, the same thing happens as does for unit test failures. If it succeeds, then tentative server deployment starts.

The new version of the server is run, however it does not accept connections yet. What it does do is connect to the proxy server, notifying it that a new game server has been started and its version number. The proxy server then asks the existing game server to pause (notifying the players that a server upgrade is in progress), at which point the game server serializes the game state and hands it back to the proxy. The proxy then hands it to the new server, which attempts to fully recreate it. If the new server fails, it notifies the proxy and exits. The monitoring process detects the unexpected exit and processes the output, doing the unit/functional test failure activities, after which the proxy server resumes activity on the old game server.

If the new game server successfully recreates the state it was handed in a paused state, then it notifies the proxy which then proceeds to channel its connections to the new game server, and decommission the old server.

Anyway, back to editing. People can use the editor of their choice locally on their own game server running from their local branch. They can at any time engage the unit or functional testing locally. No more clobbering of changes made by others, except through sloppy merging. Coders are expected to have run the tests locally before checking into the central branch.

[locke]

When doing major things to the code, I use Komodo Edit.

When I'm just tinkering or debugging, I use nano and I SSH onto the actual server.

You'd be better off using the Git/SVN -> editor tool chain. This is a common collaborative programming setup where one site hosts various versions (dev/live or debug/release) and you check files in and out using svn (cross-platform).

[dentin]

Subversion via SSH for code synccing between dev and production boxes.

VI at console terminal for editing. F1-F3 typically for general .c/.h file editing, F4 for compiling, F5 running a GDB session for test, F6, F8, F9, and F10 with telnet sessions for test as appropriate, F7 for notes and todo list. F12 is admin link to production server.

The Linux console terminals are in mode 307, 1280x1024x8. The resulting text console size is 160x64, which works really well for editing.


-dentin
Alter Aeon MUD - An Online RPG

[Pymeus]

I also use mcedit (the built-in editor for Midnight Commander), either locally or remotely. It's a simple interface relative to most text-mode editors and the syntax highlighting is much more visible than others I've dealt with. I've never really used Midnight Commander itself, oddly enough.

[plamzi]

Version Control System: SVN (Subversion server for Linux)

Text Editors:
VIM for quick changes
InType or Eclipse on Windows
XCode on OSX

[Markov_AU]

We use SVN for source control now (recent development) and I'd like to pitch a windows based tool I used some too for editing, Teratext editor, it's made by some Russians I believe lol

[Vatiken]

I use geany to edit source and I transfer files using simple click&drag in Ubuntu.

[Vandread_TSOS]

I use Visual Studio 2010 (Pro, I use it with work, so I didn't need to get a copy just for the mud) and it gives me some great features like the intellisense which make development so much easier.

I also use the AnkhSVN add-on for it and have SVN on our ubuntu server for version control so the asst coder and I can work at the same time without worrying about overwriting each other's updates.

All in all it makes for a pretty easy development environment and it works really well. Unfortunately 2010 express doesn't support add-ons so you need at least the pro version, but there are other ways to acquire fully functional copies through the trial version.

[Trip]

Microsoft Visual Studio 2008 now, and before that Microsoft Visual C++ 6. Compile it and ftp it to the mud server. But we're on a windows box. On those instances where I've worked on other muds who were on linux, Usually just use Ultraedit and load and save the file directly from/to the server using the built in ftp integration.

[Pymeus]

We've found version control to really be a critical tool. Not only does it help us coordinate the efforts of multiple coders, but it's extremely comforting to know that we can step our code back to virtually any point since version control was implemented. It can also expedite tracking down new bugs; running a few diffs will tell us exactly what's changed lately.