Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow rust monster configs to pick up on oredictionary definitions #15

Open
Sunconure11 opened this issue Jul 16, 2018 · 20 comments
Open
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@Sunconure11
Copy link
Owner

Since many things have oredictionary definitions, this could prove useful when dealing with say, multiple mods that add various forms of copper.

@Sunconure11 Sunconure11 added enhancement New feature or request help wanted Extra attention is needed labels Jul 16, 2018
@BlackJar72
Copy link
Collaborator

I may look into it some time, but it could get a bit complicated depending on how its done. Iterating registered items in post-init (similar to how Doomlike Dungeons exports block and item lists) would probably be the basis. Then it would need to check each item against a list of ore dictionary entries (not sure how to do this off the top of my head). Could be a bit slow (O{m,n) = m*n), but might not be to bad during start-up.

I'll be slowing down on these things -- its become self-destructive the amount of time that goes into these modding binges and letting too many other things go.

@Sunconure11
Copy link
Owner Author

Sunconure11 commented Jul 31, 2018

Hm, for the metal configs, does it pick up on just ore, or does it allow for ingots and what not too? I'm making sure I'm doing this right, as I am allowing all metals in my pack to be attacked. You might want to check if metadata is taken though.

Also, it appears Rust Monsters were meant to spawn near their respective veins of metal. Would it be possible to add a config to list ores for them to spawn by?

https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/minecraft-mods/1272780-dungeon-mobs-reference-to-new-thread-in-last-post

Also, just making sure, but this is correct syntax for the metal list, yes?

		minecraft:gold_ingot
		abyssalcraft:abyingot
		abyssalcraft:cingot
		abyssalcraft:dreadiumingot
		abyssalcraft:tiningot
		abyssalcraft:copperingot
		abyssalcraft:ethaxiumingot
		aetherworks:item_resource:4
		aquaculture:loot:1
		astralsorcery:itemcraftingcomponent:1
		basemetals:obsidian_ingot
		basemetals:redstone_ingot
		basemetals:adamantine_ingot
		basemetals:antimony_ingot
		basemetals:bismuth_ingot
		basemetals:coldiron_ingot
		basemetals:copper_ingot
		basemetals:lead_ingot
		basemetals:nickel_ingot
		basemetals:platinum_ingot
		basemetals:silver_ingot
		basemetals:starsteel_ingot
		basemetals:tin_ingot
		basemetals:zinc_ingot
		basemetals:aquarium_ingot
		basemetals:brass_ingot
		basemetals:bronze_ingot
		basemetals:cupronickel_ingot
		basemetals:electrum_ingot
		basemetals:invar_ingot
		basemetals:mithril_ingot
		basemetals:pewter_ingot
		basemetals:steel_ingot
		botania:manaresource
		botania:manaresource:4

@BlackJar72
Copy link
Collaborator

Any block or item should work. I'd have to look at it again, but one short coming I hadn't thought of before is that I don't think it understands meta data at this point. That may very well be something that needs fixing. But beyond that it can be anything in the game that can exist as an Item.

@Sunconure11
Copy link
Owner Author

Can we add a config setting to allow it to spawn near a list of modded ores, in addition to the ones from vanilla? Since one behavior of it is to spawn by such.

@BlackJar72
Copy link
Collaborator

That should be possible, probably not too hard -- though I'd probably make understanding damage / data / meta values a priority (which definitely shouldn't be hard -- I've done that before with the loot lists for Doomlike Dungeons). But yeah, that can be done. It could probably extract blocks from the food list, but otherwise a separate list could be done.

That leads to why it has its own config folder -- at a certain points it might make sense to give config files to individual mobs as more options are made available.

@BlackJar72
Copy link
Collaborator

Oh, I do wonder why you have "basemetals:obsidian_ingot" -- obsidian isn't a metal, and it doesn't make any more sense they'd want that than diamond (which they currently do not eat).

@Sunconure11
Copy link
Owner Author

I was tired, and was trying to cover as many modded ingots as possible

@Sunconure11
Copy link
Owner Author

Sunconure11 commented Jul 31, 2018

Okay, it looks like configs are not working in general for the rust monster. No matter what modded stuff I throw at them, if it is in the config, they do not pick up on it.

@BlackJar72
Copy link
Collaborator

OK, I'll have to look into sometime over the weekend I guess.

@BlackJar72
Copy link
Collaborator

Well, I fixed the bug where they don't use the food list at all -- I had them eating bricks and leaves for a test and it worked fine.

I'll look into the other fixes and enhancements later.

@BlackJar72
Copy link
Collaborator

No, it definitely won't work with damage / meta values -- its a set of Item, not ItemStack. Items don't have that data, stacks do. It would really complicate things to have it use ItemStacks, though I can see how this could be a problem with mods that use "god items."

@Sunconure11
Copy link
Owner Author

There are mods that assign meta values as to conserve on IDs. An example would be thaumcraft, all of it's ingots are technically one item, just with differing meta.

@Sunconure11
Copy link
Owner Author

Also, just in case, but since you are using a similar set up for entities to spawn from the shrieker, you might want to test that too.

@BlackJar72
Copy link
Collaborator

I already tested the shrieker -- it works, that always did.

@BlackJar72
Copy link
Collaborator

BlackJar72 commented Aug 4, 2018

Rust monster foods should now work as soon as the latest up-load is approved and becomes available. Not sure if this should be closed -- its not ore dictionary support.

Note, the syntax is "modid:name" to include all block / item versions, or "modid:name:meta" to include a specific meta value. It has to be this way to support item with actual durability. So...

                botania:manaresource
		botania:manaresource:4

...doesn't really make much since in that scheme. It should probably be...

                botania:manaresource:0
		botania:manaresource:4

...if I'm interpreting the intention correctly.

@Sunconure11
Copy link
Owner Author

Config system may have broken, resulting in crashes. Investigating.

https://pastebin.com/TbXbUKi7

@BlackJar72
Copy link
Collaborator

I used the wrong method to translate the string data into a number for meta data. Its now fixed in the repo. You may test and uploaded when ready.

(Frankly, I'm getting tire of this and ready for a total break.)

@BlackJar72
Copy link
Collaborator

Never mind I'll upload the fix. Then, I don't know. I'll leave it to you to close the issue when you're satisfied.

@Sunconure11
Copy link
Owner Author

I'm at a loss for words, it's still happening.

Here is my config:

https://pastebin.com/d5ikjNAk

@BlackJar72
Copy link
Collaborator

The exact same crash?! That doesn't make sense. If anything is mistyped or not found -- any errors in the list -- and it will definitely crash. But I can't see any way the old crash could still happen with the latest version (which was tested here and works).

Anyway, not time to fool with it now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants