The Major BBS Forums

This project is real and is happening finally after 3 years of "talking about it" .... With the completion of my Tele-Arena engine which came out very well i will be utilizing the same technologies i did in that engine to create a brand new MajorMud engine for worldgroup 3.xx and majorbbs 10.0 ....
So with that said i will let you know i never really played, coding i can do but mimicing game features is something i will need help with.
I have found an arsenal of info on the web to a point i feel i can replicate it pretty close and this game needs an updated engine with an accesible
codebase in the event fixes need to be made.
So right now as of this posting i have a full database (thanks to nightmare editor) and i have built my sqlite database with that data, and i have a beginning game engine
where you can enter and create your character (or load your character) and enter a "teleconference-like" room.
From there i will build onto it with info i gather.
What i need..... design-assistants, players/sysops to play the game and tell me what it needs. Unlike the GreaterMud release that came out this will be accessible by you to put on your systems not just play on mine, i will give any sysop wanting to add it on their system a copy for testing purposes if they are a member of the team.
Anyone wanting to be on the team just drop me a pm. i anticipate having something downloadable VERY soon.

Development has commenced! the first pieces of the engine are online testbbs.arcticzonebbs.net from there you can see my commitment, as i am going to
be working on this new engine, how fast i get it done will be dependent on any datamining info you can get to me.
inbox me if you want to join the team!

so i now have the full screen character editor working. i still need to tweak the usage of CP to follow the correct
rule for how much it costs per point but the editor itself is working good.
I also got the full world map to load now, so now i have the full map in the new engine.
Still trying to figure out why there is that delay when walking from room to room.... either it is intended as
some form of speed limiter to keep all users on the same speed, or it is just doing so much as it changes
rooms with database calls it delays like that..... mine goes really fast and this could pose a problem if clients
such as megamud need that delay to work.... something to look at in the future.

daniel_spain wrote:
> so i now have the full screen character editor working. i still need to
> tweak the usage of CP to follow the correct
> rule for how much it costs per point but the editor itself is working good.
> I also got the full world map to load now, so now i have the full map in
> the new engine.
> Still trying to figure out why there is that delay when walking from room
> to room.... either it is intended as
> some form of speed limiter to keep all users on the same speed, or it is
> just doing so much as it changes
> rooms with database calls it delays like that..... mine goes really fast
> and this could pose a problem if clients
> such as megamud need that delay to work.... something to look at in the
> future.

Huh is the delay always there? You might want to check for that delay if there are players that remain there in both rooms while you go from one to the other. My thoughts are if there is no delay if there is someone in both rooms you traverse from than it's probably caching out empty rooms. That way instead of having to re-initalize and re-load the room it's taking the object from memory and dumping it to HDD or visa versa when you enter the room. This was written in C, so doing ugly things like that abusing malloc was not unusual to save system resources. This would allow the detailed states that take transforming to go back to the DB can be lazy written.
If i'm right about the delay being conditional than I would imagine a hardcore player would know about it and wouldn't write code around that. If it's not conditional than it might be intentional for clients.

The delay is intentional.

MajorMUD uses deferred execution via TASKS & SYSCYC within MajorBBS/Worldgroup to handle player actions and events. I suspect this was done so that intensive tasks could be run in cycles outside of processing user input as to not make the board feel "slow". For actions like movement, it sets a delay value (Exported Function _ADD_DELAY) which specifies the amount of time to delay execution of the command in seconds. For movement specifically, they're handled in the registered SYSCYC routine. Movement delays are modified based on things such as being over encumbered, affected by a spell, etc.

We had to solve the above in order to get MajorMUD working in MBBSEmu. We documented the process of debugging it here:

https://wiki.mbbsemu.com/doku.php?id=mbbsemu:history:patreon:101820

Hope this is of some help!

BadOPCode wrote:
> daniel_spain wrote:
> > so i now have the full screen character editor working. i still need to
> > tweak the usage of CP to follow the correct
> > rule for how much it costs per point but the editor itself is working good.
> > I also got the full world map to load now, so now i have the full map in
> > the new engine.
> > Still trying to figure out why there is that delay when walking from room
> > to room.... either it is intended as
> > some form of speed limiter to keep all users on the same speed, or it is
> > just doing so much as it changes
> > rooms with database calls it delays like that..... mine goes really fast
> > and this could pose a problem if clients
> > such as megamud need that delay to work.... something to look at in the
> > future.
>
> Huh is the delay always there? You might want to check for that delay if there are
> players that remain there in both rooms while you go from one to the other. My
> thoughts are if there is no delay if there is someone in both rooms you traverse from
> than it's probably caching out empty rooms. That way instead of having to
> re-initalize and re-load the room it's taking the object from memory and dumping it
> to HDD or visa versa when you enter the room. This was written in C, so doing ugly
> things like that abusing malloc was not unusual to save system resources. This would
> allow the detailed states that take transforming to go back to the DB can be lazy
> written.
> If i'm right about the delay being conditional than I would imagine a hardcore player
> would know about it and wouldn't write code around that. If it's not conditional
> than it might be intentional for clients.

so from what i am seeing in the old database structures as well as the nightmare editor is ALL data saves as far as everything except the player info.
monsters, everything.... so i am assuming with a map of 21,760 rooms it is constantly working. even a base vanilla install of wcc's version 1.11p
even with no players in the game the module is steadily working. now btrieve as powerful as it was in those days became quite clunky when wg3
was launched and i am also running a worldgroup 2.0 and majorbbs 6.25 version of major mud that i use as reference points as i am engineering
my own engine. i want to get as much info as i can and from what i have seen a slight delay seems to always exist. i tried running a game with blank
data and it wont start (used nightmare to empty the databases) so i have to run with at least a base install data set. quite frankly i cannot see players
getting upset with QOL changes but there are that few that will point it out.

enusbaum wrote:
> The delay is intentional.
>
> MajorMUD uses deferred execution via TASKS & SYSCYC within
> MajorBBS/Worldgroup to handle player actions and events. I suspect this was
> done so that intensive tasks could be run in cycles outside of processing
> user input as to not make the board feel "slow". For actions like
> movement, it sets a delay value (Exported Function _ADD_DELAY) which
> specifies the amount of time to delay execution of the command in seconds.
> For movement specifically, they're handled in the registered SYSCYC
> routine. Movement delays are modified based on things such as being over
> encumbered, affected by a spell, etc.
>
> We had to solve the above in order to get MajorMUD working in MBBSEmu. We
> documented the process of debugging it here:
>
> https://wiki.mbbsemu.com/doku.php?id=mbbsemu:history:patreon:101820
>
> Hope this is of some help!

hrmm... under that i would assume the rtkick is ticking every second and within the real-time kicker it is processing it's own internal
queue on how things are handled over the traditional for/while loop thgrough each channel. i know in Tele-Arena to make it seem
more logical and random sean just has the loops skip every other monster and process every 2 seconds so if you have multiple
monsters in a room all of them wont execute their actions at the same time...... interesting. i will not know until i begin the
automation stuff. right now i am loading the data and handling player movement.

enusbaum wrote:
> The delay is intentional.
>
> MajorMUD uses deferred execution via TASKS & SYSCYC within
> MajorBBS/Worldgroup to handle player actions and events. I suspect this was
> done so that intensive tasks could be run in cycles outside of processing
> user input as to not make the board feel "slow". For actions like
> movement, it sets a delay value (Exported Function _ADD_DELAY) which
> specifies the amount of time to delay execution of the command in seconds.
> For movement specifically, they're handled in the registered SYSCYC
> routine. Movement delays are modified based on things such as being over
> encumbered, affected by a spell, etc.
>
> We had to solve the above in order to get MajorMUD working in MBBSEmu. We
> documented the process of debugging it here:
>
> https://wiki.mbbsemu.com/doku.php?id=mbbsemu:history:patreon:101820
>
> Hope this is of some help!

was reading your wiki post there.... did you need a sqlite file? i have one with a complete vanilla 1.11p data.
this is the one i use as the game database (MAJORMUD.DB) it is built from all of the btrieve databases.
i have it in sqlite, access, xml, and text forms. sqlite can be clunky in its own rite if not executed properly
but i feel it is superior to btrieve in all ways (my own opinion of course) and tis is why all my tele-arena engines
got updated to sqlite last year and the next release of the "tele-arena game engine" actually utilizes online editors
with no hesistation between database calls unlike where i hit issues with btrieve.

daniel_spain wrote:
> was reading your wiki post there.... did you need a sqlite file? i have one with a
> complete vanilla 1.11p data.
> this is the one i use as the game database (MAJORMUD.DB) it is built from all of the
> btrieve databases.
> i have it in sqlite, access, xml, and text forms. sqlite can be clunky in its own
> rite if not executed properly
> but i feel it is superior to btrieve in all ways (my own opinion of course) and tis
> is why all my tele-arena engines
> got updated to sqlite last year and the next release of the "tele-arena game
> engine" actually utilizes online editors
> with no hesistation between database calls unlike where i hit issues with btrieve.

That original post is from last October when we first started down that path of moving to SQLite.

Since then, we've been able to enhance the Btrieve engine within MBBSEmu to both load the Btrieve data directly from the .DAT files (no drivers required) and also setup the internal Btrieve Ordinals called by the modules to execute SQLite queries.

We haven't run into any issues with SQLite... yet. We've created a pretty robust Unit Test suite for that entire section of the Emulator.

You can check out the implementation for those here:
https://github.com/mbbsemu/MBBSEmu/tree/master/MBBSEmu/Btrieve
https://github.com/mbbsemu/MBBSEmu/tree/master/MBBSEmu.Tests/Btrieve

enusbaum wrote:
> daniel_spain wrote:
> > was reading your wiki post there.... did you need a sqlite file? i have one with
> a
> > complete vanilla 1.11p data.
> > this is the one i use as the game database (MAJORMUD.DB) it is built from all of
> the
> > btrieve databases.
> > i have it in sqlite, access, xml, and text forms. sqlite can be clunky in its
> own
> > rite if not executed properly
> > but i feel it is superior to btrieve in all ways (my own opinion of course) and
> tis
> > is why all my tele-arena engines
> > got updated to sqlite last year and the next release of the "tele-arena
> game
> > engine" actually utilizes online editors
> > with no hesistation between database calls unlike where i hit issues with
> btrieve.
>
> That original post is from last October when we first started down that path of
> moving to SQLite.
>
> Since then, we've been able to enhance the Btrieve engine within MBBSEmu to both load
> the Btrieve data directly from the .DAT files (no drivers required) and also setup
> the internal Btrieve Ordinals called by the modules to execute SQLite queries.
>
> We haven't run into any issues with SQLite... yet. We've created a pretty robust Unit
> Test suite for that entire section of the Emulator.
>
> You can check out the implementation for those here:
> https://github.com/mbbsemu/MBBSEmu/tree/master/MBBSEmu/Btrieve
> https://github.com/mbbsemu/MBBSEmu/tree/master/MBBSEmu.Tests/Btrieve

yeah since i switched to sqlite i actually prefer it anytime i am doing a multi-database addon (tele-arena, majormud, usurper, tlord) i have hit no snags
and until someone proves me wrong it is super beneficial over btrieve.