Jump to content
XCOMUFO & Xenocide

Item.xml


Zombie

Recommended Posts

I believe this has been done to make things a bit easier for the translation.  That is, the identifier strings such as "ITEM_XENIUM-122" will be translated into the actual strings that will be shown to users.  (This is currently done by lookup in english.xml) By using the ITEM prefix, we get two advantages.

1. strings that have not been converted are more obvious,

2. it's easier to know what the string is.

With translation, you mean game support for more than English?

I'm looking at Graphics.xml. I'm seeing how various elements with the tag

"graphic name" are prefixed with either "FAC_" and "XNET_"

 

I think I understand the intention, that is its a DATA_INDEX but its being mixed in with actual DATA?

 

I think this might be better to consider... for example, in the graphics.xml

file, the graphic name is the object's INDEX.

 

 

Where "mesh_type" is an index to the different types of mesh objects, yes?

and "RESEARCH_FACILITY" is an index to a specific graphic mesh.

For display purposes, the index "RESEARCH_FACILITY" translates into

"Research Facility" for English game play .... and actually "RESEARCH_FACILITY"

could just be a number but its enumerated to "RESEARCH_FACILITY"...

for easy reading.

 

My n00b $0.02, just trying to understand the history....

:)

thanks...

Kelargo

Link to comment
Share on other sites

  • Replies 147
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Edit: nope, according to the XDD Items Configuration document, range is defined as this:
3.1. Weapon Actions

3.1.1.

This allows the weapon to fire a single, vaguely accurate round.  Usually faster than an , but slower than

 

Contains:

  How far the shot will travel accurately

  How likely the shot is to hit the target

  How many time units this action will cost

So by conventional definitions range is commonly referred to as "drift". :)

Just to recap here: range in item.xml refers to shot accuracy per max distance.

 

So my question is now: "Who would know anything about how these values were assigned"? SupSuper perhaps? :wink1:

 

- Zombie

We'll based on this thread:

http://www.xcomufo.com/forums/index.php?sh...408&hl=item.xsd

 

I'd try:

Cpt. Boxershorts

centurion,

guyver6,

captainmikey (who hasn't been seen for nearly 2 months)

Red Knight

 

In that order.

Link to comment
Share on other sites

I believe this has been done to make things a bit easier for the translation.  That is, the identifier strings such as "ITEM_XENIUM-122" will be translated into the actual strings that will be shown to users.  (This is currently done by lookup in english.xml) By using the ITEM prefix, we get two advantages.

1. strings that have not been converted are more obvious,

2. it's easier to know what the string is.

With translation, you mean game support for more than English?

Correct.

 

I'm looking at Graphics.xml.  I'm seeing how various elements with the tag

"graphic name" are prefixed with either "FAC_" and  "XNET_"

 

I think I understand the intention, that is its a DATA_INDEX but its being mixed in with actual DATA?

 

I think this might be better to consider... for example, in the graphics.xml

file, the graphic name is the object's INDEX.

 

 

Where "mesh_type" is an index to the different types of mesh objects, yes?

and "RESEARCH_FACILITY" is an index to a specific graphic mesh.

For display purposes, the index "RESEARCH_FACILITY" translates into

"Research Facility" for English game play .... and actually "RESEARCH_FACILITY"

could just be a number but its enumerated to "RESEARCH_FACILITY"...

for easy reading.

 

My n00b $0.02, just trying to understand the history....

:)

thanks...

Kelargo

Actually, in this context, I think (so don't quote me) the XNET_ and FAC_ prefixes are there to keep the graphic names (indexes) distinct.

E.g. "XNET_BARRACKS_FACILITY" is the barracks image that is used by XNET, while "FAC_BARRACKS_FACILITY" is the barracks image that is used by the base view. It is concieveable (if improbable) that they might be different.

I don't see much to gain by adding a mesh type element.

Link to comment
Share on other sites

We'll based on this thread:

http://www.xcomufo.com/forums/index.php?sh...408&hl=item.xsd

 

I'd try:

Cpt. Boxershorts

centurion,

guyver6,

captainmikey (who hasn't been seen for nearly 2 months)

Red Knight

 

In that order.

Time to rally the troops then! PM's sent to those in question this afternoon (Mr Knight, you are not included). Hopefully this will be resolved soon. :)

 

- Zombie

Link to comment
Share on other sites

Edit: nope, according to the XDD Items Configuration document, range is defined as this:
3.1. Weapon Actions

3.1.1.

This allows the weapon to fire a single, vaguely accurate round.  Usually faster than an , but slower than

 

Contains:

  How far the shot will travel accurately

  How likely the shot is to hit the target

  How many time units this action will cost

So by conventional definitions range is commonly referred to as "drift". :)

Just to recap here: range in item.xml refers to shot accuracy per max distance.

 

So my question is now: "Who would know anything about how these values were assigned"? SupSuper perhaps? :wink1:

 

- Zombie

Sorry, my department is strictly UI, everything else that goes on around here is a mystery to me :P
Link to comment
Share on other sites

Sorry, my department is strictly UI, everything else that goes on around here is a mystery to me :P

Just covering all the bases, SupSuper. :D

 

From the one PM I received, it seems as though range numbers were probably arbitrarily assigned. Guess I'll flag that for future consideration. :)

 

- Zombie

Link to comment
Share on other sites

Zombie,

 

If you can send me a copy of your updated item.xml, I'll try and find some time over the weekend to update item.xsd and the item.xml parsing code in xenocide code so that it all works.

 

Please post to

 

work: davidt (at) pharos (d0t) co (d0t) nz

home: dteviot (at) iconz (d0t) co (d0t) nz

 

Thanks

Link to comment
Share on other sites

Zombie,

 

If you can send me a copy of your updated item.xml, I'll try and find some time over the weekend to update item.xsd and the item.xml parsing code in xenocide code so that it all works.

 

Please post to

 

work: davidt (at) pharos (d0t) co (d0t) nz

home: dteviot (at) iconz (d0t) co (d0t) nz

 

Thanks

No problem. Sent it to both addresses just in case. I just realized item.xml almost doubled in size since I got my grubby little hands on it. Wow. :)

 

- Zombie

Link to comment
Share on other sites

Zombie,

 

If you can send me a copy of your updated item.xml, I'll try and find some time over the weekend to update item.xsd and the item.xml parsing code in xenocide code so that it all works.

 

Please post to

 

work: davidt (at) pharos (d0t) co (d0t) nz

home: dteviot (at) iconz (d0t) co (d0t) nz

 

Thanks

No problem. Sent it to both addresses just in case. I just realized item.xml almost doubled in size since I got my grubby little hands on it. Wow. :)

 

- Zombie

Hi Zombie,

 

By any chance, did you validate your changes to item.xml with xmlspy or some other XML checker?

 

I’ve found the following issues, they’re not possible with the schema as it exists. Are they an error, or do I need to update the schema?

1. Flashpod is missing a prime element. (I’ve given it a value of 0.5)

2. You’ve got a throw element for xenium. (Commented out element)

3. Many of the alien corpses have a throw element. (Commented out element)

4. The gravity distortion launcher’s guide element has an “accuracy” element (Commented out element)

5. The damage types for the flashpod and smoke grenade don’t exist. (Commented out damage element)

6. You’ve added ITEM_ALIEN_GRENADE, which doesn’t appear to exist anywhere else. (I don’t see an XNET item for it.) (Commented out item)

7. I haven’t added HWP element type to XML, so I’ve commented out damage and firing stats. For time being.

 

Also, I’ve adjusted the “cost” element I gave you earlier. It now looks like this:

    <construct>
       <facility type="FAC_ENGINEERING_FACILITY" space="18" />
       <cost hours="1600" money="150000">
           <item type="ITEM_COMPOSITES" quantity="3" />
       </cost>
   </construct>

I made the change to make the parsing easier. It should now be possible to use common code for parsing the cost (and in future the bonus) elements out of research.xml and items.xml.

 

 

Attached is updated item.xml, item.xsd

item.zip

Link to comment
Share on other sites

I’d like to discuss the possibility of modular HWPs.

 

Currently, there are 5 models of HWP,

Tracked Cannon

Tracked Rocket

Tracked Laser.

AntiGrav GAIA

AntiGrav Plasma

 

Which gives us 2 chassis, and 4 turret designs. (3 turret designs, if we assuming that Rocket and GAIA are nearly the same thing.)

 

So, the idea is to separate HWPs into two pieces, the chassis and the turret. And the idea would be you assemble the pieces together, so on the “equip soldier” dialog you can select a chassis, and then equip it with a turret, in much the same way as you give a soldier a gun. And you load up the HWP with additional ammo, in much the same way you fill a soldier’s backpack.

 

The turrets would be weapons, just like all the rest of the soldier items, but they’d be too big, or too heavy, for soldiers to carry. As a possible enhancement, we could allow a HWP to be equipped with any weapon. (To minimise art requirements, reuse the Cannon turret for anything that’s not the usual turret weapon.)

 

Why am I making this proposal?

Please bear with me, it gets complicated.

The main reason is I’ve run into a bit of an issue with items. Currently, I don’t have an item class for HWPs, and just adding one starts making things awkward.

The first issue is that the Item classes I created (for inventory management) don’t quite match the classes defined in item.xsd. To explain, for inventory purposes, it’s very important if a weapon takes a clip or not, to the extent that there are two separate classes, one for weapons that have clips, and another for ones that don’t.

 

Which brings us to issues with HWPs.

First, as the plasma and laser HWPs have unlimited ammo, the others use clips. Thus, for inventory purposes 2 HWP classes would be needed. Instead, if the HWPs are modular, then we only need one HWP class, to represent the chassis. (Note, the HWP chassis is more like a soldier for many purposes than an item) and the turret is just another weapon item.

Second, the HWPs have different ammo capacities than soldiers. So, I proposed that the HWPs get unique clips for their weapons. (Even though the rocket and GAIA launchers are essentially the same as those used by soldiers.) This isn’t a big issue in terms of code (we just add additional clip items to the item list) but it’s a bit ugly from gameplay logistics. By separating the weapon from the chassis, we can use the same ammo for both devices. The additional magazine capacity being provided by the HWP itself.

 

Aside:

 

weaponItemType in item.xsd doesn’t distinguish between them weapons with clips and those without. (Except that it has either a damage or a clip element.)

 

This becomes an issue in the prototype factory, because when loading the items from item.xml, I need to create the c++ class to hold the item information, and I can’t use the item’s type info in item.xml to tell which class I need to create. So, the current workaround is a hardcode c++ lookup table like this:

   ADD_PROTOTYPE(ItemBaseOnly,  "ITEM_ALIEN_COMPOSITES");
   ADD_PROTOTYPE(ItemBaseOnly,  "ITEM_ALIEN_BREEDING_CHAMBER");
   ADD_PROTOTYPE(ItemBaseOnly,  "ITEM_ALIEN_MEDICAL_ROOM");
   ADD_PROTOTYPE(ItemBaseOnly,  "ITEM_BIOLOGICAL_RESEARCH_ROOM");

 

Unfortunately, this means that we can’t add a new item simply by adding an entry to item.xml. We also have to update the lookup table. This is unacceptable.

 

It should be possible to fix this by adding additional types to item.xsd. e.g. add a weaponItemTypeWithClip to item.xsd. However, to do this I’m going to have to map out the item.xsd class hierarchy, and match to the C++ item class hierarchy.

Link to comment
Share on other sites

Hi Zombie,

 

By any chance, did you validate your changes to item.xml with xmlspy or some other XML checker?

The answer to that question should be apparent by all the errors you found. I did not validate anything as I thought my job was to only to revise. Sorry. :(

 

I’ve found the following issues, they’re not possible with the schema as it exists.  Are they an error, or do I need to update the schema?

1. Flashpod is missing a prime element.  (I’ve given it a value of 0.5)

2. You’ve got a throw element for xenium. (Commented out element)

3. Many of the alien corpses have a throw element. (Commented out element)

4. The gravity distortion launcher’s guide element has an “accuracy” element (Commented out element)

5. The damage types for the flashpod and smoke grenade don’t exist. (Commented out damage element)

6. You’ve added ITEM_ALIEN_GRENADE, which doesn’t appear to exist anywhere else.  (I don’t see an XNET item for it.) (Commented out item)

7. I haven’t added HWP element type to XML, so I’ve commented out damage and firing stats.  For time being.

1. I removed the prime element from the flashpod because in the original game it worked as soon as it was thrown. I just realized that the flashpod is defined as "grenadeWeaponItemType". Technically, because it does not produce damage, the flashpod should be defined as "equipmentItemType". This should bypass the need for a prime element. :wink1:

2 & 3. Items such as xenium and alien corpses were able to be picked up (and therefore thrown) in the original game. Added that info for completeness sake, but didn't realize that element was undefined for those items.

4. As before, in UFO: EU the Blaster Launcher had an accuracy associated with it. Didn't know it was wrong to add an accuracy element even though it is a weapon.

5. Damage for smoke: In the original document there was a comment asking for the smoke grenade damage (<!-- Damage? -->) so I added it in. My mistake - I forgot to comment that out. :doh:

Flashpod damage: here again, the problem lies with the flashpod's definition. See my answer to issue 1.

6. The Alien Grenade was missing from the original item.xml so I added the entry assuming that the XNET item was already defined. Guess that was a wrong assumption.

 

[Edit: the item.xml you packaged does not seem to be a revised copy...]

 

- Zombie

Edited by Zombie
Link to comment
Share on other sites

I’d like to discuss the possibility of modular HWPs.[...]

I would love to agree on this. I always wanted to have modular HWPs. The problem is, that it changes a few things in gameplay, and we anted to have v1 just like the original UFO:EU. So my question is: would it be possible, to have everything modular as you recommend, but to force the player to use a nonmodular design? So that he only sees the equipped HWP?

If we decide to go with the modular design - that would be RK's call - AWD will have to change their models.

Edited by Mad
Link to comment
Share on other sites

Hi Zombie,

 

By any chance, did you validate your changes to item.xml with xmlspy or some other XML checker?

The answer to that question should be apparent by all the errors you found. I did not validate anything as I thought my job was to only to revise. Sorry. :(

 

That's what I thought, I was just being tactful. I think.

In future, please use an XML validator, it makes my job a lot easier. I only have to fix my mistakes. :)

You might try this one: http://jaxe.sourceforge.net

I’ve found the following issues, they’re not possible with the schema as it exists.  Are they an error, or do I need to update the schema?

1. Flashpod is missing a prime element.  (I’ve given it a value of 0.5)

2. You’ve got a throw element for xenium. (Commented out element)

3. Many of the alien corpses have a throw element. (Commented out element)

4. The gravity distortion launcher’s guide element has an “accuracy” element (Commented out element)

5. The damage types for the flashpod and smoke grenade don’t exist. (Commented out damage element)

6. You’ve added ITEM_ALIEN_GRENADE, which doesn’t appear to exist anywhere else.  (I don’t see an XNET item for it.) (Commented out item)

7. I haven’t added HWP element type to XML, so I’ve commented out damage and firing stats.  For time being.

1. I removed the prime element from the flashpod because in the original game it worked as soon as it was thrown. I just realized that the flashpod is defined as "grenadeWeaponItemType". Technically, because it does not produce damage, the flashpod should be defined as "equipmentItemType". This should bypass the need for a prime element. :wink1:

2 & 3. Items such as xenium and alien corpses were able to be picked up (and therefore thrown) in the original game. Added that info for completeness sake, but didn't realize that element was undefined for those items.

I can fix things so that they can be thrown. It requires moving the throw property "up" the tree, into troopItemType, and then updating everything to match. Just want to know if I should do that.

 

4. As before, in UFO: EU the Blaster Launcher had an accuracy associated with it. Didn't know it was wrong to add an accuracy element even though it is a weapon.

The question is, does the schema need to have accuracy added, or do we need to remove accuracy from the Blaster launcher? My guess is we need to add accuracy, but I'm not sure who to ask. Screw it, I'll just update the schema, if I'm wrong, then it can either be taken out or ignored.

 

5. Damage for smoke:  In the original document there was a comment asking for the smoke grenade damage (<!-- Damage? -->) so I added it in. My mistake - I forgot to comment that out. :doh:

Flashpod damage: here again, the problem lies with the flashpod's definition. See my answer to issue 1.

Again, I'll probably need to update the schema

 

6. The Alien Grenade was missing from the original item.xml so I added the entry assuming that the XNET item was already defined. Guess that was a wrong assumption.

Not necessarily, it's possible that we SHOULD have an alien grenade, and it's ommission was a mistake. I think we need to put it in, but I'll check with RK.

 

[Edit: the item.xml you packaged does not seem to be a revised copy...]

- Zombie

:doh: The updated file is reviseditem.xml. I'll upload it tonight when I get home.

Not a major issue, I've got to do some revisions anyway.

Link to comment
Share on other sites

In future, please use an XML validator, it makes my job a lot easier.  I only have to fix my mistakes. :)

You might try this one:  http://jaxe.sourceforge.net

Thanks, I will do that. :)

 

I can fix things so that they can be thrown.  It requires moving the throw property "up" the tree, into troopItemType, and then updating everything to match.  Just want to know if I should do that.

Are you asking me? Anyway, If we want to be able the pick up and throw those items in the battlescape, then yes, change it.

 

The question is, does the schema need to have accuracy added, or do we need to remove accuracy from the Blaster launcher?  My guess is we need to add accuracy, but I'm not sure who to ask.  Screw it, I'll just update the schema, if I'm wrong, then it can either be taken out or ignored.

Technically, it is still not understood how the 120% accuracy for the Blaster Launcher works. From the little bit of testing I did on this subject a while back, a soldier having a FA of 0 had the same probability of hitting a target than a solder with 100%. Not sure how this will play out in Xenocide, but I think you made a good choice of adding it in.

 

Not necessarily, it's possible that we SHOULD have an alien grenade, and it's ommission was a mistake.  I think we need to put it in, but I'll check with RK.

Thank you. =b

 

:doh: The updated file is reviseditem.xml.  I'll upload it tonight when I get home.

Not a major issue, I've got to do some revisions anyway.

Sorry, I probably should have mentioned I renamed item.xml to reviseditem.xml so that I still had an original copy somewhere. No rush on posting it until you update item.xsd. :)

 

- Zombie

Link to comment
Share on other sites

Hi,

 

I was looking at the bugs and old posts...

and I'm wondering how Manufacturing Dependencies are addressed?

 

In the original, Manufacturing rate is a function of Cost, Engineers, Workspace and on

occasion one or more things, such as UFO Navigation or Alien Alloys, etc.

The later is a function of Research Results from ojects collected on a sucessful mission.

 

So my simple question is how is this managed?

Is this is mapped out in some XML schema file?

If not, is this something that needs defined.

 

thanks,

kelargo

Link to comment
Share on other sites

Hi,

 

I was looking at the bugs and old posts...

and I'm wondering how Manufacturing Dependencies are addressed?

 

In the original, Manufacturing rate is a function of Cost, Engineers, Workspace and on

occasion one or more things, such as UFO Navigation or Alien Alloys, etc.

The later is a function of Research Results from ojects collected on a sucessful mission.

 

So my simple question is how is this managed?

Is this is mapped out in some XML schema file?

If not, is this something that needs defined.

 

thanks,

kelargo

I'm not exactly sure what your question is.

I assume what you're asking is something like "Items that can be manufactured have to be researched before they can be manufactured. How is this constraint encoded/enforced."

 

The answer is

1. The information is encoded in the file research.xml. Check the element. An element gives the player the ability to use an item, and make it if buildable. As regards enforcing it, I haven't written the code for manufacturing projects yet.

Link to comment
Share on other sites

Sorry for not being more clear...

 

research.xml has a little bit of what I'm talking about.

But I'm talking about more than just the ability to use an item.

I understand the code is not there yet... and that's not

what I'm talking about.

 

Below is from research.xml

As you said, it talks about grants needed before an item can be used.

 

<!-- Plasma Cannon  -->

-

-

 

 

-

 

 

 

 

 

 

I'm talking about economic constraints of game play.

 

For example, to Manufacture One Plasma Cannon, the following

need to occur: (numbers are just made up to illustrate)

 

1. Cost: Amount of Money (Dollar or Euros)  $20,000

2. Time to Manufacture: 10 days for every Engineer assigned

3. Work Space: Manufacturing uses 10% of One Workshop

4. Storage Space Required:  5% of a Storage Facility

5. Xenium-122 = 3 Units

6. Alien Composites = 1 Unit

This is the dependency of every Manufacturing Item I'm Talking about.

 

Purchasing Items is similar, but simpler.

Purchasing has

1. Cost of Item, $1500

2. Time to Deliver without an assigned Engineer, 3 Days

3. Storage Space for the Item 5% of a Storage Facility

 

The Numbers are specific for every Item.

Is this Defined any where?

 

Hope this is clearer... :)

 

Regards,

Kelargo

Link to comment
Share on other sites

The Numbers are specific for every Item.

Is this Defined any where?

 

Hope this is clearer...  :)

It is to me. I just finished adding those parts to item.xml. :)

 

Which reminds me, we might need to add manufacture space in item.xml, dteviot. :wink1:

 

- Zombie

Edited by Zombie
Link to comment
Share on other sites

The Numbers are specific for every Item.

Is this Defined any where?

 

Hope this is clearer...  :)

It is to me. I just finished adding those parts to item.xml. :)

 

Which reminds me, we might need to add manufacture space in item.xml, dteviot. :wink1:

 

- Zombie

Already done. Have another look at the facility element.

Link to comment
Share on other sites

Already done.  Have another look at the facility element.

My poor zombified scatter-brain. How could I forget that? I added those numbers too. LOL

 

kelargo: in case you are interested, this is what the current item.xml code looks like for manufacturing:

 

Also, I’ve adjusted the “cost” element I gave you earlier.  It now looks like this:

 

    <construct>
       <facility type="FAC_ENGINEERING_FACILITY" space="18" />
       <cost hours="1600" money="150000">
           <item type="ITEM_COMPOSITES" quantity="3" />
       </cost>
   </construct>

- Zombie

Link to comment
Share on other sites

OK, I've checked the updated files into subversion:

basic.xsd

item.xml

item.xsd

research.xml

 

Some notes:

1. I Gave the XCAP clips a very large size (so soldiers should be unable to carry them, and a storage size of 16

2. Might want to double check the numbers for creating ammo for the GAIA XCAP, they look a bit big.

3. May want to check stats for Raptor corpse.

 

I believe I've fixed all above issues.

1. Added Zombie's item construction information to item.xml

2. Added Zombie's additional item info to item.xml

3. Added new items: clips for XCAPs and Alien Grenade

4. Assorted fixes to item.xsd/item.xml

Link to comment
Share on other sites

OK, I've checked the updated files into subversion:

basic.xsd

item.xml

item.xsd

research.xml

Could you do me a favor and point me in the correct direction where those files are located in subversion? I found (I think old) copies of that info here. I can hardly write up a response without studying the changes first. :wink1:

 

- Zombie

Link to comment
Share on other sites

OK, I've checked the updated files into subversion:

basic.xsd

item.xml

item.xsd

research.xml

Could you do me a favor and point me in the correct direction where those files are located in subversion? I found (I think old) copies of that info here. I can hardly write up a response without studying the changes first. :wink1:

 

- Zombie

No, I checked my work into the main trunk

http://svn.projectxenocide.com/xenocide/tr...me/data/schema/

 

The dteviotItems branch was where I did the initial items development. That code has been merged into the mainline, and the branch should be deleted.

Link to comment
Share on other sites

Ah, thanks! :)

 

Some notes:

1. I Gave the XCAP clips a very large size (so soldiers should be unable to carry them, and a storage size of 16

2. Might want to double check the numbers for creating ammo for the GAIA XCAP, they look a bit big.

3. May want to check stats for Raptor corpse.

1) I'll have to do some calculations on XCAP clip storage size yet. Will work on that tonight.

 

2) The only thing off is the Xenium quantity. It should be 40 instead of 200. Don't know why that number popped up, but good catch. As for the other stats, they are high for a reason: One shell is super-expensive. Multiply that by 8 and... you get the idea:

 

                  ------- Quantity -------
Property          Clip (8)       Shell (1)
Sell              $252,000        $31,500
Hours               3200            400
Money             $120,000        $15,000
Xenium               40              5
Composites           64              8

3) Don't know what stats you want me to check there. Everything is as good as it's going to get right now. Size and weight stats for the 2x2 aliens (Raptor, Terror Disc and Artopod) are still unresolved issues and therefore are meaningless at this point in time. ^_^

 

- Zombie

Link to comment
Share on other sites

3) Don't know what stats you want me to check there. Everything is as good as it's going to get right now. Size and weight stats for the 2x2 aliens (Raptor, Terror Disc and Artopod) are still unresolved issues and therefore are meaningless at this point in time.  ^_^

 

- Zombie

:doh: I thought it had been solved, but if it hasn't you're right. Nothing to do at the moment.

Link to comment
Share on other sites

Guest Azrael
Zombie,

 

Sorry to nag, but do you want to do anything about the research bonus discussed in post #72 in this topic? (Sorry, not sure how to link to individual posts)

http://www.xcomufo.com/forums/index.php?showtopic=242024476

 

And if there is a research bonus, do construction bonuses exist?

 

Click to the post number, in the top right of every post.

Link to comment
Share on other sites

Zombie,

 

Sorry to nag, but do you want to do anything about the research bonus discussed in post #72 in this topic? (Sorry, not sure how to link to individual posts)

http://www.xcomufo.com/forums/index.php?showtopic=242024476

 

And if there is a research bonus, do construction bonuses exist?

Nope, not a nag. :)

 

Research... ok, let me look. (I was the one who did some "studies" on how research is handled a while back for the X-COM wiki). :wink1: Normally, if a research project is listed as x scientist days to complete, the amount of time is it takes is a range depending on how many scientists are assigned.

Min Days= INT((Scientist Days/# of Scientists)/2),

Max Days= INT((Scientist Days/# of Scientists)*3/2).

 

This is for an initial rating of "Unknown". But there are other ratings which pop up from time to time: Poor, Average, Good and Excellent and sometimes the project finishes instantaneously. As of yet, we are still unsure of how these "bonuses" are awarded. I think it's based off the number of scientists assigned to the project. Haven't had the chance to verify anything yet as those type of trials are very extensive and picky to run. One of these days... :)

 

As for the bonuses Az mentioned before his long table, those are modifications made by xcomutil to X-COM and are not original to the game. (Alien interrogations did not help to improve chances). I'm not 100% positive on this though. Scott T. Jones would be the man to ask here on how he arrived at the alien interrogation bonus numbers.

 

There are no construction bonuses. It's only found in research.

 

As for what I want to do about this... well, I'd kinda like to finish off this item.xml stuff first, then work my way over to the next project. Almost done with verifying the space for each item (I never really checked it in the game before). After that, I'm all yours. :)

 

(Oh, by the way: to link to posts directly, left click on the post number. A screen will come up saying something to the effect of "Manually copy the direct link to the clipboard". The address to that post is highlighted below. Right click on the address, copy it, then paste it anywhere you want. I never copy it to the clipboard because this way is easier. )

 

- Zombie

Link to comment
Share on other sites

Zombie,

 

Sorry to nag, but do you want to do anything about the research bonus discussed in post #72 in this topic? (Sorry, not sure how to link to individual posts)

http://www.xcomufo.com/forums/index.php?showtopic=242024476

 

And if there is a research bonus, do construction bonuses exist?

Nope, not a nag. :)

 

Research... ok, let me look. (I was the one who did some "studies" on how research is handled a while back for the X-COM wiki). :wink1: Normally, if a research project is listed as x scientist days to complete, the amount of time is it takes is a range depending on how many scientists are assigned.

Min Days= INT((Scientist Days/# of Scientists)/2),

Max Days= INT((Scientist Days/# of Scientists)*3/2).

 

This is for an initial rating of "Unknown". But there are other ratings which pop up from time to time: Poor, Average, Good and Excellent and sometimes the project finishes instantaneously. As of yet, we are still unsure of how these "bonuses" are awarded. I think it's based off the number of scientists assigned to the project. Haven't had the chance to verify anything yet as those type of trials are very extensive and picky to run. One of these days... :)

 

As for the bonuses Az mentioned before his long table, those are modifications made by xcomutil to X-COM and are not original to the game. (Alien interrogations did not help to improve chances). I'm not 100% positive on this though. Scott T. Jones would be the man to ask here on how he arrived at the alien interrogation bonus numbers.

 

There are no construction bonuses. It's only found in research.

 

As for what I want to do about this... well, I'd kinda like to finish off this item.xml stuff first, then work my way over to the next project. Almost done with verifying the space for each item (I never really checked it in the game before). After that, I'm all yours. :)

 

(Oh, by the way: to link to posts directly, left click on the post number. A screen will come up saying something to the effect of "Manually copy the direct link to the clipboard". The address to that post is highlighted below. Right click on the address, copy it, then paste it anywhere you want. I never copy it to the clipboard because this way is easier. )

 

- Zombie

Fine with me. I just wanted to know your plans, in case it would have been useful for me to do something ahead of time. e.g. If I'd got the construction costs into the schema (item.xsd) BEFORE you added them, there would have been no need for me to massage them into a valid form.

Link to comment
Share on other sites

Fine with me.  I just wanted to know your plans, in case it would have been useful for me to do something ahead of time.  e.g. If I'd got the construction costs into the schema (item.xsd) BEFORE you added them, there would have been no need for me to massage them into a valid form.

*nods* Entirely true. Well, if anything else needs to be added to item.xml which isn't listed, we'll hash it out and fix up item.xsd first, then apply the form to item.xml. (Does that make any sense?) ;)

 

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

 

Okay, I went through storage space for items in item.xml today. I think I remember seeing a discussion where the space for Xeno items was multiplied by 10 for ease of application, so I just multiplied my numbers by a factor of 10. Problems:

  • Xeno UFO construction is 2, while in-game it's 1.
  • Xeno composites are listed as 10, while in-game they are 1 (could be a typo).
  • XCAP chasis' are half as big is the X-COM counterparts. Calculation error? Don't know. Could be a way to cut down space since one XCAP would require more than 1 General Store module! ^_^

Edit: even if this is not the case, the capacity of the General Store module needs to be multiplied by 10 (to 500) to take into account the fudge factor. Or, are we just going to divide item space by ten for actual storage space? Don't know about this one folks. Help would be appreciated!

 

Ammo for the craft and XCAPs need to be updated to take into account clip size. More of a note to myself.

 

Other than that, everything seems to be in order for storage space - except for maybe the Craft Cannon's clip size. In X-COM, the craft cannon's shells didn't need any storage space (read: one general store module could hold an infinite amount). In Xeno the space listed is one. Seems a bit low in my book. Something like 2-3 per clip sounds more reasonable. :P

 

- Zombie

Edited by Zombie
Link to comment
Share on other sites

Fine with me.  I just wanted to know your plans, in case it would have been useful for me to do something ahead of time.  e.g. If I'd got the construction costs into the schema (item.xsd) BEFORE you added them, there would have been no need for me to massage them into a valid form.

*nods* Entirely true. Well, if anything else needs to be added to item.xml which isn't listed, we'll hash it out and fix up item.xsd first, then apply the form to item.xml. (Does that make any sense?) ;)

Makes perfect sense

 

Okay, I went through storage space for items in item.xml today. I think I remember seeing a discussion where the space for Xeno items was multiplied by 10 for ease of application, so I just multiplied my numbers by a factor of 10.

That's correct

 

Problems:
  • Xeno UFO construction is 2, while in-game it's 1.
     
     
  • Xeno composites are listed as 10, while in-game they are 1 (could be a typo).
     
     
  • XCAP chasis' are half as big is the X-COM counterparts. Calculation error? Don't know. Could be a way to cut down space since one XCAP would require more than 1 General Store module!  ^_^

Edit: even if this is not the case, the capacity of the General Store module needs to be multiplied by 10 (to 500) to take into account the fudge factor. Or, are we just going to divide item space by ten for actual storage space? Don't know about this one folks. Help would be appreciated!

 

Ammo for the craft and XCAPs need to be updated to take into account clip size. More of a note to myself.

 

Other than that, everything seems to be in order for storage space - except for maybe the Craft Cannon's clip size. In X-COM, the craft cannon's shells didn't need any storage space (read: one general store module could hold an infinite amount). In Xeno the space listed is one. Seems a bit low in my book. Something like 2-3 per clip sounds more reasonable.  :P

 

- Zombie

Feel free to update the numbers.

Edited by dteviot
Link to comment
Share on other sites

Feel free to update the numbers.

Done. Updated UFO construction and Alien Composites. Also changed XCAPs to 60 storage instead of 30, and amended craft clip storage space too.

 

Did some calculations concerning storage space for a Cannon Clip. 2-3 was still too low so I increased it to 5 which I think is reasonable. That should be it for storage.

 

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

 

Ok, we still need to add a corpse/body item yet. ;)

 

Because a plain-clothes soldier weighs 22 units in X-COM, I propose armor weight should be 2 for Combat Armor and 4 for the Combat Powersuit and Anti Grav Powersuit. That way, we can assign a body weight of 22 to unconscious or dead officers and just tack on the armor weight to the body. :)

 

- Zombie

Link to comment
Share on other sites

Refactoring items

 

OK, here’s what I propose doing to items. Please refer to the attached diagrams, and then my reasoning.

Can anyone point out any issues/disagreements, before I proceed with this.

 

Attached, should be.

1. Current items xsd and c++ hierarchies.

2. Spreadsheet of items and their actions.

3. Proposed items xsd and c++ hierarchies

 

Reasoning. (For xsd/xml schema)

1. Fold the guided, ranged and melee weaponItemType classes into weaponItemType.

Just provide an element, with possible actions of shoot (snap, auto, aimed & ship), guide and hit.

2. Consolidate the two clip classes (craftClipItemType & clipItemType) into single class.

3. Consolidate the two weapon classes (craftWeaponItemType & weaponItemType) into single class.

 

Points 2 and 3 have a potential issue, as there are a couple of minor differences between craft and troop weapons and clips.

The main item being craft items are used by craft, while troop items are carried by soldiers. This should not be a problem, adding a flag to indicate if clip/weapon is used by craft or soldier it solves it. This means when we go to equip troop and equip craft dialogs we will only be shown the appropriate types of items available in the base’s store.

 

There is the argument that having a single type for weapons and clips means we can’t use double dispatch to prevent us putting craft clips into troop weapons. However, this is a red herring, as double dispatch can’t be used to prevent us loading, for example, plasma rounds into a pistol. Weapons already know the type(s) of ammo they use, so this should not be an issue.

 

Only remaining issue is weapons & clips will need to inherit from troop item type, which will give craft weapons and clips size and throw properties. (Which I don't think we need worry about, can just put in dummy values.)

 

Also, a number of these classes have , but in fact, the only items that use a custom action are: medkit, motion sensor, psi amplifier and psi probe.

(Weapons use one or more of the attacks mentioned in 1, and grenades use prime.)

Therefore, strip the action item from everything except equipment Item type.

 

Additional change to C++ classes.

At moment, there are two different clip classes in C++ code. (One for troop items, one for craft.) - With HWPs there could be 3.

There's also two classes of craft weapon pod, and two class of troop weapon, one that takes a clip, and one that doesn't. With HWPs, this would add another two.

So: Possible simplification.

1. Go to single clip type. Only difference between clips is what uses them, and if troops can carry them. Who cares if player gets a trooper to carry cannon ammo around? Good exercise. And weapons know the ammo they use.

2. Create an AmmoInfo or similar class, that encapsulates the information about a weapon using ammo or not. Then just need single class each for troop weapon, craft weapon, or HWP class which contains an AmmoInfo class.

 

Issues/Questions:

1. We’re missing armor, craft & HWP classes.

2. The Laser pistol has 2 snap shot actions, I assume one is an auto shot.

3. Proximity grenade seems to lack a “detection range”

4. All grenades lack a “blast radius”

5. Why is UFO_CONSTRUCTION an item?

item_initial.xls

item_xsd.initial.2.png

item_xsd.proposed.png

Link to comment
Share on other sites

Refactoring items

 

OK, here’s what I propose doing to items. Please refer to the attached diagrams, and then my reasoning.

Can anyone point out any issues/disagreements, before I proceed with this.

 

Attached, should be.

1. Current items xsd and c++ hierarchies.

2. Spreadsheet of items and their actions.

3. Proposed items xsd and c++ hierarchies

 

Reasoning. (For xsd/xml schema)

1. Fold the guided, ranged and melee weaponItemType classes into weaponItemType. 

Just provide an element, with possible actions of shoot (snap, auto, aimed & ship), guide and hit.

2. Consolidate the two clip classes (craftClipItemType & clipItemType) into single class.

3. Consolidate the two weapon classes (craftWeaponItemType & weaponItemType) into single class.

 

Points 2 and 3 have a potential issue, as there are a couple of minor differences between craft and troop weapons and clips.

The main item being craft items are used by craft, while troop items are carried by soldiers. This should not be a problem, adding a flag to indicate if clip/weapon is used by craft or soldier it solves it.  This means when we go to equip troop and equip craft dialogs we will only be shown the appropriate types of items available in the base’s store.

 

There is the argument that having a single type for weapons and clips means we can’t use double dispatch to prevent us putting craft clips into troop weapons.  However, this is a red herring, as double dispatch can’t be used to prevent us loading, for example, plasma rounds into a pistol.  Weapons already know the type(s) of ammo they use, so this should not be an issue.

No disagreements from me, it sounds like a plan. However...

 

Only remaining issue is weapons & clips will need to inherit from troop item type, which will give craft weapons and clips size and throw properties.  (Which I don't think we need worry about, can just put in dummy values.)

I shudder a bit when reading this. Back in the day when I used to program, I was taught that if two classes were not totally identical, then it is better to keep them separate. Chalk this up to old-school programming where processor optimization (and memory) was a primary concern. These days this really isn't a problem anymore, but is the logic still sound? *shrugs* To a point maybe. How much space will a couple "dummy" values occupy? Not much I'd guess. Since this probably doesn't apply, it should be fine. :P

 

Also, a number of these classes have , but in fact, the only items that use a custom action are: medkit, motion sensor, psi amplifier and psi probe.

(Weapons use one or more of the attacks mentioned in 1, and grenades use prime.)

Therefore, strip the action item from everything except equipment Item type.

I like the sound of this. =b

 

Additional change to C++ classes.

At moment, there are two different clip classes in C++ code. (One for troop items, one for craft.) - With HWPs there could be 3.

There's also two classes of craft weapon pod, and two class of troop weapon, one that takes a clip, and one that doesn't. With HWPs, this would add another two.

So: Possible simplification.

1. Go to single clip type. Only difference between clips is what uses them, and if troops can carry them. Who cares if player gets a trooper to carry cannon ammo around? Good exercise. And weapons know the ammo they use.

2. Create an AmmoInfo or similar class, that encapsulates the information about a weapon using ammo or not. Then just need single class each for troop weapon, craft weapon, or HWP class which contains an AmmoInfo class.

1) Just remember that we would need to come up with some numbers for size, weight and throw for these items if they are going to be found on the battlescape. Not to mention that artwork would need to create specialized icons to represent these items in inventory too. Here is where my old-school programming takes over again. Will the addition of these details be worth more trouble than a separate class? I am by no means an expert programmer so the decision is for someone else. I just propose suggestions. :wink1:

 

Issues/Questions:

1. We’re missing armor, craft & HWP classes.

2. The Laser pistol has 2 snap shot actions, I assume one is an auto shot.

3. Proximity grenade seems to lack a “detection range”

4. All grenades lack a “blast radius”

5. Why is UFO_CONSTRUCTION an item?

1) Indeed, those are still missing.

2) Yes, the top one is supposed to be an auto shot. I could have sworn I fixed that at one time. Hrm, maybe I forgot to save.

3) Yeah, that was something I was going to bring up. I didn't know if defining this property in item.xsd would require it for all grenades.

4) Blast radius is something which we need to discuss further. A simple answer is just not possible right now. You can define it I suppose, but values cannot be assigned until some issues are resolved.

5) Technically, it is an item in X-COM. Then again, it was a game artifact: the programmers defined an UFOpaedia entry and assigned values. They just didn't have time to implement it. :)

 

- Zombie

Edited by Zombie
Link to comment
Share on other sites

Additional change to C++ classes.

At moment, there are two different clip classes in C++ code. (One for troop items, one for craft.) - With HWPs there could be 3.

There's also two classes of craft weapon pod, and two class of troop weapon, one that takes a clip, and one that doesn't. With HWPs, this would add another two.

So: Possible simplification.

1. Go to single clip type. Only difference between clips is what uses them, and if troops can carry them. Who cares if player gets a trooper to carry cannon ammo around? Good exercise. And weapons know the ammo they use.

2. Create an AmmoInfo or similar class, that encapsulates the information about a weapon using ammo or not. Then just need single class each for troop weapon, craft weapon, or HWP class which contains an AmmoInfo class.

1) Just remember that we would need to come up with some numbers for size, weight and throw for these items if they are going to be found on the battlescape. Not to mention that artwork would need to create specialized icons to represent these items in inventory too. Here is where my old-school programming takes over again. Will the addition of these details be worth more trouble than a separate class? I am by no means an expert programmer so the decision is for someone else. I just propose suggestions. :wink1:

I have to admit, folding the craft weapons into the troop weapons is something I'm not 100% comfortable with. The issue is that the craft weapons and troop weapons are essentially the same thing, except they have different owners. The "Weapon" and "Clip" behaviours are almost the same. Unfortunately, I can't push the common code up the tree to the base, because it's inappropriate for the base Item class. And I don't want to duplicate code. An alternate solution might be to have multiple inheritance, with mixin "weapon" and "clip Info" classes, but I'm not sure what xenocide's general policy on multiple inheritance is.

 

EDIT. I should add that we probably wouldn't have the craft weapons and clips appearing on the battlescape. (We put a flag in the weapon and clip classes to say who "owns" them, and if they're craft they don't appear in the equip soldiers GUI.)

As regards artwork, I believe it will be needed anyway, for the "equip craft" GUI.

 

Issues/Questions:

1. We’re missing armor, craft & HWP classes.

2. The Laser pistol has 2 snap shot actions, I assume one is an auto shot.

3. Proximity grenade seems to lack a “detection range”

4. All grenades lack a “blast radius”

5. Why is UFO_CONSTRUCTION an item?

1) Indeed, those are still missing.

2) Yes, the top one is supposed to be an auto shot. I could have sworn I fixed that at one time. Hrm, maybe I forgot to save.

3) Yeah, that was something I was going to bring up. I didn't know if defining this property in item.xsd would require it for all grenades.

4) Blast radius is something which we need to discuss further. A simple answer is just not possible right now. You can define it I suppose, but values cannot be assigned until some issues are resolved.

5) Technically, it is an item in X-COM. Then again, it was a game artifact: the programmers defined an UFOpaedia entry and assigned values. They just didn't have time to implement it. :)

 

- Zombie

While we're about it, did you ever figure out range? Or does it make more sense for us to redefine it as a property of the item itself, and represent the maximum range for the weapon? Or does range change depending on type of attack, e.g. aimed vs. snap?

Edited by dteviot
Link to comment
Share on other sites

I have to admit, folding the craft weapons into the troop weapons is something I'm not 100% comfortable with.  The issue is that the craft weapons and troop weapons are essentially the same thing, except they have different owners.  The "Weapon" and "Clip" behaviours are almost the same.  Unfortunately, I can't push the common code up the tree to the base, because it's inappropriate for the base Item class.  And I don't want to duplicate code.  An alternate solution might be to have multiple inheritance, with mixin "weapon" and "clip Info" classes, but I'm not sure what xenocide's general policy on multiple inheritance is.

Multiple inheritance is something to consider. But like you said, the policy is here is unknown.

 

EDIT.  I should add that we probably wouldn't have the craft weapons and clips appearing on the battlescape.  (We put a flag in the weapon and clip classes to say who "owns" them, and if they're craft they don't appear in the equip soldiers GUI.)

Right, I somehow understood this. Only battlescape items could potentially spawn. Craft weapons are not a battlescape item, so only tank ammo would. ;)

 

While we're about it, did you ever figure out range?  Or does it make more sense for us to redefine it as a property of the item itself, and represent the maximum range for the weapon?  Or does range change depending on type of attack, e.g. aimed vs. snap?

From centurion's PM reply, the range numbers were "pulled out of our collective a$$es". LOL Range was primarily defined for craft weapons. From what I can tell, range is a max distance a craft weapon can fire. Obviously, hand-held weapons never had this. We would need to discuss this option further to determine if we want it present. Basically, I do not know what the numbers are supposed to represent for hand-held weapons. :)

 

- Zombie

Edited by Zombie
Link to comment
Share on other sites

While we're about it, did you ever figure out range?  Or does it make more sense for us to redefine it as a property of the item itself, and represent the maximum range for the weapon?  Or does range change depending on type of attack, e.g. aimed vs. snap?

From centurion's PM reply, the range numbers were "pulled out of our collective a$$es". LOL Range was primarily defined for craft weapons. From what I can tell, range is a max distance a craft weapon can fire. Obviously, hand-held weapons never had this. We would need to discuss this option further to determine if we want it present. Basically, I do not know what the numbers are supposed to represent for hand-held weapons. :)

 

- Zombie

 

 

Range is a function of initial velocity, except for Rocket weapons which have their own power supply and could be considered to have a Constant Velocity until the rocket fuel is expended, then the velocity would decay util it crashes.

 

Some physics equations on projectiles

http://www.glenbrook.k12.il.us/GBSSCI/PHYS...tors/u3l2d.html

I'm sure there's other good references out there, too.. :)

 

I dont think the original had this much physics in the game... I'm just throwing this out for consideration.

 

This version is a little more unique in that the Space is real float units instead of those

pre-defined cubes for the character.

 

The original had the ground level and then three more block spaces above the character. I think the space of travel for a projectial was constant velocity and infinite length of travel, until it hit something in the battlescape area. I think the original game had two points defined in this simple

3-dimensional array. I think the original had some conic probability function to determine the final location of the projectile's desintation, then the graphic just displayed it out until it collided with something in the 3-d array space.

 

That is, with 100% accuracy, the project would travel from Point A to Point B with little deviation. With 50% accuracy, the project would fan out some amount with a 50% chance of hitting the target, per shot, based upon optimum range of the weapon. If points A and B were half the distance of optimum weapon range, then

the probability would increase to 75% probability of hitting the weapon.

If the distance was further away from optimum weapon range, then the probability of hitting a target would liewise decrease 25% probability of hitting the target.

 

Do this make sense?

 

In this version, since resolution of space movement has a much finer granularity, it may be worth considering these projectile physics equations in determining the enumerated properties of the weapon's characteristics.

 

If this level of detail is of interest, then I think probabilty could still be used with physics of projectiles. Its not as simple to implement as the original. But I think game play would be more interesting... The probability parameter could be applied to the initial velocity of the projectile. If optimum initial velocity is 1000 Kilometers per sec (KPS), then the accuracy of the weapon deviates around this value. The most accurate weapon would always have initial velocity of 1000 KPS. A less accuracte weapon would be +/- 10 KPS (randomly determined) A Much less accurate weapons would be +/- 100 KPS. so one.

 

I'm offering this as a way to look at implementing physics in the game for weapons.

This way of looking at weapons can be used for all weapons, even aircraft weapons.

As I said earlier, the only difference is Rockets have a constant velocity util the fuel is expended. The initil velocity of the rocket can be a random value deviated around an initial constant value. I'm also offering this as a way to contrast how I believe weapon physics were implemented in the orginal and to contrast to the issues currently being discussed. :-)

 

Just one other thing, this web page I referenced does not take into consideration Drag, reducing the velocity over time. I dont think drag is needed either, at least at this point in time. If there's no drag, maybe Rockets and Projectiles are not really very different... ;)

 

Maybe I'm just talking too much. :P

 

$0.02 :-)

 

Kelargo

Link to comment
Share on other sites

The whole battlefield isn't much more than ~100-200 m across, right? So having physics on the projectiles does not make much sense to me, since at 1 km/s muzzle velocity it produces a maximum deviation of ~10 cm from the straight line approximation. IIRC, the whole range stat for handheld weapons comes from the desire to have shotguns/melee weapons; for melee, the range would be fixed at whatever is an "arm's reach", and for shotguns and other firearms it's kind of redundant if we use a sensible hit detection method, since accuracy would determine it. On the other hand, we could use an abnormal way of choosing the projectile's path to involve range (say, change the distribution of the directions of the shot depending on the range stat: make it normal with standard deviation being const*(distance to target/range), set shotgun range to something low, and watch shots getting really inaccurate outside of some const*range ball).

 

Guided projectiles are fun, but I'd like to invoke KISS since we would only have it play a role in the aeroscape, which is simulated behind the scenes in V1 and so setting accuracy appropriately should be enough to emulate this behaviour.

Link to comment
Share on other sites

set shotgun range to something low, and watch shots getting really inaccurate outside of some const*range ball).

 

A shotgun really has limited range, because the projectile shot has a drag component decreasing velocity very quickly... velocity is not constant, but has a steep negative sloop over time. so, what I said earlier about constant velocity of projectiles is probably not best... each projectile weapon could have a negative slope function over time representing the velocity for specific TUs.

 

The decreasing velocity also goes into determining the effective impact on the target.

If the bullet slows down, its not effective at making damage.

So you have to be close to kill the alien. A pistol does not act like an artillery round travelling great distance. :)

 

Just some more thought to all of this...

 

As I said, I think Range is a function of velocity...

but I see targeting as a different function that goes into this.

 

But targeting has its own probability of accuracy. Shooting a target is

directing the projectile from point A to point B. In the game, the location of

point B is absolutely known, but there's the probability of accuractely hitting it.

The probability of hitting the target is a function of distance from point A.

That is there's a conic fan of probability eminating from point A.

Some accurate weapons will have a narrow cone and less accurate weapons would have a wider cone of probability.

 

This aspect also goes into the skill level of the Solider, too. A more skilled soldier will hold a weapon more steadiliy. While a wounded or nervous soldier, with low moral, would not be able to target point B accurately. Hence a wider cone of targeting probility with low moral.

 

I agree, KISS... I'm just explaining how I see physics to implement shooting weapons for game play.... my idea of fun. :D

 

I always like the parabolic affect of gravity in JOUST

http://www.klov.com/J/Joust.html

versus the mindless straight shooting of aliens in SPACE INVADERS.

http://www.klov.com/S/Space_Invaders.html

 

=b

 

any thoughts?

 

regards,

kelargo

Link to comment
Share on other sites

  • 1 month later...

OK, looking at my previous Items proposed C++ class hierarchy (refer http://www.xcomufo.com/forums/index.php?sh...2025189&st=87), I’m thinking it can be simplified some more. From an INVENTORY/ITEMS perspective, there is no difference between a Grenade and Equipment (First aid kit, scanner, etc.) In fact, the only real difference is the “actions” a soldier can do. (Snap shot, aimed shot, guide, heal, scan, prime, etc.) This makes me think we should have an “actions” class hierarchy, each ItemTroop contains a collection of actions that the item can perform. The actions are read out of the XML file.) As a side effect, this means you could give your pistol “smart” bullets by giving the pistol object a guide action.

 

This means we can dispose of the ItemGrenade class, and fold it into the ItemEquipment class.

I think we need to keep the ItemWeapon and ItemClip classes, because Weapons can contain clips.

Item alien is needed because in bases aliens have special properties (rank and alive/dead.)

I’m not entirely sure if Armour needs its own class. It could be argued that it’s just a another equipment item, like a scanner or med kit. (The special case is that armour can be WORN by a soldier, which is an inventory behaviour.)

Another question, could we combine the Weapon and Equipment classes? I’m not sure about this, some things, like the med kit, have a limited number of uses per mission, but they don’t have the “weapon” behaviours – range, damage, etc.

 

Thinking on a bit further, I’m wondering if part of the reason the proposed item class hierarchy is getting complicated is because it’s really two hierarchies. An inventory/item hierarchy, which covers buy/sell/build/store and a “solider objects” hierarchy which describes the classes of objects (and their behaviours) used by soldiers.

 

What do you think?

 

Edit: fixed link

Edited by dteviot
Link to comment
Share on other sites

Another question, could we combine the Weapon and Equipment classes?  I’m not sure about this,  some things, like the med kit, have a limited number of uses per mission, but they don’t have the “weapon” behaviours – range, damage, etc.

 

hmmm... actually, the med kit could be described as a hand-to-hand weapon dealing negative damage. (negative) damaging of morale and stamina probably shouldn't be unique to med kits, as I can easily imagine someone wanting to include weapons that scare people or wear them down after V1.0.

even the "body-zone-targeting" is something that could (should?) be used for weapons too.

 

so I say combine them. I don't see a true difference in the quality of weapons and med kits. it's all about quantity and algebraic sign. that is, if negative damage is currently possible at all...

Link to comment
Share on other sites

Another question, could we combine the Weapon and Equipment classes?  I’m not sure about this,  some things, like the med kit, have a limited number of uses per mission, but they don’t have the “weapon” behaviours – range, damage, etc.

 

 

I think its important to distinguish between two kinds of Range. Well, maybe its

not two kinds of range, but be more very specific about what *has* range.

 

1. If the Weapon has a projectile (bullets in clip, rocket)

then the Projectile has a range and corresponding accuracy.

 

2. Some weapon Items can be thrown. For example, a grenade gets Primed. Then thrown, all a Function of TUs. But the object that gets thrown does not have to be a Weapon. The Soldier can throw their Med-Kit or Motion Detector or Alien corpse for that matter. Throwing a Med-Kit and hitting an alien may have some nominal hp in damage... but essentially ineffective. The accuracy of throwing is a function of the Soldier and their corresponding Health and Moral and possibly other personal characteristics.

 

In this schema, after the soldier has used up all of their bullets in their clip, they can have the ability to throw their weapon away. Perhaps, not tactically advantagous, but do-able for that matter the soldier can throw their fully loaded weapon away... perhaps to be stupid or to give it to a commrade who is weaponless.

 

So, in a sense the Med-Kit does have some characteristics of the Grenade weapon, as it can be thrown, as well as provide negative HPs to the Player. I guess the Med-Kit could heal an injured Alien, too ?

 

My $0.02, all object should branch out from the same base of objects, as some characteristics are in common, to all Items.... have some form of: holding, packing, carrying, throwing, priming, researching, buying, manufacturing, storing, transfering, triggering(shooting or button pushing), flying, refueling, rearming, selling. (verbs that end in "-ing") .

 

some of these action verbs for objects may have NULL values, but the parameter *should* exist.

 

 

:)

Link to comment
Share on other sites

I think its important to distinguish between two kinds of Range. Well, maybe its

not two kinds of range, but be more very specific about what  *has* range.

 

1. If the Weapon has a projectile (bullets in clip, rocket)

then the Projectile has a range and corresponding accuracy.

 

2. Some weapon Items can be thrown. For example, a grenade gets Primed. Then thrown, all a  Function of TUs.  But the object that gets thrown does not have to be a Weapon. The Soldier can throw their Med-Kit or Motion Detector or Alien corpse for that matter.  Throwing a Med-Kit and hitting an alien may have some nominal hp in damage... but essentially ineffective.  The accuracy of throwing is a function of the Soldier and their corresponding Health and Moral and possibly other personal characteristics.

 

actually, all items can be thrown, as you said. hitting and damaging somebody with a thrown object is something for V1+. the range of throwing is definitely NOT an item characteristic, but depends on the throwing soldier. it should, however, be modified by an item characteristic: mass

I don't know if we have mass as an item characteristic, but we probably need it for encumbrance (soldiers having less TU when carrying heavy stuff) as well as exhaustion (soldiers losing more energy per square walked when carrying heavy stuff).

I should also think that all items should have some kind of "armor" value, determining how much explosive force is needed to destroy it when it is lying on the ground inside the blast radius. of course, for V1.0, this value could be identical for every item (true to X-Com), but it would be nice to already implement this at this stage, to allow for interesting stuff later (secondary explosions, X-Corps snipers shooting the GDL out of the Grey Commander's hands, ... )

 

 

In this schema, after the soldier has used up all of their bullets in their clip, they can have the ability to throw their weapon away.  Perhaps, not tactically advantagous, but do-able for that matter the soldier can throw their fully loaded weapon away... perhaps to be stupid or to give it to a commrade who is weaponless.

 

So, in a sense the Med-Kit does have some characteristics of the Grenade weapon,  as it can be thrown, as well as provide negative HPs to the Player. I guess the Med-Kit could heal an injured Alien, too ? 

uh... now that's something we should think about, but definitely not V1.0

Link to comment
Share on other sites


×
×
  • Create New...