Okay, so, this has giving me conniptions for the past 5 hours or so.

4zK's chambering code makes use of RotAngle to make things look good. I have attached a thing to a weapon, and would like for it to follow the gun when it does move using 4zK's code (looks weird if it doesn't)

Now, I've gotten as far as the attachment recognizing when exactly it needs to rotate, but... it just won't. I tested making it rotate all the time, and it seems it won't do that either. Is RotAngle modification just turned off for attachments? Does it always follow the gun, and if so, why won't it follow when the gun's RotAngle is changed by 4zK's lua?

EDIT: I've done some print() magic and turns out... it doesn't recognize that it's rotating, even though it is. It gives me the normal, static rot angle caused by just aiming around.

WHAT

EDIT: Got it to work! It wouldn't read the RotAngle correctly, so in the weapon's lua I made it temporarily set its ShakeRange to its RotAngle, which the attachment COULD read. Would've used Sharpness, but that was already in use and fragile, so I took the next most useless thing.

For what it's worth, one of the newer versions of CC gave us the ability to set custom values for things. So you could do weapon:SetNumberValue("this is the key for the value", <number to set to here>).
There's also set string value and set object value, which let you set things other than numbers. Very useful and less likely to run into overlap than using something else, since you can just use your rte name or something as a prefix for the value.

Look here for more details:
http://wiki.datarealms.com/LuaDocs/MOSR ... umberValue

Oh, that makes things much simpler. Still wonder why it can't read normal player variables (like self.hiHello or something) or even RotAngle, which is a game-supplied variable.

Thanks, though!

Game supplied variables should be readable, not sure what's up with that. I've definitely set RotAngle on actors from outside scripts in the past. It could have to do with it being a HeldDevice or whatever though, RotAngle may be unusable for them in some way (maybe it gets reset to where it should be held).

Script made variables not being readable have to do with how the lua binding is set up in CC. I don't know too much about this but I think it's that they're not actually variables of the C++ object, like the game-supplied variables are. Instead they're handled by lua metatables which map variables and functions and stuff to object references or something like that. So you can, actually access script variables with some effort through the metatables (if you go back in the lua scripting forum a few years I think there are topics on it) but it's not easy and probably not really worth doing. Also, it's been a rather long time since I read up on all this stuff so I could be kinda incorrect on the details.

Hey, since you're already here, could you help with another problem?



Whenever the parent of the attachable I have with the above code gets gibbed (shot to destruction for example) the game freezes. It used to crash outright, but when I added that ToDelete it only freezes. Any idea why?

I also have it set to GetsHitByMOs = 1 in the ini so it can have an ID and find its parent, but I immediately turn it off later, since it covers the parent and would shield it from all attacks which isn't the intention. Does this remove its ID (sets it to 255, Null) and severely confuse the game when it tries to delete it?

EDIT: Okay, disregard all that, something's wrong with the actual weapon. I removed the attachments with that and it's still happening. Hmmm...

EDIT 2: I am totally clueless. I'm reluctant to share the .lua because it's top notch s̶p̶a̶g̶h̶e̶t̶t̶i̶ ̶c̶o̶d̶e̶ top secret stuff and I want to keep it a pleasant, high quality surprise, but if you think you can help I'll do anything to not have to make my weapon(s) indestructible.

EDIT 3: I threw a bomb on the gun on the ground with the console open to try to get something. Nothing. Does CC have a hidden crash log anywhere?

EDIT 4: i am bamboozled. it's not the weapon, it's the attachments. so that's back to square 1.

EDIT 5: i get games where it works, i can shoot the gun into gibs 5 times with the attachment on and it wont crash. then i try both, same code on both, and it crashes. go back to 1, which worked, it crashes. man what IS THIS

its 5 am what am i even DOING

EDIT 905: ok i am going to sleep. it works utterly at random. also rootID returns nil all the time evn though it clearly cannot given it has to be SOMETHING for the parent thing to even work (which it does, since it works as intended with the whole visuals thing)

i dont know

EDIT 7: ive woken up and i feel a strange duty to keep documenting my finds just in case it might help a soul later on

without exposing too much, what it does is check for the parent's (the gun in this case) sharpness and change its frames based on that. removing that whole section of the code obviously makes the thing non-functional, but also confirms that the actual parent-finding code is not the problem.

i have added multiple sanity checks (only allowing parent to be set once, a check if parent exists again, a check if parent sharpness exists) but to no avail. the strangest part is if that i use one of the attachments and just keep restarting CC and destroying it, 15% of the time it works perfectly. the other 85% it crashes instantly upon destruction. self.GetsHitByMOs has seemingly no effect, unless used on the bigger attachment that covers the weapon. once hit a few times (it has gibwoundlimit and gibimpulse limit set to very high amounts) it disappears.

EDIT infinity: ive made a global script to save the console every frame. shows nothing. entire game 100% stops the moment the gun is destroyed with an attachment, no error nothing

EDIT infinity omega: temporarily fixed by making it ungibbable and making it despawn after being out of somebody's hands for 90 sec. if there is a function to count how many times its been hit i could completely takeover the gibbing mechanism in lua, but then it'd have no gibs and just despawn

EDIT last: ok so self.WoundCount is a thing. i am making lua delete the gun outright when its wounds are over 20. this works around my problem completely, since nothing actually gibs (which messes the game up and makes it crash)

i have now recoded a good 15% of the weapon code through lua all for some silly system god damn this game makes me do weird stuff

if these edits help anybody i will be very glad

EDIT actual last: what an adventure!!!! all i need now is to re-code the gib system. i can do this, but how do i make things spawn in lua relative to the thing they spawned from? i know it has something to do with RotAngle affecting Velocity but idk enough about logical math to actually do this

Seems like sleep was a good idea, sometimes it's better to step away from these things and come back to them the next day.

Crashes like what's happening to you occur when you have a script trying to run a nonexistant object's function. So if you have some gun and you do gun:GibThis(); gun:GibThis(); it'll break, because the gun no longer exists the 2nd time. To avoid this, you have to safety check, usually that will involve using the MovableMan:IsActor(actor) or MovableMan:IsDevice(item).

Also, I've pasted in a guaranteed working parent check that I've made and used for a bunch of items. Feel free to use it if you'd like.

I would've assumed the the whole if parent == nil then find parent else (actual code) would've taken care of that. I will try adding another check and seeing what's up - the weird part is that a very old thing I made using that very code works 100% perfectly, so I doubt the parent code is the culprit. Will edit in results of using IsDevice().

EDIT: Had to use IsHDFirearm and omit the MovableMan:, but it works perfectly. Had the funny side effect of making the attachments fly off and when it gibbed, but I added a simple check to delete itself if its parent had become invalid.

Thanks, dude. I'm sure even with that fix this is still crash-happy code, but at least now any crashes are fairly random rather than consistent.