I leave with answers, and I return with more questions. I woke up this morning, took one look at the code I left open last night, and said to myself "Okay, I can't put off asking for help anymore." Why not get everything sorted out all at once, if possible?

1.) I've been holding off on coming back here just in case something I'm doing is stupid, but this issue has been baffling me for days, to the point where I've set it aside to work on more productive code. I spent some time moving some of my code to libraries; in particular, I moved my previously-infantile combat code and the empty js include for my no-br-typewriter adaptation to individual, but interlinked, libraries. I think I even got that part to work at some point in time, somehow, after studying another forum post where jaynabonne included an example of an interruptable typewritten exposition block.

Pastebin: FX

However, now, even if I quite literally only use an exact, but renamed, clone of the $.fn.typewriter code block in playercore.js, any attempt to call the function simply prints an empty line. The default Typewriter effect still works fine, so the issue certainly doesn't seem like it's in the first JS block. I can't see an issue myself in the second JS block, but that's where I assume it is. I'd love it if someone could point it out for me, because at this point, I can't even begin to attempt extending that code.


2.) In the time between my last post and this one, I've spent a good deal of time tinkering, tweaking, and otherwise filling in the mechanical backbone for a story I haven't set in stone yet. Things like equipment, combat, a stacking prototype, liquid, etc; things that I don't need yet, but definitely want done now, before they can't be changed easily. Things that sometimes make Quest choke and sputter for a second or two while doing live debug tests in-game.

The stuff I've been reading on the forum hasn't been given me much hope, but is there a way to use JS to return data without my current, fiddly 'specialized-switching-ASL-call' function? In particular, Quest doesn't seem to support more than one decimal. I actually coded my combat calc while away from home, so I didn't realize I couldn't just "return" the proper damage to the Quest script; I ended up adapting the JS code to call said function twice to store the target and deal # damage to it.

--> While writing #5, I actually ended up fiddling with my combat code again, and realized I was doing something so horribly wrong that, I realize now, the switching part of the function was completely unnecessary. Nonetheless, I'd still love to know if there's a way to pass data from JS to Quest more seamlessly; namely, without dedicated function calls.


3a.) I actually have a couple of questions related to the mapping system. For one, I've figured out that putting a room inside another room will draw the parent room automatically while inside any subroom; that's absolutely great for, say, the main protagonist's home, where he'll know exactly where things are. However, no matter what I do, I can't seem to make that work without it seeming sloppy; either there are several squares inside his house where the player 'discovers' rooms, or there are glaringly obvious chunks missing (0 outline thickness rooms) from a room's lining in their place. Is there any way to outright turn off rendering for some rooms, and/or...

3b.) Is there any way to customize/add or call hidden drawing icons for the map? For example, there are your basic hallway (e/w, n/s) and dead end (e, s, w, n) segments, but there's a distinctive lack of a selector for anything like T or cross-intersections, corners, hall turns, diagonals, etc. I've basically foregone customizing rooms to look nice on the map until later on, because it's difficult to do so without those little things annoying me.

I have noticed the script-menu section for 'custom drawing'. I haven't fiddled with it yet, due to previous reasons, but would it be the 'answer to my problems', so to speak? Or would the existing in-game map drawing probably mess with any attempt to make nice maps with it?


4.) There's so much unused space in my status-attributes panel. Is there any way I could convert the status attributes into barred displays- nothing extremely fancy, but not quite so simple as "X/X"? I considered an ASCII display (converting X health into one line on a display, i.e. +:||||||||||), but that method feels a bit cheap?


5.) How reasonably difficult would it be to make a combat interface that doesn't rely on the command bar (ie, choice [x] + enter)? In particular, I'm interested in using JS to get which key a player presses and immediately load the selected menu either to the main screen, or possibly to a dedicated "combat" panel. Currently, I'm just getting player input and using a switch to decide which action to perform, but that extra requirement of pressing enter strikes me as a little clunky for the combat system I'm going for.

1) A tip if you're working with JavaScript: if when your game is running, you click on HTML Tools in the tool bar, it will bring up a very useful window that, among other things, has a Console tab. You can see any JavaScript errors there. Even given that, it took me *too long* to work out the error, which is that you need a semicolon (";") on the end of the block assigned to TextFX. Otherwise, the JS compiler carries on and tries to combine the anonymous function declaration that comes next with that, and it gets all confused.

2) The short answer is, no. You have to use ASLEvent to pass data back to the Quest code.

However, a number of statements you made before that, about problems you were having, etc, made me want to say "Can you show some examples of that?" because it sounds like you're having some interesting issues that might have simple solutions given some sample code. For example, you say, "In particular, Quest doesn't seem to support more than one decimal." which I can't even find a way to make meaningful (more than one decimal per number? no. More than one number with a decimal? Well, it should...) So, I don't know what the problem even is. And the sentence that came after that was intriguing as well (having to call a function twice???), but without seeing some actual code to know what you're trying to do, I can't offer any advice on other ways to do it.

One thought: I once implemented some code for command links in a text-input-less game, where I had a single command that took a parametrized string containing an object, a script attribute name, and the parameters to pass to the script. That way, if I had twenty or more different links, I didn't have to create that many individual commands - I just had one general purpose command that dispatched the request to an object's script, which was much cleaner (for me). Functions don't have the same creation overhead as commands, so I'm not sure if that would solve the problem you're experiencing or not, but it is a way to go, if it makes sense for you.

3) For this as well, if you could put together a simple sample app that exhibits the problem, and then we can run it and you can virtually say, "Ok, see that? That's what I want to change", then it will be easier to get some answers. Otherwise, I'd have to try to put together my own sample code and hope it somehow matches yours to the extent of seeing what you're seeing or want to see.

But another short answer: the custom drawing should allow you to draw your own widgets on the map.

4) Your status attribute can have HTML (see, for example, my progress bar code in the forum's Library section). So you can make it what you want, even an image.

5) If have experimented with hooking key pressed using JavaScript, and then simply pumping them up the app using ASLEvent. It seemed to work in the desktop version, but you might want to check the online player before committing to using it, if you ever plan to publish that way.

jaynabonne wrote:1) A tip if you're working with JavaScript: if when your game is running, you click on HTML Tools in the tool bar, it will bring up a very useful window that, among other things, has a Console tab. You can see any JavaScript errors there. Even given that, it took me *too long* to work out the error, which is that you need a semicolon (";") on the end of the block assigned to TextFX. Otherwise, the JS compiler carries on and tries to combine the anonymous function declaration that comes next with that, and it gets all confused.

Thanks, when I get on my main PC I'll go change that. That was one hell of a sneaky bug.

jaynabonne wrote:2) The short answer is, no. You have to use ASLEvent to pass data back to the Quest code.

However, a number of statements you made before that, about problems you were having, etc, made me want to say "Can you show some examples of that?" because it sounds like you're having some interesting issues that might have simple solutions given some sample code. For example, you say, "In particular, Quest doesn't seem to support more than one decimal." which I can't even find a way to make meaningful (more than one decimal per number? no. More than one number with a decimal? Well, it should...) So, I don't know what the problem even is. And the sentence that came after that was intriguing as well (having to call a function twice???), but without seeing some actual code to know what you're trying to do, I can't offer any advice on other ways to do it.

One thought: I once implemented some code for command links in a text-input-less game, where I had a single command that took a parametrized string containing an object, a script attribute name, and the parameters to pass to the script. That way, if I had twenty or more different links, I didn't have to create that many individual commands - I just had one general purpose command that dispatched the request to an object's script, which was much cleaner (for me). Functions don't have the same creation overhead as commands, so I'm not sure if that would solve the problem you're experiencing or not, but it is a way to go, if it makes sense for you.

I meant to type 'decimal point', as in hundredths, thousandths, etc. I wrote the first half of this post right when I woke up, then added to it throughout the day as I dug through my notes file.

My combat system takes an integer defense for a certain damage type (i.e. defKinetic = 1), converts it into 1% multiplier reduction of that type of damage (1 / 100, 1 - 0.01), then sends the rounded and whole integer back to Quest. Because Quest can't handle those kinds of numbers, I used JS to run the numbers; plus, I'm sure doing it this way will eventually make combat much faster.

I'm not at my main computer right now, but I can recall the initial CombatASLCall function I made to adapt my initial combat code off the top of my head:

if (switchvar = 0) {
  switchvar = 1
  targetobj = GetObject(input)
} else {
  switchvar = 0
  RemoveHP (targetobj, input)
}

An ASLEvent would call this function twice in a row to get the necessary data; however, I had a major facepalm moment while writing #5; I didn't have to pass the target to JS at all, because all JS was doing was handling the calculations. That function got simplified to one line or so, while quest just stores the target object itself before calling the JS calc.

jaynabonne wrote:3) For this as well, if you could put together a simple sample app that exhibits the problem, and then we can run it and you can virtually say, "Ok, see that? That's what I want to change", then it will be easier to get some answers. Otherwise, I'd have to try to put together my own sample code and hope it somehow matches yours to the extent of seeing what you're seeing or want to see.

But another short answer: the custom drawing should allow you to draw your own widgets on the map.

The first area, rooms 1-6, are about equivalent to the starting area of my game, before I stopped trying to map things nicely. Directly south from start is a main area, and each room you enter messes with the major room's border a little bit more. Directly east is a bathroom; if you enter here first then walk into room4 of the main area, it erases what could previously just barely pass as a dividing wall.

There's a hallway connected diagonally to the bathroom; at first glance, it looks like a straight hallway, correct? There's no (nice) way to show that there's actually a t-split there; the major room can't be drawn in any way save for a box, and the minor rooms can only choose between so many 'tiles'. Maybe I'm asking a bit much of the mapping system, but I'd like to be able to use those 'missing' tiles.

jaynabonne wrote:4) Your status attribute can have HTML (see, for example, my progress bar code in the forum's Library section). So you can make it what you want, even an image.

Awesome. I didn't know the extent to which that would work; I've only recently started coloring stats with HTML.

jaynabonne wrote:5) If have experimented with hooking key pressed using JavaScript, and then simply pumping them up the app using ASLEvent. It seemed to work in the desktop version, but you might want to check the online player before committing to using it, if you ever plan to publish that way.

Hmm. I wouldn't want incompatibility to make anything not work. I'll look into other control options, but I always personally preferred quick and to the point menus; something along the lines of a selector wheel

A quick reply about the integer calculations: if you have an integer in Quest, if you divide by 100, then it remains an integer, and you will truncate the decimal places. But if you divide it by 100.0, then it will treat it as a floating point calculation, and you will retain the decimals. So:

If you have damage = 1 (as an integer), then

damage/100 = 0

but

damage/100.0 = 0.01

One of those times the variables type comes into play. In case that helps simplify things by you not having to dive into JavaScript for the calculation. I'll check out the rest a bit later.

Cylius_Optimi wrote:...
My combat system takes an integer defense for a certain damage type (i.e. defKinetic = 1), converts it into 1% multiplier reduction of that type of damage (1 / 100, 1 - 0.01), then sends the rounded and whole integer back to Quest. Because Quest can't handle those kinds of numbers, I used JS to run the numbers; plus, I'm sure doing it this way will eventually make combat much faster.
...

Quest can handle floating point arithmetic, using double attributes, but in this case you should be able to stay with integers, as long as you multiply by 100 early enough. Say the base damage is 12, and the armour has a value of 2, the first one here will give you 11, which is right, the second gves zero.

12 * (100-2) / 100
(100-2) / 100 * 12

Do all your multiplying before the dividing, and it should be fine. And probably quicker than going into JavaScript and back. And definitely easier!

jaynabonne wrote:A quick reply about the integer calculations: if you have an integer in Quest, if you divide by 100, then it remains an integer, and you will truncate the decimal places. But if you divide it by 100.0, then it will treat it as a floating point calculation, and you will retain the decimals. So:

If you have damage = 1 (as an integer), then

damage/100 = 0

but

damage/100.0 = 0.01

One of those times the variables type comes into play. In case that helps simplify things by you not having to dive into JavaScript for the calculation. I'll check out the rest a bit later.

The Pixie wrote:

"Cylius_Optimi"

...
My combat system takes an integer defense for a certain damage type (i.e. defKinetic = 1), converts it into 1% multiplier reduction of that type of damage (1 / 100, 1 - 0.01), then sends the rounded and whole integer back to Quest. Because Quest can't handle those kinds of numbers, I used JS to run the numbers; plus, I'm sure doing it this way will eventually make combat much faster.
...

Quest can handle floating point arithmetic, using double attributes, but in this case you should be able to stay with integers, as long as you multiply by 100 early enough. Say the base damage is 12, and the armour has a value of 2, the first one here will give you 11, which is right, the second gves zero.

12 * (100-2) / 100
(100-2) / 100 * 12

Do all your multiplying before the dividing, and it should be fine. And probably quicker than going into JavaScript and back. And definitely easier!

I didn't realize "double" type variables would actually accept more than tenths! When I was initially setting things up for my game, it truncated anything past 0.0 to 0.1. No clue how that happened, it worked fine when I tried again recently.

I rewrote the combat code completely inside Quest; I also plan to switch out my integer-based stats to double-based stats very soon. Thanks for the help.

Regarding the mapping issue, I don't know if this will help, but you can actually control which sides have the border drawn. Unfortunately, there's no built-in way to (say) not draw the fill. I tried both "rgba(0,0,0,0)" and "transparent", and it just drew black. So even when the border doesn't draw, the fill still draws, which will eat into your parent frame. You might be able to work around that by manually drawing the parent frame just that much further from the rooms so it doesn't get "eaten". I tried that quickly with no luck. I could try again.

I have attached a modified version of your game with two changes (well, two classes of changes):

1) I turned off the border for the parent rooms.
2) I manually edited the "grid_bordersides" attribute for each room. The dropdown with things like "North-South", etc only has a subset of the full 16 possibilities. The border sides are stored as an integer attribute with value from 0-15 (four bits). The bits are:

north = 8
east = 4
south = 2
west = 1

You add together the borders you want drawn and set the grid_bordersides attribute, and it draws just those. So, for example, for your room1, since it had exits to the east and south, I assumed it would have borders north and west. So I set its grid_bordersides attribute to 8+4 or 12. (You can find the attribute in the attributes list for the object. You may have to scroll down to find it.) It does give you that level of control, at least. I think to not draw the white for the room (or shrink it a bit), we'd have to dive into JavaScript and start overriding functions. Not impossible, but I wanted to see what you thought of this before we went further.

Another thought: I have code that "pre-visits" all the rooms in the game, forcing them to draw in the map. That way, the map is fully visible up front. If all the children draw, you might not even need a parent room in that case. Let me know if that would be useful, and I'll dig it up.

Actually, here's a version where the map fully draws up front. I'm not completely sure why it sort of scrolls into view; I think it might be because in the process of visiting all the rooms, the map shifts, and then it recenters when the game starts.

Anyway, the key is a function called "VisitRoom" which calculates and draws the room you pass and then recursively visits any rooms that lead off it via exits. (It sets a flag on each visited room to keep from recursing forever.) The game just calls it on "player.parent" in the start script to get the ball rolling.

In case it's useful...

jaynabonne wrote:Regarding the mapping issue, I don't know if this will help, but you can actually control which sides have the border drawn. Unfortunately, there's no built-in way to (say) not draw the fill. I tried both "rgba(0,0,0,0)" and "transparent", and it just drew black. So even when the border doesn't draw, the fill still draws, which will eat into your parent frame. You might be able to work around that by manually drawing the parent frame just that much further from the rooms so it doesn't get "eaten". I tried that quickly with no luck. I could try again.

I have attached a modified version of your game with two changes (well, two classes of changes):

1) I turned off the border for the parent rooms.
2) I manually edited the "grid_bordersides" attribute for each room. The dropdown with things like "North-South", etc only has a subset of the full 16 possibilities. The border sides are stored as an integer attribute with value from 0-15 (four bits). The bits are:

north = 8
east = 4
south = 2
west = 1

You add together the borders you want drawn and set the grid_bordersides attribute, and it draws just those. So, for example, for your room1, since it had exits to the east and south, I assumed it would have borders north and west. So I set its grid_bordersides attribute to 8+4 or 12. (You can find the attribute in the attributes list for the object. You may have to scroll down to find it.) It does give you that level of control, at least. I think to not draw the white for the room (or shrink it a bit), we'd have to dive into JavaScript and start overriding functions. Not impossible, but I wanted to see what you thought of this before we went further.

Another thought: I have code that "pre-visits" all the rooms in the game, forcing them to draw in the map. That way, the map is fully visible up front. If all the children draw, you might not even need a parent room in that case. Let me know if that would be useful, and I'll dig it up.

That's extremely useful! I'll definitely have to tinker with it and integrate it into my main game.

jaynabonne wrote:Actually, here's a version where the map fully draws up front. I'm not completely sure why it sort of scrolls into view; I think it might be because in the process of visiting all the rooms, the map shifts, and then it recenters when the game starts.

Anyway, the key is a function called "VisitRoom" which calculates and draws the room you pass and then recursively visits any rooms that lead off it via exits. (It sets a flag on each visited room to keep from recursing forever.) The game just calls it on "player.parent" in the start script to get the ball rolling.

In case it's useful...

Thanks! Actually, that feature would definitely be helpful for the greater majority of rooms, but I'd also like some rooms to stay hidden; stuff like unexplored wilderness, alleyways, etc. Is there a way you'd suggest to toggle automapping for certain rooms?


EDIT: I'm actually looking through the second MapTest in Notepad++; it looks like you included some JS, but it didn't get included with the game?
If that's an important component, just thought you should know.

Give me a few minutes to think and I'll update this again.


EDIT 2: Alright, I've compared the original MapTest and the newest one you uploaded. Custom borders definitely solves a lot of my problems with the mapping system; I can't account for every situation ever, but combined with auto-mapping, this seems to have basically covered all of question 3.

I think I'll rewrite the Core editor entry for the map system if possible, and add all possible combinations. I would like to know if it would be possible to cleanly override that segment with a library; I'd be perfectly willing to post my 'map extension library' once finished, if I can forego editing the core files.

I'm actually looking through the second MapTest in Notepad++; it looks like you included some JS, but it didn't get included with the game?
If that's an important component, just thought you should know.

Sorry about that. The JS was the beginning of something that didn't pan out. You can remove the reference in the file.

Actually, that feature would definitely be helpful for the greater majority of rooms, but I'd also like some rooms to stay hidden; stuff like unexplored wilderness, alleyways, etc. Is there a way you'd suggest to toggle automapping for certain rooms?

I haven't tried this, but the VisitRoom code sets a "genvisited" boolean attribute to true on each room it has visited, so it won't visit them again. In theory, if you set that flag on a room manually, the code wouldn't go into that room, so the room wouldn't get drawn - or any other rooms leading from it, if there is only one path to them through that room. It might add the exit, though, which might make it's being hidden a little more obvious. (I don't know if it will do that. I'd have to try it.)

Really quick before I head out- if I should post this somewhere else in the forum, let me know.

MapTilesExt_Types.aslx -> Goes in your game include

MapTilesExt_Editor.aslx -> Replaces <include ref="CoreEditorObjectMap.aslx"/> in CoreEditor.aslx

It changes the map editor tab to have all various combinations easily marked. Types go in include because I couldn't get a general include to override the core map tab.