This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

Cygwin and DoT

Posted by Microp on Thu 28 Mar 2002 05:00 PM — 11 posts, 37,106 views.

Microp USA #0


Posted by Kalahn United Kingdom (48 posts) bio
Date Sun 27 Jan 2002 10:10 PM

Message 1.69q compiles clean out of the box on Cygwin.

- Kal



Awsome, so it's ready to go with Cygwin in 1.69q.
And around April 10, 1.69q will be released.

Do I have my facts straight?
Kalahn United Kingdom #1
Yeah, April 10 is a fair estimate of when 1.69Q will be released. No promises of course, basically I release when it is ready... currently I am in the process of patching in a lot of new code from storm-bringer, after this and running it on 3 or 4 muds to confirm we are 100% stable I will release.

During the testing time on a few muds I will be working on the area set etc.

- Kal
Microp USA #2
Great!

I had heard that DoT doesn't have any hard coded stock areas, mobs, or objs (which is great for us who aren't very advanced in C.)(so we can easily start from scratch) Is this true?
Kalahn United Kingdom #3
Quote:
I had heard that DoT doesn't have any hard coded stock areas, mobs, or objs (which is great for us who aren't very advanced in C.)(so we can easily start from scratch) Is this true?


Well yes and no.

Dawn will quite happily boot with no area files, it will dynamically generate one area with a single room (limbo) so people can login. I wouldn't recommend this option, because you would be missing a lot of objects etc... for example the create rose spell uses a rose object. When you kill a mob, a particular object is used for the corpse. A lot of the code has been enhanced to not assume the object is present (create rose will tell the player a particular object is missing and abort the spell for example).

In addition I have recently decided to reserve all vnums from 1 to 500 for dawn's internal use. This will avoid vnum clashes with future versions that add more features (e.g. the herb system).


I think the real strength when talking about hard coded, is that very little is still hard coded. So if you dont like something you can change it without knowing C. 1.69q will take things another little step further forward... as contients names are now stored in a text file (were hardcoded in 1.69p).

There are some files dawn requires to boot, but these are text files which you can change either using an olc interface (raceedit for example), or manually system/races.txt. The olc interface is recommended though.

The biggest flexiblity is the gameedit feature, using this you can easily tweak a lot of the game environment.

Just the flags section in gameedit include the following:


nopermdeath 
noshort_descripts holyname_for_all
remort_supported 
remort_in_score 
no_sublevels no_bias_against_rerolling
role_rolemaster_stats
use_rolemaster_modifiers
no_letgaining_required 
bard_done class_creation_no_star 
max_align_range22
always_allow_setage 
restricted_grouping morgue_enabled
msp_check_fileexist peaceful_mud 
read_passwords_as_cleartext 
dont_perform_ident_lookups
players_cant_access_others_colours
WIN32_perform_local_dns_lookups
log_all_ip_connects_to_admin/connects.txt disable_rps_system 
outfit_enable 
show_stat_averages_in_creation newbie_locked 
player_locked
no_second_skill_required 
admin_default_whoinvis
autonote_renames_to_admin 
autonote_immpkill_to_admin 
no_weblog
use_laston_imm_value 
no_attacking_shopkeepers 
shopkeepers_can_be_killed 
hide_area_shortnames 
newbies_get_all_maps 
no_tell_restrictions 
bypassduel_reduces_karns 
no_duel_required 
verbose_dates_in_logs 
disable_verbose_olc_logging 
nocharm_has_noaffect 
no_msg_about_old_mudclients 
no_autodamage_command 
no_autologoff_for_imm 
wholist_sort_by_level 
wholist_imms_before_morts 
dont_display_codebase_4_login 
dont_display_who_4_login
gain_hp_when_leveling 
gain_one_train_when_leveling
info_enabled 
who_title_enabled 
mortlaston_requires_part_of_name 
mortlaston_requires_full_imm_name 
language_not_scrambled
language_name_not_in_says 
no_decreasing_max_karn 
no_clantalk 
experimental_damage_scaling 
display_p_reset_bugs_on_wiznet 
autoafk_disabled 
storm_damage_messages 
show_qp_in_score


And new in 1.69q:

automatic_letheroing 
can_teach_spells_while_unlearned     disable_extended_ascii_characters
use_dynamic_wizlist 
lockers_disabled


I aren't going to explain what they all mean in this message, but I think it really demonstrates the flexiblity.

- Kal
Microp USA #4
Awsome,

I can't wait for it to be released!

One last question though, I am considering making a non-magical Mud (ie. no spells, enchantments, live gods, etc.).

Would this be possible in DoT? -By just deleting the relevant txt commands/helpfiles/skills (assuming it's not hardcoded)?

Or would it require alot of C knowledge to do this (make it non-magical).

Could I then add new skills/commands/helpfiles (such as ex: >plant (crop) -ontop of the existing (remaining) ones.
--Basically replace all magic spells/skills with new custom non-magical skills/commands.

Or would I be better off starting with a more basic code foundation, like PennMush?

Quote:

In addition I have recently decided to reserve all vnums from 1 to 500 for dawn's internal use. This will avoid vnum clashes with future versions that add more features (e.g. the herb system).

In addition I have recently decided to reserve all vnums from 1 to 500 for dawn's internal use. This will avoid vnum clashes with future versions that add more features (e.g. the herb system).


What do you mean by "reserve"? I could delete them, just not edit them?

Thanks for the info..
Amended on Thu 11 Apr 2002 03:55 AM by Microp
Microp USA #5
Thought I'd post again to re-activate this thread. In case it was overlooked.
Nick Gammon Australia Forum Administrator #6
I don't see what is stopping you removing any spells you want to remove. Probably deleting them from the command file, or setting their level very high would do that. I'm not the DoT expert however. :)

PennMUSH is quite different - get a copy and play with it to see, if you want. It is more for building as you go. One of my pages on my site describes the difference.

Quote:

What do you mean by "reserve"? I could delete them, just not edit them?


What Kalahn means is, to keep them for DoT internal use. I suppose you could delete them, the idea is you aren't supposed to create new ones in that range - he wants to keep them for particular purposes.
Microp USA #7
K Nick thanks,

I actually have already tried PennMUSH, but I didn't get very far. I was mainly waiting to see what the "experts" deemed my best coarse.

Now that I know, I'm on my way :)

I can't wait for the new DoT to come out, from what I've seen it's just to good to pass up. Though I'll give PennMUSH another whirl.
Nick Gammon Australia Forum Administrator #8
Trouble is, PennMUSH does not come with much in the way of area files etc.

This might be fine if you want to start from scratch, indeed it might be ideal.

With PennMUSH default distribution, you start with one room, and start building from there.

I have a building guide on this site somewhere, it gives you an idea of how to get started.
Microp USA #9
I checked out the Guide you spoke of awhile back, at the time I was commited to Smaug so I only read through it once. I'll see if I can find it again.

I have alot of plans for the mud, and seeing as I am so terribly new at this (green as summer grass) - sometimes I can't decide where to begin. Designing the world is almost as hard. Let alone trying to figure out how to get it all into code.

Agreeing with your conclusion, I'd rather have no stock areas, stock spells, only the bare essentials. PennMUSH has that, but it's no where near as advanced. Though it may be easier to start from scratch on PennMUSH, DoT would allow me to climb higher in the end.

Any idea the VNUM Limit for DoT? I think smaug is 37,000, and I'm hoping DoT is a bit higher. I'd prefer more breathing room.

This last one is mainly from curiousity with a hint of confusion mixed in.
In Telnet the background of muds are white with black text, in MushClient it's opposite: black with white text. Is there anyway to control this no matter the client used? Or is it solely dependant on the client being used and it's settings.

*sighs* well back to work.
Thanks Nick.
Amended on Thu 11 Apr 2002 08:14 AM by Microp
Nick Gammon Australia Forum Administrator #10
I imagine DoT has no great limit on vnums, except whatever 2**32 is.

As for the colours, MUSHclient defaults to telnet colours - grey on black, however MS telnet defaults to black on white. It is a client thing.