181 replies to this topic

[LinktheMaster]

And you made them visible with npc->DrawStyle, was it? That's not working for me at all...

Yeah. I had "Is Invisible" checked on the enemy. The set npc->DrawStyle = DS_NORMAL;

[Saffith]

Would you mind making a demo quest for that? It's not working for me, and I don't even see how it could, so I don't know what else to do...

[LinktheMaster]

Sorry, my apologies. It didn't work before. I had forgotten that I had drawn over the enemy each frame to force the enemy to appear above Link. So the DrawStyle was in fact not unhiding the enemy. Sorry about that.

[Saffith]

Ah, okay. Well, with that out of the way, I think we're set for RC3. Just have to wait for _L_ to stop by.

[Jared]

As a quest rule, it's pretty easy. Just did it, in fact. Somewhat harder as an enemy flag.

Very great! Yay!!!!

[blue_knight]

I didn't mention it before, but going through the changelog for the next version so far I really appreciate this change:

ZScript: Upped the Off-screen Bitmap dimensions to 512x512

Thanks Gleeok. The other fixes and tweaks sound great too.

[CastChaos]

What about the power level issue, that the item editor takes the power level of items into consideration more than how it does for other settings. Like:

I have
Worn out glove (power level 1): supposed to move one heavy block per screen
Bracelet 1 (power level 2): supposed to move any number of heavy blocks
Bracelet 2 (power level 3): supposed to move any number of very heavy blocks
How it really works: Bracelet 1 already moves very heavy blocks, for it has power level 2.
It would have been great to actually specify which item pushes how heavy blocks, because this way the power level overrides intended settings, like:

I have
blue candle (power level 1): supposed to react to blue candle flag, costs magic
blue lantern (power level 2): supposed to react to blue candle flag, costs NO magic
red candle (power level 3): supposed to react to red candle flag, costs magic
red lantern (power level 4): supposed to react to red candle flag, costs NO magic
Now what happens is that the blue lantern reacts to red candle flags already, since it has power level 2.


Another thing:
Having the "strings disappear" rule checked wouldn't make "feed the goriya" rooms impossible to use, since then the upper half of the screen becomes available even without giving the bait?


So far these were the things coming to mind about what would make me not accept a version as stable.

[LinktheMaster]

Okay CastChaos. I'm sorry, but that post is just really frustrating to me.

While I agree about the "Feed the Goriya" rooms thing. If the strings disappear rule nullifies that, it's in fact a bug and should be fixed.

But I'm sorry, complaining about the stuff with your bracelet and candle/lantern stuff is absurd. It's not absurd that you want to do it. It's an interesting idea, I'll give you that. But you can't come up with something really complex like that has never been doable, then make statements like ZC not being stable because of it not working how you invision it. It's like me saying "This version of ZC doesn't have OoT-like graphics. This would make me not accept this version as stable." The power level is the way it is because it's the way Z1 handled it.

Although, to give you some helpful feed back, you can trick ZC into doing what you want. From my testing, items with larger IDs take precedence over items with smaller IDs if they have the same power level. So the blue candle/lantern would both be power 1, but the candle's item ID would be less than the lantern. Same goes for the red ones, but both of their power levels would be 2.

I figured that out and tested it in less than 5 minutes. If you're going to come up with complex stuff like that, though, you need to think of how to make it work under ZC. Don't jump to acting like ZC is broken because you're trying to do obscure stuff like that.

Edit directed toward Saffith
I don't think this would be difficult for you to add. But would there be any way we could get Other (floater) enemies set to flying? I merely ask because with custom enemies, there's no way to have make a fully custom enemy that actually manages the npc and have it fly above layers 3 and 4. I've had to resort to drawing over the npc myself. Which isn't hard, but it's unnecessary. I would pick an arbitrary flying enemy class, but all of them I've tested have some weird behaviors that make it impossible to truly use (the keese one for example keeps trying to move when I have its step to 0).

[Saffith]

It looks like they're already flying. RC2.5 is the first release with that change, so have you checked there?

The Goriya room thing is fixed.

[LinktheMaster]

It looks like they're already flying. RC2.5 is the first release with that change, so have you checked there?

Ah, my apologies. I didn't think to double check in RC 2.5. Thanks.

[CastChaos]

I wasn't complaining, was "asking". So that paragraph about items with same power level but different ID would have been enough. : )
It's OK that it's only from RC2.5, I like RC2 how it is anyway.

[LinktheMaster]

It's OK that it's only from RC2.5, I like RC2 how it is anyway.

For my test, I was using RC2, actually. It should work in both RC2 and RC2.5. I don't see that as something they would change.

[Timelord]

Thanks for looking into that, I (and I'm sure others) really appreciate cross-platform usage. I don't actually recall any quests with a slash in their filename, however people could (in theory) have added one. If so, that's a potentially trivial matter versus not being able to slap your .qst and .sav files on any other system and continue playing, or share them, or anything else. I have always maintained that a document created by an application should work on all platforms where that application works, and now in the era of the Android-everything, I think the Linux build will actually gain a good following.

Who maintains the -L distro, so that I may appropriately report bugs and/or ask questions to the correct person? I noticed that the Linux build runs somewhat slowly on the identical HW as the Windows build, so either I need some additional libraries or drivers of some kind, or it isn't mking use of what I have, or it could just be throwing a tantrum for any reason. There is nothing otherwise that should cause a problem, and the Windows version ran splendidly.

Yes, I know this isn't really helpful at all at all, without knowing all of my exact HW specs, and all the distro and kernel info, but I'd rather ensure I direct this type of report to the correct people, or the correct board. I am also curious if an OSX-PPC build is possible using the same sources; this could be cool, assuming the endian reversal is not a problem for the compiler being used, etc..

If you are wondering, I'm not a Linux junkie. I use the OS suited to the work I'm doing... For DTP & Design, I use OSX; for engineering & CAD, I use Windows, and for networking I use Linux. I no longer do any video work, so that's a non-issue. I do like to be able to both work and play, as well as do basic productivity on whatever system I am on at present, so having ZC work in multiple places ins a real boon. It was just a bummer when my XP set-up toasted, as I said 'I'll just toss my files onto my Ubuntu SSD, and all will be fine', and then it wasn't.

I am still curious how the .sav files store filename information, and if they are hex encoded, binaries, or something else. I didn't see any reference docs that cover that, so I hope it is not a problem to inquire, rather than just tossing it at every editor application to see if one can read its format. I did not toss it to a hex editor yet, but I may give that a try eventually so that I can rename the filename pointers manually.

Anyhow, it's brilliant that 2'5 RC3 is just around the corner: For the record, I've been somewhat stalling in what I wanted to do, as I want to ensure i can use the most of what 2.5 offers, using a stable release that isn't out-of-date, as I don't want things to break. I have no doubt that it'll be a long while yet before I have time to finish anything interesting though, as I have much else (work and other projects) that are all backed-up to oblivion.

In any case, having played 2.5 quests, such as SoW, I am in love with the new ZC. There isn't much more I could ask for out of it. I still think that other/custom quest-completion item triggers would be awesome, but there are ways around that as well.

Edited by ZoriaRPG, 07 February 2012 - 10:23 AM.

[Saffith]

Who maintains the -L distro, so that I may appropriately report bugs and/or ask questions to the correct person? I noticed that the Linux build runs somewhat slowly on the identical HW as the Windows build, so either I need some additional libraries or drivers of some kind, or it isn't mking use of what I have, or it could just be throwing a tantrum for any reason. There is nothing otherwise that should cause a problem, and the Windows version ran splendidly.

I'm the one who handles the Linux builds.
The difference in speed comes from Allegro; it's using DirectX on Windows and software rendering on Mac and Linux. There's an add-on that allows it to use OpenGL, but attempts to use it have not gone well so far. I'll probably give it another try before we're done, though. I will at least be using profile-guided optimization for future builds.

I am also curious if an OSX-PPC build is possible using the same sources; this could be cool, assuming the endian reversal is not a problem for the compiler being used, etc..

PPC used to be supported, and it's still possible, as far as I know. I'll have to ask _L_ about it.

I am still curious how the .sav files store filename information, and if they are hex encoded, binaries, or something else. I didn't see any reference docs that cover that, so I hope it is not a problem to inquire, rather than just tossing it at every editor application to see if one can read its format. I did not toss it to a hex editor yet, but I may give that a try eventually so that I can rename the filename pointers manually.

The whole file's encrypted. Meant to prevent cheating, I suppose.

[Gleeok]

The difference in speed comes from Allegro; it's using DirectX on Windows and software rendering on Mac and Linux. There's an add-on that allows it to use OpenGL, but attempts to use it have not gone well so far.

Are you talking about allegroGL? I've already tried porting ZC to AGL once before and trust me when I tell you that project went in the recycle bin faster than you can pee on it. ..There was so many problems with that (internally and from zc code) where it would just be easier to rewrite the whole thing from scratch. Even if by some miracle it worked well enough to play through a quest without crashing the FPS would actually be much worse than it is already, because you're not really changing CPU to GPU, it's just adding it on at the end through a bunch of hacks really. To even start thinking about improved framerates you'd probably have to replace all the rendering code in ZC, plus remove all the allegro-graphics-api calls for something else, and change the way graphics from quest files are loaded and used... then deal with palettes. lol.

I had a screenshot of agl-zc somewhere... hmm.