How would I go about retrieving all ores from the ore dictionary, given some partial string (e.g. "ore", "wood", "gem").

 

I don't want to use the resulting collection as a recipe, so don't point me at how to use the dictionary for recipes.  I specifically need to know the block ID numbers of the various ores to compare them with the return from world.getBlockId(x, y, z) for determining if something special needs to occur.

 

It's easy enough to do a by-hand tabulation of the vanilla ores, but I want my mod to also work with any other ore any other mod might add, without knowing the exact name of the ore.

How would I go about retrieving all ores from the ore dictionary, given some partial string (e.g. "ore", "wood", "gem").

 

I don't want to use the resulting collection as a recipe, so don't point me at how to use the dictionary for recipes.  I specifically need to know the block ID numbers of the various ores to compare them with the return from world.getBlockId(x, y, z) for determining if something special needs to occur.

 

It's easy enough to do a by-hand tabulation of the vanilla ores, but I want my mod to also work with any other ore any other mod might add, without knowing the exact name of the ore.

How about subscribing to the OreRegisterEvent (as early as possible so you don't miss any) and then keeping your own List of "ores" that match your criteria.

 

I ended up getting help from someone who'd done it before, but I didn't know where I'd get my answer first.

 

But yes.

 

That did it.

How about subscribing to the OreRegisterEvent (as early as possible so you don't miss any) and then keeping your own List of "ores" that match your criteria.

 

I ended up getting help from someone who'd done it before, but I didn't know where I'd get my answer first.

 

But yes.

 

That did it.

By the way: there also is OreDictonary.getOreNames if anyone needs it

 

That gets all blocks that match a single name.  And by single name I mean "oreCopper" (you have three installed: 1551, 21345, and 27000) not "ore" (you have iron, coal, copper, diamond...)

That gets all blocks that match a single name.

It gets all OreDict entries. And by that I mean all of them. You could just get them and loop through to find the ones you need.

 

Which is inefficient to be doing 50,000 times a tick.

(50,000 is not an unreasonable estimate in my case.  If anything it's conservatively low by a few powers of 10.  A more accurate estimate would be 2²⁴, if I understand the map code correctly.)

 

Edit:

Ran a test, my custom map hits ~10,000 blocks per update on flat maps and almost 200,000 per update on a generic vanilla world (average ground height of 63).  So less than I suspected, but the suspected value is probably pretty close to the worst-cast scenario.

What the hell is your mod doing? Sounds incredibly inefficient and wistful.

Also, you only need to grab it once, as the returned ArrayList will be updated automatically...

yes but getOres(name) does not.

What the hell is your mod doing? Sounds incredibly inefficient and wistful.

 

I'm not doing anything the base vanilla map code doesn't already do.  You know how it updates the maps in vertical slices?

 

Yeah, has nothing to do with spacing out figuring out what color the pixels needs to be to reduce lag.  It's an artificial delay in sending the data from the server to the client.

yes but getOres(name) does not.

He wants a partial match (every ore****).

Do I really fucking have to spell it out?

for (String name : getOreNames())
{
  if name matches shit we care about:
    ourCache.add(getOres(name));
}

 

What the hell is your mod doing? Sounds incredibly inefficient and wistful.

 

I'm not doing anything the base vanilla map code doesn't already do.  You know how it updates the maps in vertical slices?

 

Yeah, has nothing to do with spacing out figuring out what color the pixels needs to be to reduce lag.  It's an artificial delay in sending the data from the server to the client.

And so?

Point is massive massive amounts of computations done every tick is a HORRIBLE idea, ESPECIALLY if the data will not be changing, ever. Unless someone goes and changes a block.

 

As for maps, they don't do there calculations EVERY tick, they only do it if a player is holding the item in there hand.

Which is rarely, and when it does it, it does it in a optimized manor.

Those vertical lines? Thats not a artificial delay persey, just a queuing system to make sure the system doesn't overloaded the tick or network.

And so?

Point is massive massive amounts of computations done every tick is a HORRIBLE idea, ESPECIALLY if the data will not be changing, ever. Unless someone goes and changes a block.

 

As for maps, they don't do there calculations EVERY tick, they only do it if a player is holding the item in there hand.

Which is rarely, and when it does it, it does it in a optimized manor.

Those vertical lines? Thats not a artificial delay persey, just a queuing system to make sure the system doesn't overloaded the tick or network.

 

I know it's only when it's in their hands.  It is, however, every tick when active.

And as far as I can tell, those vertical lines come from the SERVER sending the packet data to the CLIENT.  NOT the actual calculation.  One of the map types I'm working on updates the map data every frame (that the player is holding it, obviously) regardless of the pixel's location on the map (as it's based on another entity's position) and it STILL draws in vertical lines.

Did you miss the part where I explained the vertical lines?

Did you miss the part where I explained the vertical lines?

 

Did you miss the part where I said that I specifically put code to update constantly and I still got vertical lines and traced it back to the packet handling code?

No, you just fail to understand what a queue to prevent network/tick overloading.

It chunks up the data to columns.

And you fail to miss my point:

 

While there is code to prevent NETWORK overloading there is not code to prevent TICK-UPDATE OVERLOADING.  At least, not so far as I've noticed.

There is, Notch hides it behind the 'view distance' part of the maps.

It only scans a very small range {pragmatically speaking}

Anyways this topic has diverged to the stupid level. Point I was trying to make is be weary of what you do, you don't know how many times i've had to deal with modders thinking Forge makes there computer lag when its just a modder doing something.. really.. really.. bad.