Thought Exercise - Abstracting MoparCoders from the more Esoteric Parad

#21

meiscooldude: I don’t think I have ever seen a project on this website, that actually uses the Waterfall method, as you describe. There’s no specification, there are no design documents and there are no Unit tests etc. What there is, is pretty much only the implementation phase.

I have also never used the Waterfall method in a real project (only in a select few projects during my studies at University). These days it seems like not many uses it anymore (this is based on my observations, so may not be totally true). Instead, these days people seems to prefer the Agile methods. I have successfully used Scrum at one company I was employed. It was great. But I am not so sure if it would work out well if you’re not in the same building (which most of us wouldn’t be, if partaking in a project via this community, for instance).

#22

I’ve always considered Waterfall to be default in the absence of a declared method.

And I’ve worked on (and heard of several others) a team with a remote engineer using Scrum. It is possible.

#23

Disregard the process of development and just go ahead with a project. Start out with a few developers to write the ‘core’ of the server. By ‘core’ I mean networking, updating etc. These few developers should concentrate on making the server more ‘plugin-oriented’ because a majority of people in the RSPS scene still just download a source, stuff code from tutorials into their almighty client.java and run that server. That said, most of the time they copy and paste the code wrongly and face compiling errors which can be easily fixed.

With the idea of plugins, they can instead download a plugin into the plugin folder and run the server with ease. Most importantly, basic configuration for the specific plugin should all be parsed from a file, so they can easily change the messages to send without ruining the plugin with even more errors. RS2 server development will be similar to Minecraft server developments, people write plugins instead of adding onto the original server’s source.

tl;dr: Original developers release a source with an unmodifiable base for plugin developers to write plugins. MoparScapers can download plugins and run their servers with a click!

#24

I think this would probably be the best solution to our problem, mainly because this is the approach that I have taken, and it actually works extremely well. Basically, it is as you said, you have plugins folder where plugins that are built for that version of the ‘base’ are placed, and the server goes through them on startup and loads them up. Then, it loads configuration files that can set variables to pass to a plugin, and that plugin can change things such as messages or XP rate based on that configuration.
[center][/center]

I think this would be the simplest approach to use, because it is an easy drag and drop for the server owner, and then editing configuration files shouldn’t be too hard for them to do with all the .cfg files they have now. Plus, I know that it works.

#25
StaffAreas.jar 49 KB
and that's after compression..........what the fuck...............
#26

you take plugins a bit too abstractly i think

#27

Its great that you really understood my point. :rolleyes:

The file size is first because Mac OS X Snow Leopard uses 1000 bytes as 1 KB instead of 1024 bytes, making every file seem bigger. Second, here is the contents if you are really that curious about it, and please note that 4 KB files are actually < 4 KB, its just their size on the disk:
[center]

9c0K.png1000×618

[/center]

Plus, the point of putting it in a JAR file is so that you can drag and drop disable it. You can put multiple plugins in one JAR file, but then you need to edit a configuration file to disable only a specific plugin in that JAR file.

#28

talk about bloated…

#29

I don’t see anything inherently wrong with distributing plugins as jar files. Ry is right, it simplifies the process.

With that said, abraham is right – those are hefty plugins even just considering the number of classes you’ve used.

#30

and that’s after compression…what the fuck…[/quote]

You guys aren’t actually arguing about whether 49KB is too big for a single plugin are you? This would be the reason no work gets done here. :wink:

#31

I think there’s a lot of reasons that nothing gets done here… that’s just one of them…

#32

Thats one of the points I was trying to make. We shouldn’t be having a discussion about designed a server, its been years, there should be an actual server. I have no control over the size of a JAR file created by Netbeans, and no one has actually commented about the plugin system itself besides Lothy.

#33

since you’re so intrigued by your non-innovative idea of using JARs as dynamic modules, tell us more about how your system maps specific configuration files to specific plugins, what scope the configuration variables have across the application, how plugins bind to the actual application etc

#34

Currently, the configuration system is very basic. The configuration file for a plugin is read as a every two lines being a key/value pair, and then those values are added to a Map and made available to the plugin. There is also a configuration file for the whole server that works the same way, except the values are accessible to the entire server. If plugins wish to load additional files, they can do so.

As far as the binding to the actual application, the system is mostly event based. On startup, plugins register listeners for events with the server, such as a listener for when the player clicks option one on a certain object ID, or when the player logs in, and so on. There are some slight exceptions to listener model, the main thing being the area system. Plugins can register new areas with the server to change the combat setting there, or change the music, or to be notified when entities enter or leave that area. These are registered along with regular listeners, and the server automatically sorts them out and uses them correctly.

Also, if this is such as non-innvative system, why has everyone here been talking about developing a new server for YEARS, yet barely anyone has actually done it and made real progress with such a server? We shouldn’t be having topics about how to develop a new 317 server, we should have a server by now. I’ve provided benchmarks of this servers performance and demonstrated what it can do, and am open to constructive criticism, not flaming.

#35

I agree with ry, abraham. What makes you feel like you can look down your nose at him and act as if you’ve released something better when it is clear to everyone here that you haven’t.

#36

one thing i’ve more recently had concern with in dealing with the plugin idea is ACLs and permissions for plugins.

#37

[quote=“Newty, post:35, topic:375660”]I agree with ry, abraham. What makes you feel like you can look down your nose at him and act as if you’ve released something better when it is clear to everyone here that you haven’t.[/quote]when did i ever say or even imply that i had released something better than ry? ps ry hasnt even released anything either, but regardless, that doesn’t mean i cant tell him when something looks like its bloated as fuck…

#38

So you blame me for:

  1. The size of the bytecode that javac creates.
  2. The size of the JAR file due to the ZIP compression algorithm.
  3. The fact that Snow Leopard defines a KB as 1000 bytes instead of 1024 bytes.

That makes sense. :stuck_out_tongue: Do you have any other comments or suggestions about the actual system as opposed to something completely irrelevant?

#39

[quote=“ry60003333, post:38, topic:375660”][quote author=abraham2119 link=topic=471593.msg3516309#msg3516309 date=1299024017]
that doesn’t mean i cant tell him when something looks like its bloated as fuck…
[/quote]
So you blame me for:

  1. The size of the bytecode that javac creates.
  2. The size of the JAR file due to the ZIP compression algorithm.
  3. The fact that Snow Leopard defines a KB as 1000 bytes instead of 1024 bytes.

That makes sense. :stuck_out_tongue: Do you have any other comments or suggestions about the actual system as opposed to something completely irrelevant?[/quote]umm…

the fact that a plugin defining “staff areas” consists of 100 kb (or 97.7 kb if you were on windows) uncompressed in classes is completely fucking ridiculous and shows how bloated your overall server must be

#40

Its actually 49 KB if you look at the first screenshot, files less then 4 KB appear as 4 KB because of the block size of the hard drive. And also, you have no idea what you are talking about. You make up fake arguments like this because you can’t do this yourself. If you honestly do believe that it is my fault for creating “bloated” bytecode or ZIP files, you seriously need a reality check on how programming and Java works. The capacity of hard disks is now in the terabyte range, I doubt that 49 KB for a plugin matters, and the memory usage and performance of the server are well beyond anything you, or anyone else, has shown. Additionally, you seem like love to argue about nothing, because that is essentially what we are doing. As moparisthebest said, this is something completely irrelevant to the server. I am the one who has already proved multiple times that my approach has been the most successful so far, and I am not saying that it is the best way, but right now it beats everything else. I have no problem debating real issues with other people, but you are obsessing over a small and irrelevant detail, which just makes you ignorant.

The fact that you try and make these kinds are arguments and obsess over these details demonstrates how unsuccessful you must be at programming things that are actually used.