inheritance lost on publishing?

pfw
OK, I am sure I am doing something wrong - but not clear what it is:
Using the Windows Quest Editor Build 5.6.5514.32136 and generate a simple game (aslx attached).
I have a command "listallrooms" which works when I play the game from th editor interface. When I publish and run the .quest on Windows I get the following error:
Error running script: Error evaluating expression 'DoesInherit( object_x, "editor_room")': No element 'editor_room' of type 'ObjectType'
This implies the inherited types have not been carried into publication.

Is there an option I missed somewhere?

Thanks for the help and a fun piece of software :D

Pertex
editor_room ( and editor_room, editor_player..) is only used for the editor and is removed in the published game. Best thing would be to add a new attributes to your rooms and use it to create a list of rooms

pfw
Thanks. Out of interest, why do they exist/ get removed?

HegemonKhan
the specific Object Types (via as Inherited Attributes) 'editor_room', 'editor_object', and 'editor_player', provide the Attributes that gives us the Editor's Tabs+controls of these in the Editor (the drop-down boxes of choices, text boxes, and etc):

'whatever' Object -> 'object~whatever it is called' Tab -> Object Type [object, room, player, or object+room] -> various options (based upon it's object type)

so, when you actually start the game, there's no more editor mode, and thus no reason to have~use the Object Types of 'editor_object, editor_room, editor_player' within the game play mode.

So, you need to make your own custom Attributes, if you need to reference the types of objects for your scriptings.

------

Object Types (and their Inherited Attributes):

http://docs.textadventures.co.uk/quest/ ... /type.html
http://docs.textadventures.co.uk/quest/types.html
http://docs.textadventures.co.uk/quest/ ... herit.html

from the 'how to (guides) section of the wiki, linked here:

http://docs.textadventures.co.uk/quest/guides/

here's about the creation+usage of the Object Types (via as Inherited Attributes):

http://docs.textadventures.co.uk/quest/ ... types.html
http://docs.textadventures.co.uk/quest/ ... nced_.html

these are the direct links about the creation and usage of the Tabs+Control tags for (only) the editor's usage:

http://docs.textadventures.co.uk/quest/ ... nced_.html
http://docs.textadventures.co.uk/quest/ ... s/tab.html
http://docs.textadventures.co.uk/quest/ ... ntrol.html

-----------

Pixie's Simple Combat and Spell Libraries, creates new editor 'magic' and 'combat' Tabs+Controls, for you to use the editor, to easily set up your game's combat and magic stuff:

http://docs.textadventures.co.uk/quest/ ... nced_.html
http://docs.textadventures.co.uk/quest/ ... nced_.html
http://docs.textadventures.co.uk/quest/ ... nced_.html

The Pixie
pfw wrote:Thanks. Out of interest, why do they exist/ get removed?

This is a good question. I got caught with this once, and I see no reason for it. It is useful to know if something is a room, and this would be the best way.

The best alternative is probably to check if the object has any exits, and assume it is a room if it does.

pfw
Thanks for the detailed explanation

Silver
The Pixie wrote:

"pfw"

Thanks. Out of interest, why do they exist/ get removed?


This is a good question. I got caught with this once, and I see no reason for it. It is useful to know if something is a room, and this would be the best way.

The best alternative is probably to check if the object has any exits, and assume it is a room if it does.



Unless the rooms don't have exits because the author has created some alternative mechanism for moving around the game like with commands or whatever. I just went to check and it does seem that the only difference between an object being a room or not is whether it can create exits in the gui. Couldn't he/she add some attribute manually for the game to check? Like:

object.isroom or somesuch? A pain, I know, but sounds easier than checking for exits (in my mind).

The Pixie
If I had commands moving the player round, I would still try to use exits, but give the alias as the command (eg an alias could be jump for example, rather than north).

The problem with setting flags is forgetting for a room; it could be very difficult to debug. Also, I personally would find setting flags on dozens of objects boring, and writing a function interesting, so would always do the latter!

Here is a function that will check an object for you.
  <function name="IsRoom" parameters="obj" type="boolean"><![CDATA[
return (ListCount(ScopeExitsForRoom(obj)) > 0 or GetBoolean(obj, "thisisaroom"))
]]></function>

It will return true if the object has any exits or if you set a Boolean attribute called thisisaroom to true for any rooms with no exits.

HegemonKhan
this seems to be one of the big design choices in programming code:

tons of Attributes vs omni-parsing Scripting

do you do the manual work of adding~setting all of the individual Attributes in your game, or do you make scripting that then does it for you? (there's pros and cons to both design methods)

that I've come across, as I'm learning to code

(I presume good coders prefer doing more with scripting, than with attributes)

jaynabonne

(I presume good coders prefer doing more with scripting, than with attributes)


The preference is usually whatever results in the sanest, most robust code. If you need code, you write script. But data-driven designs can work very well as well. (The response library I used in spondre is a small kernel of a library driven by copious amounts of data.)

The Pixie has it right here: having to manually add an attribute to all objects is not only a real pain, but it's highly error-prone. It's very easy to make a mistake. And, worse yet, hard to modify if you have to make a change across all the rooms. That points to it not being (necessarily) the best approach. Of course, if you had no choice, well then you make do... :)

Bottom line: you can't speak of absolute preferences for such things. The tool you use depends on the situation.

Silver
And your knowledge! I wouldn't know how to write a script to do it. Then again, I haven't the foggiest what they're trying to do.

HegemonKhan
scripting can get very complex-webbing too (too much interacting scriptings for your brain to handle given your coding ability), besides whether you can even figure out how to do the coding scriptings (for us code noobs), whereas using straight-up attributes is extremely simple (but extremely tedious).

a simple example of Attributes vs Scripting:

Attribute Usage:

<attr name="current_life_integer" type="int">0</attr>
<attr name="minimum_life_integer" type="int">0</attr>
<attr name="maximum_life_integer" type="int">0</attr>
<attr name="buffed_maximum_life_integer" type="int">0</attr>
<attr name="debuffed_maximum_life_integer" type="int">0</attr>

by having these 5 Attributes, I can easily adjust them and plug them to equations (scripting) as needed, in with simplicity. If an enemy damages me, I reduce the 'current_life_integer'. If I level up, then I raise the 'maximum_life_integer'. If I do a 'full heal' spell, then I just set it as 'current_life_integer = maximum_life_integer'. If I cast a spell that temporarily raises my max life, than I just raise the 'buffed_maximum_life_integer', while leaving my normal max life (maximum_life_integer) intact. The same if an enemy uses a spell that temporarily lowers my max life, just lowering the 'debuffed_maximum_life_integer', while leaving my normal max life (maximum_life_integer) intact. etc etc etc

using Attributes makes the scripting easier, but it's a lot more work (writing~coding)

Scripting Usage:

instead, I'd just have 'life_integer', using equations (scriptings) to do whatever I might need, but this requires a lot more control by your part to make sure that it all works syncronously together. No examples... too difficult for me, laughs. I'm a noob at coding, this would take a lot of effort and time to do!

using Scripting, makes the scripting harder, but it's a lot less work (writing~coding)

---------------

here's a qwasi-example (HK altered) from Pixie's Level Library of using Scripting (to create your attributes):

<object name="global_data_object">
<attr name="attribute_stringlist" type="simplestringlist">strength;endurance;dexterity;agility;speed;luck</attr>
</object>

<object name="player">
</object>

<function name="function_1">
foreach (attribute_x, global_data_object.attribute_stringlist) {
if (not HasInt (player, attribute_x)) {
set (player, attribute_x, 0)
}
}
</function>

// since 'player' has none of the Attributes, the scripting will give the 'player' all of these Attributes with having the Value of 0:
// player.strength = 0
// player.endurance = 0
// player.dexterity = 0
// player.agility = 0
// player.speed = 0
// player.luck = 0


scripting is very good, as you don't want to be writing in the 6 attributes for 1000 character objects, but you got to know how to do the scripting, and keep it all synchronized functionally together, and keep it all organized to+for you.

-------------------

here's an example, of more detailed scripting:

<object name="global_data_object">
<attr name="attribute_stringlist" type="simplestringlist">strength;endurance;dexterity;agility;speed;luck</attr>
</object>

<object name="player">
</object>

<object name="orc">
</object>

<function name="function_1" parameters="character_parameter">
foreach (attribute_x, global_data_object.attribute_stringlist) {
if (not HasInt (character_parameter, attribute_x)) {
if (character_parameter.name = "player") {
if (attribute_x.name = "strength" or attribute_x.name = "endurance" or attribute_x.name = "dexterity") {
set (character_parameter, attribute_x, 100)
} else if (attribute_x.name = "agility" or attribute_x.name = "speed" or attribute_x.name = "luck") {
set (character_parameter, attribute_x, 0)
}
} else if (character_parameter.name = "orc") {
if (attribute_x.name = "strength" or attribute_x.name = "endurance" or attribute_x.name = "dexterity") {
set (character_parameter, attribute_x, 0)
} else if (attribute_x.name = "agility" or attribute_x.name = "speed" or attribute_x.name = "luck") {
set (character_parameter, attribute_x, 100)
}
}
}
}
</function>

// player.strength = 100
// player.endurance = 100
// player.dexterity = 100
// player.agility = 0
// player.speed = 0
// player.luck = 0

// orc.strength = 0
// orc.endurance = 0
// orc.dexterity = 0
// orc.agility = 100
// orc.speed = 100
// orc.luck = 100


pretend that I did this for 1000 character Objects, not just 2, much less work than manually writing in the 6 attributes for each character object

jaynabonne
Well, the last example isn't real code anyway, because "attribute_x" is a string and so has no "name" attribute. But that aside, you'd have to be insane to write code like that. It not only makes it all more opaque and harder to understand, but it serves no purpose whatsoever besides obfuscating things. So straw man aside...

The difference between that code and the example you give just prior (quasi PIxie) is that in the previous example, the script doesn't actually know the attributes. It's a general-purpose script that is just setting attributes based on the parameters passed (via the list). Your expanded code example has the attributes listed both in the list and in the code. It has no generality. In order to add a new attribute, you have to modify *both places*, which is shotgun surgery at its worst. There is no reason whatsoever to write code like that, unless you're a masochist. :)

jaynabonne
Also, to analyse a little bit further, the "quasi Pixie" code example you gave has an advantage if it is delivered in a library, where the user of the library can configure the attributes externally. In other words, the code can't know up front what attributes to set. That makes it a perfectly legitimate use of code as opposed to just having hard-coded attributes, because the latter would be impossible. You need to be able to adapt to different attribute sets dynamically.

Which makes your last code example even worse, as it doesn't even serve that purpose.

This topic is now closed. Topics are closed after 60 days of inactivity.

Support

Forums