Post feature requests for future 2.xx versions (e.g. 2.55) here. We will consider reasonable, and possibly even unreasonable requests.
Please refer to the 2.future Plans topic before submitting a request.
Printable View
Post feature requests for future 2.xx versions (e.g. 2.55) here. We will consider reasonable, and possibly even unreasonable requests.
Please refer to the 2.future Plans topic before submitting a request.
Hmmm, a few features I would like you guys to consider are the following:
1) Sideview ladders (given the variety of scripts at PureZC are either broken or don't have all functions to work properly).
2) Sideview water (because why not?)
3) I'm not sure if this would directly affect the engine, but another request would be expanding the Palette table to use more than just CSets 2, 3, 4 and 9.
4) Lastly, a few new items wouldn't hurt, like the Pegasus Boots, Shovel, and such. I know they're already existent as scripts, but I feel they would work better being hardcoded in the engine, because by doing this, you can save a lot of scripting space, flags and misc. Plus, sometimes setup is a bit quirky, especially when you want to combine them with other scripts.
So far, those are the only things that I could come up with.
Sideview Castlevania-styled staircases. Just like in Link stuck in Castlevania.
Extend combo type and combo flag tables. 5 scripted entries in both tables sometimes is not enough.
Screen->SecretCombos[] r/w.
Screen->UndoSecrets(). Flicking gates on and off, rotating bridges are examples.
Syntax highlighting in buffer.
I'm gonna be that annoying guy. :P
I'm sure it's going to be worked on, but of course ALttP scrolling. Another thing I feel is important is some sort of way to talk to NPCs/signs without the use of a script.
A big one would be to get rid of the subscreen, and use subscreen elements ON the actual screen, like a normal 3D Zelda games. I know some ZC quests have attempted and succeeded with this! It would be amazing to use from the get-go.
Good luck on making this semi-new engine!
@Lynker
That would actually belong in the ZC 3.0 Suggestions. ZC Scrolling would requiring rewriting most of 2.x.
It's something I've thought about myself, it's possible. But it would be a pain in the ass to code.
We'll certainly be goinginto some sideview fixes. I think that was on the to-do list already, but if not, I'll add it.Quote:
Originally Posted by Demonlink
I've had a list of hardcoded item requests, and to be fair, some might be viable, however, here's the catch:
All new item classes would need to be added to the table. We wouldn't use any of the 256 classes, as doing that could break quests. Say that we made zz95 the boots: Anyone using that for a custom item, would have a broken quest in 2.55. I also don;t want us to add items that are easy to do with scripts. Boots, maybe, but I was thinking of making Link's walking speed, and animation, a variable.
A shovel would be easy to add, but people might want it to work differently. Plus, it could end up being a Link class item if we did it traditionally. I might do that though, as it's a common Zelda item that wouldn't be terrible, however we'll need to define a new Link->Action (LA_DIGGING) and animation.
My main concern with hardcoding new items is that people will want them to work differently, like the sword, now. Soke though, would in fact make sense.
I was actually thinking of doing something different: Making pre-packaged quest templates, for quest styles, that have pre-included and compiled items, and engine effects. I've already been working on one that emulates the Gameboy style games, and we could include thingslike thatto allow expandeditem lists, without needing to hardcode them.
If we hardcode anything, i think the ice rod, fire rod, and cane of somaria are the most popular requests. We do need to fix/change magic consumption on a frame basis, and add a timed consumption value to all the items, particularly the Cane of Byrna.
Quote:
Originally Posted by Alucard
A flag editor is planned, as are additional custom flag IDs.
I like Screen->Secrets(false), and I can;t believe that I forgot about this. Really, I'd like to make it possible to individually set/unset screen secrets.
r/w Undercombos, is good.
Not sure about stairs internally, as that would require massive reworking, but grawswandir might be willing to do it.
Quote:
Originally Posted by Lynker
Precisely. I'll just say it now: Z3 scrolling (internally) is not planned for 2.future. This is the most anticipated feature request of the lot, and I'm not saying it's impossible, but some of the changes that we're making could greatly improve custom scrolling engines. I've already made a scrolling engine, and with some of the changes that we're making, if this becomes viable, I'd rather include a template quest for it.Quote:
Originally Posted by Tamamo
Reading enemy lists from any screen is the biggest single thing that we plan to add that will improve scrolling engines, and the npcdata class is a close second.
The same applies to changing the screen dimensions. Making subscreens invisible is on the list, but making the screen square is not, for very good reasons. Most of how ZC operates depends on a fixed screen size, so the amount of engine redesign to do this would be immense.
I do have 'make screen boundaries(where scrolling occurs) a variable' on the to-do list, so it would be possible to change the ultimate screen dimensions downward, but this would in turn make the internal maps look very odd, as the questmaker would need to fill the area outside the boundary space with combo 0, so there'd be a big black grid around the screens when viewing the map.
I'm not sure there would be any resolution to this, unless we make a combo type 'Screen Edge' and somehow rework maps to tile screens ignoring the areas outside the bounds; but that likewise would be a mess.
To be fair, this is something that I've wanted personally as well; but that doesn't give it any higher priority. We will of course consider these things 'down the road', but not for any initial 2.future things.
Anyhow, keep the requests flowing. I'm only responding to this one directly, because a few of these are repeated from other members.
Sideview fixing though, that's going to happen eventually.
Unsure what feature to request so I'll request something crazy:
The ability to freely move between Maze screens that are adjacent with each other (No looping when trying to move to an adjacent Maze screen) and to have the Maze solution somehow involve all of the adjacent Maze screens instead of just a single screen. I believe this is possible with scripting already and maaaybe tile warps, but a more simplified intuitive approach that doesn't involve manual scripting would be neat.
Have you ever used the Age of Kings scenario editor? In particular, the trigger editor? If Zquest could do anything remotely like that, that would streamline an enormous amount of design and script work.Quote:
I like Screen->Secrets(false), and I can;t believe that I forgot about this. Really, I'd like to make it possible to individually set/unset screen secrets.
This sounds FANTASTIC. Would love to hear more/update status.Quote:
I was actually thinking of doing something different: Making pre-packaged quest templates, for quest styles, that have pre-included and compiled items, and engine effects. I've already been working on one that emulates the Gameboy style games, and we could include things like that to allow expandeditem lists, without needing to hardcode them.
For my own needs:
More utility in using secrets/flags.
Talking NPCs hardcoded.
FFC's movement behavior that can be manipulated by secrets.
In sum: the ability to make a basic cutscene without using scripts, with NPCs having a conversation, moving around, and performing actions.
I think these have been requested already, just adding them as my own wishlist:
Sideview ladders
Enemy type editor
Map sizes increased (16x16?)
View menu: Ability to set palette per map in addition to per screen.
Subscreen editor: ability to place/move elements with a mouse.
Pie-in-the-sky, prolly 3.0 feature instead: all layers compounded into a single map screen, with a toggle to work on different layers.
I don't outright reject this, but to be honest, I'm not sure that I comprehend what you want out of this request. You can already make mazes of any number of screens, that deposit the player into a boundary that is more then one screen in size, using basic side warps, so...how do you want this to work, exactly?Quote:
Originally Posted by Nicholas Steel
For the moment, we haven't been discussing adding any new hardcoded engine things, be they items, npcs, or the like. If we did add internal NPCs, they'd need to work differently, and we'd need to change them to some kind of class, or add to the npc class used for enemies. That might be the best solution, to add an 'enemy type' of 'speaking npc', that has some kind of hardcoded path style movement, that doesn;t damage Link, but will allow speaking with a button press. That press would need to be its own variable, as well, to allow people to modify it.Quote:
Originally Posted by EJSnowden
It may be possible to add turn combos, that cause an npc to change directions, that affect any npc object, including enemies to control movement.
I'm not sure how ffcs being modified by secrets would work, but I think it would require some heavy rewriting of the ffc object type. We want to add solidity variables to ffcs, and possibly some memory management so that they don't eat up RAM constantly, so I suppose we could look into that; however, I do not know what kind of control events you'd want, or how you would want to implement them.
Many of the changes that we plan, are toward shifting to using ZScript more readily, and possibly by default for some things. That doesn't mean that we will force people to use scripting, but it may mean that (at least initially), many of the things that we add will be script-mandatory, until we can figure out what kind of interface to use to manipulate them with the editor.
The non-enemy npc type seems to be something feasible though. Instead of attacks, it would have a movement value, and probably a string value. We might be able to do that in one of the next few releases.
I think a better way to explain my intentions:
Say you set a Trigger(1):
Trigger(1) has any number of assigned Flags and Secret Combos. These can be general (e.g. all Script 98 flags present) or specific (e.g. assign Custom Secret Combo 1 to X/Y coordinate). If all Flags are activated, Trigger(1) activates and initiates all assigned Secret Combos. Trigger(2) can be set with its own unique set of Flags and Secret Combos, and 3, 4, etc.
This is basically how the AoK editor worked, and although I understand it might not even be technically feasible, I think if it were possible, it would enormously reduce reliance on scripting, or even allow more power for scripters, especially if the system were expanded in the future. Examples of more advanced functionality might be: Triggers that can initiate scripts, or be initiated by scripts. A set of global values that can be referenced and manipulated. Triggers that are designated inactive/active by default, and can be activated by another or run in a loop. Flags based on time intervals. Commands that manipulate FFC or NPC behavior- telling them to move to a specific place, cycle to the next combo, cycle to a different FFC, bringing up a text string, or spawning an enemy.
Pie-in-the-sky stuff, I know.
Something maybe more possible: the ability to assign scripts to a screen, in the same way FFC and items already do? Or is this too similar to using an invisible FFC to be useful?
I'm honestly unsure of how much work this would require, but it feels like something that will be possilble much later down the pipe. The ffc objects have a number of fundamental flaws, and adding this much t them will only compound the problems of correcting those; butwe'll eventually get around to ffc-related things, and see what we can do.Quote:
Originally Posted by EJSnowden
The main concern here, is that there would be a limited number of triggers, under a system that doesn't use scripts, and I feel as if people will want more out of it than that. It may be possible to make a default ffc script, that all ffcs run unless otherwise assigned, and add some GUI options to the editor to set its values.
Please clarify 'global values'. The remainder of this is already possible with scripts; so I presume that you mean that you want timing options without scripts? Note that other editors that allow this, typically use default scripts, or some similar mechanism, and then set values via a GUI; or by direct code.Quote:
A set of global values that can be referenced and manipulated. Triggers that are designated inactive/active by default, and can be activated by another or run in a loop. Flags based on time intervals. Commands that manipulate FFC or NPC behavior- telling them to move to a specific place, cycle to the next combo, cycle to a different FFC, bringing up a text string, or spawning an enemy.
The npc things that you want shouldn't be terribly difficult, but it'll require a new npc class.
We have something similar to this on our agenda. At least, I know that I have it on mine, and I seem to recall that @Gleeok wanted to do something similar. Essentially, a new, globally accessible object that can run scripts like an ffc, but that isn;t tied to a screen, and that doesn't have editor ffc attributes. Essentially, a way to do what ffcs can do, without the burden of how the ffc class works. @Dimentio deemed the object a 'mini global', IIRC.Quote:
Pie-in-the-sky stuff, I know.
Something maybe more possible: the ability to assign scripts to a screen, in the same way FFC and items already do? Or is this too similar to using an invisible FFC to be useful?
It would act as a global script of sorts, but it runs on demand. Generally, how ffcs are used with scripts, or run with ffcscript,zh, but internal, and with the ability to have independent timing from the global active script, as ffcs do now; but with the addition of using Waitdraw() to control their timing.
Note that this is merely a concept, and not anything real at present, so we have no idea how it'll work; if it becomes 'a thing'.
I'm certain this is doable by scripting already- counters and flags that are stored upon completing objectives, to tell the game what to do next. I.E., the triforce pieces, but much expanded.Quote:
Please clarify 'global values'.
Then I suppose what I'm wishing for is more functionality accessible by GUI. Especially of things related to cutscenes. New items, enemies, combo functions are fairly straight-forward, create one script, set your FFC, flags and such per screen, and you're good to go. In contrast, each individual cutscene requires its own script, a tedious process, and made even worse if it's supposed to be interactive.Quote:
The remainder of this is already possible with scripts; so I presume that you mean that you want timing options without scripts? Note that other editors that allow this, typically use default scripts, or some similar mechanism, and then set values via a GUI; or by direct code.
So here's a thing. Not sure if anyone mentioned this one.
The ability to directly copy an item class to a blank item class allowing you to create a variant line of the same type of item. For example. We have the wand in the game and its class wand. How about a wand that shoots something other than magic waves. How about one that shoots a fireball that can pierce? Doing so without affecting the same item requires quite a bit of time coding in ZScript but as its a relatively simple function that can be applied based on a "base item type" that already exists why not just have the ability to clone the family and provide a few more options in the editor. This would save a lot of headaches for people who want multiple types of an existing weapon (like wands or arrows).
Speaking of arrows; how about more item counters. The current method of creating a proper item counter was mentioned by someone as being hard/impossible to work with. More counters would allow a few useful things like multiple ammo types for your bow, or even a supply of low recovery level potions, or other special items scripted by modders that have trackable limited uses.
And along with those counters, I've run into this situation twice now; Keys that are unkeyed (ie normal keys) will currently work in dungeons where level specific keys are used even if the item is disabled. What I've been trying to do is make it so normal keys work only on chests in the overworld while level keys are required to get though dungeons.... so... why not have options set for key items on where they can be used. Options could include "doors only", "doors and armos/chest combos", "lock blocks", "doors and chests", "doors and lock blocks", "all locks". If you felt so inclined, perhaps an option to have more than one type of door lock available which would require more complex key-finding. Also, how about an option where finding the "master key" ie. boss key would allow you to use the key to open all dungeon locks?
Also, on the subject, an option to eliminate knock-back on certain damage combos. Currently if you hit a damage combo you get thrown backwards as if hit by an enemy. I wanted to make a poisoned swamp in an area on my last project but scrapped the idea as moving around became much too annoying since Link would touch the water then instantly throw himself back like he just realized the water was made of spiders or something.
Hah!I recently put together a very basic model (on paper) for defining Script Itemclass types. This would use the z* itemclasses, and allow a user to define them directly, then apply them to an item and have that item do whatever they set up for that itemclass.Quote:
Originally Posted by Lelouche Vi Britannia
We also need to fix the Magic Book, as setting its power doesn't affect the flame damage.
(emphasis, mine)Quote:
Speaking of arrows; how about more item counters. The current method of creating a proper item counter was mentioned by someone as being hard/impossible to work with. More counters would allow a few useful things like multiple ammo types for your bow, or even a supply of low recovery level potions, or other special items scripted by modders that have trackable limited uses.
Do you happen to have a reference for that comment? I'm not sure what you mean by a 'proper counter'; nor do I know if this is intended to imply that it is difficult to accomplish this in ZScript, or difficult to modify the source to expand the number of available counters; else something entirely different.
If you are scripting things, and need many counters, you can just store the values in an array, or variable. I suppose we can add more, but I don't know how much of a pain that would be. I don't think it would be too difficult, but I've no idea yet; and depending on how the values are stored, it could either be easy-peasy, or a true nightmare.
I want to change the way counters work, in general, to use signed longs, instead of (supposedly unsigned) ints. I say 'supposedly' there, because they roll over at a signed int value, but Tamamo claimed they were unsigned. Negative counters do have practical applications, and should be a thing in the future.
I do like the idea of custom key types, and matching combos; or additional key types. You can fix the level keys issue with a tiny global function:Quote:
And along with those counters, I've run into this situation twice now; Keys that are unkeyed (ie normal keys) will currently work in dungeons where level specific keys are used even if the item is disabled. What I've been trying to do is make it so normal keys work only on chests in the overworld while level keys are required to get though dungeons.... so... why not have options set for key items on where they can be used. Options could include "doors only", "doors and armos/chest combos", "lock blocks", "doors and chests", "doors and lock blocks", "all locks". If you felt so inclined, perhaps an option to have more than one type of door lock available which would require more complex key-finding. Also, how about an option where finding the "master key" ie. boss key would allow you to use the key to open all dungeon locks?
Spoiler: show
We'd need to add a flag for that. I already planned to turn most of Link's conditions into vars, including knockback.Quote:
Also, on the subject, an option to eliminate knock-back on certain damage combos. Currently if you hit a damage combo you get thrown backwards as if hit by an enemy. I wanted to make a poisoned swamp in an area on my last project but scrapped the idea as moving around became much too annoying since Link would touch the water then instantly throw himself back like he just realized the water was made of spiders or something.
This is also very easy to do, by script...something like this as a global function:
Spoiler: show
My Request is to up the Tile Page Limit. In my new Tileset I am making it is all 8-bit color. Well, I have been making tiles and then erasing some, making tiles and erasing some, and I am finally to the post where I am almost at max capacity for my Tileset for my games I am making. It would be amazing if we can get the Tile Page Limit to be doubled from 256 to 512.
I'm pretty sure Saffith already fixed magic book damage in the 3.0 source, but I've been wrong before. So yeah.
http://armageddongames.net/showthrea...he-Item-EditorQuote:
Originally Posted by ZoriaRPG
I may have misinterpreted what was here but I don't think so. It made it sound like customized counters were simply not possible. If you know how to script this out, I would love to know how. I researched it but I guess the math functions required are over my head right now. I'm still getting used to tweeking scripts already made to do what I want them to do (which has become pretty easy now). But other than some really basic stuff, I'm not a guru yet.
Quote:
Originally Posted by Lelouche Vi Britannia
Here is an example:
Spoiler: show
I made this purely out of me head, in about ten minutes at most. As can see, it's not terribly difficult to do this, and it allows you to display the counter on the screen, wherever you bloody well please. I hope this it sans-error...
If you want to know how to store, and modify an internal Game->Counter[ctr] by shifting weapons,I can give you an example of that, too. Doing this involves little more than storing one state, (CTR_ARCHIVED_*), and if the weapon is selected, store the previous ammo into a backup array index, read a backup array index for the ammo to load, and transpose their values if the condition test evaluates for the specified state.
[ unintentional double post ]
So then is there a way to have a visual counter show up that changes depending on which item is currently set to B?
Nevermind, figured it out and found the script fix for showing counters for both buttons.
Under Etc->Options, a setting for more streamlined combo placement called "Advanced Combo Brush".
If you want to select a combo you have to right-click and select an option it from a drop-down menu.
If you want to draw a block of combos you have to right-click and select an option from a drop-down menu.
If you want to change the brush size you have to right-click and select an option from a drop-down menu.
Overall, it's a very tedious, clunky process. My proposed "Advanced Combo Brush" setting would be exactly like that in Tiled:
Right-click selects a combo.
Right-click dragging selects multiple combos.
If you want to go back to placing single combos, right-click a single combo. From experience, I find it to be a quick, easy system that enables you to build maps twice as quickly. It has no compatibility issues and the existing system could be kept as the default option. :)
One fairly easy request:)
A check-box in the "Tile Warp" window that would force Cave/ItemCellar warps to actually go to the map# specified by the DMap
another words: If I tell a Tile Warp on map#2 to go to a Cave/ItemCellar Dmap that is mapped to map#1 I would like it to actually go to map#1 instead of map#2. This would not change the Screen behavior, but this would make repeatable custom guys much easier. Perhaps put the checkbox next to the Combos Carry Over checkbox.
There's an example of what I am trying to do in my betaquest ZeldaRemastered. (I swear it worked before.?)
^^My first Post^^
This seems like a prudent request to fill. Thank you for pointing out something we have overlooked.Quote:
Originally Posted by jimbrads
@ZoriaRPG
There's a lot of old code that is commented out, unfinished, or just plain unavailable in the quest editor for various reasons.
What are your plans for resolving those issues?
You probably have too much on your plates already, but it can't hurt to request something: Loop start and loop end times for enhanced music like mp3s.
My plan, in general, is to retain what is useful, finish what is practical, rewrite what is beneficial, and crimp out what is extraneous.Quote:
Originally Posted by Tamamo
Ideally, to clean up as much as we can. We are also working on useful commenting of the codebase, over time.
Some code that is commented out though, we may retain, if we cannot reach a decision. Some of it is there as a record for historical purposes, and I do not personally wish to obliterate it.
There is also new code that is commented out and unfinished, because one or more of us has not yet completed it. That is a new issue.
As far as practical completion and revision, the general priority list is:
Rewrite Link's Collision Box with all objects and map flags, cleanly. Remove competing functions and make one universal collision calculation.
Rewrite warping, and segregate scripted warping from ordinary warping.
Revise weapons, and npcs.
Move script-only features into a scripting class.
Simplify trigger events, and make them cleaner, and more organised.
Add a series of methods to allow contributors to more readily and easily expand the script engine.
Add and strengthen sanity checks in the ffscript code to reduce accidental user errors that can, for example, do invalid things.
Expand, clarify, and generally improve script error reporting.
The culmination of this will make it much easier to do things, such as allowing custom sized player hitboxes and sprites; adding flags (and the flag editor), create less buggy scripts, and make it far easier to work with the source code. I have already made several documents for contributors, and developers alike, that detail holw to add to, or modify ZSvript functions, and variables; and class-components (weapons, items, and link; thus far).
These are separate docs. @DarkDragon suggested inserting the docs in-line with the source, but I feel that doing this will detract from the (already poor) readability. Instead, in-line comments will suffice, and I will eventually bind all these docs and notes into a PDF, as I will do likewise for ZSvript; and if we choose to implement AS as ZScript v9000, for that as well.
you don't have a choice but to retain it in that case.
You do not want to know what would happen if you were to remove the 12 npc enemies we don't really need.
Every npc in zc would be fucked...
This is why i was so against merging 2.x and 3.0.
They we're suppose to be separate before you folks even got the source.
I honestly must know: Do you do a bit of drinking before you post to AGN every day?Quote:
Originally Posted by Tamamo
I mentioned npcs on one line, 'Revise npcs'. What the hell are you talking about, at all?
I'm genuinely bewildered by how off-the-wall your reply reads, and I cannot place how it connects to any of this, other than you trying to be smug for whatever reason.
Who said we would ever remove npcs from the engine? The revision plans are related to how npcs work internally, both to the class, and how they can be addressed with scripts. We want to make them more flexible, add some new stuff, clean up some of the hardcoded routines, and whatnot; not rewrite them in entirety.
That act would clearly belong to 3.x.
Hell, I only responded to your earlier post because it had genuine concerns that we care about. Now we're wandering into madness. FWIW, I have a very good idea of what kind of things can occur if you obliterate something that the engine relies upon. Insert sanity check here.
I'm not sure which conversation you're referring to, but my general opinion is that information useful to quest authors should go in external docs, and information only relevant to developers is best incorporated in the source where it's most likely to be seen and maintained.
It was in my last git push. The issue is that the details (1) are cross-subject in a manner that they cover aspects of specific engine components that are spread across multiple source files. There is no specific file in which they belong; and (2) I think it is helpful to have docs as separate .txt or .pdf files so that you can review them separately. I have no qualms about inserting it into the source as well, but I feel that a comprehensive docs set that explains how things works would be best as a manual of sorts.Quote:
Originally Posted by DarkDragon
If our system was cleaner, and less convoluted, perhaps it wouldn't matter as much, but I find it helpful when I have a reference to use for any given project.
I also want to improve source comments, but adding thousands of lines of explanatory docs to the source is something that people tend to frown upon in my experience. I used to do a lot of in-line docs in code, and everyone seemed to hate that.
I was giving you an example.Quote:
Originally Posted by ZoriaRPG
Theirs a reason that file is called guys, and not npcs you know.
Check the code. Their are 12 indices for npcs 6 standing and 6 walking.
Hell their are so many unimplemented enemies it's quite tiring, and some of them would be so easy to implement, (diagonal constant traps are a simple fix.)
The only two options available for those things is to fix them, implement them, or simply make them available to the quest developer.
And no, i joke drink before posting on agn. "I would make a counter involving reading your post, but let's not degrade this discussion further"
Hahah. I asked, because the post seemed so random, and almost gibberish in a way.Quote:
Originally Posted by Tamamo
I do occasionally drink when working on the source, or complex scripts for hours on end. It helps a bit.
If you are interested in seeing some of the new stuff in action, I have a videos on Youtiube in a playlist with demonstrations of some new 2.54 features. I would appreciate feedback on this stuff; although I admit that I need to (1) split each new addition or set of additions into a single video (per 'feature' or per 'change'), as I did with the newer videos; and I must eventually add voice commentary. (I am working on completing my audio recording set-up at present. )
Insofar as your questions about ncs, I'll probably implement the nearly finished npcs, but we also plan to add some new stuff in that regard, particularly bosses, and some common foes from Z3 and LA, using new npc vars, flags, and defences. One of my projects is a ;shock; defence, which will also require another sprite for Link. The latter bit will be fun. Enemies with a fire, or freeze defence, will likewise need new Link sprites (on fire, frozen), and of course, we need a sprite for 'falling'.
I am rather versed in the source at this point. I know the points that are frail, the points that are malleable, and how to work with /most/ of it. The stuff that I have added ( ZScript Commands, short version | All New Things), should give you some indication that I am at leasst moderately competent, as with very few exceptions, it all works precisely as I intended. Link's hitbox though...can go suck a lemon.
TBH, npcs are third on my priority list at present. @Dimentio was going to work on them, but I need to decide what new vars we need, and what flags or flagsets we will be adding to the clas and structs before we muck with the individual npcs. At least we will be adding npcdata, or some equivalent thereof, and I am certain that npcs need a 'MaxHP' var.
I did start on the diagonal hookshot. If you remember, we discussed that a long time back, and you said it was too much of a mess to implement. I am about halfway done wiith it. At present, it works, but I have not completed the handle sprites, or the head sprites, to use an angular tile; and i need to adjust the latching slightly, but here:
https://www.youtube.com/watch?v=xPbi...q3EHzuW21&t=1s
Before I added the item editor flag for 'Diagonal', I also mucked about in ZScript, and found that you can force the new hookshot to do some brilliant, and comical things:
https://www.youtube.com/watch?v=3vjmF4KHckI&index=7&list=PLJZ0n259IQOb2_y6 V5czZR-dq3EHzuW21
If you are curious, no, the diagonal flag in the item editor does not allow the stuff in the latter video, but you can do it with scripts. It reminds me a bit of the whip in Akumajou Dracula (Super Famicom.)
I have not seen any new beta builds to download and check out. I want to check out the newest beta build please.
Here are a few beta builds that you may try, for 2.54:
Executables, docs, and scripts:
https://pastebin.com/LHTV48HE
http://timelord.insomnia247.nl/zc/zc..._20JAN2017.zip
Package with source:
http://timelord.insomnia247.nl/zc/zc..._20JAN2017.zip
I have newer files, but they are not ready for a public beta, and I frankly want to merge everything into ZC main (canonical) before I do anything more.
If you want a build of 2.50.3.* (unreleased beta of main), I can build it for you.
Note that the majority of improvements, new features, and changes in [2.future] 2.54 are ZScript related, although there are also many ZQuest and a few ZC viewer improvements. After the merge, that number will expand, and I can resume working on all the things that I wish to flesh out.
Read the included text files, 2,54_New_Quest.txt, 2.54_New_ZScript,txt, and so forth; or the whole zscript.txt file if you use the language.
The ZC Dev link in my signature goes to the path on the server on which I push binaries and source packages.
Great Thank you! Sorry for the long delay but I just finished BotW (cemu) and am back for more ZC.
(Don't judge me I do own a real copy on a Wii.)
Quote:
Originally Posted by jimbrads
I'm also sorry, as I have forgotten what you were requesting. :D
A Few Things I really want to have in the Enemy Editor:
1. An option to turn On/Off Enemy Knockback, so that you can have weaker enemies have knockback, while stronger ones don't
2. Add the Enemy Defense options of:
Stun and Hurt
Hurt only if Level 2+
Hurt only if Level 3+
Hurt only if Level 4+
3. Have the option for the Hookshot to remove an Enemy's shield like in A Link Between Worlds