Skip to topic | Skip to bottom
Home
DGD

Welcome Register

TWiki Web TWiki Web Home Changes Topics Index Search


TWiki Webs DGD Main Sandbox TWiki Welcome Register


TWiki Web TWiki Web Home Changes Topics Index Search


TWiki Webs DGD Main Sandbox TWiki Create personal sidebar porn free porn

DGD.ImmortiusJournalr1.4 - 21 May 2005 - 18:35 - ErwinHartetopic end

Start of topic | Skip to actions

Immortius' Journal

A tale of one man's battle in codescape.

Introduction

Preface

Heya. This is my journal. Specifically, this is my DGD journal. Its will contain reports on my progress in creating a small high level lib on top of the DGD KernelLib. It will contain a various information on what I'm doing, my reasons for doing so, problems I've overcome (or at least think I've overcome) and so on.

This journal serves two purposes. Firstly, the information in here can eventually be refactored into other pages, helping to expand this (so far) bare wiki. Secondly, people are free to comment on any of my observations. This itself may turn to discussions that can be refactored, further adding to the wiki.

ImmortLib Basis

The lib will be built on top of the KernelLib, leaving it intact. Some will be based on code from Yhared MUD, a pre-alpha DGD mud I'm also working on that uses DGD with the 2.4.5 Lib. But this code will mostly be the light and fluffy high level stuff, and will be carefully inspected before use. The lib will aim to make use of full persistance via statedumps.

Currently using DGD version: 1.2.87

Progress Report

Compiling DGD

My current version of DGD was compiled under windows using Visual Studio .Net with the ANSI patch, without turning off any of the optimisations. (It was also optimised for P4 systems). Compilation was very easy with no issues at all.

Getting Started

The first thing I did was read through Noah Gibs extremely helpful DGD pages. Following his example I created an initd.c, telnetd.c, and my own user.c and wiztool.c. I also created my own errord.c, but not an objectd.c. I decided to save that until later when I was a bit more comfortable with the KernelLib.

Almost immediately I discovered that errord.c was not reporting compile errors to the admin. The errors would still be logged, but I wouldn't be told of them personally. I quickly hacked in some code to errord so that all errors would be immediately reported to anyone named "admin". Later I'll replace this with something more graceful.

Admin Login

Although this is documented, I feel it is important to include this here - when you log onto the binary port and use the name "admin", you will end up as an instance of /kernel/obj/user.c, NOT whatever you define to replace it in your telnetd.c. This can be extremely useful - it allows you develop your new user object(s) and still be able to access the mud as a privaleged user, and later on if you break something major you will probably still be able to log in and fix it. Of course, it can be confusing when logging in as admin on the telnet port acts as a normal player but admin on the binary port works completely differently.

Implementing a second (or more) auto objects

An important step in making sure I didn't have to change the KernelLib was to implement a second auto object, to be inherited by everything outside of /kernel/ and /usr/System/. This is done by:

  1. Create an objectd object and register it it with the driver as your object manager. Objectd will have to be under /usr/System/, and probably should be loaded by the initd.
  2. Add the line #include "AUTO" to /include/std.h and add an empty file named AUTO to the /include/ directory.
  3. Implement the function path_special() in objectd. This function should take in the path of a file (not including the ".c") and return from this the location of an include file, which should contain a single line inheriting the relevent auto object. If you don't want to add an auto object to an object, you MUST return an empty string - if you return nil the compile will fail with an error. You will need this if your new auto object is not in System or Kernel space.
Items inheriting a second auto object will still be effected by the normal auto.

In the end I actually created two extra auto objects - one in the /usr/System area, for the more secure stuff and anything that needs access to the kernel (like thread local storage accessing functions), and one in the /usr/Game area for everything else.

The Player <-> Pawn Architecture

...

Discussion

Comments?

...so what's happened? been a while since the last update smile - Anon reader smile

Well... I died. Ok, maybe not. But things got kind of busy, and I'm back to working on my main-side-project (http://www.night-blade.com).
to top


You are here: DGD > ImmortiusJournal

to top

Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback