tbaMUD Continued development of the CircleMUD core

pretty much what the title says, i have been wanting to make unique properties on certain objects without editing the original item saved to the vnum, or without creating a new object entirely.

is that ^^ possible in tbamud currently? i've seen these features in EOS and EOSII before (only as a player though, not a coder. and we were able to add/remove flags/stats/etc)

I am probably just missing the way this is done entirely, but if someone could point me in the right direction that would rock my sox

To make a long story short: I think there used to be - I seem to remember adding iedit ("instance edit") to some codebase a LONG time ago. However, it's not in the tbamud codebase, so my memory may decieve me.

What needs to be altered to be able to do this?
- The rent/objsave code is built handle saving and loading of changed objects. No changes are needed here.
- A new iedit command would need to be implemented. It can use most of the oedit functionality, except selecting the object (the iedit command itself) and saving when done (ie. don't free the olc object, just stop pointing to it, and don't update the item lists).

Any takers?

It was a popular patch a while back. Check out the iedit readme and the patch here. Since we haven't done much development for players it has never come up to be installed on tbaMUD.

I should warn you, though. The loading and saving of rent objects is done in ASCII already, and much of the old iedit patch is concerned with this loading and saving of items. This might be a good time to make a new version.

oooer, i like it when i ask the good questions, hehe now i'll have to check this out.
I did stumble across the circlemud mailing list in a google search mentioning iedit, if i get anything working i'll definitely share!

edit
and thank you for the info :D
/edit

Is there a working link to the above patch somewhere? I found one snippet on the QueensU list, but it's rather a mess.

Tristen620 - did you ever get anything working on this?

Disgustingly, the final vote whether to switch our mud's sourcecode over to CircleMUD seems to swing on me getting this particular functionality working asap. Otherwise they're loving everything so far. Thanks all for your work into keeping this mudbase going!

If i'm not mistaken the latest version of CWG's Rasputin contained an updated and functional iedit. It might be easier to rip it out from CWG and transfer it into tbaMUD, then to try and dust off an ancient patch.

Bah, yet another thing I have been interested and cast off my desk into the void... i forgot entirely until i saw you type my name :D and no i looked a little, then got majorly distracted and dropped it before even starting.

I have a hugely expanded version of 'set' that allows set obj in my codebase (108 set char fields, 48 set obj fields, includes the full functionality of 'string' as well). Would that serve your needs?

I can look at merging that up with TBA tonight. I imagine I might have to disable set room and set zone for now, I'm not sure if there might be unpleasant interactions with the TBA OLC?

Thanks everyone for the responses!

I spent a VERY long night pulling apart the Rasputin release and can attest that extracting that 'snippet' will be non-trivial. Basically, they have UNIQUE_SAVE as an additional item EXTRA flag, and it is tied into much functionality in the release including saving player corpses, the mail system, and extra skills such as scribing.

Adding an item flag to handle this seems like a reasonable approach, but (imo) the Rasputin code seems a bit squirrely and would require significant clean-up. I'm too new with TBA to have a good handle on how corpses, mail, etc are being done already so perhaps I'm trying to replicate some of the OBJ_ID_BASE function that's already there? Anyway, I'll still plugging away at this and will post as I have anything. Any thoughts on this strategy would be welcome!

Dio - I'd love to see what you have. Trading unique items is a major part of my mud's economy and expanding object fields and wear locations is my next task. I'm the only builder...and I usually work directly in the area files over OLC, so working Oasis code is a lower priority for me. (I hope that doesn't get me burned at the stake by you tba folks. >.<)

Well, as far as I understand it Oasis works on the db (obj_proto and mob_proto). Set works on the instantisations of the db objects (i.e. players, mobiles and objects in the game) - so set only has a persistent effect if the results are saved, in the player file or rent files. Therefore, the two shouldn't tread on each others' toes. Rooms, worlds and zones are different because set is then working on the db, and so there's more risk of unpleasant interactions. (For objs and mobs, my editor has a different method of OLC which was to modify an instantiation and then write that back to the DB).

I've looked briefly at the code and a direct port to TBA is not easy because of the horrible magic-number nature of the way that set was implemented (and I extended that; it makes stripping out my extensions and adding the TBA extensions a spaghetti nightmare).

However, I have some code for an alternate flexible set which should be more quickly brought to life so I'm fiddling with porting that instead.

Looks like the code's working. I just have to make the changes to handle the bitarrays system in TBA and it's ready to go - tomorrow hopefully.

OK, I think this one should work if plugged into a vanilla TBA codebase (although it's possible it's reliant on a couple of the small tweaks I've pushed into my local version that I'll be sending to Fizban later, and there's always the possibility there's something here that MSVC handles that gcc et.al. won't like).

fields.c

Just add that to your project / makefile and link it up - you can replace do_set with do_fieldset in interpreter.c or have both available as required.

Notes on fieldset:
- doesn't support pfile targets yet, but other than that it should be fully functional on players, mobiles and objects
- fieldset <target> will give you a list of fields that you can set on the target
- there's a specific format required for bitvector fields unlike regular do_set.
- permissions are probably too stingy at the moment; my mindset is still set by its use on a MUD where there were several sub-classes of IMPL and rampant mate-assisting amongst the lower-level gods (I had to add fingerprints on objects, as well as code to find out 'who loaded that load-only item'...)

If you want, you can add show_object and show_mobile to do_show as well, which generate reports out of the db allowing just about any of the obj or mob struct fields as filters. Useful for balancing worldfiles - not too much of a problem with the TBA world which is very flatly balanced. To give it a spin try something like "show mob combat level=20-30" to get a list of hard mobiles.
Notes on show:
- format is show obj/mob <report> <list of filters in the form field=value or field!=value>; anything matching everything on the filter list is shown
- bitvector filters are of the form field=bit|bit|bit|bit rather than set's field.bit notation
- report formatting has known problems with colour codes in names (colour bleeds and format width issues)
- sorting and averaging are not implemented yet, but would be nice in the future

Thanks Dio! I will try yours next. I played around with the Rasputin code for awhile, but got tangled up in the differences with the save object code. That's the critical part of this...if I could figure out a clean way to do that I could write it from scratch.

I found a copy of the iedit patch here and have spent the past two days on that, but it's tanking somewhere in a bunch of variable changes to the oedit code between 3.61 and 3.0 version the patch was built on. That patch is crammed with unrelated stuff as well, so it's quite a clean up job. I'll keep poking at that but anything I come up with will likely be as nasty a hack as already fills my current smaug base. bleh to that.

Thanks again!

Sorry for the double-post but just an update: No luck for this so far on my relatively clean 3.61 install. VERY long list of variable errors and other mess.

From welcor's post above the objsave code should be able to handle the iedit mod? But dang if I can get it working...

Can you post the compiler output and I'll see if I can spot the problem?

If it's something gcc doesn't like, I can maybe see if I can do something under cygwin.

Hmmm. Doesn't seem to be too many problems here, compiling on gcc. Six warnings, two of which are due to a genuine bug:
- objects to the outside possibility of a side effect conflict in lowercase()
- in set_obj_affect, the 'type' in printf should be buf2
- match_field_string and parse_filter have the const*const* to const** casting issues because search_block hasn't been declared const*const*

Other than that, it compiles OK. (I tested with the most up-to-date gcc 4.3.4).

Haven't had time to actually run the code, I'll see if I can do that tonight (and fix the warning issues). In the meantime, get me the error list and I'll see what looks to be a problem.

Cheers

Yep, runs with no problems here with a cygwin / gcc compiled version with both fieldset and show mob apparently working fine.

Thanks Dio!

My host uses gcc 4.1.2 - shouldn't be a problem there. Are you working with the same makefile included with the 3.61 distro?

I'll post the errors when I get home. (They finally firewalled me at work. sigh.)

Yep. For the quick test this morning I just dropped the fields.c that I posted up into the standard tba 3.61 src directory. At lunchtime I built the whole modified 3.61 I sent to Fizban (which has fields.c in it) and ran that, in order that I could catch any other discrepancies that gcc didn't like. No changes to anything but the C code.

Yep, I'm still trying to get some version of this function working.... :D

I'm currently trying to install Dio's fields.c on a clean install of 3.62. Has anyone tried this and if so, precisely how are you linking it up? I assume that's where my problems are as there isn't anything else I'm changing.

On a related note, I'd offer to help out working iedit function directly into TBA. I don't know enough about the code to do it myself, so I encourage any suggestions. I offer this is a pretty important addition to consider for future versions of TBA. Most active muds have some sort of "individualized object" function. (My mud voted down using TBA because I couldn't get these restrings working, but hopefully I'll being able to sway them down the line!)

Thanks all!

I've still never gotten this working. :(

Does anyone have any ideas or tips? I believe this to be rather basic functionality for any live mud (I've never played one that didn't have some sort of individual object restrings) so I'm still hoping to push into into being a priority for TBA development.

Thanks all!