Who dev 1.10.2 tested the newer version in their offhand does it still work or is it still bugged from forge?
I am back developing mods but, just not this one right now. I am developing NoCubes fork, arcticraft, and some skylands mods from < 1.6.4 along with maybe evil minecraft and jurassic times mod?(can't find compiled or decompiled version up to date). All of this to revive all good old mods.
Mc_Base is learning asm we will be properly porting to newer versions soon once we replace the crappy new combat system with the old one completly
I noticed several terrible bugs recently that are going on still. There will be another update soon enough with a fake world, and such along with exception handling. Next the aether will be compatible again along with other mods that add in functions with buckets.
Working on the coremod loader as we speak so I can update to 1.12+. For 1.7.10 core loader function: backport features which I found necessary for gameplay 1.12+ = no new combat system by default config and ASM utilities to basically have NEI enhanced version of spawners.
I actually have to finish up some other projects before fully finishing 1.7.10 and porting with the coremod as well.
Great mod. Very well done. I have found a bug though. Here's what the EnchantmentsSpanwerConfig.txt config looked like when it worked.
#Enchantment Config Choose Which Enchantment To Use and What Level
#The Parameters Are EnchantmentId:Level
#The Parameters for no Enchantment is null:null or 0:0 at the first enchantment
<Enchantment>
33:1
</Enchantment>
But when I added looting...
#Enchantment Config Choose Which Enchantment To Use and What Level
#The Parameters Are EnchantmentId:Level
#The Parameters for no Enchantment is null:null or 0:0 at the first enchantment
<Enchantment>
33:1
21:1
</Enchantment>
Neither silk touch or looting work as if it ignores the config.
EDIT: Using 1.7.10
RE-EDIT: I did some more testing. Looting does work if I set it to only use looting and not silk touch.
Great mod. Very well done. I have found a bug though. Here's what the EnchantmentsSpanwerConfig.txt config looked like when it worked.
#Enchantment Config Choose Which Enchantment To Use and What Level
#The Parameters Are EnchantmentId:Level
#The Parameters for no Enchantment is null:null or 0:0 at the first enchantment
<Enchantment>
33:1
</Enchantment>
But when I added looting...
#Enchantment Config Choose Which Enchantment To Use and What Level
#The Parameters Are EnchantmentId:Level
#The Parameters for no Enchantment is null:null or 0:0 at the first enchantment
<Enchantment>
33:1
21:1
</Enchantment>
Neither silk touch or looting work as if it ignores the config.
EDIT: Using 1.7.10
RE-EDIT: I did some more testing. Looting does work if I set it to only use looting and not silk touch.
Could you restate this? The enchantment config is suppose to be all the global enchantments required for all default spawners there is a block override but, the official overrides update is a slight distance away as I am developing an API and coremod at the same time.
Edit: just tested works fine my current setup is enchantment and this enchantment. I will make an enhancement later for enchantments per line is that what you wanted. That would be further down the road after the overrides update?
Oh, I thought I could make multiple types of enchants drop spawners separately. Sorry I misunderstood. I wanted it to use Silkorlooting. NOT Silkandlooting. Sorry I didn't know how it worked.
Rollback Post to RevisionRollBack
If I helped, or you just like my post, please press the button.
Oh, I thought I could make multiple types of enchants drop spawners separately. Sorry I misunderstood. I wanted it to use Silkorlooting. NOT Silkandlooting. Sorry I didn't know how it worked.
With the api I am currently writing you might be able to do that in the near future with Evil notch core but, 1.7.10 is an alpha for apis and 1.10.2 is in pre-alpha
what do you think of this. Of course this would require an almost re-write for all line classes as they would have logic now
Ah an edit. Yes I think that is good! Would that only be for the latest version? Or for all versions?
EDIT: I ask because I'm using the 1.7.10 version.
Um I think 1.7.10 needs to be finished first and for that requires alot of re-writing, also evil notch core needs to be finished before I could do this since silkspawners LineObj is outdated and only uses one class which should be 4+ classes extending each other aka very messy can't parse or extend anything else to make new lines
No promises but, This might get done as it requires me to see what lines need to be dynamic logic like that.
Ah an edit. Yes I think that is good! Would that only be for the latest version? Or for all versions?
EDIT: I ask because I'm using the 1.7.10 version.
I only see && || logic for two line objects{ LineBase and a new LineBase Obj} where it would have int,int,int as dynamic. This is because, the rest of the parsing wouldn't make any sense
"modid:block || modid:block" > LineBase doesn't make sense until applied as an int "int:int || int:int"
"modid:block = int,int,int || modid:block = int,int,int" > LineDynamic doesn't work for the && || logic you wanted
" "modid:block" = int || "modid:block" = int" " > I think this is messy and I have no use for this yet in any mods including weighted inventory
""modid:block" {NBT} = int || "modid:block" {NBT} = int" > Same as above no use for && || logic
Well in order for any && || logic to work you need a new line base similar to line dynamic except this one has no formatting
"int:int,int:int"
So in conclusion the only LineBase Obj that would make any sense would be LineBase && LineDynamicNoFormatting (will be renamed in code)
"modid:block || modid:block,modid:block" > "int:int || int:int,int:int"
So these would have to be added in order to complete the amount of line objects for any newer/other projects
LineItemStackBase
"modid:block" <int> {NBT}
LineDWNF(Line dynamic with no formatting)
"int:int,int:int"
Line Dynamic Logic (ArrayList) where each index is one line of logic
"int:int,int:int || int:int"
Wow, I've discovered that your mod adds a really cool feature which adds more roman numerals beyond X for enchanting. And allows you to enchant beyond the vanilla level cap! But it also makes all my enchants extremely cheap. See spoiler:
Is it ignoring the "RepairCost" tag?
It's always one level. Is there a way I can change this?
Rollback Post to RevisionRollBack
If I helped, or you just like my post, please press the button.
ZephaniahNoah
Wow, I've discovered that your mod adds a really cool feature which adds more roman numerals beyond X for enchanting. And allows you to enchant beyond the vanilla level cap! But it also makes all my enchants extremely cheap. See spoiler:
Spoiler (click to show)
It's always one level. Is there a way I can change this?
Edit: what is your version 1.7.10? I remember playing it with 130+ levels to get to tier IX
Well in order to get to that high of a level you need to spend alot of levels in order to get books that high around 130+ levels so... Also I think it should calculate 1 level per enchantment on a book? If not this is a bug
There is no current config option for this but, in the future there might be if you officially request it.
You will be happy to know I am working on a dynamic line logic line parser. Like I said the parsers of the lines were all completed made a dynamic line and everything broke. All my line classes need more dynamic parsing and an almost total re-write even though I just re-wrote them. I need to make sure to get them and break them up only at the defined syntaxes
In the future this and other core utilities will be in evil notch core which in the future silk spawners will require. Basically just in game features like anvil mechanics and all block properties except for virtual spawner harvest levels?
Yeah my version is 1.7.10. I installed the better anvil mod and it fixed the problem. The enchants now get more expensive over time.
I will look into this then.
You kept complaining about not having levels increasing what do you want by this? I believe you need to get the levels onto the books in the first place but, what did you mean by this when combining two items?
This mod is far from being abandoned it's being enchanted #Mounted Spawners
In This experimental Alpha Edition of EvilNotchCore Pigs Never Show Upon Placement This bug since the beginning will be patched!
Silk spawners code is going to either be re-written or re-organized an all utilities merged to EvilNotchCore. This is because silk spawners should only be silk spawners forge eggs, silk buckets, etc...
It is but, only the super basic function of picking up the spawner and placing it.
Who dev 1.10.2 tested the newer version in their offhand does it still work or is it still bugged from forge?
I am back developing mods but, just not this one right now. I am developing NoCubes fork, arcticraft, and some skylands mods from < 1.6.4 along with maybe evil minecraft and jurassic times mod?(can't find compiled or decompiled version up to date). All of this to revive all good old mods.
Mc_Base is learning asm we will be properly porting to newer versions soon once we replace the crappy new combat system with the old one completly
I noticed several terrible bugs recently that are going on still. There will be another update soon enough with a fake world, and such along with exception handling. Next the aether will be compatible again along with other mods that add in functions with buckets.
are you planning to port to 1.11.2
Working on the coremod loader as we speak so I can update to 1.12+. For 1.7.10 core loader function: backport features which I found necessary for gameplay 1.12+ = no new combat system by default config and ASM utilities to basically have NEI enhanced version of spawners.
I actually have to finish up some other projects before fully finishing 1.7.10 and porting with the coremod as well.
Evil Notch core is in dev meaning you might see some silk spawners activity sooner or later: Custom font renderer is next update.
Great mod. Very well done. I have found a bug though. Here's what the EnchantmentsSpanwerConfig.txt config looked like when it worked.
#Enchantment Config Choose Which Enchantment To Use and What Level
#The Parameters Are EnchantmentId:Level
#The Parameters for no Enchantment is null:null or 0:0 at the first enchantment
<Enchantment>
33:1
</Enchantment>
But when I added looting...
#Enchantment Config Choose Which Enchantment To Use and What Level
#The Parameters Are EnchantmentId:Level
#The Parameters for no Enchantment is null:null or 0:0 at the first enchantment
<Enchantment>
33:1
21:1
</Enchantment>
Neither silk touch or looting work as if it ignores the config.
EDIT: Using 1.7.10
RE-EDIT: I did some more testing. Looting does work if I set it to only use looting and not silk touch.
If I helped, or you just like my post, please press the button.
My mods...
Could you restate this? The enchantment config is suppose to be all the global enchantments required for all default spawners there is a block override but, the official overrides update is a slight distance away as I am developing an API and coremod at the same time.
Edit: just tested works fine my current setup is enchantment and this enchantment. I will make an enhancement later for enchantments per line is that what you wanted. That would be further down the road after the overrides update?
Oh, I thought I could make multiple types of enchants drop spawners separately. Sorry I misunderstood. I wanted it to use Silk or looting. NOT Silk and looting. Sorry I didn't know how it worked.
If I helped, or you just like my post, please press the button.
My mods...
With the api I am currently writing you might be able to do that in the near future with Evil notch core but, 1.7.10 is an alpha for apis and 1.10.2 is in pre-alpha
what do you think of this. Of course this would require an almost re-write for all line classes as they would have logic now
Ok. Thanks for explaining.
If I helped, or you just like my post, please press the button.
My mods...
Ah an edit. Yes I think that is good! Would that only be for the latest version? Or for all versions?
EDIT: I ask because I'm using the 1.7.10 version.
If I helped, or you just like my post, please press the button.
My mods...
Um I think 1.7.10 needs to be finished first and for that requires alot of re-writing, also evil notch core needs to be finished before I could do this since silkspawners LineObj is outdated and only uses one class which should be 4+ classes extending each other aka very messy can't parse or extend anything else to make new lines
No promises but, This might get done as it requires me to see what lines need to be dynamic logic like that.
I only see && || logic for two line objects{ LineBase and a new LineBase Obj} where it would have int,int,int as dynamic. This is because, the rest of the parsing wouldn't make any sense
"modid:block || modid:block" > LineBase doesn't make sense until applied as an int "int:int || int:int"
"modid:block = int,int,int || modid:block = int,int,int" > LineDynamic doesn't work for the && || logic you wanted
" "modid:block" = int || "modid:block" = int" " > I think this is messy and I have no use for this yet in any mods including weighted inventory
""modid:block" {NBT} = int || "modid:block" {NBT} = int" > Same as above no use for && || logic
Well in order for any && || logic to work you need a new line base similar to line dynamic except this one has no formatting
"int:int,int:int"
So in conclusion the only LineBase Obj that would make any sense would be LineBase && LineDynamicNoFormatting (will be renamed in code)
"modid:block || modid:block,modid:block" > "int:int || int:int,int:int"
So these would have to be added in order to complete the amount of line objects for any newer/other projects
Wow, I've discovered that your mod adds a really cool feature which adds more roman numerals beyond X for enchanting. And allows you to enchant beyond the vanilla level cap! But it also makes all my enchants extremely cheap. See spoiler:
Is it ignoring the "RepairCost" tag?
It's always one level. Is there a way I can change this?
If I helped, or you just like my post, please press the button.
My mods...
Edit: what is your version 1.7.10? I remember playing it with 130+ levels to get to tier IX
Well in order to get to that high of a level you need to spend alot of levels in order to get books that high around 130+ levels so... Also I think it should calculate 1 level per enchantment on a book? If not this is a bug
There is no current config option for this but, in the future there might be if you officially request it.
You will be happy to know I am working on a dynamic line logic line parser. Like I said the parsers of the lines were all completed made a dynamic line and everything broke. All my line classes need more dynamic parsing and an almost total re-write even though I just re-wrote them. I need to make sure to get them and break them up only at the defined syntaxes
In the future this and other core utilities will be in evil notch core which in the future silk spawners will require. Basically just in game features like anvil mechanics and all block properties except for virtual spawner harvest levels?
Yeah my version is 1.7.10. I installed the better anvil mod and it fixed the problem. The enchants now get more expensive over time.
If I helped, or you just like my post, please press the button.
My mods...
I will look into this then.
You kept complaining about not having levels increasing what do you want by this? I believe you need to get the levels onto the books in the first place but, what did you mean by this when combining two items?
Thanks to elix_x
This mod is far from being abandoned it's being enchanted #Mounted Spawners
In This experimental Alpha Edition of EvilNotchCore Pigs Never Show Upon Placement This bug since the beginning will be patched!
Silk spawners code is going to either be re-written or re-organized an all utilities merged to EvilNotchCore. This is because silk spawners should only be silk spawners forge eggs, silk buckets, etc...
00100010 01110100 01101111 01101111 01101100 01100011 01101100 01100001 01110011 01110011 00100010 00101100 00100010 01101101 01101111 01100100 01101001 01100100 00111010 01100010 01101100 01101111 01100011 01101011 00100010 00111100 01101101 01100101 01110100 01100001 00111110 01111011 01001110 01000010 01010100 01111101 00100000 00111101 00100000 01101001 01101110 01110100