Hey guys, I'm just gonna throw this out there. Anybody wanna kick in ideas for stuff that needs to go into a community-made stdlib?
My contributions:
Math:
+ floor()/ceil() (floor rounds left, while ceil rounds right)
+ clamp() (clamp a value between min and max)
+ inner()/outer() (round away from or toward zero, AKA truncation and inverse truncation)
+ decimal() (returns the decimal component of a number)
+ atan2()
+ ang2dir()
+ dir2ang()
+ getang()
+ to_places() (reduces a value to a set number of decimal places)
+ left_x() (the following 6 functions return absolute pixel coordinates of an object's bounding box)
+ right_x()
+ center_x()
+ bottom_y()
+ top_y()
+ center_y()
+ hypotenuse() (supply a and b to get c)
Strings:
+ begins_with()
+ begins_withEx()
+ ends_with()
+ ends_widthEx()
+ replace_text()
+ replace_textEx()
+ tokenize()
+ tokenizeEx()
+ trim_whitespace()
+ findtext_all()
+ findtextEx_all()
* findtext_last()
* findtextEx_last()
* JSON2datum()
* datum2JSON()
+ dir2text()
+ text2dir()
+ screen_loc2num()
+ copy_after()
+ copy_afterEx()
+ copy_before()
+ copy_beforeEx()
Object Management:
* datum.Cleanup() (replaces Del() to speed up garbage collection)
* datum.Clone() (override function for creating clones of objects)
+ islist()
+ ismovable()
Constants:
+ TICK_LAG
+ TILE_WIDTH
+ TILE_HEIGHT
+ FPS
Client-server utils:
* JS<->DM communication utilities and standard JS functions for working with DM
* client.browser_vendor
* client.browser_version
* client.JSCall()
* client.JSCallback()
Keyboard interaction:
+ key defs
+ key categories
+ key_category()
+ key_name()
+ name2keycode()
+ char2keycode()
+ keycode2char()
Interfaces:
+ appearance datum interface
LordAndrew's contributions:
+ tan()
+ arctan()
+ cot()
+ arccot()
+ sec()
+ arcsec()
+ csc()
+ arccsc()
Anybody else got anything good that needs to go into a DM stdlib?
Rickosay's contributions:
+ client.mouse_x
+ client.mouse_y
* client.mouse_state
+ client.mouse_buttons
ID:1872243
Jun 12 2015, 4:20 pm (Edited on Jul 18 2015, 6:00 pm)
|
|
Jun 12 2015, 4:23 pm
|
|
We need round UP and round DOWN.
|
A working eval() Never gonna happen. I've already written a DM parser and VM before, and I'm not impressed with how slow it is. |
Missing trigonometry functions, maybe isclient()?
Ter13 wrote: * datum.Cleanup() (replaces Del() to speed up garbage collection) Could you elaborate more on how this works? |
In response to LordAndrew
|
|
LordAndrew wrote:
Missing trigonometry functions, maybe isclient()? I assume it looks through the variables and removes any and all references and then sets its loc to null |
I can't think of anything else right away, but I will try to remember to check back Monday, when I have time on the computer.
|
In response to Developous
|
|
Round up: ceil(n), or -round(-n).
Round down: floor(n), or round(n). They're actually the first two things on the list. |
A bunch of the math and dir stuff is done:
#define floor(x) round(x) And a bunch of the text stuff is done: proc |
In response to Kozuma3
|
|
Kozuma3 wrote:
LordAndrew wrote: Actually, no. That's the worst way you can do this. By default, datum.Cleanup() does nothing. It's simply an analogue to a C++ destructor. I'm trying to wean this community off of del. It's slow and shitty. datum It's intended to be a centralized destructor where developers manage their references and clean up anything that would prevent garbage collection. Though I suppose that I could borrow a leaf out of SS13's book and develop a weak-ref checker that will wait one second and then call del on an object if it's still not been successfully garbage collected after Cleanup() has been called. That would ensure that Cleanup() actually works to destroy the object, but doesn't call del unless the developer has screwed up. |
It might be too big to include, but line of sight comes to mind. I personally find it odd that someone had to develop a way to determine what is in a mobs line of sight their self, rather than have it available by default.
Again, might be too big, but given the wide variety of step and walk procs I'm surprised there is nothing built-in that efficiently tells a mob to walk from point A to point B and back x amount of times or infinitely. I saw some pretty interesting handling for this and a number of other walking things via nodes somewhere on the forum not long ago though. I'm noticing a something almost any project can use kind of pattern, so a player tracking and counting proc or two might make sense. Seems like just about every game internally keeps track of who and/or how many are logged in now, but that's pretty easy to do and how they're sorted is up for debate so ehhh. Probably pretty useless, crazy ideas for this lib set up but I saw all the major stuff, had a minute to post, and figured I'd mention the first things my mind thought of at least. |
Yeah, They aren't bad ideas by themselves as far as things that would be of use.
The problem is that those kinds of things introduce impact to the project that not every project needs. Pathfinding in particular is one that just can't be generalized to every project, because making it flexible enough to be highly customizable by the end user will always introduce huge delays in processing. Pathfinding code is meant to be very tight, and writing generalized tight code is extremely difficult. |
I notice that people around here handle angles and directions differently. I prefer this way (east being 0 and counterclockwise).
|
Yeah, that sounds about right. It's unfortunate, but some of the most useful stuff just can't be generalized enough to make it work for something like this.
I remember coming across this before with genre specific game foundation ideas. Great in theory, but way too hard to generalize most of the major ones. Otherwise I'd be trying to lead a campaign for creating a lib like this for side scrollers, turn based strategy, platformers, and so on. Anyways. I haven't had any luck thinking of anything, unless something HUD or on-screen related could fit in here. Pretty sure it's too broad to cover, but much like the del() issue there are a lot of bad habits in desperate need of an assault that I know you've been going after. |
I've got a pretty nice interface lib, but a lot of people don't like the way I manage object creation and configuration, so I haven't released it fully... I might think about putting it into a library soon.
|
In response to Ter13
|
|
Ter13 wrote:
Actually, no. That's the worst way you can do this. > datum It's intended to be a centralized destructor where developers manage their references and clean up anything that would prevent garbage collection. Good luck with that. |
A gamepad control for the webclient (I have a working source code for one, based on a library that someone had written a few months back but deleted) could fit well here too, correct?
|
A gamepad control for the webclient (I have a working source code for one, based on a library that someone had written a few months back but deleted) could fit well here too, correct? I'm more thinking language features. |