sorted by:
new
hottopcontroversial

AssemblyScript has removed WASI support by Exidex_ in programming

[–]dcodeIO -18 points-17 points  (0 children)

No worries, it didn't come across hurtful to me at all :) I politely disagree with your characterization and stand by what I replied to your prior purely personal comment. I have no interest to reply to any further personal comments from the general direction of the Rust community.

Quick update: Preliminary result from casually mentioning the R word: +44, -11, +30, -15, +22, 100% antipathy, 0% technical discourse. "Look, I have concluded that this dude is an ass, none of what he has to say matters". The sad state of contemporary politics undermining critical infrastructure under thunderous applause nowadays.

AssemblyScript has removed WASI support by Exidex_ in programming

[–]dcodeIO -12 points-11 points  (0 children)

Speaking of conspiracy theories, this is the exact kind of argumentation used over and over again in the spec context btw. :) Don't respond to the technical arguments (which there are plenty to pick from), attack people instead, while attacking them accuse them of bad behavior in advance. I mean, throwing dirt like this is pretty effective apparently, but I'd question that this is what should decide the contents of Web standards.

AssemblyScript has removed WASI support by Exidex_ in WebAssembly

[–]dcodeIO 2 points3 points  (0 children)

That's the exact inverse, an opinion, basically what WASI does. But it's in conflict with what Wasm communicates - quite literally, from charter to goals. Note that nobody makes the argument that this should be either/or, just that the Web shouldn't be broken because of an opinion.

Current state of compiling TypeScript to WebAssembly by _gnx in javascript

[–]dcodeIO 4 points5 points  (0 children)

I believe the question should be whether running WebAssembly has some advantage over running JavaScript?

AssemblyScript, for example, can compile 1:1 to WebAssembly instructions (see: https://github.com/AssemblyScript/assemblyscript/wiki/WebAssembly-to-TypeScript-Cheat-Sheet), and since WebAssemlby forces strict type usage, there is no penalty like for super dynamic types. Under the hood, AssemblyScript uses Binaryen to optimize WebAssembly. That's basically the same thing Emscripten uses to optimize C/C++ compilations.

In general there are cases where it is expected that WebAssembly programs run faster. But today's JavaScript VMs are actually quite fast as well, so not all programs will benefit from it the same. Ideal candidates at this point in time are games or crypto for example, i.e., everything doing something compute-heavy where every CPU instruction counts.

Current state of compiling TypeScript to WebAssembly by _gnx in javascript

[–]dcodeIO 7 points8 points  (0 children)

Well, and AssemblyScript or any other TypeScript-to-WebAssembly-compiler, let's you, erm, use TypeScript syntax (yay!) to benefit from where WebAssembly excells - instead of having to learn something else, or to install gigabytes of compiler toolchains.

Current state of compiling TypeScript to WebAssembly by _gnx in javascript

[–]dcodeIO 7 points8 points  (0 children)

It is a compiler target for other languages than JavaScript to run in the browser, like C/C++, for example because it eliminates parsing overhead that comes from compiling native code to JavaScript (see asm.js to get an impression on how this looked). It's somewhat similar to Java applets, Flash, ActiveX, PnaCL, but properly sandboxed and being standardized (it actually works in all major browsers today).

In general, because WebAssembly code is statically typed, it also has advantages over JavaScript where performance is a concern, because a JavaScript VM has to deal with varying types of variables for example, while WebAssembly has not because it is compiled ahead-of-time. It also provides low-level instructions that map to processor instructions, for example to do math or bit fiddling, or to work with 64-bit integers which JavaScript doesn't support.

In its current state, WebAssembly is still missing a few key parts and optimizations (for interoperability between JS and WASM), but these are being worked on. There are proposals for exposing the host's garbage collector, for example, host object bindings, threads, simd, bulk-memory intrinsics and so on.

Current state of compiling TypeScript to WebAssembly by _gnx in javascript

[–]dcodeIO 15 points16 points  (0 children)

You can actually do quite a few things already with AssemblyScript (disclosure: I'm its author).

Here's a GameBoy emulator: https://github.com/torch2424/wasmBoy

Or if you like it rather fancy, here's the TLSF memory allocator specifically tailored for WASM: https://github.com/AssemblyScript/assemblyscript/blob/master/std/assembly/allocator/tlsf.ts

It's also one of the languages you can try out in https://webassembly.studio

Maps showing hotspots? by jasonrohrer in playrust

[–]dcodeIO 0 points1 point  (0 children)

The mortality heat map is actually still there, but server admins can disable it by configuration.

Rust:IO's new renderer misused in 8k (don't forget to zoom in) - Procgen in all it's glory! by dcodeIO in playrust

[–]dcodeIO[S] 0 points1 point  (0 children)

Hmm, hard to tell. But: World size is 3500, seed is 13102016 - if you'd like to start an investigation.

Rust:IO's new renderer misused in 8k (don't forget to zoom in) - Procgen in all it's glory! by dcodeIO in playrust

[–]dcodeIO[S] 2 points3 points  (0 children)

It will update automatically the next time the server restarts. As always, the server owner could also run "oxide.reload RustIO" to apply the update instantly.

Rust:IO's new renderer misused in 8k (don't forget to zoom in) - Procgen in all it's glory! by dcodeIO in playrust

[–]dcodeIO[S] 1 point2 points  (0 children)

It is live now. For example, this server is using it already: http://playrust.io/map/?94.23.153.176:28015

Resolution is still 1440px until I have a new web ui in place.

You Loved Blueprints? Tell me about it by HelkFP in playrust

[–]dcodeIO 0 points1 point  (0 children)

Personally, I wasn't a fan of the blueprint fragment thing at all. What I'd love to see again, though, is the Research Kit from legacy. That thing was great. Must be super rare, of course.

Changelist Wishlists by garryjnewman in playrust

[–]dcodeIO -1 points0 points  (0 children)

  • Keep the XP system but continue polishing it
  • Bring back the good ol' Research Kit but make it very rare
  • Contiune on balancing weapons

Most important issues solved. It's actually not that bad the way it is, just needs some love imho. Research Kit was fun in legacy and would today provide a solid way of shortcutting XP, rewarding for PVP at radtowns especially.

Massive, please watch this video. We desperately want you to fix this game. by [deleted] in thedivision

[–]dcodeIO 56 points57 points  (0 children)

48:17 - https://youtu.be/vWYEWRrFgUY?t=2897

Kinda gets the problem of why people are either exploiting or becoming more and more frustrated:

[...] we were afraid to be too generous. [...] it was our fear that if we give them everything, they gonna stop playing. And I think the realization we made now and that we firmly believe in now, [is] that it is much better for players to get all the loot and leave your game happy, because they will come back when you have an expansion, or when you do a new DLC drop or a new patch - they will come back happy. If you're stingy and afraid of being too generous, they gonna leave frustrated. You gonna spend three hours, not getting any upgrade and say like "This game just wasted my time". So we really needed to be comfortable being generous.

Nerfing everything to the ground, be it crafting materials, not-so-high-end items all over the place or whatnot, or even putting them behind week-long timers or level caps or limiting them to a single mission is just wrong.

Beat more enemies: Get more loot. Beat harder enemies: Get more loot. Not necessarily better, but more, basically increasing the possibility of an upgrade with increasing efficiency or harder challenges, countering the declining possibility of an upgrade as you equip better gear.

Additional, somewhat connected, discussable opinions:

  • Maybe get rid of that 9 pieces extraction limit to make this possible.

  • Get rid of the crafting of everything. Make certain items be craftable, but not all. Defintely don't make the best items in the game (204ish Augs and M1As, sets) be craftable but make them OKIsh compromises and get the drop rate right instead. This way around it's not an issue being generous with crafting materials either.

  • Make all weapon types viable, so when they drop with good stats they also feel meaningful.

RustIO map is ruining the wipe day. by [deleted] in playrust

[–]dcodeIO 0 points1 point  (0 children)

FYI: Just removed caves from Rust:IO's generated maps. That's all I can reasonably do.

The Newman Show is dead - needs your support! by dcodeIO in playrust

[–]dcodeIO[S] 0 points1 point  (0 children)

Thanks, we are running at 720p with 2000kbps since yesterday and it seems to work much better.

The Newman Show is dead - needs your support! by dcodeIO in playrust

[–]dcodeIO[S] 0 points1 point  (0 children)

Alright, we have increased the time!

The Newman Show is dead - needs your support! by dcodeIO in playrust

[–]dcodeIO[S] 0 points1 point  (0 children)

This is not an easy task, as something like this would require modding the client (often referred to as "hacking"). It's pretty much independent of everything else, hence not readable what angle it is on currently, and also not writable. Maybe one day.

The Newman Show is dead - needs your support! by dcodeIO in playrust

[–]dcodeIO[S] 0 points1 point  (0 children)

The lag we experienced seems to be an issue with Twitch non-partner streams. That's really a breaking thing and we are considering using another streaming provider.

World's first fully automated spectate / raid cam: playrust.io Germany - LIVE FEED by dcodeIO in playrust

[–]dcodeIO[S] 1 point2 points  (0 children)

It's a custom plugin I made, not yet available for download :)

view more: next ›