-
Posts
127 -
Joined
-
Last visited
Everything posted by iLakSkiL
-
Changed Status from Pending to Closed Changed Fixed In to 3.1.1
-
Updated in 3.1.1
-
If it's only happening when the server boots up, it's not likely an issue to worry about. The error is related to the UnloadableTrainWagons being spawned in on start. Worst case scenario, there could be a single train wagon somewhere that doesn't have modified loot. Best case scenario, and most likely, everything is fine. If it's happening all the time, then there is something wrong. But this error is related to it detecting a train wagon that it's trying to modify.
-
Changed Status from Pending to Work in Progress
-
mlrs hurts players inside raidable base
iLakSkiL replied to PhatBlinkie's Support Request in Support
Changed Status from Pending to Work in Progress -
mlrs hurts players inside raidable base
iLakSkiL replied to PhatBlinkie's Support Request in Support
I'll take a look. I can go through the RaidableBases plugin and work on an update for MLRSDamage that integrates better with it. When I first coded all of it, it was when MLRS was new and RaidableBases hadn't addressed it yet, so there integration wasn't possible at the time. Inside of MLRSDamage, the line for "Allow Damage to Raidable and Abandoned Bases" just checks to see if the building blocks being damaged have an ownership of "0". This is regardless of who "owns" the raid, for those PVE raids, where you don't want someone else doing damage to the base. This is what I can work on to integrate with RaidableBases. It does the other checks however. So if Damage to Players is off, then maybe the line in the RaidableBase profile "Allow Players To Use MLRS" is somehow overriding it and allowing player damage. But first, maybe see if setting "Allow Players To Use MLRS" to false in your RaidableBases profiles fixes the issue? I'll work with the author of RaidableBases to see where conflicts may be coming up, but theoretically, if MLRSDamage has Allow Damage to Players as false, but players are taking damage, then some other plugin must be overriding MLRSDamage. -
- 23 comments
-
- #gathering
- #gather rates
- (and 11 more)
-
Changed Status from Work in Progress to Closed
-
Changed Status from Pending to Work in Progress
-
Were you using an older version of the plugin? If so, my guess is that it's not loading the new file correctly, and still using the older config file. The "unknown command" signifies that it's not loading properly. Try renaming the oxide/config/CustomGather.json file, so that it acts as a backup. Delete the .cs file from your plugins folder, and try re-uploading the newest version again.
-
Changed Status from Work in Progress to No Response
-
Changed Status from Pending to Work in Progress
-
Is it compiling correctly in the console output? Was your file browser not updated after compiling the plugin? There's no reason why it wouldn't make those files.... I'd need more information to go off of than just that the files apparently didn't get created.
-
I'm not sure what you mean by a "list of modifiers." Do you mean a list of every thing that this plugin controls and can modify? Or like a list of entities/items and their modified rates of gather? I just uploaded a new rewrite of the plugin. In the config json file you can see all the areas that the plugin controls, i.e. picking items off the ground, fishing, harvesting, excavator, etc. And in the data json, you set the gather rates for specific areas, like the overall gather rate which includes items picked off the ground, items picked from planters, and harvested items like trees and ore, and then the other areas like fishing, excavator, quarries, etc.
- 23 comments
-
- #gathering
- #gather rates
- (and 11 more)
-
Changed Status from Work in Progress to Closed
-
Changed Status from Not a Bug to Closed
-
Changed Status from Work in Progress to Closed
-
Changed Status from Work in Progress to Closed
-
Changed Status from Work in Progress to Closed
-
Added in version 3.0.0
-
Changed Status from Work in Progress to Closed
-
Changed Fixed In to Next Version
-
I'll give it a test and see what I come up with. The only downside to doing a remainder of 2 instead of 12 is that, visually, the MLRS will only fire out of a couple tubes, and not cycle through all 12 tubes when firing a barrage. The plugin prior to v1.4 only shot out of one tube, so I was hoping to fix that and make it more visually appearing. Hopefully I can figure it out so that it works as intended with an odd number of rockets! Thanks for the info, and hopefully I'll have an update soon.
-
@aimacak Odd... Help me quick with a couple questions so I can test it and see: - What are your stack sizes for mlrs missiles on your server? - What are you setting the number of rockets to be fired? Is that an odd number? - Are they placing an odd number of rockets into the MLRS that is less than the maximum it will shoot? (i.e. placing 35 in when max to shoot is 48) The odd number shouldn't matter since, if the ammo left is greater than 12, it divides the total by 12 and returns the remainder plus one. (i.e. 35 % 12 = 11, or 37 % 12 = 1) So it will always return a number between 1-12, but never 0 or anything higher than 12, so it should never go out of the index range. So I'm kind of at a loss as to why this would happen. I'll try to do more testing with your parameters and see if I can reproduce it on my end.
-
This is the code for the MLRS entity's method of FireNextRocket, which is being reported where the error is happening. public void FireNextRocket() { float single; ServerProjectile _gravity; this.RocketAmmoCount = this.GetRocketContainer().inventory.GetAmmoAmount(2048); if (this.nextRocketIndex < 0 || this.nextRocketIndex >= this.RocketAmmoCount || base.IsBroken()) { this.EndFiring(); return; } StorageContainer rocketContainer = this.GetRocketContainer(); Vector3 _position = this.firingPoint.get_position() + (this.firingPoint.get_rotation() * this.rocketTubes[this.nextRocketIndex].firingOffset); float single1 = 1f; if (this.radiusModIndex < (int)this.radiusMods.Length) { single1 = this.radiusMods[this.radiusModIndex]; } this.radiusModIndex++; Vector2 _insideUnitCircle = (Random.get_insideUnitCircle() * (this.targetAreaRadius - this.RocketDamageRadius)) * single1; Vector3 trueHitPos = this.TrueHitPos + new Vector3(_insideUnitCircle.x, 0f, _insideUnitCircle.y); if (!base.TryFireProjectile(rocketContainer, 2048, _position, Ballistics.GetAimToTarget(this.firingPoint.get_position(), trueHitPos, this.rocketSpeed, this.vRotMax, this.rocketBaseGravity, this.minRange, out single), this.rocketOwnerRef.Get(true) as BasePlayer, 0f, 0f, out _gravity)) { this.EndFiring(); return; } _gravity.gravityModifier = single / -Physics.get_gravity().y; Interface.CallHook("OnMlrsRocketFired", this, _gravity); this.nextRocketIndex--; } I utilize the hook OnMLRSRocketFired in the plugin to change the default amount of rockets to fire. Otherwise, the MLRS will only shoot a maximum of 12 rockets regardless of how many are put in. Code is below for that private void OnMlrsRocketFired(MLRS ent, ServerProjectile serverProjectile) { if ((ent.RocketAmmoCount + rocketsFired) > _config.defsettings.rocketAmount) { ent.RocketAmmoCount = (_config.defsettings.rocketAmount - rocketsFired); } if (ent.RocketAmmoCount > 12) { ent.nextRocketIndex = (int)((ent.RocketAmmoCount % 12) + 1); rocketsFired++; return; } else { ent.nextRocketIndex = ent.RocketAmmoCount - 1; rocketsFired++; return; } } The only thing I can think of off the top of my head is that I have my math wrong in the else statement and the subtraction of 1 to the RocketAmmoCount when setting the nextRocketIndex is making it go out of bounds in certain cases, but I haven't run into this error myself while testing the plugin. Additionally, @aimacakreported an error in which "MLRS froze and tried to shoot (it was FIRING on the monitor), but for some reason it didn’t shoot, and every attempt to fire a rocket displayed a message in the console." That is odd, because assumingly, it should fire rockets, and only hang up on the last one if the nextRocketIndex reaches -1 (rocket ammo being 0 and then subtracting 1). But even then, when the ammo count is 0, the code should terminate before it doing another call of the OnMLRSRocketFired hook. If you can try to recreate the situation in which you encountered the error, that would be tremendously helpful. The config settings looked good too, so no idea as of now what caused this.