Building on what was said in previous threads....
http://www.neurohack.com/transcendence/ ... .php?t=174
http://www.neurohack.com/transcendence/ ... .php?t=456
__________
1. Are there any general functions for reading and writing information to items and classes of items? For example, let's say I wanted to read the description of an item and then change it. There's no itmGetDescription or itmSetDescription that I know of, so I was hoping that something like:
(objGetGlobalData itemName "description")
...would work.
But it it looks like this function only works on station type objects, and only retrieves information that's been set with objSetGlobalData anyway. It doesn't seem to read base attributes (or whatever you call them) from the XML, like mass, name, and description.
Being able to change an item class's base attributes would allow things like technology upgrades, or a weapon who's stats could change over time, so it'd be a neat thing to be able to do... if it's doable.
2. Is there a getDataType function? That would really help in debugging (or at least understanding) some of the scripting code.
3. What data types are in the game? Are stations, ships, items, and spaceObjects all different data types, or are they just different types of objects?
Scripting questions: reading and writing data; data types
For your first question- I'm not sure if there's any way to do that using functions like you would like. Although it may be possible, I highly doubt it, as descriptions and such are stated in your code. You can, however, make another item with the same (or similar) name but a different UNID, and, of course, a different description. Just remove the first item and replace it with the second item with the different description. It would have the exact same effect, if I am understanding you correctly.
As for your other questions, I'm not really sure. I like to use the reasoning "If George would need it, it's probably there." But if it's not used anywhere else, chances are it's not going to work. I'm not sure about the data types in question 3. Not sure what you're talking about. The type of object prefixes the actual UNID. So &st---0xE####### would imply the object is a station.
As for your other questions, I'm not really sure. I like to use the reasoning "If George would need it, it's probably there." But if it's not used anywhere else, chances are it's not going to work. I'm not sure about the data types in question 3. Not sure what you're talking about. The type of object prefixes the actual UNID. So &st---0xE####### would imply the object is a station.
You make a good point. The Transcendence code is very practical that way: if and when George sees a need for something, it'll be there.Sponge wrote:"If George would need it, it's probably there."
That being said, just because something isn't used in the current code, doesn't mean that it's not there. It could exist for debugging purposes, or have been used in an earlier verion but not anymore. I think some of the functions mentioned in the links at the top aren't used in the current code, for instance.
Both of those being said, I doubt that there's a generic function for reading and writing base attibutes (or whatever you call them), as there are a plethora of functions for itmGetX, etc., and a generic function would make them all unnecesary except for efficiency/convenience purposes. However, there might be an oddball way to do it. Only George knows for sure.
And even if it doesn't exist now, it's a useful thing to have, so it might exist in the future. So it doesn't hurt to ask and see what the hidden features/plans are.
Same with a getDataType function. It probably doesn't exist now, but you never know: maybe there's an oddball way to do it. And if it doesn't exist now, it's a useful thing to have, so maybe it'll exist in the future. It all depends on what George's plans are, and, again, only George himself knows them for sure.
As for the data types, I'm still trying to figure those out. Right now it's trial and error.
~
[Grabs a box of batteries.] The power is mine! MINE! Ah hahaha! AHHHH HAHAHA!
[Grabs a box of batteries.] The power is mine! MINE! Ah hahaha! AHHHH HAHAHA!
You can get and set data to any space object (ship or station) with objGetData and objSetData. Those come in the format:
(objSetData obj identifier value)
(objGetData obj identifier)
where
obj is the space object you are attaching the data to
identifier is a string which you will use to identify the data
value is the data to be saved
In the world of software development, what you are looking for are called getter and setter. Getters and setters allow you to directly influence variable or attribute data of a realtime object through the use of a method or function. Of course, riddling your code with getters and setters pretty much ruins any encapsulation you might have.
(objSetData obj identifier value)
(objGetData obj identifier)
where
obj is the space object you are attaching the data to
identifier is a string which you will use to identify the data
value is the data to be saved
In the world of software development, what you are looking for are called getter and setter. Getters and setters allow you to directly influence variable or attribute data of a realtime object through the use of a method or function. Of course, riddling your code with getters and setters pretty much ruins any encapsulation you might have.
Thanks for your input, Burz. Unfortunately, it did not answer my questions. So I guess I'll have to wait for the big George to respond. (I'm surprised that he hasn't responded already... He normally seems to love talking about scripting.)
BTW, it's nice to know that there are some other modders on here who have studied OOP.
BTW, it's nice to know that there are some other modders on here who have studied OOP.
~
[Grabs a box of batteries.] The power is mine! MINE! Ah hahaha! AHHHH HAHAHA!
[Grabs a box of batteries.] The power is mine! MINE! Ah hahaha! AHHHH HAHAHA!
Okay, I'll be more specific.
1. Yes there are function for reading many of the attributes of objects in the game. As far as I know, no one has a complete list. Gets are more common than Sets and the basic form is for items is (itmGetAttr item) where Attr is replaced by the Attribute you want. For example, (itmGetUNID gItem) will retrieve the UNID of the item stored as gItem.
2. Not to my knowledge, but there is a function that determines if a variable is a function or not, read some of the script related to gMargin for more details. A few other specific functions exist, (objIsShip obj) will determine if an obj is a ship, for example.
3. All objects in the script are pointers. As far as I can tell, there are spaceObjects, ships which extends spaceObjects, stations which extends spaceObjects, items, and armors which extends items.
Remembering that objects are pointers is important, because storing references to objects in other objects (i.e. the lead ships at Point Juno) requires using
(objSetObjRefData ...) instead of (objSetData ...)
1. Yes there are function for reading many of the attributes of objects in the game. As far as I know, no one has a complete list. Gets are more common than Sets and the basic form is for items is (itmGetAttr item) where Attr is replaced by the Attribute you want. For example, (itmGetUNID gItem) will retrieve the UNID of the item stored as gItem.
2. Not to my knowledge, but there is a function that determines if a variable is a function or not, read some of the script related to gMargin for more details. A few other specific functions exist, (objIsShip obj) will determine if an obj is a ship, for example.
3. All objects in the script are pointers. As far as I can tell, there are spaceObjects, ships which extends spaceObjects, stations which extends spaceObjects, items, and armors which extends items.
Remembering that objects are pointers is important, because storing references to objects in other objects (i.e. the lead ships at Point Juno) requires using
(objSetObjRefData ...) instead of (objSetData ...)
1. As in your previous post, you're repeating a bunch of stuff I already know... which should have been obvious from my initial post at the top of the thread, but maybe I didn't state things as clearly as I thought.
Let's see... I wrote:
"Are there any general functions for reading and writing information to items and classes of items?"
Ah, that's not too clear unless you read the example below it. I should have wrote:
"Are there any general functions for reading and writing the base attributes of items and classes of items?" (like mass, name, and description)
2. Ah, objIsShip! (and such) Thank you! That's the dirty oddball workaround I was looking for!
3. Interesting observations about some object types being extensions of another. That clears things up. If it's true, for instance, that ships and stations are extensions of spaceObjects, then any functions that work on spaceObjects should work on them. That's good to know, and I'll test that out. By the way, how did you determine that the object types are hierarchical like that?
Let's see... I wrote:
"Are there any general functions for reading and writing information to items and classes of items?"
Ah, that's not too clear unless you read the example below it. I should have wrote:
"Are there any general functions for reading and writing the base attributes of items and classes of items?" (like mass, name, and description)
2. Ah, objIsShip! (and such) Thank you! That's the dirty oddball workaround I was looking for!
3. Interesting observations about some object types being extensions of another. That clears things up. If it's true, for instance, that ships and stations are extensions of spaceObjects, then any functions that work on spaceObjects should work on them. That's good to know, and I'll test that out. By the way, how did you determine that the object types are hierarchical like that?
Last edited by Karl on Fri Feb 16, 2007 2:42 pm, edited 1 time in total.
~
[Grabs a box of batteries.] The power is mine! MINE! Ah hahaha! AHHHH HAHAHA!
[Grabs a box of batteries.] The power is mine! MINE! Ah hahaha! AHHHH HAHAHA!
I'm still not entirely clear on what you are looking for, but (itmGetTypeData gItem) will pick up the 'data' attribute of an item class, and (itmGetCharges itemStruct) will pick up the number of charges (which is resetable via (shipRechargeItem ...)). Worst case, you can always store the data in the gPlayerShip. For example, (objSetData gPlayerShip &itmUNID "information") will store information about a class of item in gPlayerShip, which is always in scope.Karl wrote:1. As in your previous post, you're repeating a bunch of stuff I already know... which should have been obvious from my initial post at the top of the thread, but maybe I didn't state things as clearly as I thought.
Let's see... I wrote:
"Are there any general functions for reading and writing information to items and classes of items?"
Ah, that's not too clear unless you read the example below it. I should have wrote:
"Are there any general functions for reading and writing the base attributes of items and classes of items?"
Well, I assumed George wasn't an idiot, and went from thereKarl wrote: 3. Interesting observations about some object types being extensions of another. That clears things up. If it's true, for instance, that ships and stations are extensions of spaceObjects, then any functions that work on spaceObjects should work on them. That's good to know, and I'll test that out. By the way, how did you determine that the object types are hierarchical like that?

Also, I hasn't completely confirmed that those are subclasses, implementing an Interface is also an option.
It's still not clear? Hmmm... that's because the terminology needed isn't well-defined.
Ok, so when descriptions fail, examples may illuminate.
Let's say you have an item like...
And you you are modding an item, that, when applied to an armor, increases the strength of the armor and also the mass. (If you're wondering why an item would do that, think of welding extra armor plates on top of existing ones.)
Now... you could go and make a new armor, itEnhancedTitaniumPlate, as some have suggested, and swap the old armor for new when you execute the enhancement, but this method isn't going to work very well, as you want this enhancement to work for all armors, and duplicating all armors would be ridiculous and bad coding in the extreme. (And it would fail when new armors are added, anyway.)
What you need is... the ability to read and write the mass of an object. Reading mass is ok: the function itmGetMass exists. However, writing is problematic. There's no itmSetMass function.
But maybe there's another way... maybe there is a general function for reading any basic XML-set attribute of an item (like mass="1500" in the code above), and another function for writing them... which would be plausible since having dozens of itmGetX and itmSetX functions can get cumbersome, and having to make a new one for every new XML attribute can be tedius. (Encapsulation issues aside...) Of course, the possibility of these functions existing at all would depend on how the XML attributes are stored in the Transcendence program itself.
Now, on the surface, it looks like objGetData and objGetGlobalData might do this, but, as I said before and as everyone reading this thread should know by now, they only work for "data" set with objSetData and objSetGlobalData.
So there you have it.
Ok, so when descriptions fail, examples may illuminate.
Let's say you have an item like...
Code: Select all
<ItemType UNID="&itTitaniumPlate;"
name= "segment of titanium armor"
level= "1"
value= "50"
frequency= "uncommon"
numberAppearing= "1d4"
mass= "1500"
...
Now... you could go and make a new armor, itEnhancedTitaniumPlate, as some have suggested, and swap the old armor for new when you execute the enhancement, but this method isn't going to work very well, as you want this enhancement to work for all armors, and duplicating all armors would be ridiculous and bad coding in the extreme. (And it would fail when new armors are added, anyway.)
What you need is... the ability to read and write the mass of an object. Reading mass is ok: the function itmGetMass exists. However, writing is problematic. There's no itmSetMass function.
But maybe there's another way... maybe there is a general function for reading any basic XML-set attribute of an item (like mass="1500" in the code above), and another function for writing them... which would be plausible since having dozens of itmGetX and itmSetX functions can get cumbersome, and having to make a new one for every new XML attribute can be tedius. (Encapsulation issues aside...) Of course, the possibility of these functions existing at all would depend on how the XML attributes are stored in the Transcendence program itself.
Now, on the surface, it looks like objGetData and objGetGlobalData might do this, but, as I said before and as everyone reading this thread should know by now, they only work for "data" set with objSetData and objSetGlobalData.
So there you have it.
~
[Grabs a box of batteries.] The power is mine! MINE! Ah hahaha! AHHHH HAHAHA!
[Grabs a box of batteries.] The power is mine! MINE! Ah hahaha! AHHHH HAHAHA!
- Betelgeuse
- Fleet Officer
- Posts: 1920
- Joined: Sun Mar 05, 2006 6:31 am
those and similar types of functions need to be made by George. (I should make a new mod wants thread)
Crying is not a proper retort!
I'd like to see that thread. I bet putting all the new feature requests in one place will drive George nuts, and then the next version of Transcendence will involve flying a clown ship around planets made of cheese. 

~
[Grabs a box of batteries.] The power is mine! MINE! Ah hahaha! AHHHH HAHAHA!
[Grabs a box of batteries.] The power is mine! MINE! Ah hahaha! AHHHH HAHAHA!
As I have said before, people want getters and setters, but getters and setters are considered to be poor programming when created in bulk. Specifically, setters are bad for items because they screw up existing code. For example, as it stands, you can count on the mass listed in the UNID to be the mass of every item created from that UNID definition. If the mass is variable, you would have to determine the mass of any instance of that item before making a determination. Armor X has mass Y in the xml, therefore the system only needs to check one item to determine if you can hold six pieces of it in your hold. If George implements (itmSetMass ...) all functions that use the above logic would break.
Ok... here's a long and logical post that should of interest to everyone who's into programming and confusing to everyone who's not:
Worrying about style over effectiveness or efficiency is just... getting your priorities mixed up. When it comes to programming style, ask yourself: "Does this help me do what needs to be done with the least amount of wasted effort?" (Or a similar question of that nature.) I've spent alot of time in the past worrying about programming style, determining what style to use, and switching between different styles... until I realized: Style only matters if it helps you be an effective programmer. (Or makes the code look good... if you're into that, which I am.) Any style that is irrelevant (like big-endian vs. little-endian, aka opening your eggs from the big end or the little end), is pointless and not worth worrying about. And any style that gets in the way of productivity and/or effectiveness is bad and needs to be tossed out or modified. Theoretical dogma be dammed! As Bruce Lee said about style: "Absorb what is useful; discard what is not; add what is uniquely your own."
There are lots of theories of style set down without regard to the big picture. For instance, Java the language was written in large part with the attitude of "my style is better then yours", which is a big reason why alot of the progrmmers I know don't like Java. Another example is the pushing of "object oriented programming uber alles" because it's "the future". Object oriented is great in alot of cases, but there are also many instances were going object oriented is silly and inefficient--cases where functional programming is better. Of course, whenever you label something as "progress" or "the future", then it's easy to claim that it must be "better" when it fact it is really DIFFERENT, having both advantages and disadvantages relative to the other ways of doing things.
Want to see a non-programming example of this? The metric system! It's just "better" then the imperial system of measurement that the US uses, right, and we all must be backwards hicks to have not completely transitioned over to it by now, right? Wrong! The metric system has both advantages and disadvantages relative to the imperial system, which is why it hasn't "taken over" yet, and probably never will. (Frankly, I want to see a new measurement system devised that is better then either one. Ponder that.)
Going back to what you said earlier...
Moving on...
Of course, this is all guesswork as neither of us knows exactly how the program is coded. One bit I've noticed about your writing style (yeah, style again): You tend to state things as certainties when they are instead "probables" and not known for sure. You don't have any more access to the source code then I do.
Anyway, it's good that you and other modders are considering the implementation difficulties of a possible new feature; something I always do before making any suggestion.
Not necessarily. Like alot of things in programming, it depends on the situation, and that bit of style is just one factor to consider. For instance (a classic example), using goto is always bad, right? Wrong! It usually is, but not always. (If you're interested why that is so and want to read some fun debates, look up why and when goto can be good.)Burzmali wrote:getters and setters are considered to be poor programming when created in bulk
Worrying about style over effectiveness or efficiency is just... getting your priorities mixed up. When it comes to programming style, ask yourself: "Does this help me do what needs to be done with the least amount of wasted effort?" (Or a similar question of that nature.) I've spent alot of time in the past worrying about programming style, determining what style to use, and switching between different styles... until I realized: Style only matters if it helps you be an effective programmer. (Or makes the code look good... if you're into that, which I am.) Any style that is irrelevant (like big-endian vs. little-endian, aka opening your eggs from the big end or the little end), is pointless and not worth worrying about. And any style that gets in the way of productivity and/or effectiveness is bad and needs to be tossed out or modified. Theoretical dogma be dammed! As Bruce Lee said about style: "Absorb what is useful; discard what is not; add what is uniquely your own."
There are lots of theories of style set down without regard to the big picture. For instance, Java the language was written in large part with the attitude of "my style is better then yours", which is a big reason why alot of the progrmmers I know don't like Java. Another example is the pushing of "object oriented programming uber alles" because it's "the future". Object oriented is great in alot of cases, but there are also many instances were going object oriented is silly and inefficient--cases where functional programming is better. Of course, whenever you label something as "progress" or "the future", then it's easy to claim that it must be "better" when it fact it is really DIFFERENT, having both advantages and disadvantages relative to the other ways of doing things.
Want to see a non-programming example of this? The metric system! It's just "better" then the imperial system of measurement that the US uses, right, and we all must be backwards hicks to have not completely transitioned over to it by now, right? Wrong! The metric system has both advantages and disadvantages relative to the imperial system, which is why it hasn't "taken over" yet, and probably never will. (Frankly, I want to see a new measurement system devised that is better then either one. Ponder that.)
Going back to what you said earlier...
I think you've got it backwards; the whole point of having get and set methods is to KEEP encapsulation. For example: having objSetX rather then using obj.X = "funstuff", because using getters and setters lets you change how the data is stored in that object without changing the surrounding code.riddling your code with getters and setters pretty much ruins any encapsulation you might have.
Moving on...
Not necessarily. In many cases, the program can continue to do what it currently does now, which is: Treat each item modification as a seperate stack of items. (Especially if you treat variable mass as a type of item modification.) So, if you had six pieces of armor, all with different masses, you'd see six different armor listings in your hold, just as if you had put six different armor coatings on the same armor type.If the mass is variable, you would have to determine the mass of any instance of that item before making a determination. Armor X has mass Y in the xml, therefore the system only needs to check one item to determine if you can hold six pieces of it in your hold. If George implements (itmSetMass ...) all functions that use the above logic would break.
Of course, this is all guesswork as neither of us knows exactly how the program is coded. One bit I've noticed about your writing style (yeah, style again): You tend to state things as certainties when they are instead "probables" and not known for sure. You don't have any more access to the source code then I do.
Anyway, it's good that you and other modders are considering the implementation difficulties of a possible new feature; something I always do before making any suggestion.
~
[Grabs a box of batteries.] The power is mine! MINE! Ah hahaha! AHHHH HAHAHA!
[Grabs a box of batteries.] The power is mine! MINE! Ah hahaha! AHHHH HAHAHA!
Well, if you are that confused on encapsulation, then I'm glad that you didn't give a lengthy response, as it would have been a waste of time to have to respond to it.
Anyway, just look up encapsulation in any reputable online or offline source to confirm what I said.
And for what it's worth, you do seem to be a good modder, and I usually find your comments in the various threads useful, though your overconfidence in what you think you know can get annoying at times.
Anyway, just look up encapsulation in any reputable online or offline source to confirm what I said.
And for what it's worth, you do seem to be a good modder, and I usually find your comments in the various threads useful, though your overconfidence in what you think you know can get annoying at times.
~
[Grabs a box of batteries.] The power is mine! MINE! Ah hahaha! AHHHH HAHAHA!
[Grabs a box of batteries.] The power is mine! MINE! Ah hahaha! AHHHH HAHAHA!