Lubricating Oil Issue with ...

Submit ideas and suggestions on how we display, catalogue and export the resources.

Moderator: Forum Moderator

Jhaerel
Novice Crafter
Posts: 47
Joined: Thu Oct 04, 2007 10:34 pm

Post by Jhaerel » Sun Dec 02, 2007 8:48 pm

Here's another question...

If the game says 66% and 33%, does it REALLY mean 2/3 and 1/3, or does it mean 66 and 33, or 66 and 34?

Edit: I'll check out your guide too Zim, thanks and nice work!

Just got the the point in my program where I'm working in the filters...

Wondering if I should make it possible to enter the filters explicitly, or go with the percentages that are used by swg, like 25, 33, 50, 66, 75, 100 using drop downs. The thing is, if you make it explicit, how do you determine if the user types 66 and 33, use a different equation, because it's not *really* 66 and 33 exactly.

Jh

Zimoon
Forum Moderator
Posts: 4817
Joined: Mon May 14, 2007 6:55 am
Location: Stockholm, SE
Contact:

Post by Zimoon » Sun Dec 02, 2007 9:49 pm

Jhaerel wrote:Here's another question...

If the game says 66% and 33%, does it REALLY mean 2/3 and 1/3, or does it mean 66 and 33, or 66 and 34?

I have not seen a definite answer to that and have not tried myself. As a developer I should use 1/3 and 2/3 programatically, but I have no definite reply.

Edit: I'll check out your guide too Zim, thanks and nice work!

Thanks!

Just got the the point in my program where I'm working in the filters...

Wondering if I should make it possible to enter the filters explicitly, or go with the percentages that are used by swg, like 25, 33, 50, 66, 75, 100 using drop downs. The thing is, if you make it explicit, how do you determine if the user types 66 and 33, use a different equation, because it's not *really* 66 and 33 exactly.

Problem is some schematics does not only have two but three stats, such as 25/25/50, etc., so you will have to provide a long list then. On the other hand, not all end up in exactly 100, as 33+66=99, and some more. I'd offer text fields and extrapolate whatever somebody enters to 100%.

In red


/Zimoon

Jhaerel
Novice Crafter
Posts: 47
Joined: Thu Oct 04, 2007 10:34 pm

Post by Jhaerel » Mon Dec 03, 2007 3:22 pm

Actually,

I had a bit of a different idea, and I've got it partially implemented so far...

The app has a Quick Filter area... in this area, are the 11 resource stats along with a drop down box for each one. Each box allows you to choose the values --- (For no stat), 25, 33, 50, 66, 75 and 100.

So for example, you could set DR to 25, HR to 25, and OQ to 50. The title of the groupbox shows "Quick Filter (Current: xx%)". As you change the values in the drop downs, the value in the groupbox title updates.

The neat thing is, I've written it so that if you choose a value that takes the total over 100%, it automatically drops off the oldest choices (switches them back to ---) until the total is back down to 100 or less.

So for example, if you set CR to 25, DR to 25, and OQ to 50, the total at the top will be 100. If you then set SR to 50, the program will realize the total is over 100, and remove the first entry (CR). The total will then be 125, so it will go back and remove the next entry chosen (DR), and leave you with just OQ 50 and SR 50.

That part is done. The following is not yet implemented:

In the datagrid, a column called "Calculated" or "Calculation" or "Filter Calc" (Haven't decided which yet) will show up if you have actually started to manipulate the filter. This column will show the % calculation for the currently displayed resources based on the Filter combo box entries. As you change the entries, the column will automatically update.

Next, a slider at the bottom of the Quick Filter box will allow you to move the minimum percentage between 0 and 100%... This slider will set the minimum % calculation that is displayed in the datagrid... So if I set it to 70%, only values above 70% in the Calc column will even be displayed.

Finally, all of this filter implementation will be saveable. I have a listbox and save button at the top of the resource tree, where you will be able to type in a filter name and hit the save button. Saving a filter will save the currently checked nodes in the resource tree (Yes, you CAN choose more than one node with check boxes!), the current Quick Filter values, the Quick Filter minimum slider bar position, the order of the columns, and the column(s) that the grid is being sorted by. It will be a simple matter to choose a filter from the drop down list, and all of the above entries will be repopulated and the grid updated immediately.


The following items are done, but unrelated to the filter:

Another kinda "neat" thing I've implemented is automatic column removal. The option dialog allows you to turn "Automatic Column Removal" off or on... When it is set on, the resource list automatically takes out columns that have no values in them. This will start to occur as you drill down into the resource tree... For example if I choose the Flora node in the resource tree, the columns that are associated with Inorganics automatically disappear. Another example, if I check both the "Metal" and "Dantooine Wild Oats" nodes, you will get all (?) of the columns because they all have entries in the current view. Of course, this is a toggle-able option for those who want to see all the columns (Even tho they are empty).

Next, I've impleneted a "Unique Resources" feature... This feature is a button that shows up on the main toolbar. When you press this button (it stays down), the listview changes so that only one entry is shown for each resource name. For the planet, the first (alphabetically) is shown, along with ( +X)... For example if Doonium Iron is on 4 planets, the first of which is Dathomir, the planet name for the entry will be "Dathomir (+3)". The entry for the other planets will be suppressed. However, if you want to know which other planets its on, you can hover over the planet name, and a tooltip will display "Other planets:" with the other planets listed one per line.

That's all I can think of so far, I'm sure there's a lot more...

The program is working well so far. Once I get the filter all done and saveable, I have a few more things on the list to work on:

1. Saving your own resource stock
2. Saving a file of "Past" expired resources
3. Displaying age of the resource, along with expected life
4. Harvester calculator
5. Schematic Handling (This is a big one)

Jh


Jh

Holden
Apprentice Crafter
Posts: 61
Joined: Fri Oct 19, 2007 4:44 am
Location: Chicago, IL, USA

Post by Holden » Mon Dec 03, 2007 9:46 pm

Jhaerel wrote:The neat thing is, I've written it so that if you choose a value that takes the total over 100%, it automatically drops off the oldest choices (switches them back to ---) until the total is back down to 100 or less.
Do you account for resource caps? If not, then greater than 100% values are valid.

Let's say I have a recipe that calls for 50%CD/50%OQ in copper and steel. Copper is uncapped for both stats, but steel caps at 650. That means that while copper is truly 50/50, steel is effectively 50*1000/650 = ~76%/50% - 126% total. In other words, the CD of the steel, since it's capped, is actually more important than the OQ in a nominal 50/50 mix.

For this site, I use the adjusted/weighted value in order to know both the precise value a resource adds and to compare two resources against each other.

For another, concrete, example, ponder this:

Starsider has at least two different "best" titanium aluminums, depending on the percentages. For 33CD/66OQ, it's Egacium, while Ronim is better in a 50/50 mix. When doing an unweighted search, Egacium is returned as the better for both; when weighted appropriately, Ronim is returned for 50/50.

Zimoon
Forum Moderator
Posts: 4817
Joined: Mon May 14, 2007 6:55 am
Location: Stockholm, SE
Contact:

Post by Zimoon » Tue Dec 04, 2007 8:10 am

Holden wrote:
Jhaerel wrote:The neat thing is, I've written it so that if you choose a value that takes the total over 100%, it automatically drops off the oldest choices (switches them back to ---) until the total is back down to 100 or less.
Do you account for resource caps? If not, then greater than 100% values are valid.

Let's say I have a recipe that calls for 50%CD/50%OQ in copper and steel. Copper is uncapped for both stats, but steel caps at 650. That means that while copper is truly 50/50, steel is effectively 50*1000/650 = ~76%/50% - 126% total. In other words, the CD of the steel, since it's capped, is actually more important than the OQ in a nominal 50/50 mix.

For this site, I use the adjusted/weighted value in order to know both the precise value a resource adds and to compare two resources against each other.

For another, concrete, example, ponder this:

Starsider has at least two different "best" titanium aluminums, depending on the percentages. For 33CD/66OQ, it's Egacium, while Ronim is better in a 50/50 mix. When doing an unweighted search, Egacium is returned as the better for both; when weighted appropriately, Ronim is returned for 50/50.
I do not follow this reasoning easily, stats becoming more important than others, can you explain? Or I might need to caffeinate myself properly first ;)
Neither do any of you mention the amount of resources used in the schematic, which since of Ch 5 is also considered.

For just looking at stats and not bothering with number of units used, to my understanding there are only two options:
  • if the schematics call for the particular resource class its cap is consindered
  • if the schematics call for a more generic resource class that class' cap is used
You do not even have to bother with if a class has a cap or not since if you use the XML file its cap will be 1000 or any lower value, which is fine in the formula stat * 1000 / cap since 1000 / 1000 = 1. The important thing is which cap to consider, the particular resource's or any of its parent classes.

More on this issue in the Beginners Guide for Traders, but if there is anything wrong it the guide, please let me know.

/Z

User avatar
Savacc
Architect & Shipwright Forum Moderator
Posts: 1227
Joined: Mon Mar 26, 2007 9:45 pm
Location: Central Oregon

Post by Savacc » Tue Dec 04, 2007 8:34 am

Holden wrote:Do you account for resource caps? If not, then greater than 100% values are valid.

Let's say I have a recipe that calls for 50%CD/50%OQ in copper and steel. Copper is uncapped for both stats, but steel caps at 650. That means that while copper is truly 50/50, steel is effectively 50*1000/650 = ~76%/50% - 126% total. In other words, the CD of the steel, since it's capped, is actually more important than the OQ in a nominal 50/50 mix.
Im with Z here, I dont see where you are coming from?

My understanding on Steel with CD that exceed the cap (JTL or Musty resources) is that they are treated as if they were 650, or 100%. On this site, they are incorrectly (as far as I know) given % over 100.

Your second example of Titanium Coppers that are better if the schematic is 50%/50% or 33%/66%, I do understand.

Holden
Apprentice Crafter
Posts: 61
Joined: Fri Oct 19, 2007 4:44 am
Location: Chicago, IL, USA

Post by Holden » Tue Dec 04, 2007 12:49 pm

Zimoon wrote:I do not follow this reasoning easily, stats becoming more important than others, can you explain? Or I might need to caffeinate myself properly first ;)
Directing me to the Beginner's Guide won't help, but thanks. :lol:

Resource caps, when applied to 50/50 recipes, make a change in a capped stat more significant than a change in an uncapped stat.

For steel, CD650/OQ1000 is capped.

CD650/OQ950 has a weighted value of 975 (when looked at on its own):

(650*1000/650)/2 + 950/2 = 975

CD600/OQ1000 steel is significantly worse than 650/950 because of the CD cap:

(600*1000/650)/2 + 1000/2 = 961

In other words, in 50/50, 1 point of CD = 1000/650 points of OQ. Changing CD changes the value faster than changing OQ, ergo CD is actually more important than OQ.

The proper way of looking at the value of a resource is to apply the cap as it applies to a recipe. The value of a 50CD/50OQ steel is really:

(CD*1000/650)/2 = 76%CD/50%OQ

That can either be done by the program itself (in other words, included in every calculation) or it can be left alone and up to the user to know enough to weight the stats appropriately (as is done with Find Resources both here and on the .com).

Leaving it alone and allowing the user to weight the stats is probably the better idea, as otherwise you also have to account for the difference between whether a recipe is calling for "steel" at a 650CD cap or "ditanium steel" at a cap of 475CD.

In short, it's what I said in the first place: Limiting a search to 100% isn't necessarily valid. Nor, for that matter, is limiting values to the ones in a dropdown box.

The Titanium Aluminum example wasn't just about one resource being better than the other at different percent values; it was that the lesser resource is returned as the better resource if you fail to weight your search.

If you search Starsider for Titanium Aluminum at 50/50, it returns Egacium, because .5 CD + .5 OQ is higher. If you apply the resource caps to the search, it appropriately returns Ronim, because (1000/408)/2 CD + .5 OQ is higher.

Zimoon
Forum Moderator
Posts: 4817
Joined: Mon May 14, 2007 6:55 am
Location: Stockholm, SE
Contact:

Post by Zimoon » Tue Dec 04, 2007 12:59 pm

OK, now I see what you mean. Yes, each point on a capped resource will always "be worth" more than compared to a point in a less severely capped resource, or a cap-less. Personally I settle with how great it is in % of its cap though, or % of any of its parental cap, or % of 1000 whichever is the most appropriate at the moment, which depends on what the schematic calls for in that slot.

Still, you must consider the amount of each resource as if 50 units of Steel and 10 units of Metal, using the same Steel in both slots will only degrade the CD with 1/6. But that can of course be bad enough :)

The so called CD bug was squashed in Chapter 5 and hopefully it will rest in peace :?

/Zimoon

Jhaerel
Novice Crafter
Posts: 47
Joined: Thu Oct 04, 2007 10:34 pm

Post by Jhaerel » Tue Dec 04, 2007 1:40 pm

My plan was to first implement it using raw caps of 1000 just to get the calculation working, and THEN later, figure out in the tree exactly which node they have checked off. In my program, you can choose exactly the node you need based on what the schematic says, so if it says "Metal" you would check off the "Metal" node and not the "Iron" node.

To do this, I'll first look at the class of the current resource, and check that specific node in the tree. If it's checked, I'll use the caps of THAT node. If not checked, I'll go up one level in the tree, and see if that one is checked. And so on, until I know exactly which cap is required for the resource I'm currently doing calculations on.

This allows the filters to be much more versatile... If you need "Metal" in your schematic, and CD is important, you don't want it calculating the result for steel based on steel's cap, because there are other metals that are much better.

I know that for the purpose of true-to-swg calculations, the actual amount you use is important, but there's no *easy* way to implement that into a raw filter without having a bunch more boxes to fill in... Unless I make the filter entry an actual new popup window, which is a definite possibility. My plan was for that part to be implemented into the true schematic functionality (coming later!)

So far, I've got just the 1000 based filter/calc done... I need to split out some parts into a separate method, since it's pretty much repeated code for each one... Then once it's split out I'll work on a method that takes a resource ID and traverses the tree, returning the cap.

I also have to get the slider bar working, so you can hide results below a threshold... And "pretty up" the calculation column (Maybe with some colors too).

I'd also like to get a splash screen with progress bar going... so I might work on that tonight. The program actually takes upwards of 5 to 10 seconds to initialize, due to reading in the huge resource tree, (possibly downloading and) parsing in the resources, parsing all of them to a separate internal table that holds unique resources, and so on. There's a lot going on there on initial load...

Another thing I need to work on is the timestamp/expected life, as well as automatically checking to see if a new resource file is available.

Still lots to do, but it's coming along nicely.

Jh

User avatar
Savacc
Architect & Shipwright Forum Moderator
Posts: 1227
Joined: Mon Mar 26, 2007 9:45 pm
Location: Central Oregon

Post by Savacc » Tue Dec 04, 2007 10:57 pm

Long ago, the crafting god Lunariel, observed that there were shipwright schematics that took 4 resources and had an experimental % of OQ 50% and PE 50%, but only one of the resources had a PE stat. Lunariel insisted that that made the PE stat worth 4 times any OQ stat and thought we should "adjust" the % to OQ 25% and PE 75% to account for this. It is the only time in my crafting life I ever disagreed with the master. When I saw your (Holden) post, I suspected you (Holden)were falling into the same kind of thinking as Lunariel.
Why I disagree with you both (Holden and Lunariel), is that we know how SOE figures the experimantal % and handles caps and resources without a stat. It is not by "adjusting" the experimental %. Z gives great detail in his guide on how caps and resources without a stat are figured.
In your (Holden), and Lunariel's defense, Im sure you (Holden) know how the schematics actually work, and were not saying the % should be changed to "do the math", but rather that we should "think" in terms of the % not being 50/50, but rather weighted towards the capped resource or resource with a stat. If it helps you (Holden) to "think" in those terms, then go ahead. Just be sure when its time to "do the math" that you (Holden) use the actual values.
Last edited by Savacc on Wed Dec 05, 2007 8:21 am, edited 5 times in total.

Jhaerel
Novice Crafter
Posts: 47
Joined: Thu Oct 04, 2007 10:34 pm

Post by Jhaerel » Wed Dec 05, 2007 12:39 am

I'm confused, are you referring to my post?

Jh

User avatar
Savacc
Architect & Shipwright Forum Moderator
Posts: 1227
Joined: Mon Mar 26, 2007 9:45 pm
Location: Central Oregon

Post by Savacc » Wed Dec 05, 2007 8:05 am

Opps :oops: No I meant Holden. I saw your post and thought it was him. Sorry.

User avatar
Savacc
Architect & Shipwright Forum Moderator
Posts: 1227
Joined: Mon Mar 26, 2007 9:45 pm
Location: Central Oregon

Post by Savacc » Thu Dec 06, 2007 9:29 am

Jhaerel wrote:So is the max cap used in calculations for crafting? Like if the max cap on the OQ on something is 800 (just an example) and I have some of that with OQ 800, is it worth 80% for crafting or 100%?

Jh
Your drafting tool will tell you. At the assembly screen, where you add the resources, check to see if the bar is green and full or not, then look in the box in the lower right and see if the OQ calculation is 80% or 100%.

Holden
Apprentice Crafter
Posts: 61
Joined: Fri Oct 19, 2007 4:44 am
Location: Chicago, IL, USA

Post by Holden » Thu Dec 06, 2007 12:37 pm

Savacc wrote:Long ago, the crafting god Lunariel, observed that there were shipwright schematics that took 4 resources and had an experimental % of OQ 50% and PE 50%, but only one of the resources had a PE stat. Lunariel insisted that that made the PE stat worth 4 times any OQ stat and thought we should "adjust" the % to OQ 25% and PE 75% to account for this. It is the only time in my crafting life I ever disagreed with the master. When I saw your (Holden) post, I suspected you (Holden)were falling into the same kind of thinking as Lunariel.
Hmm. Yes and no. I was talking about looking at the value of a resource on its own. Obviously in the actual calculation, using your 4 resources (we'll call them a, b, c, and d) and 1 pe example, assuming you need w of a, x of b, y of c, and z of d, and that d has pe:

1/2 * (w*aoq + x*boq + y*coq + z*doq)/(w+x+y+z)) + 1/2 * (z*dpe/z)

(Or, simplified: Half the average OQ plus half the average PE.)

So while the PE of d carries far more weight than the OQ of any one resource, the PE is no more or less important than the combined OQ. While having a good PE in your d is very important, it's no less important than the average OQ of the four resources. It's easier to make sure that the PE is higher, since it's just one resource, but it doesn't change the actual formula.

What I'm referring to is that if PE of d is capped and d is a named resource, the PE of d is more important than the OQ of d when looked at on its own. Let's say PE of d is capped at 400 and you have two options for d, one 350PE/1000OQ and one 400PE/950OQ.

If you search for d on this site (and on most simplified resource viewers) and plug in 50/50 you get:

1) 1/2 * 350 + 1/2 * 1000 = 675
2) 1/2 * 400 + 1/2 * 950 = 675

The casual observer thinks these two are weighted the same and so are equally viable. Since we know how resource caps apply, we know that the actual values are:

1/2 * 350 * 1000/400 + 1/2 * 1000 = 937(.5)
1/2 * 400 * 1000/400 + 1/2 * 950 = 975

Instead of the two being equal, it's the difference between one being capped and one not. In order to find the resource that's actually better, instead of searching for 50%PE/50%OQ, you need to search for 50*1000/400 PE/50% OQ, or 125%PE/50%OQ.

It doesn't change the value of d in the formula, but it is the difference between finding the best d and finding a good d. (And no good d goes unpunished?)

All I was trying to do was find out whether Jhaerel's tool was using the simplified approach or if it accounted for caps. If it was the former, I was pointing out that for capped/named resources, values over 100% were convenient for finding resources. Since it was the latter, it was a moot point. :D

Jhaerel
Novice Crafter
Posts: 47
Joined: Thu Oct 04, 2007 10:34 pm

Post by Jhaerel » Thu Dec 06, 2007 1:29 pm

My plan is to implement a checkbox that will enable or disable resource cap based calculations, in addition to using a tree search method that will decide which cap to use in a calculation...

As I mentioned before, if you pick "Metal" in the tree, and no sub-types, any sub-type resource will be calculated with the caps for Metal. However, if you pick a sub-type, it will use that types caps for the calculation.

In other words, given a resource, it will first check to see if it's own type is checked in the tree, if not, it will search up the tree until it finds the box that is checked and use the caps for that type.

Does this fit in with how resource calculations are truly done in the game?

The quick filter on the main resource page will not take into account the amount of each resource used in the schematic. Instead, there will be another tab page where you will be able to view and hopefully create schematics. On this tab page, it will take into account resource caps and amounts.

I still have a long way to go on this, and I'm learning a lot as I go :P

Jh

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests