Prism Lens Fails To Work Consistently

[zeziba]

Following is a build with 11 nodes which consist of the following,

Head: 1 Mage Block 1 Enchanted Spell Turret - Spell: Projectile - Pierce (1-3) - Burst - Sensitive - AOE (2-5) - Harvest - Pickup 1 Tiny Redstone Panel - Has components that release a redstone signal once every interval, in this image set to 280 ticks. 1 Barrel

Node: 1 Mage Block 1 Advanced Spell Prism 1 Piercing Lens 1 Agronomic Sourcelink 1 Source Jar 1 Source Relay

Image of Node:

Image of All the Nodes:

Expected Behavior: That once a spell hits a spell prism with a lens that the lens would apply the appropriate buff. In this case the pierce lens.

Once a spell hits the prism with a lens the spell would properly have the effect applied or extended and allow for further manipulations. This can be capped but should be made obvious in the tooltip if it is the case.

What happens: In the above example system, it ends up being completely none stable with how many nodes the spell will go through. When I first set it up it went through 5 nodes with 1 pierce on the primary spell and when I loaded in today to was only going through the first two nodes even when I placed 4 pierces on the spell.

I have had the spell able to go all the way to the end of the nodes with 1 pierce as well.

The number of nodes it will go through changes if the game is restarted.

[Alexthw46]

There is currently a bug in Ars that let the projectile spell edits reflects on the turret casting them too, I wouldn't exclude some kind of sharing between the projectiles too. Rebooting the world probably forces the data inside the block to resync. Will test on if this issue is still present even with the pending fix to that bug

[zeziba]

Thanks for the info and quick getting back. I also did the following

Took off the lens and reapplied Removed the block and replaced Used the wand to change the direction of the face

The above does not change the behavior of the blocks and it seems global as if I move the setup to differing places, including different dimensions, the number of pierces is the same. So it seems that when the block, original object code, is instantiated and then is is copied the behavior of the block is moved to all similar blocks.

Also, as a note I am playing in a single player world which I have in Lan so I can play with my wife. I have not noticed a difference in behavior of the blocks from either mode.

[zeziba]

I was looking through the files and noticed,

    @Override
    public void shoot(ServerLevel world, BlockPos pos, EntityProjectileSpell spell, Vec3 angle) {
        super.shoot(world, pos, spell, angle);
        spell.pierceLeft++;
        SourceUtil.takeSourceWithParticles(pos, world, 6, AugmentPierce.INSTANCE.getCastingCost());
    }

    @Override
    public boolean canConvert(EntityProjectileSpell spell, Level level, BlockPos pos) {
        return spell.pierceLeft < 10 && SourceUtil.hasSourceNearby(pos, level, 6, AugmentPierce.INSTANCE.getCastingCost());
    }

This should be where my issue is, the canConvert() method is called in the AdvancedPrism.java and if it passes then calls lens.shoot(world, pos, spell, vec3d); which follows by calling SourceUtil.takeSourceWithParticles(pos, world, 6, AugmentPierce.INSTANCE.getCastingCost());.

This is where it will take source at the location of the prism what I read and not the origination location of the spell, which in hindsight makes sense. I will check this later but I am quite sure this is the issue. I did not read anything about that in the functions of the spell prism so I was confused about it until I read the code.

I think that this information should be included in the info book at least if possible as it would help I believe.

p.s. The arbitrary 10 limit to pierce is funny there as well lol, likely should be a config option.

[Alexthw46]

in the tooltip of the lens, "Makes the redirected projectile more piercing if source is supplied" I can make the limit configurable but it was basically to limit the abuse of the lens as it can cut down costs enormously

[zeziba]

Total agree with that thought, would even be fair if the cost was x3 as in most setups as it is such a useful thing, and did not see that particular tooltip so my bad on that though I might have just misread it as well.

It wouldn't be that hard to remove the arbitrary limit if an exponential growth curve was used, an example is as such

    @Override
    public void shoot(ServerLevel world, BlockPos pos, EntityProjectileSpell spell, Vec3 angle) {
        super.shoot(world, pos, spell, angle);
        spell.pierceLeft++;
        SourceUtil.takeSourceWithParticles(pos, world, 6, AugmentPierce.INSTANCE.getCastingCost() * Math.pow(_GROWTH_RATE_, _TOTAL_REDIRECTS_));
    }

Where _GROWTH_RATE_ would be defined in the config. Using 1.25 as the growth rate would result in the following costs on each hit growing at a nice pace. Adding the _TOTAL_REDIRECTS_ to the spell as a tracked value would allow for better control of the growth no matter the type of lens or modification used.

Using the above you would have V=C*(growth_rate)^t and using the provided values of C=40 as it is the cost of a pierce and growth_rate=1.25 would get the following costs if each redirect uses a lens of the type pierce	Redirects	Cost	Total
0	40.0	40
1	50.0	90
2	62.5	152.5
3	78.12	230.62
4	97.65	328.28
5	122.07	450.35
6	152.58	602.94
7	190.73	793.67
8	238.41	1032.09
9	298.02	1330.12

The absolutely cool thing is that if a non lens redirect was used it would not increase the cost but would still tick up the counter in this case so it would cause a natural limit to the number of times the spell could be passed around. As a note at the 20th redirect it would cost a whopping 3500 (total = 17187) source while at 10 it's 372 (total = 1702).

It would as be a design decision to not do the total redirects and only the modified ones by which the cost is added.

Overall this mod is cool as heck as it adds great functionality to an already great mod which is crazy hard to do.

Final note, it was me not reading properly. I added a reserve source jar near each node that was not connected to the relays and as the reserve was filled it performed properly. The system was not stable as the source was not guaranteed to be in the jars in each node thus breaking the whole.