With the latest CCC core 8.6.8 and NEI 1.5.2.15 with dynamic lights installed for some reason MC won't see NEI and shows a missing screen. However, if I rename your mod to z_dynamic lights_1.5.2 it will work just fine. Just thought I would let you know. Adding the z_ must make it load after NEI or something.
I can confirm this. I guess since the mods are loaded alphabetically putting a z_ in front of dynamic lights makes it load last.
PSN:
Can't you read? I said I only play PC Minecraft
Member Details
I really hate messing with mods. I removed the comma from the end of every config (just the comma at the very end, not all of the commas) & I still get a crash screen that says that drop-Items in the problem. Here's the Dropped items config:
# Configuration file
####################
# general
####################
general {
# Item IDs that shine light when dropped in the World. Syntax: ItemID[-MetaValue]:LightValue, seperated by commas
S:LightItems:10:15,11:15,50:14,51:15,52:5,62:13,74:1,76:7,89:15,90:11,91:15,99:1,119:15,120:1,122:1,124:15,130:7,138:15,149:1,150:9,152:1,327:15,331:1,348:4,356:1,369:3,377:15,378:2,379:1,384:2,385:1,399:4,403:1,404:1
# Item IDs that do not shine light when dropped and in water, have to be present in LightItems. Syntax: ItemID[-MetaValue], seperated by commas
S:TurnedOffByWaterItems=50,10,11,51,52,62,76,150,327,369,377,378
# Update Interval time for all Item entities in milliseconds. The lower the better and costlier.
I:"update Interval"=1000
}
What am I doing wrong? Did I mention that this is infuriating? It is.
First of all, I had the same problem with an interaction between Dynamic Lights and NEI, but I was able to fix it. I opened the DynamicLights jar file as an archive and replaced all files under the codechicken directory with their most recent versions from the NEI and CodeChickenCore jars. It seems likely that doing this would solve the conflict for others as well.
Secondly, I noticed an oddity with Dynamic Lights where worn helmets will stop emitting light once they become damaged. I wanted to inquire as to whether this is something that's only happening on my machine because of the edited DynamicLights jar, or if this is an already-known issue. Here's the relevant config file in case it's needed:
general {
# Item IDs that shine light while held. Armor Items also work when worn. [ONLY ON YOURSELF] Syntax: ItemID[-MetaValue]:LightValue, seperated by commas
S:LightItems=50:15,89:12,348:10,91:15,327:15,76:10,331:10,298:6,302:8,306:10,310:14,314:15
# Item IDs that do not shine light when held in water, have to be present in LightItems. Syntax: ItemID[-MetaValue], seperated by commas
S:TurnedOffByWaterItems=50,327
}
First of all, I had the same problem with an interaction between Dynamic Lights and NEI, but I was able to fix it. I opened the DynamicLights jar file as an archive and replaced all files under the codechicken directory with their most recent versions from the NEI and CodeChickenCore jars. It seems likely that doing this would solve the conflict for others as well.
Secondly, I noticed an oddity with Dynamic Lights where worn helmets will stop emitting light once they become damaged.
Why, what do you mean included NEI classes, i dont package NEI code.... what ... oh boy.
I had a bug in my workspace which had my mod packages "polluted" with ChickenBones classfiles.
I fixed it now. Re-download my mods to fix this bug if you have it (or delete the chickenbones folder from the mod archives)
As for damaged armor, that's because damaging changes the metavalue/damagevalue. I probably need wildcard code for that.
Can confirm that ATOMICS latest dynamic lights download works just fine with NEI now without any problems. No more re-naming or deleting anything. THANKS ATOMIC!!!!!
Can I specify a meta-value range for an item in the config file? I'm trying to get this to work with UnlitTorches, but that mod replaces item code 50 with the UNLIT torch (not configurable), and uses ALL meta values from 1 to whatever the max is (32768?) for the lit values as it gradually dies out. So I need to set a meta value range of 1-32768 in the dynamic lights config file, and It's going to be massively bloated if I put individual entries for each of those (which I would do with a script, not manually.. cuz GOD that's a lot of typing).
I meant no offense. It's just that last time I posted a trouble ticket on someone's bit-bucket I waited a week and a half. He didn't see it until found him on IRC at which point he apologized and fixed the problem I was having within a few minutes. After that I just don't' take chances and leave polite PMs instead. I'm sorry if it offended you.
Key point being "after a week and a half", not minutes later. At least give me a chance
1.2.1
- rewrote configuration parsing again, now supports names, ranges and wildcards
- this applies to DynamicLights_thePlayer, DynamicLights_dropItems and DynamicLights_otherPlayers configs only
- delete or fix your old config files, they are unfortunately not compatible
- see MCF thread on how to use the new config syntax
How the config syntax works:
[DynamicLights_thePlayer, DynamicLights_dropItems and DynamicLights_otherPlayers configs]
* Possible setups:
* X := simple ID X, wildcards metadata
* X-Y := simple ID X and metadata Y
* X-Y-Z := simple ID X, metadata range Y to Z
* A-B-C-D := ID range A to B, meta range C to D
There is a default value used as "setting", you can specify one by appending "=x" to the ID part
Valid Entry examples:
50
Torch BlockID, 50, will use the default light value (15)
35-* (equals 35)
Wool BlockID, covers all wool metadata/colors
35-2=12
Wool BlockID, 35, magenta subtype (meta 2), will use a light value of 12
35-2-5
Wool BlockID, accepts metadata range [2..5]
314-317-*-*=15
Item ID range [314..317] covering golden armor, wildcarded meta/damage which means any value goes
Also unnecessarily specifying the default light value of 15, you could leave =15 out aswell
You can also substitute block/item IDs with their untranslated String values, useful for mod items
tile.cloth is the same as 35, so tile.cloth-2-5=10 is valid
item.helmetGold-item.leggingsGold-*-* is valid too
Values that cannot be mapped to anything will be logged and ignored
It doesn't appear that the wildcards are working for me. "LightItems=50," causes item 50 (an unlit torch for me) to give off light, but:
• 50-*
• 50-*=15
• 50-*-*
• 50-1-*
• 50-1-32000
All of these result in no form of torch giving light. 50 is my unlit torch item code, and all of the meta values are lit torch codes. The idea is for only the meta values to give off light. Perhaps I'm missing something.
Update: I did completely reconfigured my client from scratch, and I have Dynaimc Lighting in the coremods folder.
- int sm = len > 1 ? catchWildcard(strings[2]) : WILDCARD;
- int em = len > 2 ? catchWildcard(strings[3]) : sm;
+ int sm = len > 1 ? catchWildcard(strings[len > 3 ? 2 : 1]) : WILDCARD;
+ int em = len > 2 ? catchWildcard(strings[len > 3 ? 3 : 2]) : sm;
creepers light up if they are about to blow but neither torches in player's hand nor torches on the ground are lighted. no light for golden helmets on player / in hand as well.
droppeditem config looks like it's supposed to be i guess:
# Item IDs that shine light when dropped in the World.
S:LightItems=50:15,89:12,348:10,91:15,327:15,76:10,331:10,314:14
so the torch should do it.
d'oh!
never mind. i deleted the old configs and now it works fine.
That's the old config style, unfortunately now incompatible. Basically you need to replace the 50:15 with 50=15 and such
Or just delete the old files, the new ones generate by themselves
Thanks Atomic. So, I need to remove the comma at the end of the line?
I can confirm this. I guess since the mods are loaded alphabetically putting a z_ in front of dynamic lights makes it load last.
####################
# general
####################
general {
# Item IDs that shine light when dropped in the World. Syntax: ItemID[-MetaValue]:LightValue, seperated by commas
S:LightItems:10:15,11:15,50:14,51:15,52:5,62:13,74:1,76:7,89:15,90:11,91:15,99:1,119:15,120:1,122:1,124:15,130:7,138:15,149:1,150:9,152:1,327:15,331:1,348:4,356:1,369:3,377:15,378:2,379:1,384:2,385:1,399:4,403:1,404:1
# Item IDs that do not shine light when dropped and in water, have to be present in LightItems. Syntax: ItemID[-MetaValue], seperated by commas
S:TurnedOffByWaterItems=50,10,11,51,52,62,76,150,327,369,377,378
# Update Interval time for all Item entities in milliseconds. The lower the better and costlier.
I:"update Interval"=1000
}
S:LightItems:10:15,...
should be
S:LightItems=10:15,...
First of all, I had the same problem with an interaction between Dynamic Lights and NEI, but I was able to fix it. I opened the DynamicLights jar file as an archive and replaced all files under the codechicken directory with their most recent versions from the NEI and CodeChickenCore jars. It seems likely that doing this would solve the conflict for others as well.
Secondly, I noticed an oddity with Dynamic Lights where worn helmets will stop emitting light once they become damaged. I wanted to inquire as to whether this is something that's only happening on my machine because of the edited DynamicLights jar, or if this is an already-known issue. Here's the relevant config file in case it's needed:
Thanks for the great mod, AtomicStryker!
Why, what do you mean included NEI classes, i dont package NEI code.... what ... oh boy.
I had a bug in my workspace which had my mod packages "polluted" with ChickenBones classfiles.
I fixed it now. Re-download my mods to fix this bug if you have it (or delete the chickenbones folder from the mod archives)
As for damaged armor, that's because damaging changes the metavalue/damagevalue. I probably need wildcard code for that.
Thanks for the help!
I will code a proper item configurator, maybe later today, maybe later.
1.2.1
- rewrote configuration parsing again, now supports names, ranges and wildcards
- this applies to DynamicLights_thePlayer, DynamicLights_dropItems and DynamicLights_otherPlayers configs only
- delete or fix your old config files, they are unfortunately not compatible
- see MCF thread on how to use the new config syntax
How the config syntax works:
[DynamicLights_thePlayer, DynamicLights_dropItems and DynamicLights_otherPlayers configs]
* Possible setups:
* X := simple ID X, wildcards metadata
* X-Y := simple ID X and metadata Y
* X-Y-Z := simple ID X, metadata range Y to Z
* A-B-C-D := ID range A to B, meta range C to D
There is a default value used as "setting", you can specify one by appending "=x" to the ID part
Valid Entry examples:
50
Torch BlockID, 50, will use the default light value (15)
35-* (equals 35)
Wool BlockID, covers all wool metadata/colors
35-2=12
Wool BlockID, 35, magenta subtype (meta 2), will use a light value of 12
35-2-5
Wool BlockID, accepts metadata range [2..5]
314-317-*-*=15
Item ID range [314..317] covering golden armor, wildcarded meta/damage which means any value goes
Also unnecessarily specifying the default light value of 15, you could leave =15 out aswell
You can also substitute block/item IDs with their untranslated String values, useful for mod items
tile.cloth is the same as 35, so tile.cloth-2-5=10 is valid
item.helmetGold-item.leggingsGold-*-* is valid too
Values that cannot be mapped to anything will be logged and ignored
• 50-*
• 50-*=15
• 50-*-*
• 50-1-*
• 50-1-32000
All of these result in no form of torch giving light. 50 is my unlit torch item code, and all of the meta values are lit torch codes. The idea is for only the meta values to give off light. Perhaps I'm missing something.
Update: I did completely reconfigured my client from scratch, and I have Dynaimc Lighting in the coremods folder.
- int sm = len > 1 ? catchWildcard(strings[2]) : WILDCARD;
- int em = len > 2 ? catchWildcard(strings[3]) : sm;
+ int sm = len > 1 ? catchWildcard(strings[len > 3 ? 2 : 1]) : WILDCARD;
+ int em = len > 2 ? catchWildcard(strings[len > 3 ? 3 : 2]) : sm;
Just re-download the mod
creepers light up if they are about to blow but neither torches in player's hand nor torches on the ground are lighted. no light for golden helmets on player / in hand as well.
droppeditem config looks like it's supposed to be i guess:
so the torch should do it.
d'oh!
never mind. i deleted the old configs and now it works fine.
Or just delete the old files, the new ones generate by themselves