User Tag List

Page 1 of 2 1 2 LastLast
Results 1 to 10 of 11

Thread: Enemy Editor Defences (Script 1 to 10) - Major User Request

  1. #1
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.72%

    Exclamation Enemy Editor Defences (Script 1 to 10) - Major User Request

    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.

  2. #2
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    Nope sorry the other Indices are reserved for things not involving scripting.

  3. #3
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.72%
    Quote Originally Posted by Tamamo View Post
    Nope sorry the other Indices are reserved for things not involving scripting.


    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.

  4. #4
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    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.

  5. #5
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.72%
    Quote Originally Posted by Tamamo View Post
    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.

    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.

  6. #6
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    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!
    Last edited by Tamamo; 07-31-2016 at 01:04 AM.

  7. #7
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.72%
    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.

  8. #8
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    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.
    Last edited by Tamamo; 07-31-2016 at 10:05 AM.

  9. #9
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    Deleted
    Last edited by Tamamo; 08-01-2016 at 02:11 AM.

  10. #10
    Ara? Mitsukara's Avatar
    Join Date
    Jul 2000
    Location
    -15 penalty to all intuit direction checks
    Age
    35
    Posts
    3,920
    Mentioned
    9 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    3,620
    Level
    19
    vBActivity - Bars
    Lv. Percent
    25.4%
    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.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social