Messages

[four' versions]

Yes this is the direction I am taking, but unfortunetaly I can't say when it can be done.

I fully comprehend that.

I'm a /primary/ ZC dev now,  so , I have similarly long to-do lists.

It is the correct decision though, and I'm glad that you are taking my advice from 1->2 years ago.

( I cannot comprend why Diarandor believed that adding this -kind of feature was mutually-exclusive with Lua-based control. )

I hope that all has been well with you, otherwise.  II  try to kqeep in touch, but it us hard.

I need to play the new Solarus quests, but as-is, I canna' keep up with ZC quests, and I am simultaneously coding four' versions of ZC, so my 'free time' is quite scant.

That issue aside, I have not stopped watching Solarus.

OT, but, have you added a pause feature?

There is absolutely no need to hardcode any of the events. If when adding scripts to a quest, the scripts can add dialogues, then a set of default scripts, or templates, using that type of mechanic can tailor the UI in a way that makes it dead simple to use.

This notwithstanding,  if you are concerned about adding an in-built UI with events, items, npcs, game dialogue controls; whatever, even with a hardcoded set of defaults, a user could ignore using them, and use Lua to control everything.

I do not at all comprehend the argument that having one or the other need be mutually-exclusive.  Using the Lua to shape the UI is the *best* solution, IMO, but nothing prevents Lua from working if there are also say, internal enemies.

That is precisely how I'm planning to implement npc scripts in ZC in the future, and I would at some point want to allow scripts to modify the ZQuest interface, but that is a great deal harder than it sounds, for our case.

Anyway, it /sounds/ as if this is the direction that Christopho is taking, and it is a sane path. Template script sets that generate the UI, would make the programme less rigid, not more rigid.

I suggested some stuff along this line a few years ago. The crippling issue with  Solarus, in general, is that  you  absolutely need to use Lua to do anything useful. Unless something has changed quite recently, doing a basic function, such as adding an npc, required Lua scripts; and adjusting say, the HP or attack power of that npc required editing the script as well.

(I wish that I had the time (and sanity) required to work on this, but I spend all of both on ZC.)

What  I suggested, is: Adding editor panes that can interface with scripts, read  their values, store basic values in a GUI panel, allow changing them there, then writing the values back out to the script. This could all be done in char!

Editor panes like that, could usethe script tokens (type, name) to bind them to the appropriate list.

Likewise, game actions, and game objects, could be set up in much the same way.

If Solarus was C99, I would be far more willing to work on stuff of this sort, but all of the highly-abstracted, OOP nonsense is just too much for this old bastard.

Perhaps I'll look at it again at some point.

I'm checking in, for a status update on this: Are you still planning to add the editors for game objects?

Hello again Christopho,

Have you been able to add a pause function? This flaw is still singularly agitating, as there is no way to multi-task; to take a break from the game and use my system for anything with audio.

Are there any updates on this?

I'm thinking of making predefined enemy, and item classes, with the ability to add more; then using GUI editors to set their datum, and attributes.

Do you have a new dist for the Solarus DX game?

Also, what is the proper method for moving my saved game to a directory with the updated (1.4x) engine, and a new game file?

If you want the NES screen transitions, ZC would be the easiest as a start, but to accomplish all of you ideas, you'd need to become used to some very unusual scripting APIs. (I have, over a few years, but it takes some doing.)

I have most of the code you;d need to do this in ZC, but it's very different to Solarus, in almost every way. Some things are easier, some harder, some dead simple, others obtuse. You should certainly try playing with it, but watch the how-to videos (by TeamUDF) first.

I would love to see something like this for Solarus though, as a proof of concept.

As to shields, the general rules from Z3 are:

Base (blue) shield: Blocks arrows, and stones.
Red (magic) shield: Bloocks wizrobe spells, and fireballs, plus cumulative from blue shield.
Mirror shield: Blocks lasers, and cumulative from red shield.

Those should all work in Solarus.

If you're curious, in ZC, shields (class item), block attacks in the direction the player is facing, based on a flag. (Each type of attack that you want to block, is added into the integer flag, and you may have many shields, and use fancy tricks to allow a player to shift between them, and do other things.)

http://armageddongames.net/showthread.php?97159-Next-Gen-ZC-%28Otherwise-known-as-ZC3-0%29

For those interested, we've been debating working with the Solarus basecode, with pros, cons, and concerns. Anyone who would be able to contribute there, is most welcome.

Thinks 'Terranigma', and smiles, That, or 'Sabrewulf'.

The JAVA runtime was pretty much a guarsntee of compatibility.  Would it be difficult to use substitute rutimes with a command line switch --java from one build?

XP-SP2 is still the most common desktop OS in use.

That's brilliant mate, and I look forward to it in the future.

Should you want suggestions, or advice on implementation, I'd be happy to discuss it in detail. As I said though, 30m looking at the ZQ editors should give you an idea of how to make this work in Solarus.

You may also be able to draught some co-devs for the engine, over on AGN.

Best wishes tracing that error, and resolving it. For the record, it seems mostly on overworlds, as dungeon areas have fewer transitions of this sort, and after a while, i got used to it.

I also am not sure, but I think that freezing Link while swinging the sword is a bit different to the real Z3 engine. You may want to check the timing there.

Right, immediate transitions. I suggest running it on some older laptops, to do testing, as most users won't have high-end PCs just to run this. Testing on older HW is good anyway, because it enables you to catch more performance-related bugs in general.

In the main DX project, moving between screen areas on the first map does this. There is a brief pause, the music stops, and the screen jitters. Then the screen transitions, and the music resumes.

I'm not the only user who's run into this. Moosh (also from PZC) has the exact, identical problem.

I'm not certain I'd call myself a ZQuest 'ex[ert', but I'm at least an adept.

Have you used the ZC/ZQ programmes (2.50.x)?

P.S. I had no idea that you added so much in the last month. That's quite astonishing, really, and it seems I picked the right time to explore Solarus, as a month ago, I probably would have skipped it without those editor panes.

Right, immediate transitions. I suggest running it on some older laptops, to do testing, as most users won't have high-end PCs just to run this. Testing on older HW is good anyway, because it enables you to catch more performance-related bugs in general.

In the main DX project, moving between screen areas on the first map does this. There is a brief pause, the music stops, and the screen jitters. Then the screen transitions, and the music resumes.

I'm not the only user who's run into this. Moosh (also from PZC) has the exact, identical problem.

P.S. I had no idea that you added so much in the last month. That's quite astonishing, really, and it seems I picked the right time to explore Solarus, as a month ago, I probably would have skipped it without those editor panes.