I've had tons of requests to add specific script# defs to the enemy editor, and I've also wanted it since 2.5 beta, so it needs to make its way int 2.53.
Printable View
I've had tons of requests to add specific script# defs to the enemy editor, and I've also wanted it since 2.5 beta, so it needs to make its way int 2.53.
Nope sorry the other Indices are reserved for things not involving scripting.
Quote:
Originally Posted by Tamamo
Right, sorry, but I have seventeen users that pretty much form the core of the zc scripting community, requesting this. That doesn't count other users on Pure, and probably here, that I don't commune with daily. So, no, we need to support each type individually. In fact, we could probably support more types of weapon effects, and modifiers, in the process.
Setting ignore if < > n for example. Give the user a field to enter the ignore/block/other value, rather than hardcoding it as <2, <4, <8. Item level should be in the set too.
I expect that weapon defs should be their own array in the struct, are they not? There's no reason that the sizes can't be increased, and I have no idea what you're trying to reserve, and for what reason; but this is a relatively simple improvement that has far too much user interest to ignore, because it might disrupt a potential future thing, or require potential future things to have more space.
I have to add a pile of stuff to item/itemdata, and eventually come up with npcdats too, so there's a lot of stuff that I'll need to do with these object definitions, and their registers, that amount to dull and tedious work, too.
It's shield flags, that are going to cause trouble, probably. The thing there, is that there hasn't been much demand, or interest to do anything with those, but that's where forward-planning becomes important.
Let me point something out. Eventually there will be 255 weapon classes after I finish rewriting the damn thing and implementing a custom editor for them.
There is no way we are adding 255 weapon defenses. It's just not feasible. The weapon defense system needs to be redone before that can happen anyways.
Which, as I've already explained, is problematic, in that it doesn't respect the existing system. You can't just break compatibility with what we have now, and wash your hands of it. At least, not if you want it to go into a pull. If you are going to add that many...which sounds like absurd overkill, then users are going to want to be able to have control over their effects. So, you're not thinking far enough ahead with the model that you want to introduce; and this is now the third time I've asked you to propose it properly, so that we know how you intend it to work.Quote:
Originally Posted by Tamamo
Show me how it'll be strictly compatible with the way things work now, and only adds user content onto that system, before you start insisting that we're going to use it, as I've never proposed something that kills existing compatibility. That's pretty much a base rule for this project, in general.
Have you run this weapon system by @Gleeok , @Saffith , or anyone at all? If this is something you plan for 3.0, then by all means, flesh it out all you want, but in the meanwhile, I'll just make Script 1 to 10 actually work as was originally intended, and move on to the next minor improvement.
JFYI, the reason that these defence types weren't added to 2.50.1, was that adding them would change the bytecode very slightly, which would have made 2.50.1 quests not play in 2.50.0. With that issue out the window, we can fix stuff like this.
I should note though, that I am very much in favour of defining custom item classes, so that the user can make items, weapons, or whatever, that all share behaviour, with values set by the editor pane. Finishing the itemclass code section is a good stopgap towards that goal.
edit:Actually, fuck it. I just PMed @Gleeok and @Saffith they can handle this one. I'm done with this whole conversation. I'm not going to break something because you want me to insert 9 indices into 511 fucking entities. It doesn't matter if 17 people want it, it ain't about my weapons system, it's about the fact that if we DO do this. you will offset a large collection of data making the majority of quest unplayable in that version or vice versa. There are just some things that are not meant to be ZoriaRPG give it a rest already for christ sake!
That's fine. you're just proving, yet again, that you will do only what you want to do, and not what people want out of the programme. For whatever reason, you feel as if you're the boss around here, whenever you bring up stuff like this, and I've no idea where you get that sort of notion. If you can't lay out what you want to do, then I'm guessing that you aren't even sure.
Feel free to make a fork: 512 distinct types would burst the bounds of the present system, where we have a max of 128 of each type, in the weapon types enum, and if you plan to change it to 512, then every present weapon value would break.
@Gleeok , @Saffith : Am I wrong about this?
These values are directly hardcoded, and accessed by ZScript: If you can make it strictly compatible, I'll look at it. If it is incompatible with present quests/scripts, then you are probably wasting your time. Have fun with your project though.
Also, if anyone else cares, we don't even use edefQUAKE, so I may as well fix that, and add edefBOOTS for 2.53.
edefQUAKE and edefSPIN aren't implemented those are for the quake hammer and spin attack. I actually plan on adding those. Heck I might add edefWHISTLE too I can think of way to make it work.
As for edefBOOTS we have edefSTOMP which has the same effect I think. Talking about stomp boots right?
Anyways I checked something and it looks like it may actually be possible to still do what I plan to do by following the logic Enemies use that is to say they have both an ID and a WeaponType. the ID would be their numerical ID in the editor and their WeaponType would be the built in weapon.
I still have concerns though, mainly that shifting data in the quest header is generally a bad idea that causes bugs to happen. If it's going to create a ton of bugs it's not going to happen. Plain and simple, we're working on stabilizing the 2.5.x branch actually. That last thing I will address via PM.
Deleted
This would absolutely be helpful. I have seen so many people that don't even use the other script weapon types to avoid this problem. I did it myself for over a year. I finally had to figure out how to script an NPC to set it's misc modifiers as sort of buffer placeholders just to switch the script weapon defense type in context, and then switch it back to it's default... this makes no sense.
If it is at all possible, it would be a MAJOR improvement to have a third page in the enemy editor of eweapon defenses, for each of the 10 script defenses separately. I think a lot of people would appreciate this, who simply don't come around here much.
That said, if it never works out, I do understand the ZC source is probably a nightmare to work with. There's over 15 years of legacy code to work with, after all. : ( But it'd be really, really cool, and extremely convenient.
I agree with everything aforementioned. One reason is because you might want for one LW_SCRIPT-type weapon to be an instant kill and another to just stun the enemy. This would also make setting up things like elemental damage systems easier.Quote:
Originally Posted by Mitsukara
But the primary reason to expand the enemy editor to me? LW_SCRIPT-type weapons are more easily controlled by scripts than most other types of lweapons. (Which makes sense, given their name.) I've been doing some crazy stuff with lweapons lately, but there are only so many types of them to use. You can't make swords, wands, candles, hammers, the cane of byrna or hookshots with scripts right now; although you can fake it fairly convincingly.
Certain lweapon types, like Bomb, Bombblast, Super Bomb, Super Bombblast and fire resist being controlled by scripts to their dying breaths. Boomerangs, sparkle, fire sparkle and reflected weapons are also a bit finicky. I'm not even sure how whistle whirlwinds behave.
That means we can generated and easily control via script sword beams, arrows, magic and the LW_SCRIPT-type lweapons. So if a user wants to do anything fancy with lweapons, like poison an enemy or move them in odd ways; you basically have to use one of those types.
I know this might be difficult and take a lot of time, but I do think it will be worth the effort in the end.