Well, if you're talking about somebody just having their own tan proc, that does the same as a newly built-in tan proc, then the developer should just remove theirs? Why would this be an issue?

Ah, I thought you meant that BYOND should use better naming conventions. I'm not concerned about people who already have defined the tan() proc, but the BYOND staff is far more concerned with backwards compatibility than I am.

Unless BYOND is going to start some official project, where BYOND comes with a handful of competent libraries, then providing something through a library is not a better solution.

It would be nice if people could search for and download libraries from within Dream Maker. It'd be nice to go to the reference page for the cos() proc and see some text that says "if you're looking for more trig procs, download the trig library" and be able to download the trig library right from DM. The BYOND staff needs to go one way or the other - add every feature to DM or add better support for libraries.

The best solution is to have namespaces so the math procs could be in the "math namespace" and they don't clutter up anything else. The next best solution is to put the less necessary procs in a library. The worst solution, because of how DM and the reference work, is to clutter everything with more procs that won't be used.
In response to Forum_account
Forum_account wrote:
It would be nice if people could search for and download libraries from within Dream Maker.

That is kind of the problem to begin with. There is just a clunky collection of libraries made by random users that you have to go out of your way to get. Most of them aren't even of quality worth downloading, and even more of them are just general duplicates. Which, if any of the libraries were worthwhile to begin with, there wouldn't need to be standard breaking duplicates everywhere. In Java or C++, you don't have to go searching for a library, you just pop #include SuperLibrary, and the officially supported, quality verified, standard library is available.
Falacy wrote:
There is just a clunky collection of libraries made by random users that you have to go out of your way to get. Most of them aren't even of quality worth downloading, and even more of them are just general duplicates.

Quality is a problem too, but the biggest problem with finding DM libraries is that you have to know what you're looking for. There are a lot of Java libraries so it's a safe guess that a matrix math library exists, but BYOND has fewer libraries so people are less likely to think "maybe there's a library to handle this". You have to already know what is out there and the tools (DM/website) don't do anything to help.

In Java or C++, you don't have to go searching for a library, you just pop #include SuperLibrary, and the officially supported, quality verified, standard library is available.

That's not always how it works. Those languages still have third-party libraries (of uncertain quality) which you do have to search for and download.

Neither of these problems is that big of a deal, but because BYOND has such great control and knowledge of the developer resources and the development tools, it only makes sense to do a better job of integrating them (especially with the burden it could take off the BYOND staff).
We should have every trig function, for no reason.
//trig function
sin
cos
tan
cot
sec
csc

//inverse trig functions
arcsin
arccos
arctan
arccot
arcsec
arccsc

//hyperbolic trig functions
sinh
cosh
tanh
coth
sech
csch

//inverse hyperbolic trig functions
arcsinh
arccosh
arctanh
arccoth
arcsech
arccsch

//some stuff no one ever uses
versin
vercosin
coversin
covercosin
haversin
havercosin
hacoversin
hacovercosin
exsec
excsc
crd
cis
arccis
My biggest problem with libraries is how they're maintained. First off, there's no simple way to import a copy of a lib into your project. Second, any time they're updated any file you've added stuff to gets overwritten. Third, when updating a lib there's the possibility of leaving behind stub files which might have been deprecated.
My argument against it being a lib is that we don't really have a concept of a 'standard library' in BYOND nor a mentality that would lead to treating one third-party library as the single primary tool for such and such, and the trig functions are simple enough that people won't bother looking for a library to implement them. Maybe Toadfish.pixel_projectiles has some trig functions I implemented. But wait: Forum_account.pixel_movement has that too, so now we have a name clashing or otherwise awkward situation when we include both libraries.

It will also get annoying to have a lot of these kind of 'snippet libraries' that implement simple procs every game needs because you end up having to manage a dozen of them (and download another dozen when you want to include complex library X). Alternatively we end up with a bunch of peoples' 'general everything utility library', which is lol.

Of course, in the grander scheme of things it is preferable to have these things in library format, but not before the system actually supports libraries effectively.
In response to Toadfish
ToadFish wrote:
It will also get annoying to have a lot of these kind of 'snippet libraries' that implement simple procs every game needs

Every game needs inverse hyperbolic trig functions? =)

I see what you're saying but most of these procs don't need to be part of DM - tan, atan, and atan2 are probably the only ones that it makes sense to include in DM.

Maybe Toadfish.pixel_projectiles has some trig functions I implemented. But wait: Forum_account.pixel_movement has that too, so now we have a name clashing or otherwise awkward situation when we include both libraries.

While that can be annoying:

1. It's not likely to happen. There are, at most, 40 DM libraries worth using (that's a fairly generous estimate), so it's just not likely that you'll be using two libraries that define the same proc.

2. It's not that hard to deal with - just have both libraries use the same trig functions library.

3. This isn't the only cause of naming collisions. Providing all trig functions as part of DM doesn't avoid this problem entirely, it only avoids it for these procs.

Of course, in the grander scheme of things it is preferable to have these things in library format, but not before the system actually supports libraries effectively.

It's already possible to handle this situation with a library. What other features would you need? I agree it could use improvement but for this situation you can already handle it effectively.
Goddamnit, I wrote a detailed response to your post and then I got a posting error and now I don't have it. Here's the summary.

- My original post includes those functions which most games would probably use. tan, atan (and atan2), surely. cot and acot are pretty useful. sec and csc - maybe that's overkill, but they can be useful in something like anticipating the change in the angle of a tailing missile that has a specific target.

- In response to 1.: it is actually fairly common, for example some MUD text parser libraries redundantly rewrite procs from Deadron.TextHandling or from your text lib. Alternatively a lot of libraries use Deadron.TextHandling but some probably use Forum_account.text so we have a situation where two libraries meant to accomplish the same thing are included twice.
To further illustrate the point, if you take my snippet in this thread from a year ago and turn it into a library, it will conflict with Jtgibson's vector library and I think some of Lummox's libraries. This is a problem that would've been avoided had the snippet been 'standarised' somehow. However if our standarisation takes the form of a poorly advertised library it won't be effective.
- 2.: Changing the libraries gets fairly annoying since you have to redo it whenever the dev releases an update, for example, and god knows if your previous changes are compatible with that update.
- 3.: Right. This is a broader issue which should really be solved with a more general instrument, doing that will take some more work than just making the trig functions builtin. If you're saying we should abandon this feature request in favour of a broader improvement to libraries that will make it obsolete I agree, although I don't know if it will happen.

The changes I envision to the library system are pretty simple and similar to your envisioned changes: BYOND should endorse a general suite of libraries which will serve as standard tools for game development. They should probably be automatically downloaded together with BYOND itself. Library developers should be encouraged to use this core suite instead of rewriting things themselves.

This change seems to solve most of the issues I discussed in my post. There are also Antx's concerns which should be addressed in obvious ways.
Toadfish wrote:
2.: Changing the libraries gets fairly annoying since you have to redo it whenever the dev releases an update, for example, and god knows if your previous changes are compatible with that update.

The library's author would make the changes.

The changes I envision to the library system are pretty simple and similar to your envisioned changes: BYOND should endorse a general suite of libraries which will serve as standard tools for game development. They should probably be automatically downloaded together with BYOND itself. Library developers should be encouraged to use this core suite instead of rewriting things themselves.

You can use BYOND to make a wide range of game types so how do you determine what tools are considered standard? The Sidescroller library is useful, but I'd only call it "standard" if you're making a sidescroller. If 2% of games are sidescrollers, should we include every library that would be used by at least 2% of all games?

BYOND needs better ways to find libraries and some methods that force exposure to them. For example, have the developer's home page show the four most popular libraries for a particular tag (like how it currently shows the four most popular and four newest). This way people viewing the home page have a good chance to see a library they didn't know about (might as well throw in a "BYOND seal of quality" to indicate which libraries are good). Then, show the developer home page inside Dream Maker when they start it up and people have the ability to new, good, and popular libraries from within the IDE and be able to download them.

I'm not against packaging BYOND with libraries (though it makes the libraries harder to update), but there will always be some libraries that are useful but shouldn't be downloaded with BYOND. People will always need a better way to find and download libraries than what the site provides. While this would all be nice to have, the lack of these features doesn't detract from our current ability to use a trig library.
The library's author would make the changes.

You'd have to contact two independent library authors and get them to change their library to use a third party's trigonometry library.

You can use BYOND to make a wide range of game types so how do you determine what tools are considered standard? The Sidescroller library is useful, but I'd only call it "standard" if you're making a sidescroller. If 2% of games are sidescrollers, should we include every library that would be used by at least 2% of all games?

Yes, if it seems relevant enough to game development. I don't see why including many libraries is a problem. We can have many standard libraries, we're not forcing the game developers to include them. The focus is on covering the core tools a game developer might need and putting them in one, standard package, so that their exposure is essentially identical to that of the builtin procs. You can even update the reference to have them in mind: say, in the arctan2 page write, 'dependencies: BYOND.math'. If the concern is that the package will get cluttered well, as you said, we only have about 40 libraries worth using.

Edit: Alternatively, we only include those libraries that have a more abstracted utility; math, text handling, HUDs, et cetera. This is a better alternative if people get concerned about the Sidescroller library not implementing sidescrollers the way they'd like.
In response to Toadfish
Toadfish wrote:
You'd have to contact two independent library authors and get them to change their library to use a third party's trigonometry library.

It's very easy to contact a library's author. Libraries have their own feature request forums and you can send the author a pager message or e-mail. Also, this is the kind of thing that library developers should know to do on their own.

Yes, if it seems relevant enough to game development. I don't see why including many libraries is a problem. We can have many standard libraries, we're not forcing the game developers to include them. The focus is on covering the core tools a game developer might need and putting them in one, standard package, so that their exposure is essentially identical to that of the builtin procs. You can even update the reference to have them in mind: say, in the arctan2 page write, 'dependencies: BYOND.math'. If the concern is that the package will get cluttered well, as you said, we only have about 40 libraries worth using.

There are lots of problems with packaging them directly with BYOND.

1. How do the libraries get updated? Is the BYOND installer updated every time one of the core libraries is updated?

2. What happens when a better library is made and should replace one of the core ones?

3. While there may only be 40 worth including at the moment, with how marginally useful some of those may be it'd be easy to argue for any library's inclusion.

4. Giving increased exposure and reference pages to core library functions is good for them, but hugely detrimental to non-core libraries.

The libraries that would be considered the core libraries will, along with other quality resources, be prominently displayed on the developer page. If you can browse that page from within Dream Maker you can easily find a library, download it, and inlcude it in the current project. That way you don't have to worry about which ones are packaged with BYOND and you're not giving them special treatment - the top resources will always be easily accessible to DM developers.
It's very easy to contact a library's author. Libraries have their own feature request forums and you can send the author a pager message or e-mail. Also, this is the kind of thing that library developers should know to do on their own.

It's even easier to avoid the problem in the first place!

(Incidentally, how do you work out which library to use when say, one uses Deadron.TextHandling and the other uses Forum_account.text?)

There are lots of problems with packaging them directly with BYOND

(edit - I have no idea why this part of my post is in bold, site quirk?)
It's not exactly the important part of the idea, so I guess we could think of an alternative. The important thing is finding a way to centralize them. Packaging them with BYOND is just kind of nice because you immediately have access to an array of libraries you can use to jumpstart your game. Let's discuss the issues you raised though:

How do the libraries get updated? Is the BYOND installer updated every time one of the core libraries is updated?

Can't we just have BYOND automatically check for/download them after it's finished installing?

What happens when a better library is made and should replace one of the core ones?

The purpose of the core libraries is to have an API shared by library and game developers, so if the improvements in the better library can be fitted unto the core libraries (maybe it's more efficient, or has more features) we can update them. If the new library is better by virtue of its API then it'll probably be a case-by-case basis.

While there may only be 40 worth including at the moment, with how marginally useful some of those may be it'd be easy to argue for any library's inclusion.

True enough, I don't exactly have a complete vision of what core libraries will include. It might be better to go with my second suggestion of packaging only things that we can expect any game (and many libraries) to use - math, HUDs, text manipulation, .... But really I don't know. Maybe you have a better idea?

4. Giving increased exposure and reference pages to core library functions is good for them, but hugely detrimental to non-core libraries.

Will it? It shouldn't be, as long as those non-core libraries aren't meant for issues the core libraries can handle. For example having a core HUD library shouldn't detriment from the exposure of your Sidescroller library.

The libraries that would be considered the core libraries will, along with other quality resources, be prominently displayed on the developer page. If you can browse that page from within Dream Maker you can easily find a library, download it, and inlcude it in the current project. That way you don't have to worry about which ones are packaged with BYOND and you're not giving them special treatment - the top resources will always be easily accessible to DM developers.

This is another possibility. I don't very much agree with you that also including them with BYOND will be a serious issue, but even just prominently displaying them might be fine. The question is, will simply displaying them encourage people to actually use them in favor of writing their own version? Builtin integration has the advantage of immediateness and accessibility, which just displaying them might not have. (We would also make sure that other prominently displayed resources don't clash with the core libraries, which is harder when they're on-site).

Maybe a best of both world's solution is called for - upon opening DM the developer is prompted with a sort of 'questionnaire' inquiring about the kind of project he would like to make. Maybe he's making a MUD - so BYOND then checks its 'featured' and 'core' libraries for libraries which might be relevant to MUDs, and recommends them to him. Maybe he wants to download Toadfish.MUDLibrary, so then BYOND checks what dependencies Toadfish.MUDLibrary has and downloads them - Toadfish.MUDLibrary, BYOND.TextHandling, Forum_account.MUDParser, et cetera.
In response to Toadfish
Rather than a questionnaire, why don't we just use check boxes? Think of Windows Live essentials. You choose what programs you download with it, if any. The same could be done for a list of libraries and such. The ones the developer chooses are the only ones that are added.

Alternatively, if including it at install is a problem then we should think of something like Dark Basic Professional; where there is a page that displays all the 'add-ons' you can download to include with the default build. Mind you with theirs its packs you can purchase, but BYOND could simply have it be free ones that have the proper support and such behind them.

Then all BYOND would need to do is make the page, set it up so that it can be handled appropriate by the developers and staff, then finally just link to it after installation and let people choose to open it if they want; much like they do for looking for games after download etc.
Rather than a questionnaire, why don't we just use check boxes?

This is basically what Forum_account suggests. I have no problem with it. However, I also do like the idea that you can tell BYOND 'I want to make a game of this genre' and it recommends libraries that will help you jumpstart on that.
In response to Toadfish
Toadfish wrote:
(edit - I have no idea why this part of my post is in bold, site quirk?)

My guess is because the text ends with a colon and comes before a quote.

The problem with including libraries with the download is keeping the versions up to date. If you're going to let users download content from Dream Maker, let them access any developer resources. The types of resources you're talking about could be handled by tags or other changes to the developer page. Either tag certain libraries as being "core" libraries or make a "featured" status for libraries. There could be a similar tag or listing for the "starter kit" type of library. All they need to do is fix up the developer page a little and make Dream Maker capable of displaying the web page (the reference can already do this).

While it'd be nice to have a menu shown when you create a new project with options for different game types, I'm not sure that's feasible. The staff seems hesitant to add any features like this, and if we're going to get one feature, I'd rather have a way to browse and download resources from Dream Maker than a nice menu for downloading one of a few different resources.
Anyhow, we've kind of gone off-topic. What's clear from our discussion is that it's an interesting idea that clearly needs some more thought - although that thought should probably take place in a separate feature request or BYOND Discussion =P.

I'd say this (the trigonometry) feature request should be suspended for the time being until either someone figures out how to make libraries work, making it obsolete, or it becomes clear this kind of thing should generally be builtin. This is not an urgent feature request so it can take the backseat.

Of course, I'm not in charge of this feature request or anything so if someone like Falacy does think it's urgent enough he is welcome to make his case. I'm adjourning court for now.
Lummox JR resolved issue with message:
tan() and arctan() procs have been added. arctan() can either be called with a single value, or with x,y. (Note: Many languages handle the two-argument form of arctan() by using y,x order, but we're not doing that because it's stupid and nobody should have done it in the first place.)
Page: 1 2