Woodand: Macrowski: A polyfill, or a shim, should be a spec-compliant method of providing functionality to older environments that lack it. See !es5 shim, !es6 shim, !do***ent.head, !raf, !now, etc.
Woodand: Macrowski: To get every backwards-compatible feature of ES6 in every browser and node, use https://www.npmjs.com/package/es6-shim ! It’s heavily tested, comes with Promises, and using the !es5-shim as well is strongly encouraged.
Falk: Thanks Macrowski didn’t know about that
Lizarda: Macrowski: i should use both es5 and es6 shim at the same time?
Macrowski: Fa, e, x = e ? erre : gx, e, y = e ? erre : hy === fa.theng.thenh.catcherr
Macrowski: What do you find more readable?
Macrowski: Annoymouse, depends what browsers you need support
Rumsey: Macrowski: okay thanks
Fogerty: Anoniem4l: yes, you should use both. no browser exists that doesn’t need the es5-shim for something.
Starowitz: Does JS have more than one ‘kind’ of string?
Zeck: Like a UTF string or a ASCII string type?
Viltz: That typeof just reports as ‘string’ even though they are different.
Fogerty: Totlw: no, only one kind
Fogerty: And all JS strings are composed of UTF-16 characters
Lackey: Just wondering why the sin wave in this went all off after the first reflection : http://sendvid.com/i14apdta , here’s a link to the reflection code : https://github.com/geo7/sinny/blob/master/main.js#L78
Millspaugh: I’m guessing thats what’s causing it at least.
Jakuboski: Python has a ‘unicode’ type and a ‘string’ time, and even though in JSON that looks the same, somehow that ruins everything for neo4j
Ciliberto: So i have a string like this:
Debrae: But i need it to be like this:
Fournier: Totlw: Sounds ***uely like encoding to UTF-8 maybe?
Julander: I dont really understand Unicode and all the ways to encode it
Recla: In Python its a simple variable.encode’utf-8′ or a variable.decode’utf-8′
Glab: But i dont know how to do that in JS :
Fournier: Yeah I’m not sure either, heh. There must be one somewhere.
Kimple: Baxx: there are a few reasons thats not accurate
Menes: Tcsc: what’s the most obvious?
Kimple: The two most are your integration isn’t 2nd order accurate, and you aren’t resolving the collisions at the point of impact
Kimple: You’re just noticing a penetration has happened
Kimple: But you arent taking into account when it happened
Kimple: The 2nd is more likely
Kimple: Well, the’re both true, but idk if the 1st would cause this particular bug
Kimple: I dont think it would
Kimple: Vel += acc; pos += vel; is euler integration
Majestic: Right, I’ve not done much integration, I’ve done a little bit from a textbook but not enough to ‘know it when i see it’ practically so to speak
Kimple: I don’t mean solving integrals.
Kimple: Either way, there’s an implied time parameter here.
Kimple: Vel += acc*dt; pos += vel*dt
Kimple: It doesnt make a difference since you’re doing 1st order integration
Kimple: Vel += acc*dt; pos += vel*dt + acc*dt*dt*0.5; is more accurate.
Kimple: And 2nd order accurate
Kimple: The issue is probably your collision detection
Marcinek: Right, well i guess i need to read about integration
Kimple: No fix your collision detection
Kimple: Those are the two things that stood out to me as possibly causing simulation errors
Kimple: But the collision detection here is almost certainly the issue
Kimple: What is the point of adding getters and setters to a point cl***?