Jump to content

Photo

Zelda Classic 2.50.2


  • Please log in to reply
290 replies to this topic

#31 coolgamer012345

coolgamer012345

    🔸

  • Members
  • Location:Indiana, USA

Posted 26 October 2015 - 02:41 PM

Yes, that line in stdExtra.zh was indeed the cause of the bug that I was experiencing. Which means that for my quest to work as it is currently scripted, it would have to be played in 2.5.2 to work properly. Anything else would just look wrong.

Not sure how well this would work but at the start of the quest you might be able to have something like a selection asking if you have 2.50.1 (or something older) or 2.50.2, and then use a global variable for the Screen->DrawBitmap's function's argument, which would change depending on the selected option.


Edited by Coolgamer012345, 26 October 2015 - 02:42 PM.


#32 Saffith

Saffith

    IPv7 user

  • ZC Developers

Posted 26 October 2015 - 03:44 PM

There's a limit to how far we can go in supporting stuff that depends on bugs. Almost every bug fix potentially breaks something, but we can't put every detail behind a quest rule check. It's more work (now and indefinitely), it's more overhead, and it's more time we're not working on other things. Also, there's a limit on how many quest rules we can add before the quest format has to change, and we're very close to that limit.
You can make a quest that crashes 2.50.0, but not later versions. Obviously, we're not going to support that. Generally, if a quest works right in the newest version and has issues in older ones, I'm okay with that.

 

I don't know a better place to ask, but...
 
Apparently there's another site that's doing an online game expo soon and is looking for submissions. I was wondering if it would be okay if I included a copy of ZC with my quest, since it's not a ZC site, and I don't know how well it would go over having to give extra links and directions just to be able to play a demo submission. I thought it would be easier to just zip together a copy of ZC, a copy of my quest demo, and directions on how to load the quest into ZC. Is that alright?

Fine with me. You could create a batch file or launcher that runs
zelda-w.exe -standalone "MyQuest.qst"
Then you could leave out the instructions and most of the support files. -notitle might be useful, too.

#33 MoscowModder

MoscowModder

    Sometimes lurking. Rarely posting.

  • Members
  • Location:Wisconsin

Posted 26 October 2015 - 04:54 PM

Thanks for notifying me about the bug in InvertedCircle(). I'll post an update (with a notice concerning it) to stdExtra post-haste!



#34 Anarchy_Balsac

Anarchy_Balsac

    Quest Builder

  • Members

Posted 26 October 2015 - 05:52 PM

If every bug fix potentially breaks something, maybe don't fix bugs unless they're serious? I mean, is it not a bit silly to risk breaking stuff for minor fixes?

 

For major stuff, yeah, you have to take the risk.  But I would think the minor stuff isn't worth it, really.

 

But what I find most disturbing here, is that you're starting to talk about breaking people's quests as if it is no big deal.  You may not mean it that way, but I certainly HOPE you don't.


Edited by Anarchy_Balsac, 26 October 2015 - 06:23 PM.


#35 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 26 October 2015 - 09:27 PM

There's a limit to how far we can go in supporting stuff that depends on bugs. Almost every bug fix potentially breaks something, but we can't put every detail behind a quest rule check. It's more work (now and indefinitely), it's more overhead, and it's more time we're not working on other things. Also, there's a limit on how many quest rules we can add before the quest format has to change, and we're very close to that limit.
You can make a quest that crashes 2.50.0, but not later versions. Obviously, we're not going to support that. Generally, if a quest works right in the newest version and has issues in older ones, I'm okay with that.

 
Fine with me. You could create a batch file or launcher that runs
zelda-w.exe -standalone "MyQuest.qst"
Then you could leave out the instructions and most of the support files. -notitle might be useful, too.

 

If it were minor, I wouldn't care. It doesn't break anything that I've made, but the number of quests that use bitmap drawing for this purpose that will break, isn't insignificant. I believe that 'Lost Kingdom of the Banana Blood God', will break, in 2,50.2, because of this. Anything with scripted darkness, in general, will become unplayable; and there are quite a few of those.

 

It's the 'unplayable' part, that matters.

 

It may just be best to revert, if that's the only sane option, and leave the bugfix out there in the source for the o-s project, and later fixing. Let it be fixed, when a quest file format change won't be problematic.

 

With regard to QRs, that's why I'd use a version check when loading the quest file, to handle this sort of thing.

 

 

If every bug fix potentially breaks something, maybe don't fix bugs unless they're serious? I mean, is it not a bit silly to risk breaking stuff for minor fixes?

 

For major stuff, yeah, you have to take the risk.  But I would think the minor stuff isn't worth it, really.

 

But what I find most disturbing here, is that you're starting to talk about breaking people's quests as if it is no big deal.  You may not mean it that way, but I certainly HOPE you don't.

 

 

Eventually, everyone reaches a point, where they become weary of trying to back-support every minor detail. The perpetual arguments about passwords; and the continual onslaught of feature requests, while many bugs persist, and are abused to make games, only worsens this sensation of anguish; that leads to a certain level of apathy in development processes.

 

 

Thanks for notifying me about the bug in InvertedCircle(). I'll post an update (with a notice concerning it) to stdExtra post-haste!

 

Modify it, with an additional PutPixel() before anything else, that places an invisible (colour) pixel on layer 6, at 0,0; before drawing to the bitmap. That should prevent it from being a problem with 2.50.0/1 compilations, and will maintain compatibility with 2.50.2. .


Edited by ZoriaRPG, 26 October 2015 - 09:34 PM.


#36 Anarchy_Balsac

Anarchy_Balsac

    Quest Builder

  • Members

Posted 26 October 2015 - 10:47 PM

Eventually, everyone reaches a point, where they become weary of trying to back-support every minor detail. The perpetual arguments about passwords; and the continual onslaught of feature requests, while many bugs persist, and are abused to make games, only worsens this sensation of anguish; that leads to a certain level of apathy in development processes.

 

Which is why I emphasize they should fix major bugs only.  It reduces their anguish, as well as the problems with back-support.  These problems are made even worse when people don't realize that something is a bug in the first place.  I had no idea that the statues were working "buggy", but now a major problem has been created, and I can't say I'm pleased with Saffith's attitude about it.  I'm sure he means no harm, and I don't think he's a bad guy or that he's being malicious.  But that's also why I'm suggesting a minimalistic approach to bug fixing.

 

It'll make everyone more happy, themselves, AND us.  No one cares about small, insignificant/barely significant bugs.  Though everyone agrees that the game breaking stuff must go.



#37 Russ

Russ

    Caelan, the Encouraging

  • Administrators
  • Location:Washington

Posted 26 October 2015 - 11:43 PM

Regarding the "fix" to DrawBitmap...

SX9VswK.png

I am... perhaps a little peeved by this. Any quest that used the function (of which there are several) is now broken in 2.5.2. Updating them to fix the issue will break them in 2.5.0 and 2.5.1, meaning that quests aren't compatible between the different 2.5 versions now, which adds needless complexity to everything. I can almost guarantee we're going to have a lot of confused players opening quests in the wrong 2.5 build. It seems like a "bug" that didn't really need to be fixed and caused a whole lot more harm than good.
  • Anarchy_Balsac likes this

#38 Shane

Shane

    💙

  • Moderators
  • Pronouns:He / Him
  • Location:South Australia

Posted 26 October 2015 - 11:53 PM

I like some of the small fixes honestly. The statue and hammer fixes are really nice, not sure why people dislike those. Though it's unfortunate that there appears to be a serious bug though, which is seen above. I guess for the time being, we're going to have to advise players not to play some quests in 2.50.2.



#39 Anarchy_Balsac

Anarchy_Balsac

    Quest Builder

  • Members

Posted 27 October 2015 - 12:01 AM



I like some of the small fixes honestly. The statue and hammer fixes are really nice, not sure why people dislike those. Though it's unfortunate that there appears to be a serious bug though, which is seen above. I guess for the time being, we're going to have to advise players not to play some quests in 2.50.2.

 

You don't build your quests to be highly challenging either.  FWIW, I could care less for the easy mode versions of my quests, but for the normal versions, it's an unacceptable and potentially game breaking exploit, that didn't have to exist in the first place.  I wouldn't mind the option to make shooter enemies act that way, but forcing it  isn't remotely acceptable.



#40 coolgamer012345

coolgamer012345

    🔸

  • Members
  • Location:Indiana, USA

Posted 27 October 2015 - 12:09 AM

 

You don't build your quests to be highly challenging either.  FWIW, I could care less for the easy mode versions of my quests, but for the normal versions, it's an unacceptable and potentially game breaking exploit, that didn't have to exist in the first place.  I wouldn't mind the option to make shooter enemies act that way, but forcing it  isn't remotely acceptable.

If it's any help, scripting an enemy that just shoots things (and technically, without enemies, and could even use something like a combo or flag) would be very, very easy.



#41 Anarchy_Balsac

Anarchy_Balsac

    Quest Builder

  • Members

Posted 27 October 2015 - 12:21 AM

If it's any help, scripting an enemy that just shoots things (and technically, without enemies, and could even use something like a combo or flag) would be very, very easy.

 

It has to be an actual enemy (so that the blade of pain can destroy it), and the shooting has to stop when it is destroyed (another enemy can't start shooting when it dies), and it can't be done with ghost.zh (caused serious problem when I loaded it, can probably be fixed by overhauling my code, but I don't have the time for it).  Is that currently possible without direct enemy scripts?  NPC scripts exist, but they appear to be nonspecific, general enemy scripts.



#42 Moosh

Moosh

    Tiny Little Questmaker

  • ZC Developers

Posted 27 October 2015 - 12:26 AM

It has to be an actual enemy (so that the blade of pain can destroy it), and the shooting has to stop when it is destroyed (another enemy can't start shooting when it dies), and it can't be done with ghost.zh (caused serious problem when I loaded it, can probably be fixed by overhauling my code, but I don't have the time for it).  Is that currently possible without direct enemy scripts?  NPC scripts exist, but they appear to be nonspecific, general enemy scripts.

This sounds super easy to pull off. I could even make it global so it's as if nothing in the quest was changed. The only thing I'd need to know is how the firing rate works.


  • Anarchy_Balsac likes this

#43 coolgamer012345

coolgamer012345

    🔸

  • Members
  • Location:Indiana, USA

Posted 27 October 2015 - 12:27 AM

It has to be an actual enemy (so that the blade of pain can destroy it), and the shooting has to stop when it is destroyed (another enemy can't start shooting when it dies), and it can't be done with ghost.zh (caused serious problem when I loaded it, can probably be fixed by overhauling my code, but I don't have the time for it).  Is that currently possible without direct enemy scripts?  NPC scripts exist, but they appear to be nonspecific, general enemy scripts.

I'm not quite sure what you mean by direct enemy scripts, but it would be rather easy to do without ghost.zh. Something along the lines of cycling through all the enemies onscreen, check if their ID is equal to whatever you want for a shooter, and if so create an EWeapon at the enemies position aimed at link of whatever type, damage, etc etc. You could do other things like using the enemies 11'th and 12'th argument in the editor for, say, how often it would fire, and then just read the Enemy's ->WeaponDamage and set the EWeapon ->Damage equal to that.

 

Edit: You could then use a shooter enemies ->Misc to store a counter for how often they should fire. Increase the counters every frame, and if they equal something that you want to use as the max amount of time before it fires and then make the EWeapon like I mentioned above.


Edited by Coolgamer012345, 27 October 2015 - 12:28 AM.

  • Anarchy_Balsac and Shane like this

#44 Anarchy_Balsac

Anarchy_Balsac

    Quest Builder

  • Members

Posted 27 October 2015 - 12:36 AM

This sounds super easy to pull off. I could even make it global so it's as if nothing in the quest was changed. The only thing I'd need to know is how the firing rate works.

 

I'd only need it equal to what the current fire rate of shooter enemies.



#45 Moosh

Moosh

    Tiny Little Questmaker

  • ZC Developers

Posted 27 October 2015 - 12:54 AM

I'd only need it equal to what the current fire rate of shooter enemies.

Fantastic! So the race is on until either Saffith sees this or my ancient Moosh sorcery manages to get the timing close to perfect. :P


  • ShadowTiger, Russ and coolgamer012345 like this


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users