[NEXUS] Bip-core reflex package

Hello, everyone.

I am relatively new to Achaea. When I first started, I found a fair amount of code for Mudlet but there wasn't all that much out there for Nexus packages, especially basic functionality for new players. I used to be a programmer over a decade ago and decided it would be a nice little project to make and release a package.

Please keep in mind this is a 1.0 release. If there is demand, I intend to continue development based on received feedback.

This is the current feature list (Bip-core 1.0):

    Aliases
        - Useful aliases, such as "afk" for disappearing into a journal, "st" to set target, and to use Tattoos.
   
    Auto-learn Acceptance
        - Automatically accepts requests from other adventurers to learn from you.
        - Contains logic to highlight the line notifying you when you earn free lessons.

    Auto-loot for Coins
        - Automatically loots gold sovereigns dropped after you kill a denizen or adventurer.
        - Use alias "autoloot" to enable or disable. Default enabled.
        - Automatically prevented if someone else got the killing shot.
           
    Automatic Leader Target Switching
        - Set the leader that controls your target with alias "at <leader>". Disable with "at none".
        - Automatically switches target selected when the set leader indicates a new target in partytalk channel.
        - Allows for multiple common formats for leader-selected target switching.

    Manual Fleeing
        - Uses aliases "flee" and "flee <direction>"
        - Standard movement to direction if specified; if not specified, starts north on compass, goes clockwise, up, down, in, then out checking for exits.
        - Pulls exit information from variable exitList

    Player Name Colors by City
        - Use the "pc" alias (Process City) to show player names in a color corresponding to the city of which they are a citizen (if any).
        - Other aliases include: "SaveCities" and "LoadCities" to save to/load from permanent variables and "ResetCities" to reset all city data to empty.
        - Use 'Save Client Settings' button to make the SaveCities/LoadCities data permanent for your next logon.

Other features of Bip-core include useful variables for your own character's various statuses including rage and afflictions that you can use by adding onto Bip-core or making your own modular package.

Additional documentation is in the top-most function named README-DOCUMENTATION.

To install Bip-core:
Download the latest file from github here:
https://github.com/Bip-Achaea/bip-core/archive/master.zip
Open the zip file and take out the dated .nxs file. You can then open the Nexus client settings, go to the Reflex Packages tab, and drag the .nxs file into the indicated box.

***IMPORTANT: After importing the package, log out from the game (qq) and log back in. Otherwise you will get errors. ***
(This is required because variable initialization takes place in the onLoad function, which only runs upon initial login).

Please let me know what you think - this is a 1.0 version and has been tested for a couple of weeks, but there are likely bugs. Feedback is very welcome and needed if I am to continue development.

-Bip
«1

Comments

  • KlendathuKlendathu Eye of the Storm
    Great to see Nexus scripts being shared

    Tharos, the Announcer of Delos shouts, "It's near the end of the egghunt and I still haven't figured out how to pronounce Clean-dat-hoo."
  • OH GOD @Bip YOU'RE A GODSEND.  I HAVEN'T ACTUALLY EVER BEEN ABLE TO FIND OUT PARTY LEADER TARGETTING LIKE THAT AND *sob*

    So goodddddd.
  • New one, I guess.

    The Player Names by City don't seem to actually work for Mhaldorians... And after relogging for my first time, it stopped working for Targossians (or at least for Magenta).

    Ryushin and Magenta don't pop up whatsoever for the stuff so... ??? It's a mystery.
  • Ahm so mysterious.
  • Frederich said:
    New one, I guess.

    The Player Names by City don't seem to actually work for Mhaldorians... And after relogging for my first time, it stopped working for Targossians (or at least for Magenta).

    Ryushin and Magenta don't pop up whatsoever for the stuff so... ??? It's a mystery.
    Thank you for your feedback.

    Were you getting any error messages when running the command 'pc' to load the city membership data? One bug that may occur is when cities have a low population, or maybe no hidden (veiled) population. I will look into this.

    Regarding citizens of Targossas, the default color I selected was white, so it may not be readily apparent that the colors are being changed. This default color can be changed in the "scan everything" function within the feature folder. I'm hoping people will browse through the code to customize colors, aliases, and anything else to fit their own playstyle and needs.

    The 'pc' alias goes through all cities and loads the city data into the 'working set' variable. SaveCities and LoadCities pushes and pulls the city membership data into a more 'permanent' variable that can be saved by saving the Nexus client settings to the server. By running pc, then SaveCities and saving settings data, you can log in another time, LoadCities, run pc again to add the new people, SaveCities and then save the Nexus client settings for an updated list. Just a note, I don't have 'database pruning' implemented yet for cases of people switching cities. The alias ResetCities clears out all city membership variables, which is a heavy-handed way of doing this for now.

    If this continues not to work, please pass along any information you can - coloring by city membership is one of the more complex features I implemented in Bip-core.
  • Dangit Magenta.  You broke it for Ashtan too. :<.  Now the only cities it works for is Cyrene, Eleusis, and Hashan. :'(  This might be due-in-part to the fact that the other cities have like.. maybe 1-2 people on QW.  Maybe.  I might just want a version where I can do CWHO and get my citymates for easier deathsight recognition.
  • Another note - if someone does not show up in the QW <cityname> list due to being hidden for some reason they will not get their name colored. For the next version, I plan to implement aliases to manually add and remove names from individual cities.
  • Frederich said:
    Dangit Magenta.  You broke it for Ashtan too. :<.  Now the only cities it works for is Cyrene, Eleusis, and Hashan. :'(  This might be due-in-part to the fact that the other cities have like.. maybe 1-2 people on QW.  Maybe.  I might just want a version where I can do CWHO and get my citymates for easier deathsight recognition.
    Frederich,

    For the cities that are not working, can you please do a manual QW <cityname> and copy/paste the results here? I will use the results to make city membership processing work properly for cities with low online citizen counts.

    Thank you in advance.
  • edited August 2016


    it seems that, for it to 'verify' and realize that a cities a city, it requires them to have 3, or more, citizens upon the list.  PS: Don't mind the color change I did to Cyrene, I just made it easier on my eyes because DARK BLUE on black makes my eyes hurt. @Bip

  • Thank you, Frederich. I will use this to fix low population count city processing in version 1.1. I plan to release it this week, likely in a day or two. Upgrading should be as simple as deleting the old package and installing the new, though any customization (such as color changes) will be lost. I plan for these first few versions to come very quickly.

    Please send feature requests, default color suggestions, and more bug reports as they come up.


  • It seems that your color changer doesn't play well with CONFIG COLOUR.  Is there any way to fix that?
  • What behavior would you like to see?

    Currently, it's simply finding any instance of people's names it knows about in the console text and changing the foreground color to the one indicated in the code.

  • Well, it's currently just turning the text after the color change instance 'grey' and default.  If you look before in the text, Cyrene is white, and what Hosko says is White as well.  Whenever Josslyn speaks, it goes "grey".  Something is obviously going a bit awry with that.  Is there any way to preserve the config colour text that appears after a person's name?
  • The script in Bip-core replaces text with formatted text - basically takes the person's name and replaces it with the person's name with the foreground and background colors changed. The function has no 'knowledge' of what the format of that text block was before and doesn't return the rest of the block to the original colors after the text swap is done.

    I think it's two systems doing different things at different times - the server's colour configuration and Nexus both making formatting changes - that is causing the issue. I'm not sure how I could fix this. If anyone has any coding suggestions, they are welcome.

  • I do have a solution, but it would take a little time on your end to implement.

    You can use trigger reflexes within Nexus to change the foreground and background colors of lines instead of the server-based CONFIG COLOURS command. By using one system instead of two conflicting systems, you can get the colors the way you want.

    I'm sorry if this means undoing a significant amount of configuration you already have but I think this way would be the most complete resolution to the problem.

  • BipBip
    edited August 2016
    Bip-core 1.1 has been released! The new file can be obtained with the same link. To upgrade, delete the old package and install the new one just like before.

    This update fixes a bug where it would not read city citizens for name-coloring processing if there were fewer than 3 visible adventurers.
    Also, new aliases CityAdd, CityDel, and CityMaint were added to make the name-coloring system more robust and easy to use (see change log for details).


    Change log:

    1.1  (2016-8-24)
       Updated alias "pc "(process cities) handling to process city members with fewer than 3 members visible.
       Added alias "CityAdd <city> <adventurer>" to manually add an adventurer to a city.
       Added alias "CityDel <adventurer>" to manually remove an adventurer from all cities.
       Added alias "CityMaint" to remove adventurers that are listed in more than one city as a citizen.


    Development planned for 1.2:
       More bug fixes as they are reported.
       An alias that shows which names are in each city membership list.
       Refinement of current aliases, to make them more user friendly.
       I'm accepting suggestions for more features!
  • @Bip Can you take a look at having it only affect 'full name' instances?  I'm having a city mate Silvarien go half-purple because someone elses name is Silvari, and, of course, the city mate IS one with a gem so... 
  • Frederich said:
    @Bip Can you take a look at having it only affect 'full name' instances?  I'm having a city mate Silvarien go half-purple because someone elses name is Silvari, and, of course, the city mate IS one with a gem so... 
    I'll take a look, though it may not be easy. It is my understanding that SVOF also has the same issue.
  • Bip-core 1.2 has been released! The new file can be obtained with the same link. To upgrade, delete the old package and install the new one just like before.

    This update changes functionality for alias "st". It will first check a room to see if a denizen exists with that name or partial name and if so, targets it. If not, it performs the same generic server-side "settarget <newtarget>" as before. This change should help targetting denizens on mobile devices where a tab key is not available. It also lets you use partial names, such as "st s", which will now target a snake in the room, for example. Before, it would target a non-existing denizen named "s".  Thank go to Archcypher for this feature request!

    This update patches a bug that caused partial-name words to be highlighted in city names in longer words. For example, the letters Cyr would be blue within the word Cyrene. There may still be instances of this bug occuring in cases where the name finishes of a word, such as an adventurer named Rene highlighting within the name Cyrene. The full fix is planned in 1.3. I'm still working on this, Frederich!

    A new core variable is roomInfo, which contains all objects and denizens in the room. It complements variable roomPlayers, which contains a list of all adventurers in the room. This should be helpful with future development of PVP and PVE (bashing) scripts.

    Cyrene citizen default color changed to cornflowerblue due to complaints that the standard blue was too dark.

    New alias "CityList"  will list all of the citizens of all the cities that Bip-core knows about. You can use this in conjunction with PC (Process Cities), CityAdd, CityDel, and so on for citizen information management.

    Change Log:

    1.2  (2016-8-26)
       Modified alias "st" to first find denizen in local room to target. If there is no match, it uses the generic server-side settarget instead.
       Updated Scan Everyting function to prevent colorizing partial names in words (ex, Cyr / Cyrene)
       Added variable roomInfo, which keeps track of all items and denizens in a room and their attributes
       Change Cyrene default color from blue to cornflowerblue (lighter).
       Added alias "CityList" to display all current known members of cities.


    Development planned for 1.3:
       More bug fixes as they are reported.
       Refinement of current aliases, to make them more user friendly.
       Implement "final" and complete fix for partial word coloring for citizen names within other words.
       I'm accepting suggestions for more features!
  • Bip-core 1.3 has been released! The new file can be obtained with the same link. To upgrade, delete the old package and install the new one just like before.

    This update adds functionality for alias "st". When used without a parameter, this alias will now target-cycle through all non-guard denizens in your room (if there are any). This should help targeting significantly for mobile users (it has the same functionality as the TAB key). Thanks for the request, Archcypher!

    Updated alias "st <target>" to not be case-sensitive when targeting denizens in your current room. Also, when a denizen in your room is targeted, the alias lets you know the denizen's name (rather than just the ID number).

    Alias CityMaint, used for city membership information maintenance, now also alphabetizes all city membership lists. This makes alias CityList easier to read.

    The previous update appears to have completely fixed the partial-name coloring issue for city membership. Please let me know if you encounter the issue again, and provide screenshots if you can, so I can figure out what went wrong.


    Change Log
    ----------
    1.3  (2016-8-27)
       Alias "st" without parameter now cycles through non-guard denizens in the current room (suggested by Archcypher, improves mobile device targetting
       Updated alias "st <target>" to not take uppercase/lowercase target into account - it will work either way.
       Updated alias "CityMaint" to alphabetize city membership lists in addition to removing names that are in multiple lists.

       
    Development planned for 1.4:
       More bug fixes as they are reported.
       Refinement of current aliases, to make them more user friendly.
       I'm accepting suggestions for more features!


  • Bip-core 1.4 has been released! The new file can be obtained with the same link. To upgrade, delete the old package and install the new one just like before.

    This small update fixes apostrophes after adventurer names in text (for example, Bip's) for adventurers in the city citizenship list not being colorized.

    In addition, alias "CityMaint" has been updated to include automatic removal of invalid entries (with more than one word) that can occur if text activity happens while querying for city membership data.


    Change Log
    ----------
    1.4  (2016-8-28)
       Fixed bug with name coloring that would cause apostrophes (for example, 's) to prevent the name from being colored appropriately.
       Updated alias "CityMaint" to automatically remove invalid entries (names with more than one word) caused by text activity during "pc" (ProcessCities) data gathering.
         
       
    Development planned for 1.5:
       More bug fixes as they are reported.
       Refinement of current aliases, to make them more user friendly.
       I'm accepting suggestions for more features!


  • AerekAerek East Tennessee, USA
    edited August 2016
    This is a great thing. Nexus was really in need of some third-party scripting love, so that new players aren't automatically shunted toward Mudlet or other options that have been around for longer. Keep up the good work, and I hope advanced combat-centric additions are on the horizon!

    I don't use Nexus myself and am hardly a programmer, but as I'm interested in the development of a Nexus script package, feel free to look me up if you need any Achaean mechanics explained, or a fighter's opinion on what a "good" system should offer and pitfalls to avoid.
    -- Grounded in but one perspective, what we perceive is an exaggeration of the truth.
  • Aerek said:
    This is a great thing. Nexus was really in need of some third-party scripting love, so that new players aren't automatically shunted toward Mudlet or other options that have been around for longer. Keep up the good work, and I hope advanced combat-centric additions are on the horizon!
    Thank you.

    I am contemplating releasing a sample class pack. I play as an Occultist and could release a combat pack for this class. I'm just not sure how far to go - if I release what I use myself, it pretty much makes my own work, and the work of those who have helped me, the 'baseline'. Every Occultist would have identical tools and, more importantly, some of the 'mystery' of the class would be gone. Can anyone comment on what other packages, such as SVOF, provide for class scripting? Do they 'give it all away' or just provide a template, without any decision-making trees for abilities, for example?

    I don't have the funds to multi-class to make modules for other classes at this time. I simply don't have the massive amount of credits to make it happen. I can spare time here and there for coding and have a career that helps support my family but we are not nearly wealthy enough for me to spend as much as would be needed.

    This also goes for tradeskills. I intend to get Gathering and Inkmilling eventually, and even make a tradeskill modules (Bip-Tradeskills?) with those in there. But I simply can't afford to implement everything due to lack of funds to buy all the licenses for Bip.

    Bip-core contains a bunch of extra variables that I use with my own personal Occultist package that would be very useful for implementing other class packages. I'd like to actively encourage anyone to use Bip-core to develop a class package for their own class, on a volunteer basis. Unfortunately, people releasing Nexus code on a volunteer basis doesn't seem to have been working too well up to this point.. which is why I decided to be one of the first to provide a better playing experience.

    I want to add a note before I end this post - apparently, the lack of easy denizen targeting with mobile devices using the Nexus client was a big show-stopper. Not being able to target with TAB was making things very difficult. Archcypher made a feature request and the new 'ST' alias now works pretty much identically to the TAB key in the client for target cycling. I'm hoping this helps the player base by opening up easier mobile gaming experiences for Achaea, even if I've managed to do nothing else.
  • AerekAerek East Tennessee, USA
    For the most part, third-party systems don't offer any "offensive" support for classes, that's left for the player to work out on their own. What most scripting packages do is focus on universal quality of life additions, highlighting awareness of important Achaean configurable settings, (such as CONFIG and CURING options) and the defensive side of combat. (Supplementing server-side curing with client-side affliction tracking and logic trees, i.e. "if impatience and asthma then swap these priorities".) Even then, most systems don't automatically come with "optimal" curing logic built-in, they just provide the tools that -allow- the player to build their own advanced curing logic using easier-to-understand functions. 

    SvoF does incorporate defensive class-based abilities, (Such as Fitness, Shrugging, Dragonheal, etc) but as you say, all you can really offer is support for the classes that you play, yourself. I don't think you'd need to worry too much about class-specific additions, as long as the core infrastructure of the system was stable, transparent, and flexible enough that other Nexus users could write add-ons or plug-ins that could interface with your base package with class-specific options.

    To be true, the -big- thing that Nexus lacks is a good limbcounter. Anyone who plays a limb-prep class is almost mandated to move to a client that has one of these script packages available. That's not something you'd need as an Occultist, so you're not necessarily on the hook for that, but it'd be a big service to the community if it could be done. If you ever want to talk about what a limb-counter script would entail, let us know.
    -- Grounded in but one perspective, what we perceive is an exaggeration of the truth.
  • It looks like limb counting may be useful on a per-class basis. It also appears they weapon damage, and type, are important when accounting for limb damage calulators. Are these true?

    I thought it was pretty generic - damaged, broken, mangled for whatever limb, with triggers to account for opponent healing, hits and misses. If there's a lot more involved it may take a lot of time, and might work best in individual class packages rather than Bip-core directly.
  • AerekAerek East Tennessee, USA
    You're not really tracking whether a limb is broken or not, you're tracking hits leading up to it's breakpoint. A limb's breakpoint is determined by the target's max health, and the damage of the individual weapon or attack, the formulas for which are all different and not particularly easy to suss out. Fortunately, a basic limb counter doesn't actually need to know when an opponent will break just by looking at them, the script just needs the ability to track your hits accurately without getting fooled/confused by the many things that can go wrong in a fight. That way the player can guesstimate the breakpoint, set it to "12" or whatever number, and the script will count hits and alert them when the limb is "prepped" at 11.

    I agree it doesn't need to be a key feature for Bip-Core, specifically. Like I said, I was just pointing out that's one of Nexus' key deficiencies, and what forces a lot of players away from it if they choose those classes. If you decide you'd like to try and tackle that project at some point down the road, I can PM you with details on what a basic limbcounter would need to be functional.
    -- Grounded in but one perspective, what we perceive is an exaggeration of the truth.
  • AustereAustere Tennessee
    To tag on to Aerek's post, I have a few limb formulas laying around that, while they aren't perfect, I would be happy to share.  Basically just a gathering of all the ones posted on forums over the years. 
  • I think limb counting would be best in a class module, since it can be customized with class triggers. Eventually, I'd also add the ability in Bip-core to switch which class module was active (multi-class switching).

    For now, I think I'm going to focus on more Bip-core as suggestions come in. I think I may also work a bit on the first class module. I'm not certain if it will be Occultist-specific or if it will be a simple class template so others can make their own class modules if they want.

    The purpose of Bip-core is to get a solid Nexus core set of utilities and functions so the game is more easily playable on the web platform. A secondary goal is to show different ways that Nexus programming (Scripts, functions, triggers, aliases, simple scripting, etc) can be done with a working model so that other people, who may see it as very daunting to start and learn from scratch, have something to build from. I'm hoping at some point that others can start releasing their own compatible modules to the Bip-core platform. Maybe even have competing versions of modules, so people can tweak and tune things to their own satisfaction.
  • Just wanted to give an update - I am reconsidering creation of limb counters in Bip-core. I think I will give it a try, though the effort may take some time. I will be going on vacation soon and won't be able to do any coding for a few days (Thurs-Sun) as well.

    So, keep tuned. Because each class has its own limb counting needs, this won't come quickly. But don't be surprised if you see the unfinished feature disabled in the near future of Bip-core's releases..

    I'm still looking to add to my requested feature list, too. Please keep the suggestions and bug reports coming. Bip-core may not end up fully featured like SVOF; my plan is to focus on keeping it simple and easy to use.

  • I recommend installing mudlet and grabbing the counters that are available.

    This way you can see the structure and how you want to approach the design structure.




    Penwize has cowardly forfeited the challenge to mortal combat issued by Atalkez.
Sign In or Register to comment.