Daimonin MMORPG Logo
Daimonin voting system

Recent Posts

[Arches] Joes archs by joeshmo
April 24, 2014, 10:44:53 pm
[Suggestions] Guild Revamp Discussion by clobber
April 24, 2014, 07:26:20 pm
[Scripts] Attack Register by clobber
April 24, 2014, 07:24:59 pm
[Bug discussion] Lost Skills/Levels by clobber
April 24, 2014, 07:24:22 pm
[Community chat] Last one to post wins! by clobber
April 22, 2014, 03:45:47 pm
[Community chat] Clobber's Garden by clobber
April 22, 2014, 09:44:18 am
[Daimonin project] v0.10.7 development by Shroud
April 17, 2014, 06:08:33 pm
[Dev Server] MOVED: Rewritten pick up/drop code by smacky
April 15, 2014, 03:14:20 pm

Daimonin Forums

 
Pages: [1] 2 3   Go Down
  Print  
Author Topic: Overhaul of /generate code  (Read 33080 times)
Torchwood
Warlord of Moroch Army
*
*
*
*
*
*
*



Posts: 1494
Karma: +44/-7


View Profile
« on: February 15, 2012, 06:05:50 pm »


So, as part of my quest to update the /man files for all wiz commands, I took a look at /generate.  Unfortunately, to write this /man file, I had to try to understand how command_generate() actually works.

No offence to whoever wrote it, but its not the easiest code to follow; also contains a lot of duplication (which I personally don't like).  I've rewritten it, and I think its much easier to follow now.

Anyway, the existing code is in 3 section ...

(1) Bit of initial parameter parsing

(2) An if statement:
Code: [Select]
// Now, start to create the object ...
if (at->clone.nrof)
{
    ...
    return;
}

(3) A for statement:
Code: [Select]
for (atmp = at; atmp != NULL; atmp = atmp->more)
{
   ...
   return;
}

After testing, I'm pretty sure code block 2 runs for simple objects (e.g. a sword), and code block 3 runs for multi-part objects.

However, at the end of code block 3 we have:
Code: [Select]
head = insert_ob_in_ob(head, op);
And, inside insert_ob_in_ob() we have:
Code: [Select]
if (op->more)
{
    LOG(llevBug, "BUG: Tried to insert multipart object %s (%d) in %s (%d)\n",
        query_name(op), op->count, query_name(where), where->count);
    return op;
}

So, it seems the current code doesn't actually work.  Either, there is a bug in the insert_ob() code, or /generate should place the multi-part object on the floor (and not insert in player's inventory), or /generate should kick out an error if the player tries to generate a multipart object.

Comments?


smacky
The Singular Soul of Lom Lobon Tribe
*
*
*
*
*
*
*



Posts: 8530
Karma: +272/-134


View Profile
« Reply #1 on: February 15, 2012, 06:53:05 pm »

Not sure you were around at the time, but 2 or 3 years ago several (at the time) DMs were constantly using /create to make all sorts of weird and wonderful objects but refused to accept that /create is not for fun. After many server crashes and broken player save files, /generate was developed. This was billed as a 'safe' alternative to /create, but is/was actually anything but (there'll be threads about problems), although it does have further restrictions (I don't know much about it).

/generate was also a focal point for all that amask business I mentioned the other day. IDK how much the current code reflects that.

To your last point, yes putting a multipart in an inv is very bad (it crashes the server), hence insert_ob_in_ob() code and for example, I can't remember the func name but there is code explicitly preventing a player picking up a multipart.

This could be fixed (perhaps in a similar way that multipart mobs are allowed in spawn points) but I'm not sure there's actually any benefit in doing so.

So yes, on the face of it the generate code is wrong.

TBH I'd be inclined just to scrap /generate altogether, or at least start again.
Torchwood
Warlord of Moroch Army
*
*
*
*
*
*
*



Posts: 1494
Karma: +44/-7


View Profile
« Reply #2 on: February 15, 2012, 07:44:52 pm »

OK thanks.  I was roughly aware of the problems with /create, so was trying to be careful to not change the underlying logic of the /generate command.

I've looked at the /create code now, and as expected it is almost directly the same as /generate, except /generate has some restrictions (the only object properties you can set are name, title and amask, and you cannot create mobs).

/create also has the same 'error' as /generate - creating a non-alive multi-part object does nothing (creating a live multi-part object puts it directly onto the map).

I don't intend to try to 'fix' any other functions at this stage, so in /generate I'll just take out the insert_in_ob() bit, and give a suitable feedback message to the player.

I'll try to find the threads you reference, and read up on the problems ...
smacky
The Singular Soul of Lom Lobon Tribe
*
*
*
*
*
*
*



Posts: 8530
Karma: +272/-134


View Profile
« Reply #3 on: February 15, 2012, 09:11:41 pm »

I've looked at the /create code now, and as expected it is almost directly the same as /generate, except /generate has some restrictions (the only object properties you can set are name, title and amask, and you cannot create mobs).

Well there's one problem -- .generate should basically only create mobs.

Part of it's raison d'etre was that DMs were /creating inv items which caused crashes etc, and refused to stop no matter how often the server went down or how much they were asked to, or by whom. They then got really upset at the prospect of having their new toy taken away because they 'needed' it to do raids.

So AIUI /generate was brought in as a sort of mob-only /create. A little counter-intuitively it is often safe(r) to set almost all attributes to arbitrary values on mobs than other object types, partly because mobs are by their nature temporary, cannot go into player invs, and are not saved on temp maps.
ddhanna
Drow captain
*
*
*



Posts: 115
Karma: +3/-0


View Profile
« Reply #4 on: February 15, 2012, 09:20:56 pm »

why not let those that want to /create do so. but have what ever object they create, have who created it. like a tag. a tag that would show up in the logs if that item were to crash the server.

the people that can create know what it is supposed to be used for. if one of them turn out to be a repeat offender, then take that ability away from said person.
_people_
Warlord of Moroch Army
*
*
*
*
*
*
*



Posts: 1512
Karma: +53/-4


View Profile
« Reply #5 on: February 16, 2012, 12:46:29 am »

ATM I have a system that I use for doing raids which AFAIK is a bit safer, but I'm still entirely not sure how safe. Basically it's a DMBuster-like item with a /talk interface and links to different mobs (currently only 10 or 11 are available). You can also set the level, which will scale the mob's stats appropriately (using mob:Fix()). It uses script-interrupted spawns to spawn the mob.

I have yet to see a server bug or crash caused directly by this (there was an AI crash bug at one point but I don't know if that was the script's fault).

What makes it more stable is the fact that all that can be modified is the level. I intend to add a few more attributes later, but I'll make sure to limit it (don't set type, count, or other sensitive attributes).

This only works for mobs, too, but it'd work for items as well.
Torchwood
Warlord of Moroch Army
*
*
*
*
*
*
*



Posts: 1494
Karma: +44/-7


View Profile
« Reply #6 on: February 16, 2012, 07:32:37 am »

Well there's one problem -- .generate should basically only create mobs.

Interesting!  As mentioned, /generate specifically won't create mobs!!  :)

I think /generate could stay as it is; I guess there shouldn't be too much of a crash problem if all you can do is change name, title and amask?

Perhaps I also write a /spawn function specifically for mobs - where you can only set name, title and level?
ThePlaneskeeper
Warlord of Moroch Army
*
*
*
*
*
*



Posts: 1830
Karma: +64/-27


View Profile WWW
« Reply #7 on: February 16, 2012, 08:15:17 am »

I think alot of the problem here, is that you are all introducing arbitrary elements into the server.  If you want to do a "raid," modify the maps on which you wish to affect, and put spawn points on them that are only affected by a trigger that a GM/DM can trigger.  IE: invisible to a normal player.  You could affect the attributes of the "spawn" by having done the foot work of placing "alot" of spawn points with different triggers.  Say dropping 99 coppers on a specific spot, then hitting the lever would cause a lvl 99 mob...  I haven't done alot of scripting, but i don't see how some ingenuity and hard work would be supplemented by jeopardizing server integrity.  What do I know though?  Our servers are not up 99.9% (which is the standard for gaming) of the time due to crashes, bugs and negligence.

I don't want to po-po any ideas, but if there is a safe way to do something that uses the game's well designed features, and keeps the integrity of the server in tact, we should use it...  Making new ways of introducing free radicals is like throwing balls of yarn into a giant clockwork.  Sure, they may grind up the first few, but eventually the whole thing will grind to a halt.

Thats my opinion.
Torchwood
Warlord of Moroch Army
*
*
*
*
*
*
*



Posts: 1494
Karma: +44/-7


View Profile
« Reply #8 on: February 16, 2012, 07:45:11 pm »


Some good points above ...

Anyway, for now, I've just re-written /generate and /create with mostly the same functionality as previously (its good practice for coding in C).

The originals had a lot of duplication; both these functions were essentially identical, with very minor differences - some deliberate, some less so!  Also, the code for creating multi-part objects was also mostly duplicated from that for creating single-part objects, so we had 4 large chunks of 99% duplicated code!

After the re-write, we only have one chunk of code, with a few flags here an there where different behaviour is required, so it should be easier to debug and maintain.  I've done basic testing, and it all looks OK to me so far.

Couple of minor points:
- I put a restriction on quantity to create (max 50)
- I also put a restriction on magic bonus (-10 to +10)
Are these sensible limits?

I also added in, because it was easy, /spawn.  So now we have:

/create - can create anything, set any attribute (available to /sa only)
/spawn - only living things, can set amask, name, title, level only
/generate - only dead things, can set amask, name, title only

I don't mind where we go from here in terms of adding / removing functionality, or limits, or anything else - it was a good challenge coding this stuff up!!!  :)
smacky
The Singular Soul of Lom Lobon Tribe
*
*
*
*
*
*
*



Posts: 8530
Karma: +272/-134


View Profile
« Reply #9 on: February 16, 2012, 10:09:02 pm »

Sounds good. I don't think /create should be restricted at all as restrictions kind of defeat its real purpose as a code/content testing command: I often /create +127 swords so I can wade through fights in non-SA mode and just recently I need to create hundreds of items at a time (also if you limit quantity to 50 people will just do it 10 times in a row if they want 500!).

I believe level needs to be restricted to 1-127 for /spawn (that is <1 makes no sense and IIRC it is a sint8 for some reason ATM so >127 just wraps around to -127).

Also, /spawn should probably allow attribs such as attack_* (restricted to 0 to 200) and resist_* (-100 to 100). _people_s raid script may well be better a better solution here than a command (nicer UI [I assume ;)] and more flexible/subtle restriction management).
Torchwood
Warlord of Moroch Army
*
*
*
*
*
*
*



Posts: 1494
Karma: +44/-7


View Profile
« Reply #10 on: February 16, 2012, 10:28:44 pm »


OK - thanks for feedback.  I'll incorporate those comments ...

I think /spawn and a proper Raid script, together with TPK's suggestion can complement each other.  /spawn can be use for instant (but simplistic) mobs - you can't change too much about the mobs, but you can create them quickly and where wanted.  A raid script provides the next level of complexity; a bit more time to set up / a bit more complexity in the mobs.  TPK's suggestion then goes to the final level for complex raids, with complex raid reward items, etc.

I think all have a valid place ...
smacky
The Singular Soul of Lom Lobon Tribe
*
*
*
*
*
*
*



Posts: 8530
Karma: +272/-134


View Profile
« Reply #11 on: February 17, 2012, 11:51:01 am »

Sounds sensible.

Re /spawn: Also see

http://www.daimonin.org/daipedia/MapWizardryRelativeMobLevels
http://www.daimonin.org/daipedia/MapWizardryCombatModifiiers

So item_quality and item_condition should be settable (perhaps instead of attack_* andd resist_* if you want to keep /spawn as simplistic but still useful as possible). The actual code is in spawn_point.c.
Torchwood
Warlord of Moroch Army
*
*
*
*
*
*
*



Posts: 1494
Karma: +44/-7


View Profile
« Reply #12 on: February 18, 2012, 12:16:34 pm »


I agree item_condition looks useful; but not sure about item_quality.  This is used to give variation on mob levels on a map - it takes 2 parameters (map level and relative difficulty) to randomly adjust the mob's level.  Not sure this is appropriate for /spawn - just using "level" directly is I think more intuitive (and anyway, map level is likely not relevant if there is a raid going on).

item_condition only modifies attack_* and resist_* attributes if the mob already has them, so I think you still need to be able to set these attributes directly if you want.
smacky
The Singular Soul of Lom Lobon Tribe
*
*
*
*
*
*
*



Posts: 8530
Karma: +272/-134


View Profile
« Reply #13 on: February 18, 2012, 02:05:06 pm »

Actually yes. IIRC all mob arches now have a item_quality (and item_condition in fact) already. So if you /spawn a bh for example without explicitly setting level it will be whatever level is red for the particular map diff by default. An explicit level will be that level.
smacky
The Singular Soul of Lom Lobon Tribe
*
*
*
*
*
*
*



Posts: 8530
Karma: +272/-134


View Profile
« Reply #14 on: February 18, 2012, 09:48:10 pm »

Code: [Select]
src/server/c_wiz.c:750: undefined reference to `itoa'
src/server/c_wiz.c:722: undefined reference to `itoa'
src/server/c_wiz.c:736: undefined reference to `itoa'

I don't understand the code either. You seem to be trying to write back to val the number you just got from it? To what end?

Also the funcs which take isCreate, isGenerate, and isSpawn parameters would be better taking a single mode parameter which is 1, 2, or 3 (an enum/define).
Pages: [1] 2 3   Go Up
 
 

Powered by SMF 2.0 RC1-1 | SMF © 2006–2008, Simple Machines LLC
Page created in 0.131 seconds with 24 queries.
Checkout