More friendly development process/tools for Nexus?

Hi Everyone,

I played Achaea 15+ years ago, and have just started back up. I'm hoping to use Nexus to give myself some practice with ES6 and balance playing with learning, but I'm struggling with the Nexus interface. It's difficult to untangle someone else's packages, and slow going to develop my own with the web interface.

Has anyone developed a workflow or build process they're willing to share to make it easier to develop for Nexus? I'm assuming that someone out there has a way to convert JS files into a .nxs package (which looks like it's just JSON?), or to otherwise get it into an IDE or editor to make things easier? I've found "source" JS on github for systems which appear to have been developed with an IDE (Nexsys) or use a build process (Bushido w/Yarn) but I'm not quite up to figuring out anything beyond that.

 Or, am I overthinking this and missing something simple here?

@Jhui I've been using your Nexsys package, and @Zahan your map mods, so if either of you have input I'd greatly appreciate it.

Thanks in advance everyone!


Comments

  • Mcdougall said:
     I'm assuming that someone out there has a way to convert JS files into a .nxs package (which looks like it's just JSON?),


    Someone else asked this recently and I believe the answer is as simple as changing the file extension.

    I don't use nexus though, so don't quote me.
  • @Leffe thanks for the reply.

    .nxs files look like they're JSON, so I don't think switching a non-JSON JS file to .nxs is going to give you a file that works in Nexus (could be wrong if there's some vodoo black magic going on, or if I missed something). It's possible people are writing code wrapped in the required JSON for Nexus, but that also feels pretty painful.
  • ZahanZahan Valhalla
    Sorry for the late response.  <insert excuses here>

    So far nobody i have talked to, is messing with file conversion.  The reasons you stated lead most of us to just develop plugins inside nexus settings, which isn't as much of an issue as you'd expect because the interface is pretty decent (minus the occasional bug).  I'll cover why this is actually a non-issue entirely for me below.  The PITA mostly is in digging through another's plugin you don't yet understand.

    I don't have an exact workflow/build process, honestly - I just wing it.  Although, I do always start with the "onLoad" function.  It's in this nexus function that i define nearly all of my javascript functions for that plugin, and that works for me as opening the file itself in any other text editor would.  Before nexus, I coded all my mud plugins in file form but I actually like the layout of the nexus settings enough, with how i use the onload, that i don't miss it.

    My plugins, at least, should be easy enough to dig through, especially if you start in the "onLoad".  As an old timer, my theory on coding is this: necessarily complicated stuff will be commented and have some sort of organization.  Lacking this, it should be immediately obvious what it is doing (because it is simple enough) or it's probably not worth bothering with.

    Also worth noting, and sadly shouldn't be last because probably the most helpful... is the achaea discord community.  There we have a dedicated nexus channel where even the big codedog Tecton himself pops in to help (and it doesn't take me a week to answer).  It's easy enough to find and I'm lazy (or energy efficient, as i like to call it) so no link to it here but feel free to ping me there with any questions you have about any of my plugins for a faster response.


    tl;dr: onLoad is OP af.
    Click here for Nexus packages
    Currently available: Abs, Cnote, Keepalive, Lootpet, Mapmod
  • TectonTecton The Garden of the Gods
    Yep, most browsers block .js(on) file extensions these days, so we call it .nxs, but it is just json!
  • edited June 2018
    @Zahan thanks so much for taking the time to reply with an overview as well as details. I appreciate it.   

    Zahan said:
     As an old timer, my theory on coding is this: necessarily complicated stuff will be commented and have some sort of organization.  Lacking this, it should be immediately obvious what it is doing (because it is simple enough) or it's probably not worth bothering with.

    tl;dr: onLoad is OP af

    +1000000000000 points for the above. The best decision I've ever made was to hire a developer 30+ years my senior who thought this way. He completely derailed the interview to walk me through his reasons, then dug into a few real life projects. It was surreal that he could prove the COBOL he wrote in the 80's was still processing my bank transactions reliably in 2014, and that the JS he wrote in 2010 was the (easy to follow and well documented) foundation of a project we worked on last year. I learned more about writing real-life code in my first few months working with him than I did the last 5 years.

    Anyway, rambling aside... thanks also for the info about how you structure things and use onLoad as a starting point. I had noticed comments, but as I haven't had more than a couple of hours each week to dig into Achaea over the past couple of months I hadn't picked up on onLoad being so prevalent.

    So... thanks!

    I'm sure there will be more questions to follow. Cheers for the answers so far everyone.

Sign In or Register to comment.