Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum
intoK
Apprentice


Joined: 18 Feb 2007
Posts: 190

PostPosted: Sun Nov 02, 2008 2:15 pm   

[FR] map db UserInt field access
 
well, its there since zmud, we can view/edit it from room properties window, but thats it - no way to use it in scripts, unless theres some undocumented feature i dont know about
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Mon Nov 03, 2008 6:06 pm   
 
There isn't any normal function for the UserInt field access. You'd have to use the zMapper COM API (which is available in CMUDPro) to access that field.
Reply with quote
intoK
Apprentice


Joined: 18 Feb 2007
Posts: 190

PostPosted: Mon Nov 03, 2008 6:28 pm   
 
so there isnt... but you could make one in like 3minutes Wink
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Mon Nov 03, 2008 8:13 pm   
 
Well, yes. But remember that the whole purpose of zMapper/CMUDPro was to provide "enhanced mapper scripting". It isn't really far to the people who have purchased the more advanced product to move everything into the non-Pro interface.

This is a battle that I am currently dealing with a lot right now. I *am* adding many of the zMapper/CMUDPro mapping features into the core CMUD product as part of the mapper rewrite (things like room types, background images, etc). But I still need to keep some stuff that is just for the people who paid for the zMapper/CMUDPro version, and that mainly involves the advanced COM-based scripting model.

So the regular %roomXXX scripting functions are *never* going to be as complete or versatile as the %map.xxx COM-based API.
Reply with quote
intoK
Apprentice


Joined: 18 Feb 2007
Posts: 190

PostPosted: Mon Nov 03, 2008 10:25 pm   
 
indeed, but jmho, things like room types or background images are exactly those which should be left in z/cmapper/pro version - im not happy with those, i wont ever use them

poweruser perspective - cmud mapper should provide all the scripting functionality wo bloated overhead of com interface and any graphical enhancements, be fast and lightweight, solid groundwork for scripting with no hindrance - fancy stuff like backgrounds, dockable properties window, enhanced mapper autoconfiguration, discussed in other thread improvements to #find etc. should be kept for cmudpro
i would even cut out support for jet maps out of normal cmud when time comes, just provide standalone converter

from what i had read on zmapper/cmudpro features, except access to this field in db there are no things there that id ever use, id rather pay extra for having bloat removed than added, if that makes sense Razz
ack, sorry for ranting a tad,

cheers!
Reply with quote
Dumas
Enchanter


Joined: 11 Feb 2003
Posts: 511
Location: USA

PostPosted: Mon Nov 03, 2008 11:14 pm   
 
If Zugg places too much in the normal CMUD mapper, then fewer people will have need for the Pro version, which means a loss of income. I'm fine with it, I paid for Pro despite the fact I probably won't use many of the added features.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Tue Nov 04, 2008 3:46 am   
 
BTW, there is a separate thread that Zugg created for discussion of what features from zMapper should make it into CMUD...
Reply with quote
intoK
Apprentice


Joined: 18 Feb 2007
Posts: 190

PostPosted: Tue Nov 04, 2008 8:55 am   
 
i must be wording meself poorly, you guys seem to miss whole point, do i really wrote so incomprehensible? lets try this
http://en.wikipedia.org/wiki/Feature_creep
http://en.wikipedia.org/wiki/KISS_principle
http://en.wikipedia.org/wiki/Bloatware

i chosen cmud over cmudpro cause it was less of bloatware, now it seems some more bloat leaks to cmud, this is extremely worrying, bullet-point engineering might sell to housewife that dont even need the product, but will not make poweruser happy - unfortunately with used licensing system former is more tempting than the later

finally, id happily pay again this instant, but only for version that is LESS bloated than what i have, and have useful features over it, id LOVE to be able to buy such product
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Tue Nov 04, 2008 1:27 pm   
 
Er... well, the topics you linked to aren't exactly related to this discussion. Bloatware, for example, generally refers to memory footprint and program size. It's a reference to the fact that a modern program is often many times larger than an older program that did a similar thing, presumably because now we all have 4GB of memory, you don't have to be as careful what you do with it. That's not really relevant here.

Secondly, feature creep is an argument that goes both ways. You could claim that adding any feature (such as the UserInt function you're requesting) is an example of feature creep. The ability to access all this stuff via the %map object is quite an easy way to do it - certainly no more complex than using a normal function, provided it's well-documented.

Thirdly, the examples you give of things that should be kept for CMUD pro (especially room types) are things that many people would find useful. Just because you wouldn't doesn't mean that adding them is a bad idea.

Oh, and also, as far as I'm aware, support for older zMUD maps is going to be removed, insofar as CMUD won't open them directly. It'll convert them to the new SQL format. So that is a plus :)
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Nov 04, 2008 5:32 pm   
 
What one person calls "bloat", another person calls a "critical feature". For example, many users would call the Threading stuff that you have been using extensively in CMUD "extraneous". When I look at features, I try to judge how many people would benefit/use a feature. More CMUD users are going to use background images and different room shapes than will use the UserInt field. You are the first person in 10+ years of zMUD/CMUD to request accessing UserInt via a normal script. Whereas I've had hundreds of requests for background images and custom room types.

The main feature of CMUDPro is always going to be SSH. Just because SSH is normally only needed for business applications where CMUD is used as a telnet/ssh client and not for playing MUDs. The ability to use zMapper scripting in CMUDPro is also a high-end power programming feature, so it fits with the "Pro" idea. When the database module is rewritten, CMUDPro will allow more than just the basic SQLite programming (MySQL, Postgress, SQL Server, etc). The SSH and zMapper COM interface do not make CMUDPro "bloated". It's nearly the same size on disk and in memory. COM is not "bloat" but is, in fact, a powerful way to handle object-oriented scripting in Windows.

In any case, as long as a program opens quickly and runs quickly, then I don't call it "bloated". I call something "bloated" when it takes a huge memory footprint, is slow to load, or installs tons of extra stuff on my computer that are not part of the program. CMUD doesn't do any of this. As far as Features, CMUD/zMUD have always been, and always will be, the leader in features. Not everybody uses every feature. But what you might call an "extraneous" feature is what someone else depends upon and bought CMUD to do.
Reply with quote
intoK
Apprentice


Joined: 18 Feb 2007
Posts: 190

PostPosted: Tue Nov 04, 2008 6:54 pm   
 
Zugg wrote:
What one person calls "bloat", another person calls a "critical feature". For example, many users would call the Threading stuff that you have been using extensively in CMUD "extraneous". When I look at features, I try to judge how many people would benefit/use a feature. More CMUD users are going to use background images and different room shapes than will use the UserInt field. You are the first person in 10+ years of zMUD/CMUD to request accessing UserInt via a normal script. Whereas I've had hundreds of requests for background images and custom room types.

exactly what im saying sir, youd get more money but providing full featured scripting in all versions and fancy graphics many people indeed wants (but many other will never use) in another - and possibly bloat(not muding related) features in another, keeping everybody happy

key is putting line not at what majority wants but what is core and what is fancy.
i might have been only person who requested this, but in last two yrs i remember at least 3 other have asked me about it and said darn, would be neat to use - but no, nobody gonna buy anything for this, so i dont see why you wanna make sale point on this instead of fancy gfx stuff

Quote:
The main feature of CMUDPro is always going to be SSH. Just because SSH is normally only needed for business applications where CMUD is used as a telnet/ssh client and not for playing MUDs. The ability to use zMapper scripting in CMUDPro is also a high-end power programming feature, so it fits with the "Pro" idea. When the database module is rewritten, CMUDPro will allow more than just the basic SQLite programming (MySQL, Postgress, SQL Server, etc). The SSH and zMapper COM interface do not make CMUDPro "bloated". It's nearly the same size on disk and in memory. COM is not "bloat" but is, in fact, a powerful way to handle object-oriented scripting in Windows.

before or after packing/protecting? Razz j/k -
id rather not express meself on OO(things) (my first programming language was M68k ASM, so im rather biased here), but sure, they make implementation easier on abstract level

more interfaces implemented, sigh... why call it mud client if its supposed to do all that?

Quote:
In any case, as long as a program opens quickly and runs quickly, then I don't call it "bloated". I call something "bloated" when it takes a huge memory footprint, is slow to load, or installs tons of extra stuff on my computer that are not part of the program. CMUD doesn't do any of this. As far as Features, CMUD/zMUD have always been, and always will be, the leader in features. Not everybody uses every feature. But what you might call an "extraneous" feature is what someone else depends upon and bought CMUD to do.

well, i agree in the principle, but not with where the line is drawn - as above
also having some stuff as plugins for load on demand would be nice (and can be made buletpoint feature Wink )
Reply with quote
intoK
Apprentice


Joined: 18 Feb 2007
Posts: 190

PostPosted: Tue Nov 04, 2008 7:07 pm   
 
Fang Xianfu wrote:
Er... well, the topics you linked to aren't exactly related to this discussion. Bloatware, for example, generally refers to memory footprint and program size. It's a reference to the fact that a modern program is often many times larger than an older program that did a similar thing, presumably because now we all have 4GB of memory, you don't have to be as careful what you do with it. That's not really relevant here.

bloatware is just extrapolation for current direction
i was generalizing on features not directly related to central task

Quote:
Secondly, feature creep is an argument that goes both ways. You could claim that adding any feature (such as the UserInt function you're requesting) is an example of feature creep. The ability to access all this stuff via the %map object is quite an easy way to do it - certainly no more complex than using a normal function, provided it's well-documented.

depends where you draw the line, jmo, everything related to playing mud (includes scripting) is core, fancy map display stuff are extras

true, but it adds serious os overhead in handling

Quote:
Thirdly, the examples you give of things that should be kept for CMUD pro (especially room types) are things that many people would find useful. Just because you wouldn't doesn't mean that adding them is a bad idea.

as above + from whose point of view, certainly not master z's - theres bigger market for for fancy graphics, and it has reverse correlation with low level access requirements

Quote:
Oh, and also, as far as I'm aware, support for older zMUD maps is going to be removed, insofar as CMUD won't open them directly. It'll convert them to the new SQL format. So that is a plus :)

sweet, at least one down Very Happy
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net