Snippet Sunday #3: It's not a damn database!

Page: 1 2 3 4
Jul 20 2014, 6:59 am
Or is it really all about robustness and whatnot?

It's really the latter moreso than the former. My approach actually has a minor performance hit, but it's so minor there's no point counting it.
Jul 20 2014, 11:42 am
In response to Ter13
Ter13 wrote:
You've yet to clarify what hoops those are.

1. You can only inherit/override vars, not methods, with your inheritance model. Also, I'd guess that any property used in your model has to be defined for all object types (otherwise the compiler may complain about undefined variable references).

2. You can't easily place item instances on the map. Sort of related to this, inherited properties (like icon and icon_state) aren't available at compile time.

3. The code is messier. Writing out 100 object definitions in your item_database would make it terribly difficult to figure out what inherits from what. DM's syntax for defining object types is easy to use and the indentation mirrors the object hierarchy (the IDE also shows the hierarchy in a tree view).

4. Using inheritance for all differences in behavior, like I showed in my last comment, means you will quickly run into cases where you want one object to inherit two different kinds of behavior but can't. You're reserving object types and inheritance for one specific thing and it's not always good for that.
Jul 20 2014, 11:47 am (Edited on Jul 20 2014, 11:55 am)
You can only inherit/override vars, not methods, with your inheritance model. Also, I'd guess that any property used in your model has to be defined for all object types (otherwise the compiler may complain about undefined variable references).

This is a non-issue, as my inheritance model allows the use of subtypes for the inclusion of methods in the variation.

You can't easily place item instances on the map. Sort of related to this, inherited properties (like icon and icon_state) aren't available at compile time.

This is not true.

The code is messier.

This is matter of opinion.

Using inheritance for all differences in behavior, like I showed in my last comment, means you will quickly run into cases where you want one object to inherit two different kinds of behavior but can't.

Are you seriously making the argument that doing something is bad because it commits you to that thing?

Without my approach multi-inheritance won't work either.

You're reserving object types and inheritance for one specific thing and it's not always good for that.

What? Are you high? Changes in structure or behavior are what inheritance is for. It's exclusively what it is for. You can't argue that inheritance is bad for changes in behavior or structure in any paralell universe, much less the one we happen to inhabit.

None of your arguments have any substance.
Jul 20 2014, 2:08 pm
In response to Ter13
On some level everything is a matter of opinion, just like it's my opinion that white-on-white isn't a good color scheme for your IDE. It's still possible to see pros and cons of different approaches. You still haven't explained the pros to using your kind of inheritace or the cons to not using it - can you give an example? You're assuming that people accept the "types are for behavior differences ONLY" statement as truth - if that's such an absolute truth it should be easy for you to explain the problems I'd run into if I used inheritance for something else. Saying over and over again that something is wrong isn't the same as explaining why it's wrong.

Ter13 wrote:
You can only inherit/override vars, not methods, with your inheritance model. Also, I'd guess that any property used in your model has to be defined for all object types (otherwise the compiler may complain about undefined variable references).

This is a non-issue, as my inheritance model allows the use of subtypes for the inclusion of methods in the variation.

What about the need to define variables for all types to appease the compiler? It seems like you'd have to have an odd mix of still defining object types but then not using them and putting all of the data somewhere else. Having a working example might help to make it more clear how confusing this is or isn't.

You can't easily place item instances on the map. Sort of related to this, inherited properties (like icon and icon_state) aren't available at compile time.

This is not true.

So if I use your method and define a "sword" item whose icon_state is stored in your item_database list, how do I place this object on the map and see it with the proper icon state? By writing code like this:

obj/item/weapon/sword
    icon_state = "sword"

I can place a sword on the map with one click and it has all the right values. What does this process look like if I'm using your method? I'm guessing you'd have to manually edit the object instance's icon_state if you want to see the correct image, which means you'd have to know which icon_state exactly the object will inherit and hope that never changes.

Now I'm also getting skeptical about performance. I thought BYOND optimized memory usage by having defined object types as "prototypes" so only needed to store values that differ from the prototype. If you've got a thousand instances of /turf/grass with the icon_state "grass", it doesn't allocate memory for a thousand strings because they all have the same icon_state that was defined at compile time. If one of their icon states changed at runtime it'd have to store that. I'm not sure of this at all, but I suspect that your soft-inheritance might not perform as well because BYOND can't make certain assumptions and optimizations.

Are you seriously making the argument that doing something is bad because it commits you to that thing?

Yes. You're saying that inheritance should be reserved for differences in behavior only. It's a problem to commit to using inheritance for one thing because that one thing isn't always sufficient. When you run into a case where your behavioral differences between types can't be modeled with DM's single inheritance, because (according to your approach) inheritance has to be used for behavioral differences, you'd end up not using inheritance at all - something about that seems silly.

Here's an example. Suppose you've got turfs that can make the player move (e.g. conveyor belts) and turfs that hurt the player. That might look something like this:

turf
    movement
        var
            speed = 0
        
        conveyor_belt
        flowing_water
    
    damage
        var
            damage = 0
        
        lava
        poison

But then you want to make flowing lava, a tile that moves the player and hurts them. It can't be a child of both, so you've got to do something like this:

turf
    var
        movement_speed = 0
        damage = 0
    
    Entered(mob/m)
        ..()
        
        if(src.damage)
            // deal damage to the player.
        
        if(src.movement_speed)
            // handle the movement.

Everything ends up being implemented on your base /turf object and you use properties to manage everything. This means the only way your turf types can be different is by having different property values, which, according to your post means you shouldn't define any subtypes of /turf. We end up not being able to use inheritance at all because we've reserved it for something that it's not sufficient for.

In this case, if we're not going to use inheritance for behavior differences we could use it for something else. For example, you could group the tiles by tileset (e.g. put all swamp turfs in /turf/swamp). Or maybe you'd group turfs by what level they're used in (e.g. /turf/level1/wall).

The solution is to figure out how your object types will vary and decide how you can best use object types and inheritance. Sometimes this will be for key functional differences, like differentiating weapons from armor, and other times it'll be for creating weapons with particular stats.
Jul 20 2014, 2:12 pm (Edited on Jul 20 2014, 2:19 pm)
Before we continue, could you please do me a favor and in your own words, without looking it up, summarize the difference between a class and an instance?

Furthermore, I'd like to hear your explanation of what a database record is, vice a table.

I think the reason you are having such a hard time visualizing this, and why you are bringing in so many misapprehensions to argue against this approach, is that you don't really understand at a fundamental level what these four things are.
Jul 21 2014, 11:58 am
Omg i love argument/discussions like these. i learn so much.

*pops popcorn*
Jul 22 2014, 2:46 pm
Snippet sunday #4 will be delayed until sunday for reasons.
Jul 23 2014, 5:41 am
Me too. I'll continue my bad habits because I look up to forum account. But Ile Ters too but I like to see my weapons on the map.


Btw, popcorn microwave gives you cancer the smell gives you cancer
Jul 23 2014, 11:34 am
In response to I2edSmok3
I2edSmok3 wrote:
I like to see my weapons on the map.


Who started this myth about not being able to see items that you place on the map......... ON the map??? Wouldn't the map editor be horribly broken if you couldn't see the map itself? Wouldn't we all have run to Tom's door with pitchforks and torches chanting "make lummox fix it" if we COULDN'T SEE THE ITEM WE JUST PLACED?!

Jul 23 2014, 12:16 pm (Edited on Jul 23 2014, 12:24 pm)
Magicsofa: If you do decide to read the actual snippet, you'd see that the specific icon_state is not defined in its own object for the individual instance of that object.
Instead, you create it at runtime using an ID. The direct example is here:

var
    list/item_database = list(
        ITEM_SWORD = new/item_prototype(ITEM_SWORD,/obj/item/equipment/weapon,list(weapon_type="sword",icon='sword.dmi',min_dmg=4,max_dmg=8)),
        ITEM_SPEAR = new/item_prototype(ITEM_SPEAR,/obj/item/equipment/weapon,list(weapon_type="spear",icon='spear.dmi',min_dmg=6,max_dmg=12,hands=2),
        ITEM_SHIELD = new/item_prototype(ITEM_SHIELD,/obj/item/equipment/shield,list(icon='shield.dmi',defense=10),
        ITEM_POTION = new/item_prototype(ITEM_POTION,/obj/item/consumable/health_potion,list(icon='hp_pot.dmi',restore=25))


Because of that, if you use the map editor, it will end up being the icon and icon_state of the base that you're using for that item, as opposed to the item itself. That being: A shield or a sword will end up, on the map, having the icon_state of /obj/item/equipment/weapon.

I think I would make use of this system on occasion, and I fully intend to do so. It has its pros and cons. That said...

I wouldn't attribute it with the same seriousness to use as:


"This is going to be a big "stop it now" post." - Ter13


Because of the fact that byond allows the other method easily, and for most, the differences aren't really major at all. In fact, the convenience of the other method makes it very viable.

I think the best way to handle using it and the map editor is to perhaps create spawners (which many games already have) that specifically spawn items for you, and place those on the map. The benefit is that you are able to easily choose what spawns out of it (and you can have it choose from multiple, like a list!), it can be modified during runtime to allow you to change what's spawning or even disable the spawning, and.. well, everything that comes with having behavior that can change.

I do really appreciate this snippet. I'll likely make use of it at some points and others, but it does have its drawbacks. Anyway. I think that's it.
Jul 23 2014, 12:22 pm
Because of that, if you use the map editor, it will end up being the icon and icon_state of the base that you're using for that item, as opposed to the item itself. That being: A shield or a sword will end up, on the map, having the icon_state of /obj/item/equipment/weapon.

If you aren't assigning the icon/icon_state in the instance editor alongside the item id and modified type list, you really shouldn't be complaining about the graphic being incorrect.

Like I said to Forum_Account, it's a non-issue, because it relies on you feeding the instance incomplete/incorrect data.
Jul 23 2014, 12:23 pm
I do have a quick question about the instance editor:


Does editing an instance in it edit all instances like that already on the map?
Jul 23 2014, 12:25 pm
In response to Decius Reln
Decius Reln wrote:
I do have a quick question about the instance editor:


Does editing an instance in it edit all instances like that already on the map?

(This would be the deciding factor for me in DM.)

There are two ways to edit an instance. You can edit a specific instance by right clicking on that instance on the map and selecting "Edit...", or you can select the instance on the map, and select "make active". Afterwards, you can right click on the instance in the object panel and select "Edit...", which will allow you to edit all instances of that type.

In other words, yes, you can edit all instances of a type, and you can also edit a specific instance of a type (potentially creating a new instance) as well.
Jul 23 2014, 12:26 pm (Edited on Jul 23 2014, 1:11 pm)
Ah. That completely alleviates my concern. Thank you for that.

I'd have a suggestion for next week:

Interface designing and construction.

Alternatively: Configuration files-- How and when to use them.
Jul 23 2014, 6:07 pm
In response to Decius Reln
Decius Reln wrote:
Because of that, if you use the map editor, it will end up being the icon and icon_state of the base that you're using for that item, as opposed to the item itself.

Wait hold on one second...isn't this whole example irrelevant? You showed me a list of items, and then you told me that if I used the map editor ...to what? Place the items in the list? Did you accidentally click on show all nodes?

If you do decide to read the actual snippet

Just because you read something, doesn't mean you understand it.
Jul 23 2014, 6:18 pm (Edited on Jul 23 2014, 6:35 pm)
If you use the map editor to place any items, it places the base item. The way to get around that is to use instances in it, which-- Actually is explained in the second snippet.

Now, with more info, it's irrelevant-- There is an easy way to handle it. You have to do more in order to get it to be visible on the map, but you'd still have to do more.

Anyway: More constructively, what might you like to see in the next Snippet Sunday? Ter asked for suggestions, and very few suggestions have been given.


Edit: I now actually have this implemented in my own project. And it's actually already giving me ideas for more possibilities. Yay!
Jul 24 2014, 12:42 am
In response to Decius Reln
Decius Reln wrote:
Ah. That completely alleviates my concern. Thank you for that.

I'd have a suggestion for next week:

Interface designing and construction.

Alternatively: Configuration files-- How and when to use them.

I second these examples, Especially the Configuration files one.
Jul 24 2014, 12:50 am
In response to D-Cire
D-Cire wrote:
Decius Reln wrote:
Ah. That completely alleviates my concern. Thank you for that.

I'd have a suggestion for next week:

Interface designing and construction.

Alternatively: Configuration files-- How and when to use them.

I second these examples, Especially the Configuration files one.

++
Jul 24 2014, 2:14 am
In response to Decius Reln
Decius Reln wrote:
If you use the map editor to place any items

THOSE ITEMS ARE NOT GOING TO BE LIST ELEMENTS. Or any other vars for that matter! Just think about what you are doing - you type "var/mysword = whatever", then you go to the map and place an /obj/sword. Does the obj/sword have anything to do with var/mysword? NO! The only way to see var/mysword in the object tree is to click on "show all nodes" and even then you cannot place it on the map at all. The piece of code that you showed me would be used for creating items dynamically, not for painting them on the map!

I don't know how you manage to write working code when you fail to see the logical disconnect in your example. You are complaining about something that is not even possible. Furthermore, the later explanation that you weaseled your way into was that it takes more work to use the instance editor than it does to write out a new subtype. This is just silly. Either you type "damage = 10; hands = 2" or you go into the instance editor, click on "damage", type "10", click on "hands", type "2"... how is that more work? It is a lot less typing in some cases, so it might be less work after all.

Sorry I'm getting all worked up, I just find it astonishing when people get this high-and-mighty attitude ("if you decide to read the actual snippet") when really they don't know what they are talking about. I feel that this is a time to study closely and to nod and say "thank you Ter13" like a good BYOND student. Forum_account is an experienced DM programmer and his little devil's advocate routine got swiftly shut down because his arguments were basically "I have always done it this way and I don't want to stop."

Anyway: More constructively, what might you like to see in the next Snippet Sunday? Ter asked for suggestions, and very few suggestions have been given.

I'm not really sure. Maybe when I get back from work I will have thought of something..
Jul 24 2014, 9:57 am (Edited on Jul 24 2014, 10:06 am)
MagicSofa: I think you misunderstood what I meant. I meant placing the base that you're using--

Like /obj/item/weapon

Likewise, the complaint is already... dealt with. As noted here:


Decius Reln:

Ah. That completely alleviates my concern. Thank you for that.



Likewise, I said it was more work-- Not a lot more work. The main thing would be people being unused to it, to be honest-- I'm perfectly willing to do it, for example. In fact, I just did a moment ago.

I also confess that I misunderstood what you meant, too, though. I see now that the part that should've tipped me off was here: "Did you accidentally click on show all nodes?"

"If you decide to read the actual snippet" <-- That was inappropriate however, and I appreciate you pointing it out. I'll not be so rude in the future.
Page: 1 2 3 4