Server Help Forum Index Server Help
Community forums for Subgame, ASSS, and bots
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   StatisticsStatistics   RegisterRegister 
 ProfileProfile   Login to check your private messagesLogin to check your private messages   LoginLogin (SSL) 

Server Help | ASSS Wiki (0) | Shanky.com
Usability (e.g. Core Modules)

 
Post new topic   Reply to topic Printable version
 View previous topic  Gravity Mine Post :: Post AS3 Bot Module  View next topic  
Author Message
divine.216
Newbie


Joined: Jun 12 2005
Posts: 18
Offline

PostPosted: Tue Jan 05, 2010 5:55 pm    Post subject: Usability (e.g. Core Modules) Reply to topic Reply with quote

Why is the set of core modules (the ones required to make ASSS work at all) not hardcoded into ASSS? Why must they be in conf/modules.conf -- you know, that file we encourage zone admins to tweak?

As a developer, I get it, it just feels elegant. But if we want to invite a wider audience to use ASSS (wider than those of us who code for it), then we need to have a bit of empathy for the would-be admin who expects to be able to fiddle with modules.conf (etc.), expects to be able to understand it, and expects things to work sanely.

Configurability is not about having large numbers of run-time adjustable options, it's about having useful and effective control of the application. Enthusiasm for modularity is nice for development, and we shouldn't discard it. But when we package a release, some aggregating simplicity and structure would go a long way toward making ASSS more usable.

(Note: I'm not a huge fan of finger-wagging and guilt-tripping volunteer devs -- I think it misunderstands why we code in the first instance. Still, it's more fun to write code that people will actually use, so even without getting terribly idealistic we can all get behind some usability review.)
Back to top
View users profile Send private message Add User to Ignore List Send email Visit posters website
Bak
?ls -s
0 in


Age:24
Gender:Gender:Male
Joined: Jun 11 2004
Posts: 1826
Location: USA
Offline

PostPosted: Tue Jan 05, 2010 7:09 pm    Post subject: Reply to topic Reply with quote

add #include custom_modules.conf at the bottom of modules.conf and encourage people to edit that file
_________________
SubSpace Discretion: A Third Generation SubSpace Client
Back to top
View users profile Send private message Add User to Ignore List AIM Address
Dr Brain
Flip-flopping like a wind surfer


Age:38
Gender:Gender:Male
Joined: Dec 01 2002
Posts: 3502
Location: Hyperspace
Offline

PostPosted: Tue Jan 05, 2010 7:23 pm    Post subject: Reply to topic Reply with quote

Hyperspace and Hockey Zone (and probably other zones) swap out core modules with their own replacements. That's why they're not hard coded in.

I think your issue isn't about organization, I think that it's about how ASSS is configured out of the box.
_________________
Hyperspace Owner

Smong> so long as 99% deaths feel lame it will always be hyperspace to me
Back to top
View users profile Send private message Add User to Ignore List AIM Address Yahoo Messenger MSN Messenger
divine.216
Newbie


Joined: Jun 12 2005
Posts: 18
Offline

PostPosted: Tue Jan 05, 2010 9:48 pm    Post subject: Reply to topic Reply with quote

@Bak: clever -- that should be included in any listing of ASSS admin best-practices, including the default install.

@Dr Brain: Broadly, you are absolutely right: my comment was aimed at the way ASSS is "out of the box". But your note about hyperspace and hockey zone tweaking the core modules hints at the underlying cause. People are doing one-off mods to core modules instead of configuring and adding-onto the server.

One-off solutions should be done in configuration files. Failing that, they should be done in add-on modules. Only when this fails should they hack up core modules, and this should itself prompt a bug-filing with a request that the core add functionality to the add-on API (perhaps even giving the core-hack code as a sample implementation).

Note, I said "should" -- of course everyone is free to tweak and modify and use ASSS however they please. But, when a zone faces a problem, their method to solve that problem has an impact on the usefulness of their work. And the usefulness of the work, in turn, shapes the development that grows around the project. If a zone solves their problem with a configuration file, this is immediately useful to everyone, since it can be shared in a forum post or a users guide. If their solution is an add-on module (that works with the vanilla distribution of ASSS), then this too is immediately useful to everyone, so long as everyone can download the add-on module. But if the zone solves their problem by hacking straight into core modules, then their solution is useful to no other ASSS user.

It's not clear that anyone is to blame for this core-hacking habit, and I'm not pointing fingers. Put simply, zones want to do more than is possible with vanilla ASSS + configuration files. And, presumably, they want to do more than is possible via add-on modules -- else they wouldn't need to hack at core modules.

This situation suggests one or both of the follow: (1) coders are leaping too quickly to hack core modules instead of thinking hard about whether it might be done via add-on module; (2) the modules API is shitty for add-on development or is poorly understood (which causes #1).

If coders solved problems without resorting to modifying the core, then you would get a richer development community focused on doing "plugin" development (which is easier -- you don't have to learn the whole server -- and can be compatible with one or more vanilla releases of ASSS) and also a separate group doing "core" development (which requires more expertise but aims to clean up ASSS "out of the box", to ensure backward compatibility; and to add new functionality requested by plugin developers).

With such a development community, zone admins could grab vanilla ASSS and then pick and choose among the plugins (read: add-on modules). But instead, devs are hacking up core ASSS modules, custom for each zone. This does 2 things: it requires zone admins to be (or to beg) coders, and it reinforces this by never meaningfully improving ASSS core. There are now islands of core hackers that, while sometimes doing neat things, end up being both isolated and isolating.

Not to put too fine a point on it, but I'll give an example: powerbot. One benefit of ekted's firm control on powerbot source code was the rich community of developers who focused, not on hacking up the core for some one-off problem, but rather on writing powerful plugins (because we didn't really have access to the core). These plugins were then shared and combined. They continued to work in later versions of the core. This division of labor kept both core development (by ekted) and plugin development (by the rest of us) moving. I don't mean to glorify writing to a closed API. And developing on an open platform offers endless possibilities -- indeed, it is my preferred mode of development. But open development requires a maturity, a self-imposed discipline to "solve it right", and to not use duct-tape (core hack). Otherwise, when isolated problem solving becomes a pattern, progress on the project slows to the speed of, at most, a single developer. This is why ASSS development is so sloppy and so slow.
Back to top
View users profile Send private message Add User to Ignore List Send email Visit posters website
Bak
?ls -s
0 in


Age:24
Gender:Gender:Male
Joined: Jun 11 2004
Posts: 1826
Location: USA
Offline

PostPosted: Tue Jan 05, 2010 10:47 pm    Post subject: Reply to topic Reply with quote

I think what happened was people quickly realized that if you make everything customizable it will be a nightmare to code and 90% of the things you made customizable won't end up being changed. So now it's on-demand customization, where first HZ or HS (or someone else) introduces a core modification that they use and adds an issue to the asss repository. Later on, the change gets put in for everyone else's benefit. Now the turnaround time may be slower than you would prefer, but I think the current methodology is correct.
Back to top
View users profile Send private message Add User to Ignore List AIM Address
divine.216
Newbie


Joined: Jun 12 2005
Posts: 18
Offline

PostPosted: Wed Jan 06, 2010 12:37 am    Post subject: Reply to topic Reply with quote

@ Bak: agreed, excessive customization via configuration files would be messy to code and would not be worth the time. and I also agree that "on-demand customization" of the entire code base captures how ASSS is currently being used.

But I disagree with your description of a code base maturing to everyone's benefit ("Later on, the change gets put in for everyone else's benefit.") They may drift into the code base, but not in a form usable by anyone but the handful of people who could already use it.

I'm not griping about the time -- I'm griping about the wasted effort and talent. People shouldn't be required to have a working familiarity with all server internals to write a module. It's a waste of their talent and effort. That's what APIs are for -- to abstract away unnecessary detail. But ASSS doesn't have an API. It is a large and deeply integrated codebase tied together in undocumented ways, with periodic hints of modularity, but no stable, simplified, interface to speak of. It is a monolith.

When you have been waist-deep in the code for years, it's understandable that the various components of ASSS begin to feel very modular, almost like an API. The "module" components even proclaim themselves as such. And with only 4 or 5 active developers, any changes are already familiar and they're few enough that it may even feel like a stable API. But it is not. ASSS "modules" that expose "interfaces" are nowhere documented, and are not stable. It is a big body of tightly coupled code that a small number are intimately familiar with.

Parts of it will necessarily be tightly bound together, but they should be the exception not the rule. The core should implement a stable API. And anything that can be done with the API instead of inside the core, should be. This will make the API mature (and supported) and will enable coders less experienced in the core code to write truly modular plugins -- relying only on the API, which will always "work". There is nothing like that in ASSS.

I'm not sure what you meant by calling the current approach "correct". It may maximize some things, but it's not the most fun and it's not the most productive.
Back to top
View users profile Send private message Add User to Ignore List Send email Visit posters website
BDwinsAlt
Agurus's Posse


Age:33
Gender:Gender:Male
Joined: Jun 16 2003
Posts: 1145
Location: Alabama
Offline

PostPosted: Wed Jan 06, 2010 12:51 am    Post subject: Reply to topic Reply with quote

I agree with divine. I think if changes are done to the core, they should be submitted immediately (especially big bugs), and ASSS should have an update process. If a module is essential to run the zone, then ASSS waits until a recycle of the server to install the new module. If it is not essential, then unload, and load the modified module. This keeps everyone on the same page. Include in the src folder the old files as a .bak and the new files as standard. This should be enabled/disabled in global.conf or something.

I really thing ASSS should update and distribute more. It's like there are almost no patches and just major releases. ASSS is on on-going development that needs this patches, and it takes a long time before a final releases turns around.

This in a way solves the problem, adds a little more security/stability, but you may see some flaws. But then again, that's one reason this is open source and open to ideas. That's what makes it so great. I would like to see it on-the-same-page as other servers. It makes things a lot easier.
Back to top
View users profile Send private message Add User to Ignore List Send email Visit posters website AIM Address Yahoo Messenger MSN Messenger
Dr Brain
Flip-flopping like a wind surfer


Age:38
Gender:Gender:Male
Joined: Dec 01 2002
Posts: 3502
Location: Hyperspace
Offline

PostPosted: Wed Jan 06, 2010 6:54 am    Post subject: Reply to topic Reply with quote

Long post ahead.

divine.216 wrote:
@Dr Brain: Broadly, you are absolutely right: my comment was aimed at the way ASSS is "out of the box". But your note about hyperspace and hockey zone tweaking the core modules hints at the underlying cause. People are doing one-off mods to core modules instead of configuring and adding-onto the server.


No, more often than not, people are doing core replacements to aid in add-ons.

divine.216 wrote:
One-off solutions should be done in configuration files. Failing that, they should be done in add-on modules. Only when this fails should they hack up core modules, and this should itself prompt a bug-filing with a request that the core add functionality to the add-on API (perhaps even giving the core-hack code as a sample implementation).


Yes, that's how it's done.

divine.216 wrote:
Note, I said "should" -- of course everyone is free to tweak and modify and use ASSS however they please. But, when a zone faces a problem, their method to solve that problem has an impact on the usefulness of their work. And the usefulness of the work, in turn, shapes the development that grows around the project. If a zone solves their problem with a configuration file, this is immediately useful to everyone, since it can be shared in a forum post or a users guide. If their solution is an add-on module (that works with the vanilla distribution of ASSS), then this too is immediately useful to everyone, so long as everyone can download the add-on module. But if the zone solves their problem by hacking straight into core modules, then their solution is useful to no other ASSS user.


Configuration files aren't solutions to new problems. New modules that read configuration files are solutions.

Also, there's no reason a core change can't be useful to others once it's been integrated into the standard core. That's how things happen, after all.

divine.216 wrote:
It's not clear that anyone is to blame for this core-hacking habit, and I'm not pointing fingers. Put simply, zones want to do more than is possible with vanilla ASSS + configuration files. And, presumably, they want to do more than is possible via add-on modules -- else they wouldn't need to hack at core modules.


You use ASSS if you want to do what's never been done. Core replacements to expose new API are often necessary.

divine.216 wrote:
This situation suggests one or both of the follow: (1) coders are leaping too quickly to hack core modules instead of thinking hard about whether it might be done via add-on module; (2) the modules API is shitty for add-on development or is poorly understood (which causes #1).


Again, if you're using ASSS more than likely you're going to do something that was never thought of before. Meaning there's no provision in the core, and you have to add your own API. And you can't seriously expect the core developers to provide for something that they didn't think of.

divine.216 wrote:
With such a development community, zone admins could grab vanilla ASSS and then pick and choose among the plugins (read: add-on modules). But instead, devs are hacking up core ASSS modules, custom for each zone. This does 2 things: it requires zone admins to be (or to beg) coders, and it reinforces this by never meaningfully improving ASSS core. There are now islands of core hackers that, while sometimes doing neat things, end up being both isolated and isolating.


The vast majority of modules developed aren't core modules. So I'm not sure why you're complaining about it. Core modules are only required to push the boundaries. If an ASSS admin wants to push boundaries, they'd better have a programmer.

How is the core not meaningfully improved?

divine.216 wrote:
...This is why ASSS development is so sloppy and so slow.


I think I should take offense to this.

divine.216 wrote:
...But I disagree with your description of a code base maturing to everyone's benefit ("Later on, the change gets put in for everyone else's benefit.") They may drift into the code base, but not in a form usable by anyone but the handful of people who could already use it.


Why aren't the changes from HS and HZ that got put into 1.5.0 useful to others?

divine.216 wrote:
I'm not griping about the time -- I'm griping about the wasted effort and talent. People shouldn't be required to have a working familiarity with all server internals to write a module. It's a waste of their talent and effort. That's what APIs are for -- to abstract away unnecessary detail. But ASSS doesn't have an API. It is a large and deeply integrated codebase tied together in undocumented ways, with periodic hints of modularity, but no stable, simplified, interface to speak of. It is a monolith.


They're not required to know the internals of the server to write a module. They're required to know the internals of the server to write core modules and create new API.

divine.216 wrote:
When you have been waist-deep in the code for years, it's understandable that the various components of ASSS begin to feel very modular, almost like an API. The "module" components even proclaim themselves as such. And with only 4 or 5 active developers, any changes are already familiar and they're few enough that it may even feel like a stable API. But it is not. ASSS "modules" that expose "interfaces" are nowhere documented, and are not stable. It is a big body of tightly coupled code that a small number are intimately familiar with.


What?

divine.216 wrote:
Parts of it will necessarily be tightly bound together, but they should be the exception not the rule. The core should implement a stable API. And anything that can be done with the API instead of inside the core, should be. This will make the API mature (and supported) and will enable coders less experienced in the core code to write truly modular plugins -- relying only on the API, which will always "work". There is nothing like that in ASSS.


I don't understand. Coders already write modular plugins.



To summarize: ASSS is modular because no human developer can account for all of the possibilities that ASSS allows. New ideas require tweaks to the core to expose new API and functionality. Don't misunderstand and think that all module development is replacing core modules, since that's simply not true.

Hyperspace has had only a few custom core modules over the years (I'd guess no more than 5 total), and now all but one are integrated into the standard ASSS core (the one remaining is fairly trivial and is waiting on a code overhaul before merging). Hockey zone has a similar story.

To contrast, Hyperspace currently uses 58 non-core modules, with many more no longer being used. Probably 20 of these have been released to the public.
Back to top
View users profile Send private message Add User to Ignore List AIM Address Yahoo Messenger MSN Messenger
Dr Brain
Flip-flopping like a wind surfer


Age:38
Gender:Gender:Male
Joined: Dec 01 2002
Posts: 3502
Location: Hyperspace
Offline

PostPosted: Wed Jan 06, 2010 6:58 am    Post subject: Reply to topic Reply with quote

BDwinsAlt wrote:
I agree with divine. I think if changes are done to the core, they should be submitted immediately (especially big bugs), and ASSS should have an update process. If a module is essential to run the zone, then ASSS waits until a recycle of the server to install the new module. If it is not essential, then unload, and load the modified module. This keeps everyone on the same page. Include in the src folder the old files as a .bak and the new files as standard. This should be enabled/disabled in global.conf or something.


No server that's serious about their stability would consider an automatic update system. No other serious server software does this.

BDwinsAlt wrote:
I really thing ASSS should update and distribute more. It's like there are almost no patches and just major releases. ASSS is on on-going development that needs this patches, and it takes a long time before a final releases turns around.


Patches for what? Most of the bugs I've patched lately have been for bugs introduced in beta or unreleased code.
Back to top
View users profile Send private message Add User to Ignore List AIM Address Yahoo Messenger MSN Messenger
L.C.
Server Help Squatter


Age:33
Gender:Gender:Male
Joined: Jan 03 2003
Posts: 574
Location: Missouri, US
Offline

PostPosted: Wed Jan 06, 2010 9:20 am    Post subject: Reply to topic Reply with quote

ASSS is not for everyone divine. Though, I think this is where Discretion may ultimately fail if proper support for Subgame2 is not provided. But I guess this is just a minor detail not to worry about until years down the road -- if this thought may still exist then.

EDIT: I agree with a lot of what Dr Brain and divine say. Unfortunately, there is no perfect solution, or there probably never will be. Linux will always be Linux, and Windows always Windows; ASSS will always be ASSS, Subgame2 will always be Subgame2.
Back to top
View users profile Send private message Add User to Ignore List Send email Visit posters website AIM Address Yahoo Messenger MSN Messenger
divine.216
Newbie


Joined: Jun 12 2005
Posts: 18
Offline

PostPosted: Wed Jan 06, 2010 12:25 pm    Post subject: Reply to topic Reply with quote

@Dr Brain: I apologize for the "sloppy and slow", it was unfair and too harsh.

Dr Brain wrote:
divine.216 wrote:
One-off solutions should be done in configuration files. Failing that, they should be done in add-on modules. Only when this fails should they hack up core modules, . . .

Yes, that's how it's done.

Great!

Dr Brain wrote:
Configuration files aren't solutions to new problems. New modules that read configuration files are solutions.

Also, there's no reason a core change can't be useful to others once it's been integrated into the standard core. That's how things happen, after all.

I agree that new problems will often require some code. But my concern is that the code is done in duplicate because it can't be reliably shared and reused for lack of a stable API. And you are right -- if and once they are integrated into the standard core, then core changes do become useful to others in subsequent releases. But neither of those scenarios is terribly modular -- new add-on modules depend on a sea of other modules instead of on a stable API, and core upgrades depend on a completely new release of ASSS. Again you're right, that is how things happen, but I suggest that it could be better.

Dr Brain wrote:
You use ASSS if you want to do what's never been done. Core replacements to expose new API are often necessary.

I accept that, in fact, most people who use ASSS do so because they want to do something wholly new. And I accept that these new things will often push the limits of existing core functions. But I don't think it's a good thing for ASSS to be so off-putting to people who want to do something more mundane and ordinary, like run a small subspace server.

While it's a lot less sexy to work on run-of-the-mill SS features, it's how to broaden ASSS usage. And it opens up a second tier of developers who would code against the simpler and stable API. This leaves you innovators free to push the core envelope, so long as the existing API remains stable.

It may be that I misunderstand the composition of active ASSS devs. Perhaps it seems like nobody is doing the ordinary and everyone is pushing the envelope (core hacking) simply because there are only so very precious few who are actually doing anything at all.

Dr Brain wrote:
They're not required to know the internals of the server to write a module. They're required to know the internals of the server to write core modules and create new API.

I disagree. A coder needs to be familiar with the various and shifting interfaces that are exposed by modules scattered throughout the code base. This is not an API, this is a set of components that, if draped together just-so, will combine to make the server. I'm not criticizing the fact that the server internals need to be "just-so" but I am criticizing the farce that the internals somehow constitute a stable, usable API for add-on modules.

Dr Brain wrote:

I don't understand. Coders already write modular plugins.
...
ASSS is modular because no human developer can account for all of the possibilities that ASSS allows.

asss/zone1/conf/modules.conf wrote:

. . .
;; the load order of some of these is very sensitive. don't move stuff
;; around without verifying that it's a valid load order.
. . .


ASSS is broken down into components, which are indeed called "modules", but they are tightly dependent on other "modules". This is not modularity. And this is absolutely fine. I'm just lamenting that these components in combination fail to expose a stable API so as to let a 2nd tier of developers write simpler, modular, albeit less innovative plugins using the API.

Dr Brain wrote:
Don't misunderstand and think that all module development is replacing core modules, since that's simply not true.

Hyperspace has had only a few custom core modules over the years (I'd guess no more than 5 total), and now all but one are integrated into the standard ASSS core (the one remaining is fairly trivial and is waiting on a code overhaul before merging). Hockey zone has a similar story.

To contrast, Hyperspace currently uses 58 non-core modules, with many more no longer being used. Probably 20 of these have been released to the public.

HS and HZ are both impressive and beautiful. And together you do the lion's share of moving ASSS forward. We're all grateful. It's also great to hear that you have been able to do a lot of your work without modifying the core. I'm simply urging a cleaner distinction between core and add-on modules so that the community of secondary developers can grow and so that the core can be separately polished for ordinary use.
Back to top
View users profile Send private message Add User to Ignore List Send email Visit posters website
Dr Brain
Flip-flopping like a wind surfer


Age:38
Gender:Gender:Male
Joined: Dec 01 2002
Posts: 3502
Location: Hyperspace
Offline

PostPosted: Wed Jan 06, 2010 1:52 pm    Post subject: Reply to topic Reply with quote

Lets see... about the duplicated code, I don't think there has been any examples of duplicated core modifications between hyperspace and hockey zone, since both zones were working on very different things. You seem to be arguing about a problem that doesn't exist. Lets see some examples here.

The API is stable... Almost all of the .h files haven't changed in any significant way in the last 5 years. I changed a whole lot of things for 1.5.0, but 99% of interfaces were not changed. Those that were would cause about 15 seconds of alteration in any broken module. The biggest change was moving game->SetFreqAndShip to game->SetShipAndFreq to match the parameter order, and if that's what your referring to as unstable, then we have entirely different viewpoints that probably cannot be reconciled. Again, examples of this unstable API would go a long way toward clarifying your concern.

Load order is not what I would call a tight dependency. Put your modules at the end of the file. If you make a module that depends on another module, put the dependency first. If all of your modules are independent, put them at the end in any order you please.

A coder need not be familiar with the entire core API. If they want to send chat messages, they need to know chat.h. If they want to register ?commands, they need to know cmdman.h. If they want to use LVZ objects, they need to know objects.h. If they want to use map regions, they need to know mapdata.h. The list goes on. It's not monolithic like you claim.

You wanted to know why the modules weren't hardcoded. I gave you a perfectly reasonable answer. Now you want to stop innovation so that everyone can use it--the lack of innovation?

I'll need some examples of your problems if we're going to make any progress with this conversation.
Back to top
View users profile Send private message Add User to Ignore List AIM Address Yahoo Messenger MSN Messenger
BDwinsAlt
Agurus's Posse


Age:33
Gender:Gender:Male
Joined: Jun 16 2003
Posts: 1145
Location: Alabama
Offline

PostPosted: Wed Jan 06, 2010 3:13 pm    Post subject: Reply to topic Reply with quote

The thing that bothers me the most is if Hockey Zone wanted to borrow a HyperSpace module, would it work, or would Hockey Zone have to take the time to modify their core instead of just loading the module like any other module.
Back to top
View users profile Send private message Add User to Ignore List Send email Visit posters website AIM Address Yahoo Messenger MSN Messenger
Dr Brain
Flip-flopping like a wind surfer


Age:38
Gender:Gender:Male
Joined: Dec 01 2002
Posts: 3502
Location: Hyperspace
Offline

PostPosted: Wed Jan 06, 2010 3:36 pm    Post subject: Reply to topic Reply with quote

They could borrow basically any Hyperspace module with the exception of a select few. If they wanted those, they'd have to take the modified core module too (which would be fairly trivial, comment out the core one in modules.conf, and add the hs_ replacement). Hyperspace actually uses several modules created in HZ. I don't think HZ uses any HS modules since ours tend to be more specialized.
Back to top
View users profile Send private message Add User to Ignore List AIM Address Yahoo Messenger MSN Messenger
D1st0rt
Miss Directed Wannabe


Age:36
Gender:Gender:Male
Joined: Aug 31 2003
Posts: 2247
Location: Blacksburg, VA
Offline

PostPosted: Wed Jan 06, 2010 8:11 pm    Post subject: Reply to topic Reply with quote

Divine, is this something that is more along the lines of what you are looking for? It's about a year old now and I can't think of any API changes I'd make at this point. I'm a bit biased but at least to me it's simple, with several example implementations and even some docs!

I'm actually drafting up a successor to this framework but I have to finish python support for advisers first.
_________________

Back to top
View users profile Send private message Add User to Ignore List Visit posters website
Arnk Kilo Dylie
Seasoned Helper


Age:36
Gender:Gender:Male
Joined: Jul 14 2006
Posts: 108
Offline

PostPosted: Sat Jan 23, 2010 4:32 am    Post subject: Reply to topic Reply with quote

Threadnecromancygo

Doc, hope you don't mind, but I borrowed fuschia for HZ. :-P

Both HS and HZ hardly even use core-changes anymore. HZ was living dangerously with lots of them but we finally got them all into standard asss. The lag modules still need work though, so I'll admit I swap that one out for a completely new module.

In any case most modules you'll ever want to write won't have to tear up the core to do so. The vast majority of work in both zones has gone into new modules, not changing standard ones. The biggest problem asss had was not being able to intercept and stop default asss behavior, but advisers are going to change that (already have in HZ's perspective), that doesn't leave many problems you'd need to modify the core for.

I am really confused by the need for an additional distinction between core and addon modules... the former are those you download with asss and the latter are not...not all of the modules asss provides are necessary for every zone, that's why you can disable them using modules.conf. (HZ has no flag modules loaded, for example.)

P.S. If you need updates for asss before official releases I suggest taking the plunge and setting up your asss server to be built with things straight from the hg repo. default branch for official things, akd branch if you're a little more adventurous. It should get you more involved.
Back to top
View users profile Send private message Add User to Ignore List Visit posters website
Display posts from previous:   
Post new topic   Reply to topic    Server Help Forum Index -> ASSS Questions All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You can post new topics in this forum
You can 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
You can attach files in this forum
You can download files in this forum
View online users | View Statistics | View Ignored List


Software by php BB © php BB Group
Server Load: 687 page(s) served in previous 5 minutes.

phpBB Created this page in 0.500534 seconds : 41 queries executed (89.7%): GZIP compression disabled