AMIA ARCHIVE • View topic

Hello,

this is something I already suggested in the If-I-Could-Change-Amia-Thread but I think it's actually not a pipe dream. So I just post it again here with some rewording:

Ts_ wrote:

Make it possible for players to leave placeables permanently somewhere, like this:

1) Setup job items and even fancier requested PLCs in a good spot.
2) Use an area effect widget burning a DC to freeze them in place beyond reset, permanently. (Until someone unfreezes them with more DCs.)

Why would this be good?

* A world that changes more quickly.
* Player driven development.
* Less burden on developers to flesh out e.g. faction areas.
* Another usage for DCs.

Why might it suck?

* Requires scripting
* People could abuse it to corner monsters or even players. But then DMs would stop giving these players DCs, so the abuse will stop.
* The server can only handle so many placeables. But we could set conservative limits per area on the number of permanent placeables. Players could then work within the limit.

(Original post: viewtopic.php?p=1380974#p1380974 )

Regards
Ts

PS: I really do feel bad for quoting myself and writing in so many threads at once and taking up your precious time, dear reader!

I don't think encouraging "DC wars" among people is a good idea. You can set PLCs up for 8 hours, and I have often seen DMs volunteering to keep things up even when PCs aren't around.

Neat, I had not heard of DMs doing that.

But what do dynamic areas do to those placeables?
And how long does it take to catch a DM willing to watch over a new chair somewhere?
When would a chair have been added if devs have to go to the toolset for it?

Of course, people bring their own chairs. But leaving a campsite in some remote location so that other people are aware of someone doing something here would be great. Or a pentagram from your last ritual that keeps, or player-maintained law and ban signs in front of settlements!

I want to elevate the players to designers with this and make this a living world.

DCs put some regulation on the system, but would also be easily reimbursable if a DM comes along and likes the addition. (That's really a culture thing, and might emerge or not.)

DC wars aren't the point of this and removing other people's stuff is a last resort or regulation. I'd make that a rule! Like edit wars happen on a wiki and should be resolved in the talk page instead, DC wars should be taken to the forum, preferably the IC section where the fate of some placeables can be played out. (Assuming people don't have the chance to just resolve it IG. The creator of a set of placeables should always be able to remove them for free.)

But obvious abuse (PENIS spelled out on Cordor square) could be screenied and quickly cleaned up by another player.

I can think of some other hurdles:
* Designers not seeing the entire current state of an area in the toolset. (Look IG and screenie?)
* Designers need a way to replace placeables in the toolset with other stuff instead of having overlapping results. (An invisible placeable added in the toolset with a date attached to it that removes any older player-placed PLC from its surroundings in a first step of the loading routine?)

Regards
Ts

I'll be honest, I don't comprehend the hurdles you mentioned.

I don't feel like something like this would need a system drafted up for it at this point. I think this would simply be a case-by-case thing, like if someone wanted to set up a camp, they would get in contact with a DM and discuss with them how/why/for how long. Then if the DMs are satisfied they can punch a Dev in the shoulder and say, "make a little camp that looks like this, in this spot". But it would need to be a long-term thing for it to even be considered, I'd imagine, and have some dedication shown to it similar to a faction.

Even with the Dynamic system allowing us to make quicker and easier changes, we still don't have a ton of people and we're basically always doing something. There aren't really "dry times" lately in which we'd have time to keep up on stuff like this, as a result, and a part of why we don't already.

As far as I know, making things persistent after reset isn't an option with the way the stuff works, although that would be the simplest and best thing if it were, because then there's no need for making edits to the Area. It would be great if we could because then people like Rashid with their donation exchange chest wouldn't have to worry about grabbing items out of the chest before a reset (or losing the contents in a crash) or setting it up again afterward. But, I don't think we can do this presently, and I don't know if we'd be able to.

Maybe I should have mentioned what I would imagine an implementation of this to look like:

The placeables only exist in the database and not actually in the module. That's why designers couldn't see them directly in the toolset.

Similar to the housing system, the items would be respawned from the DB. Except here it happens when the first person enters an area after reset/after an area reload.

I'd give them a unique label color like purple to differentiate them from other stuff. And some technical property pointing to their origin in the DB.

The "freeze widget" would just target an area and all non permanent placeables in that area would get added to the list in the DB with their current area/position/rotation and label/descripton/properties for unique items (and technical metadata, like an id, pckey, timestamp, and perhaps an id representing the groups of items frozen at once). Then for good measure, respawn them as permanent purples. Also take a DC from the player's account.

Removing things would target an area and remove anything stored in the DB within a certain radius from the DB. And probably just remove the IG items as well.

The system wouldn't work with a chest full of items, but I hope that chairs would be clickable when they are recreated.

I don't know how hard this would be, but it seems entirely feasible, given that we have the housing system (which might or might not be generic enough to store arbitrary placeable items already).

Regards
Ts

While not a bad idea (if not really able to implemented with how we do things presently as far as I'm aware) you have a curious view of how things work. It's not really accurate, unless something has changed in the season I was taking a break, which is why I was confused as to what you were talking about. Ultimately, Faded / Basic Human would be the one to answer if we can or ever would do this from a practical point of view, although whether or not the team would approve it is a different matter.

I have an imagined view of how things work. I've never done any NWN development at all. That probably explains a lot about me and what I say. ;)

I do have a programming background, though. This is essentially (De)Serialization of PLCs with some rules around it. I make some assumptions that items IG can be found/inspected/spawned/deleted, have variables added at runtime, and that there is a database that can do typical SQL stuff. The job system seems to use a ton of this functionality already, but the serialization is not done, and instead items (and their state) are persisted in the inventory.

The only examples of serialization that I could think of are morgans storage and the housing system, and of course these could function entirely different, too.

So, that's what I believe the world to be like.

Regards
Ts

Items and creature objects are the only objects the game can directly deserialize/serialize, its by a hack in the routines that handles persistent saving by nwns default.

PLCs are just saved resref and position, these can be saved in the database, the resref has to however point towards a valid resource that is a plc. NWN serialization is all according to their GFF format, so it'd technically be possible to modify the .utp (the files that contain plc info) at runtimes similar to how leto modifies .bic files and then load them, but its a lot of work.

The PLCs can be changed at runtime with the exception of their models. Models cannot be changed at runtime for plcs as it'd mostlikely result in a crash because the models contain information about how they interact with the walkmesh of the tile they are spawned within aswell as the appearance the clients will be prompted to load.

Hey,

thanks for the clarification! I found the SCO/RCO routines in nwnx, but didn't read them detailed enough to understand that PLCs are not covered by them.

But if resref + position does the trick, not magic serialization is needed, I guess.

Thinking about this, it would also take some effort to filter out PLCs that should not be stored, like PLCs that are already permanent by virtue of being placed in the toolset, I suppose ... But some local variable that is attached in (lots of) scripts that create user objects (starting with the PLC spawner perhaps) might solve that.
And despawning items the moment they are stored to the DB and recreating them as purple might also mess with the lifecylce of, say, spawned usable job system items. But I guess that's just an argument to not respawn until the next area load.

So ... I just wonder. Is anyone besides me actually enthusiastic about decorating the server themselves?

Regards
Ts

I was just having this discussion with my friend. We both play on Arelith, where permanent placeables are a thing (as well as a lot of other nifty scripts), and his main complaint about Amia is that the world is so huge and open, but empty. Even though Arelith is smaller, it's dense and alive, mostly because of the placeables.

A feature like this is on the end of the DMs' to do list, simply because the server operates just fine without it. However, if somebody with the skills and know-how was willing to assist them (or even do most of the work and then send them the relevant information), this and a lot of other cool features could be implemented pretty quickly.

Permanent Placeables

Who is online