Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
tintin++ ogg sound player script for linux
Author: Robert Smith
Submitted by: Vladaar
6Dragons ogg Soundpack
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.4
Author: Vladaar
Submitted by: Vladaar
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
Users Online
CommonCrawl

Members: 0
Guests: 8
Stats
Files
Topics
Posts
Members
Newest Member
481
3,735
19,370
618
Micheal64X
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » General Discussions » Add dynamic command support t...
Forum Rules | Mark all | Recent Posts
Add dynamic command support to FUSS? (13 Votes)
Yes  69.23% - 9 votes

No  30.77% - 4 votes

Add dynamic command support to FUSS?
< Newer Topic :: Older Topic >

Pages:<< prev 1, 2, 3 next >>
Post is unread #1 Oct 24, 2005, 6:05 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

Self explainitory poll really. Would you like to see the dynamic command support (dlsym) code added to the FUSS packages?

Advantages:

Less hassle to add new commands/skills/spells/spec_funs to the mud. No more need to play around with tables.c to do this.

Disadvantages:

Portability issues. Not all platforms are able to support this. Most impacted would likely be Windows compilers.
       
Post is unread #2 Oct 24, 2005, 6:54 pm
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

Never really tried it myself. Hmm. What about adding it, but having a Makefile flag (or global bool) to toggle it on/off? Or is that not possible?
       
Post is unread #3 Oct 24, 2005, 7:00 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

It's a do or don't deal, that's why there's only a Yes/No response. Once it's done, you'd be committed to keeping it.
       
Post is unread #4 Oct 24, 2005, 8:21 pm
Go to the top of the page
Go to the bottom of the page

GatewaySysop
Conjurer
GroupMembers
Posts390
JoinedMar 7, 2005

Samson said:

It's a do or don't deal, that's why there's only a Yes/No response. Once it's done, you'd be committed to keeping it.


How about offering it as a separate download so that if people want it that badly, they can have it, but if someone either doesn't want or can't use it, they can still benefit from the FUSS packages? :thinking:

I realize it pretty much doubles what's offered in the download section, but maybe for the sake of portability (especially since so many new people may be beginning with a windows platform) it might be worth it?

Just my $.02 of course. :alien:



       
Post is unread #5 Oct 24, 2005, 8:50 pm
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

I think it'd be worth including, though for myself it means adding the snippet instead or just ignoring issues with it in the future since my mud's been so modified, but it's prolly worth adding for mine too, just so many things to redo that way... *sigh*

Though, on the other hand, GatewaySysop's got a good idea, it'd mean double the maintainance though, but if it were available with and without then those who are on platforms it won't work under could still benefit from the FUSS package.. or at least keep the last fuss package that didn't have it available for download for them. *shrug* You're the one who maintains it, ultimately how you choose to 'support' non-compatible platforms is up to you.
       
Post is unread #6 Oct 24, 2005, 9:14 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

I hardly have time enough to keep up on maintaining 3 packages. There's no way I'd have time to up that to 6. So if this is decided, it will be one way or the other, not both. That's why this is being put to a vote.

On the bright side, testing in my case has shown it works on Linux, BSD, Debian, and Cygwin. I haven't fiddled with it on Dev-C++ but support for that platform is experimental anyway. I'd have to take a copy of FUSS and add the snippet to it to try but in theory it should work with the right modifications.

One thing to consider: Hotboot is already a standard feature and has been for ages now. I don't think I need to mention how non-portable that can be. So try and keep this in mind while deciding. Dynamic command support is more portable than hotboot.
       
Post is unread #7 Oct 24, 2005, 10:06 pm
Go to the top of the page
Go to the bottom of the page

GatewaySysop
Conjurer
GroupMembers
Posts390
JoinedMar 7, 2005

Samson said:


One thing to consider: Hotboot is already a standard feature and has been for ages now. I don't think I need to mention how non-portable that can be. So try and keep this in mind while deciding. Dynamic command support is more portable than hotboot.


True. Although, at least imho, it would probably be much easier for someone to remove or disable hotboot functionality than it would be to revert from using dynamic command support, if that were an issue for them anyway.

Again, just my $.02 on the subject. I've nothing against the dynamic command support, in fact it's somewhere on my to do list and has been for a while. :cyclops:

       
Post is unread #8 Oct 25, 2005, 1:05 am
Go to the top of the page
Go to the bottom of the page

Greven
Magician
GroupMembers
Posts204
JoinedMar 5, 2005

Thumbs up with Dynamic support, down with tables.c. As I said elsewhere, it is a total pain in the ass. I have not had any issues on any of the systems I've installed it on, including Redhat, Ubuntu, Slackware, and another that I can't seem to remember, so it is fairly portable. Only issue I had was when I compiled with c++, but Samson had a fix for that already.
       
Post is unread #9 Oct 25, 2005, 11:16 am
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

Then throw it in, the interest is obviously here, and if portability is only barely an issue, like I said, you could leave a copy of the most recent FUSS that didn't have it available for those who can't use it and they can catch up on FUSS fixes from the forums here like the rest of us who have modified the codebase and can't just download the new version.
       
Post is unread #10 Oct 31, 2005, 6:30 pm   Last edited Oct 31, 2005, 7:04 pm by Halcyon
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

My personal feeling is that it's something that would be classified as "bells and whistles..." Given that the main goal of the FUSS project is to fix bugs, to the best of my knowledge (Correct me if I'm wrong), it just seems to be something that's unneccessary.

Mind you, as was already stated... Hotboot functionality can be removed fairly easily... Removing Dynamic Command Support is quite likely to be at least a slightly bigger pain in the ass, should a problem arise.

Portability aside, though, my main issue is reliability. I haven't heard anything very bad about it, but the fact is, the system that comes packaged with FUSS for commands is a system we've been using for God knows how many years... It just seems like toying with something with which we have complete confidence in its reliability in favor of something that's just easier to use, and not neccessarily more safe, is a mistake. DECLARE_*_FUNS are fairly uncomplicated... If there's a problem, it wouldn't be too much trouble to pinpoint. DCS, however, is more complicated... The more complicated something is, the more involved a solution will be if a problem arises that we'd never noticed before.

IMO, it might be defeating the purpose of the FUSS project entirely by creating the potential for more problems, not less, so I vote it not be included. I personally haven't installed the Dynamic Command Support system in any of the MUDs I program for, for one reason and one reason only: I know what I have works now, and it only takes me an extra 2 or 3 minutes tops to work with what I've got. I'm lazy, but not nearly lazy enough to run the risk of doing something that could cause me big problems in the future when I already have something that works just fine.

Heaven forbid this be taken as an allegation that it's not reliable code, but the fact is, we only know it's reliable inasmuch as we haven't had any big problems with it... But shit happens, and we all know it. That's my 2 cents, be it worth its weight in gold or less than a haypenny. ;)
       
Post is unread #11 Oct 31, 2005, 7:09 pm
Go to the top of the page
Go to the bottom of the page

GatewaySysop
Conjurer
GroupMembers
Posts390
JoinedMar 7, 2005

Halcyon said:

My personal feeling is that it's something that would be classified as "bells and whistles..." Given that the main goal of the FUSS project is to fix bugs, to the best of my knowledge (Correct me if I'm wrong), it just seems to be something that's unneccessary.

Mind you, as was already stated... Hotboot functionality can be removed fairly easily... Removing Dynamic Command Support is quite likely to be at least a slightly bigger pain in the ass, should a problem arise.

Portability aside, though, my main issue is reliability. I haven't heard anything very bad about it, but the fact is, the system that comes packaged with FUSS for commands is a system we've been using for God knows how many years... It just seems like toying with something with which we have complete confidence in its reliability in favor of something that's just more simple, and not neccessarily more safe, is a mistake. DECLARE_*_FUNS are fairly uncomplicated... If there's a problem, it wouldn't be too much trouble to pinpoint. DCS, however, is more complicated... The more complicated something is, the more involved a solution will be if a problem arises that we'd never noticed before.

IMO, it might be defeating the purpose of the FUSS project entirely by creating the potential for more problems, not less, so I vote it not be included. I personally haven't installed the Dynamic Command Support system in any of the MUDs I program for, for one reason and one reason only: I know what I have works now, and it only takes me an extra 2 or 3 minutes tops to work with what I've got. I'm lazy, but not nearly lazy enough to run the risk of doing something that could cause me big problems in the future when I already have something that works just fine.

Heaven forbid this be taken as an allegation that it's not reliable code, but the fact is, we only know it's reliable inasmuch as we haven't had any big problems with it... But #### happens, and we all know it. That's my 2 cents, be it worth its weight in gold or less than a haypenny. ;)


I'm in total agreement with you on this, especially (as you noted) when it comes to removal, should that for any reason be an issue (either in the package or for the end user that decides on their own to do so). I have gone through the installation on this puppy twice now with my code and though I have no problem compiling, I still have issues with commands not being recognized. I don't know the problem as yet, but more and more I'm realizing that this is a bit more than I need right now with my time so limited. I could have easily knocked a few things off my to-do list in the time I've spent installing and trying to make this function, with untold numbers of changes to the makefile and as yet no success.

Like you, I'm not trying to bash the code or the snippet or anything of the sort. I realize full well that this could be something I did wrong. I sincerely hope no one takes it that way either. I'm just saying that hunting for solutions to problems with this system, just as you said, is more complicated.

Anyway, there's another two pennies in the pot. :alien:

       
Post is unread #12 Oct 31, 2005, 8:11 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

Lively debate. Always a good thing :)

Part of the reason this has been brought up is because this code is one of the top requests I get for help, and I see it posted about regularly in a few places. Most of them having some sort of issue with the installation not going right. Alot of the same kind of things happened with the hotboot code.


DCS, however, is more complicated


Actually once installed, DCS is fairly inocuous. It operates behind the scenes and you never really need to worry about what it's doing. New commands being created don't need 3 extra steps to get coded before you can reboot and use cedit.

If fear of it being unstable is an issue, you need only look at the AFKMud codebase. Arguably among the most stable Merc derivatives around. Includes DCS as a standard feature. It's not the stability that's of concern, it's the possible portability issues. While I haven't run into a system yet that won't support it, one could very easily exist out there. I don't have access to them all. As a general rule any system which can run hotboot will already be capable of running with DCS. The hotboot code is among the least portable snippets around and has serious issues on even common platforms like Cygwin.

Anyway, this poll will be left to run for a bit longer. I would really like for more than 9 people to decide the fate of this, one way or the other. For each person who speaks up I'm sure there's likely 10 more who don't even know this place exists but still somehow end up using the base.
       
Post is unread #13 Oct 31, 2005, 10:25 pm
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

Samson, just for the record...

I tried to install this snippet to my mud the other night and had to get your input to find the step I'd missed (declaring a function at the top of one file) and the step that was omitted from the snippet instructions (adding an include in another file) in order to get it to compile cleanly, but once I did get compiled I logged into my mud and found that I had no commands and a half megabyte log file (from a clean startup ) reflecting that each and every command, skill, & spell in my game was not found in the symbol table, whatever that means, and I'm running SmaugFUSS on Fedora Core 3 compiled under GCC 3.. luckily for me I'm also using cvs so undoing everything was fairly easy, much more so I fear than it would've been to fix the problem properly so that Dlsym would work correctly for me.

While I may yet try again another time when I have less projects underway, for now I've gone back to the good old tables.c file standard that works just fine for me. I do fully realize the benefits this offers, but just like our attempt a little while back with autodepend in the makefile, I think this will be a great idea, once we figure out how to make the snippet work smoothly for the majority without having to beg you for help with it, that way, those of us who try to make sure our otherwise moderate to heavily modified SmaugFUSS systems are kept up with all the posted fixes and enhancements can safely keep up.

As stated twice already by others before me in this thread, I think this is a great idea and a great piece of code. But I also, now, think that we should make it part of the FUSS packages.. just not until we have a snippet for those of us who can't just download the latest FUSS package and start over with it to be able to install this one without a dozen headaches to get there. :(
       
Post is unread #14 Oct 31, 2005, 11:01 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,873
JoinedJul 26, 2005

Well just so it's stated :) I installed it just the other day and emailed Samson about those very bugs you ran into.
As well as the fixes for them, which im sure he will get around to updating. I didn't have any problem with it finding the commands though so not sure right off what that issue was. I recall having a similar problem a few years ago with the snippet, and It took me like a week to get it working right. I didn't bother keeping track of all the changes I did to get it working right or that would have probably been a big help for your problem lol. If you do try again though and have the same issue let me know and I'll try to help you out with it.
       
Post is unread #15 Nov 1, 2005, 4:25 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

There is of course a difference between installing the snippet into a modified system that doesn't yet have the code vs a base with the code already installed and known to be working. The same kinds of issues would come up with alarming regularity with folks adding hotboot which is arguably much simpler to install. There are still occasional posts about it cropping up here and there but now that it's native to the package there are far less instances of this.

What I think might be warranted here is installing the code into a test package and making it available temporarily to anyone who wishes to try it. This way we can determine if the code itself is at fault or if it's something else. Not to mean offense to anyone, but if it's installed by someone who knows the code better then maybe these kinds of problems can be identified and corrected.

The minor issues Remcon mentioned were fixed already and the snippet download corrected both on my site and on Mudmagic, so that should no longer be at issue.
       
Post is unread #16 Nov 1, 2005, 10:48 am
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

I will try it again at some point in the very near future, and this time if I run into problems like this I'll be sure to talk to Remcon & Samson about it as I go so we can all figure out what's going on, like I normally would've done. It just was a bad time for me to hit snags because I was in the middle of several other major projects and at least two of them had deadlines approaching much too quickly for me. I agree, Samson, someone more familiar with the code itself is bound to have less issues with it, and the idea of distributing (or making available) a test package is not a bad one. I suspect that the major portion of the troubles that I ran into have more to do with my system's configuration than the snippet itself, but that night was not a good time for me to deal with it. (The snippet itself isn't really that complicated or difficult to install, once you make sure you've done everything listed in it and add that include that wasn't listed in it, though I gather that's been corrected already and when I do try this again, rest assured, it will be with a clean download of the snippet so I have the fixes on hand.)
       
Post is unread #17 Nov 4, 2005, 5:34 am
Go to the top of the page
Go to the bottom of the page

Zhamel

GroupMembers
Posts68
JoinedApr 5, 2005

Samson,

If you want, add the dynamic command support to the FUSS package and I'll help by maintaining the non-dlsym package. When you post bug fixes to the forums I'll add them, tar it up and send it to you. This way everyone can get what they want.

I'm willing to help out as you need it, but like I said, it's up to you.
       
Post is unread #18 Dec 3, 2005, 4:26 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

So it's been about a month now, and I see there hasn't been a great deal more activity except a few votes here and there. Standing at 8-4 in favor it doesn't seem like there's even enough people right now who care one way or the other.

So has anyone tried the test package? Does it work? Does it fail? Does Cygwin like it or no? Should we forget about this and just move on? :P
       
Post is unread #19 Dec 3, 2005, 5:53 pm
Go to the top of the page
Go to the bottom of the page

GatewaySysop
Conjurer
GroupMembers
Posts390
JoinedMar 7, 2005

Samson said:

So it's been about a month now, and I see there hasn't been a great deal more activity except a few votes here and there. Standing at 8-4 in favor it doesn't seem like there's even enough people right now who care one way or the other.

So has anyone tried the test package? Does it work? Does it fail? Does Cygwin like it or no? Should we forget about this and just move on? :P


I'm still wondering what the problem was. Both Conner and I seem to have had an almost identical situation going on and that makes me wonder if its not just something on my end. Did he ever figure this problem out? Whatever his issue is, its probably related to mine.

As I said, installed it twice, no dice. Haven't had time to go back to do it again (still don't) but there must be something afoot here, no? I'm obviously not the only person with the same problem.

Anyway, whatever happens to the base package really doesn't matter to me since I've been modifying mine for ages and will continue to do so (at least I hope to). If/when the issue is resolved and we know what the problem is/was I would certainly like to get back into alignment with the stock package and upgrade, and hopefully at that time it'll all work out.

Do whatever you think is best Samson. The community owes you big time for all the work you've put into the FUSS packages and either way you go I'm sure we're all behind you.

Keep up the good work, wherever it leads.

       
Post is unread #20 Dec 3, 2005, 6:00 pm
Go to the top of the page
Go to the bottom of the page

Stan
Fledgling
GroupMembers
Posts23
JoinedNov 19, 2005

I would love to see dynamic command support added.
I usually play with a different codebase every 2 weeks, and I do not even run the game til I have dynamic command support installed.
       
Pages:<< prev 1, 2, 3 next >>