IDEAS FOR RYZOM


uiWebPrevious1uiWebNext

#1 Multilingual 

Not really an idea but also not a bug; depends on interpretation.

As far as i can see, 'Up to X' prospect works bottom-up. As in:

are there any Basic mats of specified type?
if Yes then End
are there any Fine mats ....


Which I find basically useless. Shouldn't it be the other way around? 'Up to X' to me seems like "I'd like X but if there are none I'll live with (X-1), hell, even (X-2) will do in a pinch."

Of course, as almost always, best solution is to have both. Bottom-up as well as top-down. it's not like we lack skill points.

Funny enough, if Excellent mats share the area with lower grades we get season/time/weather 'errors' prospecting for exactly Choice. Above ground.

And finally, get rid of "Not found due to an obstacle". Collision detection was relaxed (even almost removed for mobs) for a reason and there are no other LOS checks I'm aware of. Again, for a reason.

Last edited by Olmo (2 years ago)

#2 [en] 

Olmo
Funny enough, if Excellent mats share the area with lower grades we get season/time/weather 'errors' prospecting for exactly Choice. Above ground.

And finally, get rid of "Not found due to an obstacle". Collision detection was relaxed (even almost removed for mobs) for a reason and there are no other LOS checks I'm aware of. Again, for a reason.

Not arguing that prospecting does not need changes (it does), but the way it works is (more ore less):
* server generates random x,y coords based prospect area coverage (range, angle) and number of source (+few bonus spots for free iirc).
* x,y is feed into function that gives back resource type, grade at that location (procedurally generated based deposit)
* it then checks them against prospect action filter (grade, type, ecosystem) and deposit filter (grade, type, ecosystem, time, weather)
* it tries to give most specific error message.

ie, if you ask 'up to choice' and prospect in area that has overlapped excellent deposit, then you may see (if no match was found)
* not in this weather, time, season, or
* if weather, time, season matches you may see 'resources found, but different grade, because you hit x,y location that generated excellent source (and you wanted choice), or
* you may see 'no resources found in this area', which means x,y did not generate any source despite being inside deposit area.

minor, major stanzas give bonus sources for server to choose so use them if you can.

also note
* above ground deposits have choice,excellent in them
* procedural generation may render uneven distribution of nodes in deposit area
* or uneven distribution of type/grade is some parts of the area.

unfortunatelly 'tracking' only leads you to the deposit.

---

Hello!

#3 Multilingual 

* it then checks them against prospect action filter (grade, type, ecosystem) and deposit filter (grade, type, ecosystem, time, weather)

One thing at a time. Quoted is all I'm currently talking about. Checks happens serially not in parallel (?). So order in which they happen is (should be) relevant.*

First of all, generated results that are about to be checked against prospecting action filters need to be sorted by:
a) grade
b) mat brick

Throwing unsorted list/array/w.e. into checking procedures will always generate a mess that's then difficult to make sense of.

Thinking some more about prospecting actions, I think we should just be given ability to build grade filter ourselves.

Current stanzas get converted into series of single-grade stanzas; eg. 'Up to Choice' becomes 'Basic', 'Fine', 'Choice'
+ new stanza 'Inclusive' which tells server we want all matching nodes. This allows backward compatibility.

Next, new single-grade stanzas get introduced and we can use those to build grade filters as we see fit. These then operate in two possible modes (defined by stanza):
'Exclusive' = Return list of first matched
'Inclusive' = Return list of all matched

'Inclusive' example:
Prospect action is 'Excellent', 'Choice', 'Fine' + 'Inclusive'
Generated list has some 'Choice' and some 'Fine' but no 'Excels'. List is sorted so "E" is at the top (none), "C" in the middle (some) and "F" at the bottom (some). Then server goes from top to bottom and fills out list to return until w/e decides the length is met. So if, let's say, max 8 nodes are to be returned and there are 2 'Choice' and 9 'Fine' sources in generated list, we get 2 'Choice' and 6 'Fine'.
(It's even simpler if max number of sources is passed to generating procedure)

'Exclusive' example would be:
Prospect action is 'Choice', 'Fine' + 'Exclusive'. If there are no 'Choice' mats in generated list, server returns list of 'Fine' nodes. If there are, we get list of 'Choice' nodes but no 'Fine'.

This scheme also simplifies which fail messages to return. If there was no 'Excel' stanza in prospect then whole season/weather/time block can be skipped. I would even go so far as to skip that in every case except if 'Excel' or 'Sup' are alone in prospect action.

Additional complication would be disabling 'Inc/Exc' options during action build until at least two grade stanzas are in the list.

--------------
* Some type of checks could actually be parallelised fairly well. For instance distance and mat checks are independent but I suppose then one has to get into whole race conditions, shared variables and other assorted pain of threads so probably not worth it.
uiWebPrevious1uiWebNext
 
Last visit Sunday, 28 April 01:27:59 UTC
P_:

powered by ryzom-api