Daimonin MMORPG Logo
Daimonin voting system

Recent Posts

[Community chat] moving the servers by smacky
Today at 09:22:31 pm
[Community chat] Is this game dying? by smacky
September 27, 2014, 06:44:59 pm
[Community chat] Last one to post wins! by Shroud
September 25, 2014, 09:16:36 pm
[Daimonin project] v0.10.7 development by smacky
September 24, 2014, 02:21:26 pm
[Suggestions] Guild Revamp Discussion by Shroud
September 19, 2014, 06:05:45 pm
[Daimonin project] Combat balancing by Shroud
September 15, 2014, 01:44:52 pm
[Bug discussion] v0.10.6 Bugs by Shroud
September 12, 2014, 06:47:52 pm
[Suggestions] Third Hand Belt by petarkiller
September 11, 2014, 07:18:54 pm

Daimonin Forums

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



Posts: 1494
Karma: +44/-7


View Profile
« Reply #15 on: February 18, 2012, 10:39:04 pm »

I could do an enum ... good point.

Ah!  Because of this line, for example:
Code: [Select]
i = MAX(1, MIN(i, 127));
So, we scan i from the val string and turn it into a number.  Then the above code forces the value of i to be adjusted within sensible limits (1 - 127) if required.

So, if you try to set level = 200, i will be reset to 127, and if you set level = -200, i is reset to 1.

We then write the (possibly new) value of i back into var, so the calling function can process it.

(Hope that explained it)

But what does "undefined reference to itoa()" mean?  itoa() is defined in stlib.h.

~~~~~~

EDIT:  I'm also not happy with something in the base CreateObject() function.  My excuse is that I copied it from the original code!  The original code had the statement:

Code: [Select]
if (at->clone.nrof)
This was used to decide whether to run the "create a single object" code; if not, then run the "create a head object and link in all the ->more objects" code.

But this doesn't make sense; there are some arches that don't have nrof defined, but are "single" objects (with no ->more).  And surely, a direct check for ->more somehow would be better?
smacky
The Singular Soul of Lom Lobon Tribe
*
*
*
*
*
*
*



Posts: 8643
Karma: +275/-134


View Profile
« Reply #16 on: February 18, 2012, 11:09:37 pm »

I see. Do sprintf(val, "%d", i); instead. Undefined reference means it does not exist. stlib.h must be a Windows attempt to force its own version of stdlib.h on the world.


Yes grr... The server used to take nrof 0 (ie, no attribute in the arch) as meaning nrof 1. In fact I think it still does in most cases.

But when I rewrote the stacking code I changed this. IIRC nrof 0 for stackable objects means ... oh I can't remember but the point is these items need to explicitly be nrof 1-n, nrof 0 is a special case. So I changed all the arches in arch/item.

So that code needs to take at->clone.nrof == 0 and at->clone.nrof == 1 as meaning the same thing (or we should autocorrect 0 to 1 in loader.l).
Torchwood
Warlord of Moroch Army
*
*
*
*
*
*
*



Posts: 1494
Karma: +44/-7


View Profile
« Reply #17 on: February 19, 2012, 07:57:13 am »


My turn for grrr ...

I did initially try sprintf(), but it didn't work, so I moved on to itoa().  Of course, I realise now it didn't work because of a stupid typo on my part (no, I'm not going to tell you what the typo was!).  Of course, sprintf() works perfectly!!  Code updated ...
Torchwood
Warlord of Moroch Army
*
*
*
*
*
*
*



Posts: 1494
Karma: +44/-7


View Profile
« Reply #18 on: February 19, 2012, 10:22:10 am »

Back to the nrof thing again ...

Thought about this a lot, and I understand what the original code was doing now (I think).

+  If the arch definition contains "nrof", then the code goes ahead and sets this value (so creating a 'stack' of items).

+  If the arch def does not contain "nrof", the code assumes it is not valid to set this attribute for this object, and so individually creates each item separately.

Makes sense I guess - so I'll keep this logic in.

However, now I have another point; should we allow players to generate objects such as (1) system objects, like skill objects, or ai objects, (2) map items like walls / floors / masks (3) other stuff like rune_acid?

It would make sense to restrict /create to only certain object types ... but which ones?
smacky
The Singular Soul of Lom Lobon Tribe
*
*
*
*
*
*
*



Posts: 8643
Karma: +275/-134


View Profile
« Reply #19 on: February 19, 2012, 11:53:05 am »

Again don't restrict /create at all.

But I agree, no sys_objects for /generate. ISTR doing something about this already, but when people /create or /generate exits, they must appear directly oon the map, not in an inv as applying an exit in an inv crashes the server. Actually maybe that was the change. Applying the exit in inv no longer crashes, it just says 'it is closed'. In which case, don't worry about it.

I guess all other types are safe for /generate as it can't fiddle with sensitive/undefined attributes.
_people_
Warlord of Moroch Army
*
*
*
*
*
*
*



Posts: 1570
Karma: +53/-4


View Profile
« Reply #20 on: February 19, 2012, 06:05:15 pm »

Yes, you did fix the /create exit bug quite a while ago.
Torchwood
Warlord of Moroch Army
*
*
*
*
*
*
*



Posts: 1494
Karma: +44/-7


View Profile
« Reply #21 on: February 19, 2012, 07:04:19 pm »

OK ... /generate now restricted so it can't create sys_objects.  No restriction added to /create (and /spawn only creates mobs anyway, so no check needed there).

Next ...

As a player when using /create, I can never remember whether its coin_gold or gold_coin, or coingold, etc.  So I thought (and again, my primary driver here was really trying to understand the arch and artefact files a little bit more, rather than anything else!! :) ), a command to list out valid arch names would be useful.

So, latest commit r6784 adds /listarch.

This takes a parameter, which specifies the type of object to run /listarch on (I don't ever want to list them all, as there are too many!!).

So, /listarch 15 will list out all valid arch names for weapons, and /listarch 6 will list all foods.

All works well, but it leads to an obvious question; how is the player supposed to remember type 15 represents weapons?  What I really want is for /listarch with no parameters to return a list of type names and type values - in exactly the same way that /addexp with no parameters will give a list of skills and their skill numbers.

I can't find anywhere in the code where type 15 is associated with a string value "weapons", so I guess I've got to add in something somewhere?
_people_
Warlord of Moroch Army
*
*
*
*
*
*
*



Posts: 1570
Karma: +53/-4


View Profile
« Reply #22 on: February 19, 2012, 07:33:38 pm »

That's only handled by the editor in types.xml (I think that's the file). So you'd best just look at those and add string values for each type number.
smacky
The Singular Soul of Lom Lobon Tribe
*
*
*
*
*
*
*



Posts: 8643
Karma: +275/-134


View Profile
« Reply #23 on: February 19, 2012, 08:31:45 pm »

A misunderstanding. /create creates objects based on the named arch, not the type (which is 'just' another attribute). Listing arch names is a nono (there are thousands). I sympathise -- I can never remember coins either -- but it's too bad.

BTW I say type is just another attribute. It's a special case. Unless you absolutely know what you're doing (and even if you do, don't do it on main), don't change type with /create (same rule applies to objects on maps, although it is a rule which has frequently been broken in the past).
Torchwood
Warlord of Moroch Army
*
*
*
*
*
*
*



Posts: 1494
Karma: +44/-7


View Profile
« Reply #24 on: February 19, 2012, 08:59:24 pm »

Not sure I follow you there?  I understood /create uses the "Object XXX" bit of the archetypes file ... (not the type attribute)

Anyway - as I already committed it to trunk can you take a look at the code and try to run it?  It works well for me on my local; no noticeable performance issues.  By specifying the type number to /listarch you only get a small portion of the complete arch list (so I hope we won't get server performance issues).

Try /listarch 15 or /listarch 6 as described above ... (or /listarch 36 to get a reminder of those pesky gold coins).

If after looking at it, you think it is too slow, then we can easily abandon this command - I don't mind (although I might save it in a personal stream for future reference).

EDIT: Or maybe (if it is too slow), rather than abandoning completely, put some #ifdef stuff round it so it is only available on local and dev server, and not on main (after all, you'd hope that people wouldn't be doing too much experimentation on main, so would know what arch names to use)!
smacky
The Singular Soul of Lom Lobon Tribe
*
*
*
*
*
*
*



Posts: 8643
Karma: +275/-134


View Profile
« Reply #25 on: February 20, 2012, 01:46:49 pm »

I didn't say whose the misunderstanding was, did I? ;)

But having tried it I do think no. It could be convenient sometimes, granted. But a minor convenience for a major (relatively speaking) amount of server work and bandwidth usage. We loop through the entire arch list and artifact list every call and call NDI numerous times. Then for type 80 (monster) for example, on dev/test this is currently over 4k worth of names. Even 15 (weapons) is over 2k. That's a lot of bw for a minor convenience and will only get bigger.


This did remind me of a few things though. /generate does need to be restricted further by type. For example, type 1 (player) should not be /generatable.
Torchwood
Warlord of Moroch Army
*
*
*
*
*
*
*



Posts: 1494
Karma: +44/-7


View Profile
« Reply #26 on: February 20, 2012, 02:38:37 pm »

No problem!

So, get rid of completely?  Or put "#ifdef DAI_DEVELOPMENT_CONTENT" round the code, so it can only be used on local / dev servers?

Hehe ... I guess that means "/listamask" that I created yesterday (i.e. /listamask sword will give a list of amasks that can be applied to object type 'sword') is also out!!! :)

I think long term, I could still implement these commands, but they would need a different approach - i.e. do some extra processing of the arch file at server start up to "pre-build" the lists for each object type.  The "/listarch type" then only has to print out the pre-existing list.

Or there might be another way?  Maybe we do what you are planning with /help, whereby these "lists" are precompiled and sent to the client at login so that /listarch becomes effectively a client-side only command.

Anyway ... on hold for now.
Torchwood
Warlord of Moroch Army
*
*
*
*
*
*
*



Posts: 1494
Karma: +44/-7


View Profile
« Reply #27 on: February 20, 2012, 08:22:19 pm »

This did remind me of a few things though. /generate does need to be restricted further by type. For example, type 1 (player) should not be /generatable.

OK - I can restrict /generate on type 1 objects - although you can actually /generate a player quite nicely (i.e. my local server didn't immediately crash) - they just stand there and do nothing though!!! (and you can't seem to target them).

You can also /generate a new bed_save object; works as well!  :)
smacky
The Singular Soul of Lom Lobon Tribe
*
*
*
*
*
*
*



Posts: 8643
Karma: +275/-134


View Profile
« Reply #28 on: February 23, 2012, 01:34:28 pm »

Another thing, /generate (and /spawn -- although ATM you can't get donation mobs anyway) should not be able to make donation items.

ATM there is no is_donation attribute so I guess one needs to be added to mark donation (fake) arches and then disallow the command if at->clone.is_donation.
Torchwood
Warlord of Moroch Army
*
*
*
*
*
*
*



Posts: 1494
Karma: +44/-7


View Profile
« Reply #29 on: February 26, 2012, 02:58:07 pm »

Well, that was instructive!  I'd never really heard of the flex scanner before, so had no idea how the arch file was actually read ...

Anyway, I've now added a new arch flag "is_donation".  Code is updated and committed; hope it is ok.

I haven't gone through the donations.art file though to add the new flag to each object; I guess this should wait until after the new code makes it onto Main?
Pages: 1 [2] 3   Go Up
 
 

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