As of today, The 1.0-dev develop branched merged into the main branch. This was a a lot of work. Thanks everyone who helped and contributed! As usual, report bugs in the issue tracker.

Key documentation to read:

• New installation instructions if you install from scratch
• Upgrading your 0.9.5 game to Evennia 1.0

Evennia 1.0 Release Notes

This summarizes the changes. The doc release notes is like this list but with more detail. The Changelog has all the detail.

• Main development now on main branch. master branch remains, but will not be updated anymore. If you follow along on GIT, switch to main branch; the develop branch will not see updates until work on the next Evennia version picks up.
• Old documentation sources (github wiki, readthedocs) were closed. Docs are only in one place now, at https://www.evennia.com/docs/latest/index.html.

Minimum requirements

• Python 3.10 is now required minimum. Ubuntu LTS now installs with 3.10. Evennia 1.0 is also tested with Python 3.11 - this is the recommended version for Linux/Mac. Windows users may want to stay on Python 3.10 unless they are okay with installing a C++ compiler.
• Twisted 22.10+
• Django 4.1+

Major new features

• Evennia is now on PyPi and is installable as pip install evennia.
• A completely revamped documentation at https://www.evennia.com/docs/latest. The old wiki and readmedocs pages are closing.
• Evennia 1.0 now has a REST API which allows you access game objects using CRUD operations GET/POST etc. See The Web-API docs for more information.
• Evennia<>Discord Integration between Evennia channels and Discord servers.
• Script overhaul: Scripts’ timer component independent from script object deletion; can now start/stop timer without deleting Script. The .persistent flag now only controls if timer survives reload - Script has to be removed with .delete() like other typeclassed entities. This makes Scripts even more useful as general storage entities.
• The FuncParser centralizes and vastly improves all in-string function calls, such as say the result is $eval(3 * 7) and say the result the result is 21. The parser completely replaces the old parse_inlinefunc. The new parser can handle both arguments and kwargs and are also used for in-prototype parsing as well as director stance messaging, such as using $You() to represent yourself in a string and having the result come out differently depending on who see you.
• Channels New Channel-System using the channel command and nicks. The old ChannelHandler was removed and the customization and operation of channels have been simplified a lot. The old command syntax commands are now available as a contrib.
• Help System was refactored.
  • A new type of FileHelp system allows you to add in-game help files as external Python files. This means there are three ways to add help entries in Evennia: 1) Auto-generated from Command’s code. 2) Manually added to the database from the sethelp command in-game and 3) Created as external Python files that Evennia loads and makes available in-game.
  • We now use lunr search indexing for better help matching and suggestions. Also improve
    the main help command’s default listing output.
  • Help command now uses view lock to determine if cmd/entry shows in index and read lock to determine if it can be read. It used to be view in the role of the latter.
  • sethelp command now warns if shadowing other help-types when creating a new entry.
  • Make help index output clickable for webclient/clients with MXP (PR by davewiththenicehat)
• Rework of the Web setup, into a much more consistent structure and update to latest Django. The mygame/web/static_overrides and -template_overrides were removed. The folders are now just mygame/web/static and /templates and handle the automatic copying of data behind the scenes. app.css to website.css for consistency. The old prosimii-css files were removed.
• AttributeProperty/TagProperty along with AliasProperty and PermissionProperty to allow managing Attributes, Tags, Aliases and Permissios on typeclasses in the same way as Django fields. This dramatically reduces the need to assign Attributes/Tags in at_create_object hook.
• The old MULTISESSION_MODE was divided into smaller settings, for better controlling what happens when a user connects, if a character should be auto-created, and how many characters they can control at the same time. See Connection-Styles for a detailed explanation.
• Evennia now supports custom evennia launcher commands (e.g. evennia mycmd foo bar). Add new commands as callables accepting *args, as settings.EXTRA_LAUNCHER_COMMANDS = {'mycmd': 'path.to.callable', ...}.

Contribs

The contrib folder structure was changed from 0.9.5. All contribs are now in sub-folders and organized into categories. All import paths must be updated. See Contribs overview.

• New Traits contrib, converted and expanded from Ainneve project. (whitenoise, Griatch)
• New Crafting contrib, adding a full crafting subsystem (Griatch)
• New XYZGrid contrib, adding x,y,z grid coordinates with in-game map and pathfinding. Controlled outside of the game via custom evennia launcher command (Griatch)
• New Command cooldown contrib contrib for making it easier to manage commands using
  dynamic cooldowns between uses (owllex)
• New Godot Protocol contrib for connecting to Evennia from a client written in the open-source game engine Godot (ChrisLR).
• New name_generator contrib for building random real-world based or fantasy-names based on phonetic rules (InspectorCaracal)
• New Buffs contrib for managing temporary and permanent RPG status buffs effects (tegiminis)
• The existing RPSystem contrib was refactored and saw a speed boost (InspectorCaracal, other contributors)

Translations

• New Latin (la) translation (jamalainm)
• New German (de) translation (Zhuraj)
• Updated Italian translation (rpolve)
• Updated Swedish translation

Utils

• New utils.format_grid for easily displaying long lists of items in a block. This is now used for the default help display.
• Add utils.repeat and utils.unrepeat as shortcuts to TickerHandler add/remove, similar
  to how utils.delay is a shortcut for TaskHandler add.
• Add utils/verb_conjugation for automatic verb conjugation (English only). This
  is useful for implementing actor-stance emoting for sending a string to different targets.
• utils.evmenu.ask_yes_no is a helper function that makes it easy to ask a yes/no question
  to the user and respond to their input. This complements the existing get_input helper.
• New tasks command for managing tasks started with utils.delay (PR by davewiththenicehat)
• Add .deserialize() method to _Saver* structures to help completely
  decouple structures from database without needing separate import.
• Add run_in_main_thread as a helper for those wanting to code server code
  from a web view.
• Update evennia.utils.logger to use Twisted’s new logging API. No change in Evennia API
  except more standard aliases logger.error/info/exception/debug etc can now be used.
• Made utils.iter_to_str format prettier strings, using Oxford comma.
• Move create_* functions into db managers, leaving utils.create only being
  wrapper functions (consistent with utils.search). No change of api otherwise.

Locks

• New search: lock type used to completely hide an object from being found by
  the DefaultObject.search (caller.search) method. (CloudKeeper)
• New default for holds() lockfunc - changed from default of True to default of False in order to disallow dropping nonsensical things (such as things you don’t hold).

Hook changes

• Changed all at_before/after_* hooks to at_pre/post_* for consistency
  across Evennia (the old names still work but are deprecated)
• New at_pre_object_leave(obj, destination) method on Objects.
• New at_server_init() hook called before all other startup hooks for all
  startup modes. Used for more generic overriding (volund)
• New at_pre_object_receive(obj, source_location) method on Objects. Called on
  destination, mimicking behavior of at_pre_move hook - returning False will abort move.
• Object.normalize_name and .validate_name added to (by default) enforce latinify
  on character name and avoid potential exploits using clever Unicode chars (trhr)
• Make object.search support ‘stacks=0’ keyword - if >0, the method will return
  N identical matches instead of triggering a multi-match error.
• Add tags.has() method for checking if an object has a tag or tags (PR by ChrisLR)
• Add Msg.db_receiver_external field to allowe external, string-id message-receivers.
• Add $pron() and $You() inlinefuncs for pronoun parsing in actor-stance strings using msg_contents.

Command changes

• Change default multi-match syntax from 1-obj, 2-obj to obj-1, obj-2, which seems to be what most expect.
• Split return_appearance hook with helper methods and have it use a template
  string in order to make it easier to override.
• Command executions now done on copies to make sure yield don’t cause crossovers. Add
  Command.retain_instance flag for reusing the same command instance.
• Allow sending messages with page/tell without a = if target name contains no spaces.
• The typeclass command will now correctly search the correct database-table for the target
  obj (avoids mistakenly assigning an AccountDB-typeclass to a Character etc).
• Merged script and scripts commands into one, for both managing global- and
  on-object Scripts. Moved CmdScripts and CmdObjects to commands/default/building.py.
• The channel commands replace all old channel-related commands, such as cset etc
• Expand examine command’s code to much more extensible and modular. Show
  attribute categories and value types (when not strings).
  • Add ability to examine /script and /channel entities with examine command.
• Add support for $dbref() and $search when assigning an Attribute value
  with the set command. This allows assigning real objects from in-game.
• Have type/force default to update-mode rather than resetmode and add more verbose
  warning when using reset mode.

Coding improvement highlights

• The db pickle-serializer now checks for methods __serialize_dbobjs__ and __deserialize_dbobjs__ to allow custom packing/unpacking of nested dbobjs, to allow storing in Attribute. See Attributes documentation.
• Add ObjectParent mixin to default game folder template as an easy, ready-made
  way to override features on all ObjectDB-inheriting objects easily.
  source location, mimicking behavior of at_pre_move hook - returning False will abort move.
• New Unit test parent classes, for use both in Evenia core and in mygame. Restructured unit tests to always honor default settings.

Other

• Homogenize manager search methods to always return querysets and not sometimes querysets and sometimes lists.
• Attribute/NAttribute got a homogenous representation, using intefaces, both
  AttributeHandler and NAttributeHandler has same api now.
• Added content_types indexing to DefaultObject’s ContentsHandler. (volund)
• Made most of the networking classes such as Protocols and the SessionHandlers
  replaceable via settings.py for modding enthusiasts. (volund)
• The initial_setup.py file can now be substituted in settings.py to customize
  initial game database state. (volund)
• Make IP throttle use Django-based cache system for optional persistence (PR by strikaco)
• In modules given by settings.PROTOTYPE_MODULES, spawner will now first look for a global
  list PROTOTYPE_LIST of dicts before loading all dicts in the module as prototypes.
  concept of a dynamically created ChannelCmdSet.
• Prototypes now allow setting prototype_parent directly to a prototype-dict.
  This makes it easier when dynamically building in-module prototypes.
• Make @lazy_property decorator create read/delete-protected properties. This is because it’s used for handlers, and e.g. self.locks=[] is a common beginner mistake.
• Change settings.COMMAND_DEFAULT_ARG_REGEX default from None to a regex meaning that
  a space or / must separate the cmdname and args. This better fits common expectations.
• Add settings.MXP_ENABLED=True and settings.MXP_OUTGOING_ONLY=True as sane defaults, to avoid known security issues with players entering MXP links.
• Made MonitorHandler.add/remove support category for monitoring Attributes with a category (before only key was used, ignoring category entirely).

I realized I’ve not posted here in a while, but Evennia, the Python MU* creation system, is moving forward, now at version 4.0.0 (we follow semantic versioning).

Release post

Evennia 4.0.0

March 17, 2024

Major release. Check out for backwards-incompatible changes below.

Version updates

• Feature: Support Python 3.12 (Griatch). Currently supporting 3.10,3.11 and 3.12. Note that 3.10 support will be removed in a future release.
• Feature: Update evennia[extra] scipy dependency to 1.12 to support latest Python. Note that this may change which (equivalent) path is being picked when following an xyzgrid contrib pathfinding.
  Backwards incompatible changes
• Feature: Backwards incompatible: DefaultObject.get_numbered_name now gets object’s name via .get_display_name for better compatibility with recog systems.
• Feature: Backwards incompatible: Removed the (#dbref) display from DefaultObject.get_display_name, instead using new .get_extra_display_name_info method for getting this info. The Object’s display template was extended for optionally adding this information. This makes showing extra object info to admins an explicit action and opens up get_display_name for general use.
• Fix: (partly Backwards incompatible depending on your usage): DefaultObject.get_numbered_name used .name instead of
  .get_display_name before, which broke recog systems.

New features

• Feature: Add ON_DEMAND_HANDLER.set_dt(key, category, dt) and .set_stage(key, category, stage) to allow manual tweaking of task timings, for example for a spell speeding a plant’s growth (Griatch)
• Feature: Add ON_DEMAND_HANDLER.get_dt/stages(key,category, **kwargs), where the kwargs are passed into any stage-callable defined with the stages. (Griatch)
• Feature: Add use_assertequal kwarg to the EvenniaCommandTestMixin testing class; this uses django’s assertEqual over the default more lenient checker, which can be useful for testing table whitespace (Griatch)
• Feature: New utils.group_objects_by_key_and_desc for grouping a list of objects based on the visible key and desc. Useful for inventory listings (Griatch)
• Feature: Add DefaultObject.get_numbered_name return_string bool kwarg, for only returning singular/plural based on count instead of a tuple with both (Griatch)

Bug and security fixes

• Fix Removed the @reboot alias to @reset to not mislead people into thinking you can do a portal+server reboot from in-game (you cannot) (Griatch)
• Fix: Refactor Clothing contrib’s inventory command align with Evennia core’s version (michaelfaith84, Griatch)
• Fix: Limiting search by tag didn’t take search-string into account (Griatch)
• Fix: SSH connection caused a traceback in protocol (Griatch)
• Fix: Resolve a bug when loading on-demand-handler data from database (Griatch)
• Security: Potential O(n2) regex exploit in rpsystem regex (Griatch)
• Security: Fix potential redirect vulnerability in character page redirect (Griatch)
• Doc fixes (iLPdev, Griatch, CloudKeeper)

Evennia Dev blog

This blog post talks about the release plans version 1.0 of Evennia, the Python MU* development framework. It also goes into some changes to how you can now customize multiple sessions (Evennia’s has supported puppeting multiple characters at the same time from different client windows for a long time, but this makes it more flexible).

Thanks for the nice comments Yes, it’s good to get this out, finally.

BTW, Latest main branch Evennia now supports adding NPCs backed by an LLM chat model.

https://www.evennia.com/docs/latest/Contribs/Contrib-Llm.html

Unsurprisingly, I agree with @Faraday concerning softcode

At least concerning Evennia, the FuncParser is indeed the closest we have moved to something similar to softcode, but it’s intentionally stopping at being a way to create advanced formatting solutions rather than offering the pieces needed to be turing-complete. As I also write in the documentation to it, one could in principle make some sort of LISP-like language using FuncParser (lots of parentheses, all functional programming), but it’s not something I plan to add to core Evennia at least.

As for a multidescer - yes Evennia has an optional multidescer contrib. I created one once people from another MUSH-heavy forum told me that this was one of the more common things MUSHers use softcode for. You can read about the Evennia implementation here: https://www.evennia.com/docs/latest/Contribs/Contrib-Multidescer.html

Sorry for double-post, catching up on some stuff in the thread.

@somasatori

As it stands, the multidescer contrib mentioned above will probably be easier for use as a multidescer (see link above). To be honest, it was created before the FuncParser (what is called ‘code in descs’ above) existed so it’s quite likely one could implement a multuidescer using the FuncParser too, haven’t tried.

The FuncParser is overall considerably more than just ‘code in descs’ though. It is a full, safe parser, for dynamically modifying strings based on situation or who sees them. You embed strings like $foo(arg, arg) and the return of these (Python functions you implement under the hood) will replace that position in the string. Descriptions are just one use case; another one is to implement ‘actor-stance emoting’, so that you can have your game systems send strings like "$You() $conj(smile) to $you(otherperson)" and everyone will see their appropriate strings (You vs your name etc). It’s used for prototypes and other places too.

@imstillhere said in AI Megathread:

@Griatch said in AI Megathread:

As for me, I find it’s best to embrace it; Digital art will be AI-supported within the year. Me wanting to draw something will be my own hobby choice rather than necessity.

are you aware that artists for whom this is NOT a hobby are suffering from this thing you’re excited to “embrace”

When photography displaced illustrators there was a new human art form that supported human creativity and jobs. When digital art allowed quick work in a new medium it was still human artists at work.

Yes, I expect this will dramatically change the art industry. I can see why people are legitmately concerned. Same is true for a lot of white-collar jobs (for once, the blue-collar workers may be safest off). While I don’t work as a professional artist, I expect my own job in IT to fundamentally change or even go away too, as programmers eventually become baby-sitters of AI programmers rather than actually code ourselves. Since I think that this is inevitable, I’m trying to learn as much as I can about it already.

AI removes the human and removes the employment and does so by unethical sourcing of human effort.

There’s definitely discussions to be had about the ethical sources of the training data; OSS models (which is what I use, since I run these things locally) are already trying to shift to using more ethically sourced, freely available data sets (but yes, there are still issues there, considering the size of the corpus). You can in fact look into those data sets if you want - they are publicly searchable. Companies with proprietary solutions (Midjourney is particularly bad here) will hopefully be forced to do so by lawsuits and regulation, eventually. But that said, I’d think that even an AI completely trained on public-domain images will still change the industry, so it’s not like this changes the fundamental fact of the matter: LLM processing is here to stay.

To say that’s no different than painting in photoshop is naive at best and disingenuous at worst.

AI image generation is only one aspect of LLMs. It on its own is certainly not the same as painting in Photoshop, and I never suggested as much. But I do expect photoshop to have AI support to speed up your painting process in the future - for example, you sketch out a face and the AI cleans it up for you, that kind of thing (not that I use Photoshop, I’m an OSS guy. ). But yeah, for professional artists, I fear the future will be grim unless they find some way to go with the flow and find a new role for themselves; it will become hard for companies not using AI to compete.

Congrats @Faraday, good work!

What are your plans for Ares post-1.0?
.
Griatch

By the way, here’s an example of a smaller AI model trained using only public-domain images. The tech will move on also if regulators pull the brakes.

Now I realize that copyright laws and internet regulations are imperfect, but imagine what the world would look like if everyone had just folded over Napster. “Oh well, data can be shared easily now; screw the musicians.” Or if YouTube had just let everyone upload every movie they owned, free for anyone to watch. “Oh well, movies can be shared easily now; screw the filmmakers.”

You can already generate your own AI music. In a year you’ll be able to generate your own movies from a prompt, so that industry is also in for an upheaval …

@Cobalt

Alas, as is outlined in the old tutorial, Arxcode is maintained by the Arx folks and not by Evennia devs.

I wrote that tutorial as a service back then when it made sense (and it did indeed easily install at the time, promise!) … but at this point I don’t think ArxCode has kept up with Evennia development (it was using an old Evennia version already when it was created, it’s even still on Python2).

I’ll check in with Tehom if there are plans to update the tutorial (or Arxcode).

I realized I’ve not posted here in a while, but Evennia, the Python MU* creation system, is moving forward, now at version 4.0.0 (we follow semantic versioning).

Release post

Evennia 4.0.0

March 17, 2024

Major release. Check out for backwards-incompatible changes below.

Version updates

• Feature: Support Python 3.12 (Griatch). Currently supporting 3.10,3.11 and 3.12. Note that 3.10 support will be removed in a future release.
• Feature: Update evennia[extra] scipy dependency to 1.12 to support latest Python. Note that this may change which (equivalent) path is being picked when following an xyzgrid contrib pathfinding.
  Backwards incompatible changes
• Feature: Backwards incompatible: DefaultObject.get_numbered_name now gets object’s name via .get_display_name for better compatibility with recog systems.
• Feature: Backwards incompatible: Removed the (#dbref) display from DefaultObject.get_display_name, instead using new .get_extra_display_name_info method for getting this info. The Object’s display template was extended for optionally adding this information. This makes showing extra object info to admins an explicit action and opens up get_display_name for general use.
• Fix: (partly Backwards incompatible depending on your usage): DefaultObject.get_numbered_name used .name instead of
  .get_display_name before, which broke recog systems.

New features

• Feature: Add ON_DEMAND_HANDLER.set_dt(key, category, dt) and .set_stage(key, category, stage) to allow manual tweaking of task timings, for example for a spell speeding a plant’s growth (Griatch)
• Feature: Add ON_DEMAND_HANDLER.get_dt/stages(key,category, **kwargs), where the kwargs are passed into any stage-callable defined with the stages. (Griatch)
• Feature: Add use_assertequal kwarg to the EvenniaCommandTestMixin testing class; this uses django’s assertEqual over the default more lenient checker, which can be useful for testing table whitespace (Griatch)
• Feature: New utils.group_objects_by_key_and_desc for grouping a list of objects based on the visible key and desc. Useful for inventory listings (Griatch)
• Feature: Add DefaultObject.get_numbered_name return_string bool kwarg, for only returning singular/plural based on count instead of a tuple with both (Griatch)

Bug and security fixes

• Fix Removed the @reboot alias to @reset to not mislead people into thinking you can do a portal+server reboot from in-game (you cannot) (Griatch)
• Fix: Refactor Clothing contrib’s inventory command align with Evennia core’s version (michaelfaith84, Griatch)
• Fix: Limiting search by tag didn’t take search-string into account (Griatch)
• Fix: SSH connection caused a traceback in protocol (Griatch)
• Fix: Resolve a bug when loading on-demand-handler data from database (Griatch)
• Security: Potential O(n2) regex exploit in rpsystem regex (Griatch)
• Security: Fix potential redirect vulnerability in character page redirect (Griatch)
• Doc fixes (iLPdev, Griatch, CloudKeeper)

One interesting suggestion I saw was to use a categorization LLM (so not one trained for chat, but for categorizing text input into known categories), in order to allow players to input free-form text that then gets categorized/interpreted into one of a few hand-written responses, like quest info etc.

With Evennia now supporting AI npcs, it will be interesting to see what people come up with

@Rinel said in AI Megathread:

I very strongly support the implementation of strict regulations on how the models are trained, with requirements that all training data be listed and freely discoverable by the public.

Proprietary models like Midjourney and OpenAI don’t release any of this stuff, alas. But if you stick to OSS models, like Stable Diffusion, you can freely search their training data here (they also use other public sources). There are tens of thousands of LLM models for various purposes and active research on hugging face alone; they tend to be based on publicly available training data sets.

@Faraday You talk as if it’s a clear-cut thing that these models are based on “theft”. Legally speaking, I don’t think this is really established yet - it’s a new type of technology and copyright law has not caught up.

If you (the human) were to study Picachu (as presented in publicly available, but copyrighted images) and learn in detail how he looks, you would not be breaching copyright. Not until you actually took that knowledge and made fan-art of him would you be in breach of copyright (yes, fan-art is breaching copyright, it’s just that it’s usually beneficial to the brand and most copyright holders seldomly enforce their copyright unless you try to compete or make money off it).

In the same way, an AI may know how Picachu looks, but one could argue that this knowledge does not in itself infringe on copyright - it just knows how Picachu looks after all, similarly to you memorizing his looks by just looking.

One could of course say that this knowledge inherently makes it easier for users of the AI to breach copyright. If you were to commission Picachu from a human artist, both you and the artist could be on the hook for copyright infrigement.

So would that put both the AI (i.e. the company behind the AI) and the commissioning human in legal trouble the moment they write that Picachu prompt? It’s interesting that the US supreme court has ruled that AI-generated art cannot be copyrighted in itself. So this at least establihes that the AI does not itself has a person-hood that can claim copyright (which makes sense).

Now, I personally agree with the sentiment that it doesn’t feel good to have my works be included in training sets without my knowledge (yes, I’ve found at least 5 of my images in the training data). But my feelings (or the feelings of other artists) don’t in itself make this illegal or an act of thievery. That’s up to the legal machinery to decide on, and I think it’s not at all clear-cut.

@Rinel said in AI Megathread:

@Faraday said in AI Megathread:

Now I realize that copyright laws and internet regulations are imperfect, but imagine what the world would look like if everyone had just folded over Napster.

More seriously, LLMs are far, far worse than Napster, which hurt recording companies way more than it hurt actual musicians. I’m not taking a stance on the ethics of pirating, but there’s a difference between people copying things that others have made and people outright displacing human creators.

So, if I understand you right, it’s not unethical training sourcing that is the issue for you (as it seems to be for Faraday), but the societal implications of the tech itself?
That’s a valid view. But while we can regulate and fix ethics of training sets, we won’t realistically stop AI being used and possibly upending a lot of people’s jobs in the same way as was done by countless new technologies in the past.

I’m not saying I want people to lose their jobs, I’m just saying this is something we need to learn and adapt to rather than hope that the genie can be put back in its bottle.

By the way, here’s an example of a smaller AI model trained using only public-domain images. The tech will move on also if regulators pull the brakes.

Now I realize that copyright laws and internet regulations are imperfect, but imagine what the world would look like if everyone had just folded over Napster. “Oh well, data can be shared easily now; screw the musicians.” Or if YouTube had just let everyone upload every movie they owned, free for anyone to watch. “Oh well, movies can be shared easily now; screw the filmmakers.”

You can already generate your own AI music. In a year you’ll be able to generate your own movies from a prompt, so that industry is also in for an upheaval …

@Kumakun said in UrsaMU, back from the project graveyard.:

@Griatch Honestly? It taught me that I didn’t have to get super fancy about things. Seriously. It’s not at all a slight. Evennia isn’t overly engineered, and, is approachable when making customizations. It’s kept simple, and I really appreciate how pythonic the project is.
I’m also in love with just having your business logic to worry about. I’m not a fan of having to dig through my evenv to find it, but I could say the same about digging through a node_modules folder.
The thing that really got me moving though, was the EJS. I silent screamed a little when going through the web side of things. Totally started reliving EJS nightmares. I could have made a custom skin for it, sure - but, the error reporting for EJS is horrible, at least was back when I didn’t have many other choices!
Ultimately, when I deem this experiment successful? I’ll rewrite it in Golang, and harden it past a prototype MVP - at least that’s the plan!

Thanks for the answer! Glad to hear Evennia’s design was a little inpirational. The webclient code is admittedly first written at a time when Typescript was but a glimmer in the eye of some guru somewhere; it was written to be as generic as possible. One could certainly rework it with a more modern style today. Time, time …

@shit-piss-love said in AI Megathread:

@Griatch said in AI Megathread:

But yeah, for professional artists, I fear the future will be grim unless they find some way to go with the flow and find a new role for themselves; it will become hard for companies not using AI to compete.

This is what I expected, but the first people that made me start considering the positive effects of AI on the field of professional art are my friends who are professional artists. Most of them seem really happy with adding to their toolkit. Concept Art in hours what would previously take them days, or in the same amount of time being able to do significantly more iterations resulting in what they feel is a better final product. The takeaway I’ve got from conversations with them is that it will come down to quality of studio whether they use AI tools to level-up the art departments, or attempt to replace them. But as one said “An AI isn’t going to take my job. It will be a professional peer who knows how to use AI better than me.”

That’s encouraging to hear! If your friends feel they are on top of the coming changes, all the more power to them.