Man, I don't even know. There's absolutely nothing there that should remove any effects, ever. That's creepy.

Edit: Oh hey, question. In the situation where a capacitor is already built, and shield gets built next to it, when to the adjacency effects get added? Upon initial placement, or upon completion? Basically, I want to know when OnAdjacentTo is firing.

Edit 2: You're destructively overriding OnStopBeingBuilt and OnCreate. I'm really surprised that isn't breaking a bunch of stuff, actually. Make sure they both call the ones from SEnergyCreationUnit with the same parameters.

To answer your first question. It happens when the construction is finished. And I will add the SEnergyCreationUnit to onstop and oncreate.
Edit: After adding SEnergyCreationUnit to onstop and oncreate it bricks the entire script.
But just to make sure I am doing it right you mean like this right?
SEnergyCreationUnit.OnCreate = function(self)
Instead of just Oncreate = function(self)
The error reported is.
WARNING: SCR_LuaDoFileConcat: Loading "g:\my docs\my games\gas powered games\supreme commander forged alliance\mods\powerslave-shields\units\xsb1187\xsb1187_script.lua" failed: ...forged alliance\mods\powerslave-shields\units\xsb1187\xsb1187_script.lua(17): `}' expected (to close `{' at line 14) near `='
INFO: Script module '/mods/powerslave-shields/units/xsb1187/xsb1187_script.lua' exists but doesn't define 'TypeClass'.
Falling back to 'Unit' in module '/lua/sim/unit.lua'.

Those were the only changes. So for further testing I am going to remove that and continue with the other stuff you provided.

Edit2: Think I got it worked out.
You mean like this instead:

I do see what you mean about the tabbing. I will kick notepad++ in the head and tell it to do spaces instead.

Ok, so I've gotten everything working now. Your code worked perfectly. I'll be tweaking some things here and there but it works like a champ. The onadjacent to is firing properly, removing effects as necessary. And firing the extra effect when shields are full.

Edit: So I've been poking around with effect blueprints and am not noticing a change to the effects at all. Is there a preferred way to test effects rather than having to reload the game after each change?

Yes, actually. Run this mod and have /EnableDiskWatch in your commandline. That mod lets you reload merged blueprints and generally keeps things from blowing up when reloading blueprints.

Any changes you save to a blueprint should then cause the bp to be reloaded, which should take effect on the next unit you spawn. Some things may take effect immediately (like weapon ROF, max hitpoints, etc), but I'd be surprised if that were the case with emitters due to how they're created.

With /EnableDiskWatch on, you can also reload a script module on the fly, and it should take effect on the next unit spawned. Individual unit scripts will generally still require you to manually run the dirty_module lua function in the console like this, though:The module name is always full path of the file in lowercase, so for a mod unit it might be something like '/mods/powerslave/units/xsb1187/xsb1187_script.lua'.

Any scripts that depend on the script being marked by dirty_module will also be reloaded on the next unit creation that depended on them, e.g. if you have a Unit.lua hook, and you change and save it, the next unit you create (of any type) will force a re-load of Unit.lua, defaultunits.lua, <faction>units.lua, and the unit's script itself. Practically speaking this doesn't change much, since you'll probably only be editing one file in that chain at a time.

I'll give the sim command a try. I had been using the reload mod before I posted that question and it didn't help. I have also been using the /enablediskwatch command for a long time now.
One thing that was a bit buggy. It seems that the while loop doesn't take into account the shield generator dying. So, when it dies and the effects are running, it cancels the loop and you have the effects stuck on. I fixed this by adding a for loop in onnotadjacent to that clears the shields.FX table. Seems to work, throws a few warnings but it all looks ok.

Do the emitter bps not get reloaded or something? I've never had a blueprint not reload - the game is supposed to monitor any file with a .bp extension that it has mounted.


Also, the shield loop is supposed to set shieldRatio to 0 when there are no living shield units in the table, but that might not be happening. Add a log message right above the shieldRatio if<>then block that dumps it to the log. If it is 0, then maybe I'm missing something obvious in the check logic. If that function is causing any errors, then post them, because I definitely did something wrong.

Having it removed in OnNotAdjacentTo is fine as well, but if it's throwing errors, make sure you're checking for self.ShieldFX before you do try to anything with it.


I went ahead and wrote the code for controlling the sliders directly from adjacent shield units' SetShieldRatio, but I was pretty tired tonight, so I want to look it over again tomorrow before I post it.

So here's what we've got so far. Everything is working well. Once we get the sliders done this unit will be signed off and I'll release the new version.
Unit script:
http://pastebin.com/5z8yKPdc
And a screenie for those who are interested:

Any suggestions or thoughts are welcome.
They do get a little bright in groups. However it is very handy if your base is being shelled and you don't notice. So the shield capacitors also act as alarms and let you know they are working harder and that your base is being shelled.

Edit: I have found a rather suspicious bug. Seems that with ACU's and SCU's after their shields are upgraded or installed. They work fine. If you turn them off they never come back on. But, if you have them start another upgrade or start building something the shield will eventually recharge and turn back on. Until you turn it off again. If you stop the acu from building while the shield is recharging it will pause right where it was until you let it fully charge. If the shield is taken down by damage it will not come back. Seems this bug has been present since the first release so I think something may be being destructively overwritten. I have looked at the code and it all looks ok. The only thing I could think of that might have the answer would be the individual unit bp files, though I am at a loss. Maybe the shield upgrades do something funny with the categories? For all intents and purposes, all the shield capacitors are the same as their t1 and t2 power generator counterparts. Shield generators work just fine. The problem does not occur with Aeon Harbinger walkers or Obsidian tanks it does not seem to cause problems with any other unit except for ACU's and SCU's.

I'm not seeing anything in any of the three mods that would do something like that. Unless there's something in the Buff Fix mod that is doing it only under conditions activated by another mod, but I can't imagine how that would result from some adjacency buffs being added.

Did you fix the errors that were being thrown by shield effects removal?

Edit: I see you're checking 'if self.ShieldFX >= 1' - that won't work, because ShieldFX is a table. You can't compare it directly to a numeric value (that will always be false), and if it is nil, it will still throw an error. Just remove the '>= 1', so it is just checking whether or not it is nil.

Edit 2: I'm not really sure what you're doing with the shieldRatio check in ShieldCheck - you're adding effects when the shields are less than full, and removing them when all shields are full? The logic of that should be changed a bit, if that's the case.



I'm looking over this code I have for instant shield updates, and it's gonna be a lot more performance-intensive than the loop method you're using now, for minimal gain, no matter how I implement it. Just setting the loop time to 0.5s should be effective enough (if 1s isn't fast enough) and will still produce a lot less overhead than instant updates.

So for now, I'll just post the code I've got for the sliders. New OnStopBeingBuilt:
And then add this in above the shield effects block in ShieldCheck:
You'll have to tweak the slider max / speed settings; those are just placeholders because I don't really know how the sliders work, which direction they're supposed to move, how much, etc. As far as I can tell, SetGoal(0, 0, 0) is their default location on the model. x should be east/west as positive/negative respectively, y up/down, and z south/north.
A combination of say, x=10 and z=10 should move it diagonally southeast at a 45 degree angle, if I didn't screw anything up.

Let me know if you have any problems with it.

If you want the shield effects to be added only when shields are online but not full (regeneration effects, I guess?), then your two conditions should be:..as shieldRatio will always be 0 with no shields adjacent or online, and always 1 with all adjacent shields full.

If you want the effects on when the shields are offline and regenerating as well, then use something like this:..this only removes effects if the shields are full or there are no adjacent shield units left.

Had to make a slight modification to the else statement.
elseif shieldRatio == 1 and self.ShieldFX or shieldRatio == 0 and self.ShieldFX then
Seems like it was always using shieldRatio==1 and not checking for self.ShieldFX which was causing loop over errors like this.

But that minor change solved the issues and they work fine now. Will start on the sliders shortly.

Edit: Just found another bug. Seems that when if the capacitors are added to a damaged shield or reclaimed from being adjacent the shieldhp is fully restored. Though I don't know if that would be fury's department since it seems like it's all being called from the buffsystemfix.

Whoops, sorry about that. You can also get the same effect by doing:..which requires at least one of the two conditions in parentheses to be true before proceeding to the next condition.

Shields refreshing is probably a consequence of the buff additions, in particular shield max HP I would think. I'll look at how that's being added.

I tracked it down. The cause of both bugs, acu/scu shields not coming back and the insta-heal for shield gens. It's all TV 1.17's fault. Not a clue why it happens but that's it. Stuck a post in the BSF thread in the hopes Fury has an idea.

So the sliders work great. Got everything assigned. However presently they are moving out and I would prefer that they move in. I tried a couple of things that the game really didn't like. Ideas?

If total vets causing the problem posting in ghaleon's thread would be a better idea.

Not TVg, Eni's old TV. Long since abandoned/unsupported.

Are you trying negative values to move the opposite direction? I'm not sure what 'in' and 'out' are with respect to your model, as I don't know which parts on it should be moving. I've been too lazy to actually load up the game and look at the bones.

But like I said, if you want them to move up/down, use +/- y values. If east/west, use +/- x values. If south/north, +/- z values. The framework I made there supports each slider moving in a different direction/amount, so take advantage of that if you need to (e.g. if they're supposed to move in different directions).

If they're on a spinner, all bets are off - I don't know how spinners and sliders interact (or even if they can).

I think I should rephrase my question. Depending on the values of x, y, and z there need to be negative values there in order for everything to move in sync. It works well. However they are moving inwards when shieldratio=1 and moving outwards when shieldratio<1 I would like to reverse that. So that the sliders are moving inwards when the shieldratio is decreasing and returning to the original model state when the ratio is nearing full. I've tried flipping values and negatives here and there but I can't figure out how to get the sliders to have their rest point be the origin of the model and have the goal be a reflection of sheildratio being less than 1.

Huh. That.. is how it's supposed to work now. shieldRatio 0 should result in a SetGoal of 0,0,0. Likewise, shieldRatio 1 should result in a SetGoal of max x,y,z. And SetGoal(0,0,0) should be the rest point on the model.

I'm tired and stressed right now, so maybe I'm not seeing something obvious? I do know what you mean, but I'm really not sure how that could possibly happen.

If you haven't already, try logging shieldRatio just before the loop, as well as the x,y,z values within the loop. e.g.
It'll be spammy, but maybe it'll shed some light on whatever I'm not getting here.

Edit: Before the sliders were being manipulated, i.e. before this code was added to the shield check, were they at the position you wanted them to start at with 0 shields?

Before the sliders do anything. They are exactly where I want them to be when the shieldratio is 1 or full. If I place the unit somewhere where it's not adjacent to a shield generator the sliders are perfect if the shields were full. I want to take the sliders from that point and move them inward. So essentially an inverse of what we're doing now. The sliders should move from their start point inward when shieldratio is less than 1 or full. To be a bit more concise, your last question, they are at the position I want them with 1 shields, or full. Presently it's setup as the opposite. They are moving inwards when shieldratio is 1 or full, they should move inwards when shieldratio is not full or 0. Is that a bit clearer? I have a tendency to get incredibly wordy sometimes.

Ok, that makes sense now. I just assumed their start point was where they should be for 0 shields.

So, at the end of OnStopBeingBuilt, just before the shield check thread, add something like this:..so that they start retracted.
Then subtract shieldRatio from 1 in the ShieldCheck loop to reverse the relationship there:Hopefully that'll do it.

Thanks for the input.
Simply changing:
local x = (self.SliderMax[k].x or 0) * shieldRatio
to
local x = (self.SliderMax[k].x or 0) * (1 - shieldRatio)
For x, y, and z did the trick. It makes perfect sense now that I have looked at it. I couldn't figure out how to flip it previously. +1 for logic.
Got another question. I have been poking around with CreateBeamEmitter and AttachBeamToEntity but, unsuprisingly, haven't been able to get it working. The goal is to get a beam from a bp file from bone1 to bone2 on the model. At first glance it seems that I need to create the emitter first, then reference that emitter later and attach it to the tobone, but that doesn't necessarily allow me to have the origin bone where the beam is supposedly coming from.
To try and clear that up a bit. There are two bones: bottom_bolt_origin1 and bottom_bolt_goal1. I have a bp file that should make a nice lightning bolt effect. I would like to have this effect connect from origin1 to goal1. And I feel like I am going about it completely the wrong way. And the LUA doc only has two or three functions that include the tobone field.

Did you try:
* AttachBeamEntityToEntity

INFO: AttachBeamEntityToEntity(self, bone, other, bone, army, blueprint)
or:
* CreateBeamEntityToEntity

INFO: CreateBeamEntityToEntity(entity, bone, other, bone, army, blueprint)

It looks like either should work, provided they allow the same entity for both attachments.

AttachBeamEntityToEntity worked like a champ. Here's the finished script for that unit. I'm sure there could be some optimizations in there. But everything works!
http://pastebin.com/0Futv0JT
Looks pretty snazzy too. Once Mithy looks over it and makes sure I'm not doing anything really dumb then Version 7 will be released. Got the Icon and the new texture from Kira so I am tentatively signing off on it.

Looks good to me. Don't need that empty OnStartBuild override there, but since (I assume) this unit never builds anything or upgrades, it isn't actively hurting anything.

New shields are posted V0.7. I split the three separate so in the future if I make revisions I don't have to update the entire thing every time. Check out the shineyness.

Just downloaded the new shield version 0.7, and it won't unzip the .7z file. Says that each file has a problem with compression. Can you double check the upload?

Thanks...