Emailed most of this to Ray but I'll post up here to fix some confusion that lingers concerning this monster.
-I didn't make any changes to the monsters per se. In removing the dependencies I was forced to revert to a few default classes since the original ones are lost to time and edits of the mods this monster depends on (specifically the 'ol' package). Classes like 'olSkaarjProjectile' were replaced with the default 'SkaarjProjectile' because I could not locate the original. I made a thread at Old Unreal about this:
http://www.oldunreal.com/cgi-bin/yabb2/ ... 83166299/5
-Because I made no scripting changes to Cyb if it had issues before it will still have them. Ray didn't ask to make changes, only to remove the dependencies so that's all I did.
-I don't think anyone really understands how this monster works. If you have the setting "bvulnerable" set to false then all damage taken by the Cyb is diverted to it's shield. Since this shield is an 'effect' and not an 'item' it doesn't have a health value. This means you can't 'kill' the shield no matter how much you hit it. The only reason you are able to kill Cyb with this set to false is the engine is allowing some small amount of damage to occasionally happen to the monster. This is a mistake since the code prohibits damage when set to false (but this happens a lot in the engine). I'd guess you could replicate this by trying weapons like an R3 (ultra fast ripper variant) instead of massive nukes. Overwhelming the engine by flooding it with damage computations from a thousand flying ripper blades ought to kill the Cyb pretty easily even with false. Anyhow, set it to true and you can kill the Cyb without effort.
-Hurting the Cyb has absolutely nothing to do with any choice you make as to what weapon you use. Impact hammer is the same as level 5 nuke. If you have it set to invlunerable the engine will not allow it to take damage (unless you create a situation like above where you are flooding the engine with things to compute and it gets confused about some values).
papercoffee wrote:
Jack didn't made FF compatible with all mods out there ...some were not tested. FF was meant to be played with FF alone because every weapon can counter another weapon. Stone, paper, scissors schematic. And you know how stubborn he can be sometimes.
We had to make compromises.
I know I repeat myself...
papercoffee wrote:If someone want to fix this problem I would be highly thankful and would present a drawing of his/her liking as a reward.
I know we've talked about this before but I'll say it again: this has nothing to do with me being stubborn and everything to do with limitations of the engine and the way weapons are designed. The method the game uses for animating things is very, very old and outdated. By electing to create weapons with many forced animations (reloading each round, etc) you have these situations where you must ensure that cheating is discouraged. The weapons have certain settings that do this. Sure, they can be removed but you would quickly be back to players learning how to insta-fill the clip or duplicate the weapon. The source code is out there since the release and anyone is welcome to take a stab at working this all out better than I did. All of this is why almost no weapons force reloading after a set number of shots. The game just isn't designed for it. FF is best played when it is done in isolation because of the way it was designed.
I lobbied very hard for the weapons not to use an 'empty clip' reloading system but it was desired by the rest of the team. After a frank and open discussion among us I did things the way the majority of the group decided. I knew there would end up being mod conflict but I did love the unique vision FF provided and I remember telling paper something like "No one will end up playing this mod but I hope just a few people really understand what we accomplished with this working online". I've toyed several times with the idea of redoing FF and removing the reloading but it's not 'my' mod. I'd love to see extracted versions of the weapons made useful to MH servers however. It could be done without a huge amount of effort if anyone is interested and would make some fun alternatives to the 'normal' weapons.
EvilGrins wrote:I have what may by an insane question...
...how hard would it be to give the invulnerability the Cyberus has to another monster?
Would that monster need a shield like Cyberus has or would it just become unkillable??
Yes, you can 'give' this shield to another monster. In simplest form it's just an effect (like shieldbelt is an effect). The real magic is the check to see if bvulnerable is false or true. It's easy to make a mod that would give this to any monster you wanted. All you are really doing is nulling all damage the monster takes if you flagged it as invlunerable.
Sorry for the long post, just wanted to clear up some confusion. Oh, and BTW don't take my disagreement with paper over reloading as us "fighting". We had a really good discussion in the private forum about reloading when it was being developed and although paper and I entirely disagree it's never been anything but two guys who don't see eye-to-eye but deeply respect each other's position. Although I think the weapons would be much more useful without reloading it was paper's persistence and vision that kept FF on track for years and ultimately got it done. If
that guy wants reloading weapons then that guy gets reloading weapons. The issue though is you can't bypass the way the engine works and so by taking a certain path you also assume the problems that path may have.
Whew.