290 replies to this topic

[Erased Memory]

I'm not sure why this is, but I'm getting a framerate drop with 2.50.2 Its bearable, but still a little annoying.

[Gleeok]

I'm not sure why this is, but I'm getting a framerate drop with 2.50.2 Its bearable, but still a little annoying.

Wots dat mate? Yoo ain't jiffin' wit da jam? Oy guv'nor yoo 'ave to be a bit more spiffic, wot wif de shavin' skin an evryfin.

[Deedee]

I saw NJF stream my quest.

2.50.2 broke my game over screen D:

 

And it's going to break my dark room script.

Can you add an option to turn off the bug fix for compatibility issues? Because this is game breaking.

[Saffith]

Is it really that big a deal to update your quest? Surely it'd be easier than working around the bug was in the first place.
We can only add a few more rules before the quest format has to change, and this really isn't something I'd like to spend them on.

[Russ]

Is it really that big a deal to update your quest? Surely it'd be easier than working around the bug was in the first place.

I think the biggest issue is that, if you update the quest to work with 2.5.2, it won't work right in 2.5.0 and 2.5.1 anymore. Given that, from my own personal experience, people tend to not pay attention to warnings telling them what version of ZC to play a quest in, the end result is going to be that no matter what ZC version you save the quest in, somebody's going to run into a problem.

In normal circumstances, I'd say fixing a bug that people have been working around is fine. But the issue is that this isn't exactly like fixing a bug in an alpha build. It was in the stable release of 2.5, and had been around since the feature's implementation (to my understand, at least), so people just assumed "This is how this works" and built stuff with that in mind. Fixing it at this point just leads to issues. A quest rule would, from the standpoint of a quest maker like myself, be the best solution, but I can understand that that's probably far from ideal for you and Gleeok to implement.

If you don't mind me asking, what's this about only being able to add a few more rules? Does the current format have some kind of hard cap on the number of quest rules? I assume changing the format would be a massive undertaking? Sorry if I'm getting a bit on a tangent here, but I'm genuinely curious about all this. ZC's inner workings are a very strange thing to me.

[Saffith]

I think the biggest issue is that, if you update the quest to work with 2.5.2, it won't work right in 2.5.0 and 2.5.1 anymore. Given that, from my own personal experience, people tend to not pay attention to warnings telling them what version of ZC to play a quest in, the end result is going to be that no matter what ZC version you save the quest in, somebody's going to run into a problem.

If we changed it, then we'd have quests that work in 2.50.3 and not in 2.50.2. Is that any better?
 

If you don't mind me asking, what's this about only being able to add a few more rules? Does the current format have some kind of hard cap on the number of quest rules? I assume changing the format would be a massive undertaking? Sorry if I'm getting a bit on a tangent here, but I'm genuinely curious about all this. ZC's inner workings are a very strange thing to me.

Each rule is a represented by a single bit in a block of 20 bytes, and we're down to the last byte. I don't think adding more would be difficult, but it would be a bigger compatibility issue.

[Deedee]

Well, you'll have to add more quest rules in some day, and the .qst format will likely be outdated by the time the next big second digit update comes out (2.6.x or higher), as the amount of stuff in a new major update would likely break the limit anyways.

Off topic from the whole bug fix issue, but if you ever do get around to adding more quest rules, a rule to disable L/R item scrolling would be appreciated. Not saying it's required, but it would be useful.

Anyways, I'm probably updating when I have the time. The new update looks sweet!

[Mani Kanina]

If we must work around this issue then the best bet would be new version handling. Release another update of ZC at this point and name it 2.6 and make quests updated to 2.6 not runable/compatible with 2.5. This would get around to he issue of players not using the intended version of the quest.

That being said, I'm not sure if it's worth it to waste time and resources on this issue. Script authors should update their scripts to work with the bug fix. (And honestly, if your script was depending on a bug, then that's a problem with the script that should be fixed.) And if players are too dumb/lazy to play your quest in the right version, (Assuming that they are informed which version that is by you,) then that's their problem. And frankly, it should be something ZC players are used too, given there are plenty of ZC versions out there and quests don't always work on later versions then the one it was made for.

Edited by Lunaria, 12 November 2015 - 06:55 PM.

[kurt91]

If there's going to be another version of ZC made, can I request one tiny change? You know how when you drag an FFC around to position it, you can see the white frame around it? Could that frame be drawn depending on the "Combo W" and "Combo H" values instead of the "Tile W" and "Tile H" ones?

 

The reason I'm asking is because the Combo values means that the Combo effects can be made on a per-pixel basis, while the Tile values are forced to be multiples of 16, like normal Combos and Tiles. This would be a very useful change for any quest-maker who realizes how useful the Combo values can be. Let me use my current project as an example.

 

Sensitive Warps can often be *too* sensitive in where they're triggered. Stair Warps are just as sensitive on the lower half, and not triggered at all on the upper half. I made some graphics where the floor is broken and open to the ground above, The overlay where the broken ground is makes the player think that there is a couple extra safe pixels where there aren't by the standard 16x16 grid restriction. If I place the Warp effect on an invisible FFC and make it a few pixels smaller than the standard 16x16 grid would allow, I can place it over normal walkable tiles that have the hole graphics in place, and have pixel-precise collision where the hole is *supposed* to be, rather than where it technically is.

 

Many quests that use sensitive triggers such as "Step->Next" or use Tile Warps between identical screens are often a bit difficult for the player because there is no leeway on their part. For example, the Expo's TRIFORCE demo has a room where the player has to follow a fairy along a safe path. It's insanely tricky to do because of how sensitive the triggers surrounding this path are. Being able to give the player just a couple extra pixels as a margin for error would be a very nice addition, and placing the actual effects on invisible FFCs overlaid on effect-less graphics would be an easy way to do so. (Under the assuption that the triggers themselves are standard ZC fare. I do not know if it is the case in TRIFORCE's example, but you should be able to know what I'm getting at anyways.)

 

Anyways, is this a change that could easily be made, or not?

Edited by kurt91, 25 November 2015 - 06:00 AM.

[Saffith]

Shouldn't be hard, I don't think. Probably better to display both in different colors, since they can both be useful.

[Evan20000]

How important/hard is it to keep/remove ZC eating projectiles on the outer tile of the screen on non-NES dungeon maps? If this is really annoying to do, pay this request no mind.

EDIT: Is it possible to make bombs/arrows not disappear from your inventory when their counters hit 0? I'm trying to fix a really irritating bug involving magic consuming arrows/bombs that disappear sometimes.
EDIT 2: What appears to be happening is that when an item is added or removed from Link's inventory while he cannot pay for a bomb/arrow at the moment (counter below the value required to use), it removes it and then adds it back in the next time you get/lose an item when you have the correct counter amount. I'd guess it has something to do with ZC writing to the item array, noticing bombs and arrows cannot currently be used and "helpfully" removing them for you.

ZC, what in the hell?

[Shane]

EDIT: Is it possible to make bombs/arrows not disappear from your inventory when their counters hit 0? I'm trying to fix a really irritating bug involving magic consuming arrows/bombs that disappear sometimes.

Maybe I'm not understanding the question/situation enough, but couldn't you set the bombs and arrows to infinity via the magic bomb bag and quiver items? That's assuming you want an "item meter" like in A Link Between Worlds and Tri Force Heroes.

[Evan20000]

Yes, that's already done. The bombs/arrows physically leave the subscreen for some reason. Setting the counters to 99 every frame and the bomb/arrow item to true doesn't do anything either.

[Deedee]

What if you check every frame to see if link has the "bomb" item, and give it to the player when they don't have it?

[Timelord]

Mates, the problem he has is a ZC engine limitation. If the player runs out of the counter associated with an item from the bombs, or arrows itemclass, ZC removes that item from the subscreen. That meaning, that you can;t select it, and if it is selected, ZC will move to the next item, or something along those lines.

 

Changing the counter every frame will not help, as that will cause other havoc, nor will setting the item to true. (as I recall, it is never set false. This is internal subscreen behaviour, based on the item class definitions.)

 

My solution is to use a custom item class, and script arrow firing, and bomb placement. That allows more custom options, such as an error sound, when Link is out of ammunition, and increasing the arrow RoF, or the number of bombs that the player can place at one time.

 

You do lose some ZC niceties that way though, such as the sparkles on silver/gold arrows, although that's something that you can replace with an ffc if it matters that much to you.

Edited by ZoriaRPG, 27 November 2015 - 06:46 AM.