15 Feb, 2011, Tyche wrote in the 41st comment:
Votes: 0
array
15 Feb, 2011, sankoachaea wrote in the 42nd comment:
Kayle said:
Why? There are ships without weapons (or weapon slots)..These components aren't attached TO a Ship, they ARE a ship. I had already looked at equipment handling and it didn't apply.
Kayle said:
Forward in the data-structure, or forward on the list of ship slots? It seems like you're thinking about implementing a very inflexible data-structure where position 1 in the structure = position 1 on the ship. Why not go for position 1 in the structure = a-weapon/and-it's-position-on-the-ship? This is what I was getting at when I suggested a multimap with lists (though DH seems to think that's 'unusual').
I'm looking for a an appropriate structure that won't re-arrange the items inside it because one of them is removed. A vector, as was originally suggested, will move all elements forward to fill in the gaps of the removed element. This won't work in my situation, because removing a weapon from Slot 1, does not make Slot 2 slide to fill in Slot 1.
15 Feb, 2011, Kayle wrote in the 43rd comment:
sankoachaea said:
Kayle said:
Why? There are ships without weapons (or weapon slots)..These components aren't attached TO a Ship, they ARE a ship. I had already looked at equipment handling and it didn't apply.
And there can be in this system I'm writing, but the ship itself is just a collection of components, not a body. Besides, this is moot. If mirroring how Equipment is handled would have worked, I wouldn't have bothered to ask here, I would have just done it.
sankoachaea said:
Kayle said:
Forward in the data-structure, or forward on the list of ship slots? It seems like you're thinking about implementing a very inflexible data-structure where position 1 in the structure = position 1 on the ship. Why not go for position 1 in the structure = a-weapon/and-it's-position-on-the-ship? This is what I was getting at when I suggested a multimap with lists (though DH seems to think that's 'unusual').I'm looking for a an appropriate structure that won't re-arrange the items inside it because one of them is removed. A vector, as was originally suggested, will move all elements forward to fill in the gaps of the removed element. This won't work in my situation, because removing a weapon from Slot 1, does not make Slot 2 slide to fill in Slot 1.
This is why I asked. I don't know the STL very well, I don't know what each of the containers is useful for, which is why I started this topic to begin with. If I'm using a Map, or something to track the parts, I want to be able to tell which slot that weapon is without having to check ANOTHER field. I'd like as much as possible for it to be consolidated into as few fields as possible. If I can use a std::map to track Weapon to Slot, fine, I'll use that. If I need to use a Multimap to accomplish that, so be it. That's what I'm trying to find out. That's the whole point of this thread, to find the optimal solution to this issue. Not to be treated like a sub-par programmer who doesn't know the codebase he maintains well enough to know what stock setups do and don't work for what he's trying to do.
15 Feb, 2011, sankoachaea wrote in the 44th comment:
No one is treating you like a sub-par programmer. If you have specific needs regarding the implementation and the interface to it (i.e. "I want to be able to tell which slot that weapon is without having to check ANOTHER field. I'd like as much as possible for it to be consolidated into as few fields as possible") then you should make those known when you ask. If you're not being clear about those things from the beginning, you shouldn't be mad at people for trying to get a better understanding of what it is you need – especially when the premise of your post is, "I don't know what I need to use here."
In light of everything you've offered, I'd say a Lua table is the optimal structure for this situation. :smirk:
In light of everything you've offered, I'd say a Lua table is the optimal structure for this situation. :smirk:
15 Feb, 2011, plamzi wrote in the 45th comment:
Maybe the analogy to equipment slots is too simplistic. Maybe you should mimic the player structure itself, which can have top-level properties (type) as well as a nested assoc. array/map of equipment (or in your case, weapon slots). Maybe your ships are basically a kind of NPC.
If you need to access the weapon slots by name as well as number, the most language-agnostic approach is I think to have a numbered array of weapon names corresponding to keys in the assoc. array of weapons. So, for Ship Type A, you can have a weapon_slots = "0->Laser Canon 1; 1->Laser Canon 2; 2->Ion Gun". Then ship->weapons[weapon_slots[1]] will return a reference to Laser Canon 1, and ship->weapons['Laser Canon 1'] will return same by name. Removing or adding a weapon from weapons will not affect the weapon_slots array, which is preset depending on ship type and only holds the keys to accessing weapons by number.
If you need to access the weapon slots by name as well as number, the most language-agnostic approach is I think to have a numbered array of weapon names corresponding to keys in the assoc. array of weapons. So, for Ship Type A, you can have a weapon_slots = "0->Laser Canon 1; 1->Laser Canon 2; 2->Ion Gun". Then ship->weapons[weapon_slots[1]] will return a reference to Laser Canon 1, and ship->weapons['Laser Canon 1'] will return same by name. Removing or adding a weapon from weapons will not affect the weapon_slots array, which is preset depending on ship type and only holds the keys to accessing weapons by number.
15 Feb, 2011, David Haley wrote in the 46th comment:
Whether or not Kayle should have dismissed Kiasyn's post, Kiasyn has deleted posts made by other users with similarly empty and vacuous content. So it's a little inappropriate for Kiasyn to make such a post himself, after deleting similar ones by others.
15 Feb, 2011, sankoachaea wrote in the 47th comment:
David Haley said:
Whether or not Kayle should have dismissed Kiasyn's post, Kiasyn has deleted posts made by other users with similarly empty and vacuous content. So it's a little inappropriate for Kiasyn to make such a post himself, after deleting similar ones by others.
Sure, sure.. I don't want to get into Mudbyte's drama when we could focus on helping Kayle discover a solution to his engineering problem. Like Plamzi, I was thinking there was more to be had from investigating the player inventory than Kayle acknowledged. No, copying player inventory code verbatim is not going to yield the desired result but borrowing the 'paradigm' or 'concept' might allow you to determine what kind of structure will be required.
15 Feb, 2011, Kayle wrote in the 48th comment:
Player Inventory and Equipment is just a Linked List. With a flag that gets set on an item if it's being worn. Nothing fancy, and nothing helpful.
15 Feb, 2011, sankoachaea wrote in the 49th comment:
plamzi said:
Maybe the analogy to equipment slots is too simplistic. Maybe you should mimic the player structure itself, which can have top-level properties (type) as well as a nested assoc. array/map of equipment (or in your case, weapon slots). Maybe your ships are basically a kind of NPC.
Oooo, so helpful it is almost fancy.
15 Feb, 2011, kiasyn wrote in the 50th comment:
Kayle said:
So after re-reading this, what I picked up is that there are several ways to do what I'm attempting to do and that without more specifics, a proper recommendation can't be made. So here goes. Specifics.
In the system in question, players will be able to swap out any number of core components of their ships with better ones that the salvage, create, or buy. Now for everything but weapons this is easy, because you can only have one of each of them. You can only have one reactor, one hyperdrive, etc. But with weapons, it depends on the ship frame that you're using. Returning to prior examples:
The X-Wing would have 4 weapon slots, while an A-Wing would only have 2 weapon slots. (These slots are only laser weaponry, Launchers and Counter Measures have their own component types and slots.)
So, Player A owns an X-Wing with 2 Ariake Technology RX-347T Laser Cannons, and 2 CEC TR-213 Ion Cannons. Now, he salvages another Laser Cannon from a recent space engagement and decides to replace one of his existing ones. So he lands his ship at a Shipyard, and set about his work of removing one of the Ariake Technology RX-347T Laser Cannons with the new Raybark T-16X Modulating Laser Cannon. Now, logically, if he removed one of the prior weapons, the new one would be installed in it's place. They wouldn't magically re-arrange themselves because one of them came off. So if the Ariake guns were in Weapon Slots 1 and 2, and he removed the one in weapon slot 1, the new gun should go right back into Slot 1. So the slots should look like this:
Before:
Slot 1 - Ariake Technology RX-347T Laser Cannons
Slot 2 - Ariake Technology RX-347T Laser Cannons
Slot 3 - CEC TR-213 Ion Cannons
Slot 4 - CEC TR-213 Ion Cannons
After Swap:
Slot 1 - Raybark T-16X Modulating Laser Cannon
Slot 2 - Ariake Technology RX-347T Laser Cannons
Slot 3 - CEC TR-213 Ion Cannons
Slot 4 - CEC TR-213 Ion Cannons
Hopefully, that clears up that part of things. The second thing I need to be able to do is to track pairings of weapons for linked fire situations. Continuing with Player A's ship as the example. He sets the Laser weapons up as Weapon Group 1 (WG1), and the Ion weapons as Weapon Group 2 (WG2). Now in combat, if he's looking to disable his opponent instead of kill them, he can set fire mode to WG2, and just fire the Ions. Or if he needs to destroy them, set fire mode to WG1 and destroy them. Or if he just doesn't care set fire mode to full, and fire all four weapons. The groupings don't necessarily need to be handled in the same field as the actual weapon slots, they can be a second field, even say a map to hold the slots the weapons are in, and then a multimap to hold the groupings, or something. I don't really know. Hence my starting this thread.
Hopefully this helps to get a clear recommendation on how to get these set up.
In the system in question, players will be able to swap out any number of core components of their ships with better ones that the salvage, create, or buy. Now for everything but weapons this is easy, because you can only have one of each of them. You can only have one reactor, one hyperdrive, etc. But with weapons, it depends on the ship frame that you're using. Returning to prior examples:
The X-Wing would have 4 weapon slots, while an A-Wing would only have 2 weapon slots. (These slots are only laser weaponry, Launchers and Counter Measures have their own component types and slots.)
So, Player A owns an X-Wing with 2 Ariake Technology RX-347T Laser Cannons, and 2 CEC TR-213 Ion Cannons. Now, he salvages another Laser Cannon from a recent space engagement and decides to replace one of his existing ones. So he lands his ship at a Shipyard, and set about his work of removing one of the Ariake Technology RX-347T Laser Cannons with the new Raybark T-16X Modulating Laser Cannon. Now, logically, if he removed one of the prior weapons, the new one would be installed in it's place. They wouldn't magically re-arrange themselves because one of them came off. So if the Ariake guns were in Weapon Slots 1 and 2, and he removed the one in weapon slot 1, the new gun should go right back into Slot 1. So the slots should look like this:
Before:
Slot 1 - Ariake Technology RX-347T Laser Cannons
Slot 2 - Ariake Technology RX-347T Laser Cannons
Slot 3 - CEC TR-213 Ion Cannons
Slot 4 - CEC TR-213 Ion Cannons
After Swap:
Slot 1 - Raybark T-16X Modulating Laser Cannon
Slot 2 - Ariake Technology RX-347T Laser Cannons
Slot 3 - CEC TR-213 Ion Cannons
Slot 4 - CEC TR-213 Ion Cannons
Hopefully, that clears up that part of things. The second thing I need to be able to do is to track pairings of weapons for linked fire situations. Continuing with Player A's ship as the example. He sets the Laser weapons up as Weapon Group 1 (WG1), and the Ion weapons as Weapon Group 2 (WG2). Now in combat, if he's looking to disable his opponent instead of kill them, he can set fire mode to WG2, and just fire the Ions. Or if he needs to destroy them, set fire mode to WG1 and destroy them. Or if he just doesn't care set fire mode to full, and fire all four weapons. The groupings don't necessarily need to be handled in the same field as the actual weapon slots, they can be a second field, even say a map to hold the slots the weapons are in, and then a multimap to hold the groupings, or something. I don't really know. Hence my starting this thread.
Hopefully this helps to get a clear recommendation on how to get these set up.
Kayle said:
No, it doesn't work like equipment does. If it did, I wouldn't have needed to ask how to do it.
kiasyn said:
so basically you're making EQ for ships ;) have a look at how eq works for players?
No, it doesn't work like equipment does. If it did, I wouldn't have needed to ask how to do it.
I was referring to functions like get_eq_char, rem_object, wear_object which are all very relevant as they all handle different 'parts' going into different 'slots' on a parent 'ship' while maintaining slot order.
15 Feb, 2011, plamzi wrote in the 51st comment:
Kayle said:
Player Inventory and Equipment is just a Linked List. With a flag that gets set on an item if it's being worn. Nothing fancy, and nothing helpful.
After reading Kiasyn's suggestion more closely, I saw he basically did propose that you treat ships like player/NPC-type objects so I apologize to the thread for repeating his suggestion in other words. I should have just seconded his comparison.
My proposed mirroring array, although not fancy, would allow you to access weapon slots by name and number.
I must have missed the part where fancy was a requirement, otherwise I would not have wasted my time thinking through this because fancy is one thing I don't do. Also, given the treatment you gave to some suggestions given here in earnest, I'm beginning to think that the only person who can help you is you. Don't take that the wrong way–sometimes it's helpful to post a question just so you can think it through yourself and come up with what you think is best/fanciest.
15 Feb, 2011, Kayle wrote in the 52nd comment:
I should have just left the topic dead, it was more helpful that way.
15 Feb, 2011, Runter wrote in the 53rd comment:
Fwiw, I don't think it's useful to point at unspecified equipment systems as best practices for design with the STL, either. And if you're going to do that it probably is best not to make it a driveby comment without any context at all. I don't think there was even mention of which equipment system would be useful to look at.
15 Feb, 2011, jurdendurden wrote in the 54th comment:
I'm going to have to agree with the previous people talking about mirroring the char_data structure and just modifying it a tad. Basically, make a ship_data, struct, put a ship_type integer variable in it, make a table of each type of ship, with max # of weapons, max_Weight, max_speed, whatever, then you could just pull any data you needed from that. So, your ship_data struct may have WAY more variables than you may use for each ship, but you can then match each variable with whatever type of ship it is in your ship_table. From there you can just set up some sort of event system for removing the weapons and replacing them. The function for this would just refer to the table to see which sort of slots the ship has for weapons, how many it can have, and what stock weapons it comes with. For your mapping problems, just use an array like Tyche said….
If (ship->weapons[0] != NULL && ship->weapons[0].removeable == TRUE && etc etc etc)
{
ship->weapons[0] == NULL;
ship->weapons[0] = the_new_weapon;
return;
}
16 Feb, 2011, Kayle wrote in the 55th comment:
I'm not trying to get help writing the system. I've got that well under control.
I'm trying to get help picking a data type for ONE field in an already mostly written system. The examples given were to demonstrate what the system does and will be doing, so that you all had information to help point me towards an appropriate data type. One that is preferably STL because I hate redesigning the wheel. It doesn't matter how many of you say to copy character data, this doesn't work with the rest of the already written system, and I'm not rewriting months of work, just because you people think it's a good solution.
I'm looking for a data type. Not suggestions on how to write what I've already mostly written.
I'm trying to get help picking a data type for ONE field in an already mostly written system. The examples given were to demonstrate what the system does and will be doing, so that you all had information to help point me towards an appropriate data type. One that is preferably STL because I hate redesigning the wheel. It doesn't matter how many of you say to copy character data, this doesn't work with the rest of the already written system, and I'm not rewriting months of work, just because you people think it's a good solution.
I'm looking for a data type. Not suggestions on how to write what I've already mostly written.
16 Feb, 2011, plamzi wrote in the 56th comment:
Kayle said:
I'm not trying to get help writing the system. I've got that well under control.
I'm trying to get help picking a data type for ONE field in an already mostly written system… I'm looking for a data type. Not suggestions on how to write what I've already mostly written.
I'm trying to get help picking a data type for ONE field in an already mostly written system… I'm looking for a data type. Not suggestions on how to write what I've already mostly written.
You may be looking in the wrong place. Try the documentation for your language of choice.
And, if you find a single data type that allows accessing individual items by both name and number, i. e. is both positional and labeled, let me know–that would tickle my fancy.
Also, feel free to ignore this advice and post at length here about why you are ignoring it.
16 Feb, 2011, sankoachaea wrote in the 57th comment:
If you've already written most of the system then your mostly written system should be pointing you to the logical data type. You could share the specific code you're dealing with to give us a clearer idea of what's going on. That seems to work well on programming forums, probably better than describing what the code does for the player.
QFT
plamzi said:
…
QFT
Random Picks
