Jump to content

X-Division Team @XCE Solver Questions


Charon

Recommended Posts

I have some questions about the vanilla/xce zombify ability.

The 34.2 will make it possible to specify the unit which gets spawned, thanks to you,  when a unit with zombify hits it, but the vanilla zombify decides which unit gets spawned by the unit which gets hit, no ? So if a civilian gets hit a civilian zombie will spawn, if a xeno gets hit by it a xeno zombie will spawn, and when a xeno with wolf armor gets hit a wolf zombie gets spawned. Correct ?

1. Does this vanilla ability expands to new armor we implement into the game ? We have an armor called "warder". Is all that we have to specify a     <Rank type="Zombie.warder"> and the game will spawn this unit when a another unit with the ability "Zombify" hits it ? Or is it hardcoded  to only use the range of implemented "zombies.***" ?

If that works what are the specifications about the code. Like are there any limits, or anything which doesnt work ?

2. Does the vanilla Zombify and the new 34.2 zombify both work in the new version ?

Link to comment
Share on other sites

In vanilla, the various zombies are identical except their visual sprite, which is determined by the armour of the zombified unit. If you add a unit called Zombie.warder, it will spawn for units with the vanilla Zombify ability, not for others. If you use the new format of specifying spawning, then armour will not be taken into account, that being easier in terms of implementation.

The vanilla ability in 0.34.2 of course still works as it did in vanilla, because X:CE has to retain compatibility with other mods.

Link to comment
Share on other sites

Just now, Charon said:

@Draku Can you check if the vanilla Zombify ability takes non vanilla armor into account like the Warder one ? You first have to specify a zombie rank as 

    <Rank  type="Zombie.sentinel_2">

under the reaper race.

Furthermore i want you to check if the     <Rank  type="ReaperOmega"> with the vanilla zombify actually produces a different zombie. You first have to specify 

    <Rank  type="ZombieOmega.generic">
    <Rank  type="ZombieOmega.basic"> and
    <Rank  type="ZombieOmega.sentinel_2">

in the aiprops.

Than check if the game produces a Omega zombie on hit by an Omega Reaper. It should be invisible because no unit sprites have been defined yet.

Is this supposed to work ?

Link to comment
Share on other sites

1 minute ago, Solver said:

I don't see any reason why the ReaperOmega/ZombieOmega would work.

Ok, thanks for clarifying. I assumed since your statement was that vanilla zombify takes non vanilla armor into account and the game differentiates between between a reaper and a ReaperAlpha zombify hit it would also differentiate for a ReaperOmega zombify hit.

Link to comment
Share on other sites

The vanilla Zombify ability produces a Reaper.Zombie, the ZombifyAlpha ability produces a Reaper.ZombieAlpha. It's a miracle that it works - there's a bug that means Alpha zombies shouldn't ever be produced, but it combined with another bug so it actually works as originally intended. Anyway, if the zombified unit is wearing armour, the name just gets appended to the zombie name, resulting in Reaper.Zombie.Wolf or such.

Omegas won't work for sure. If you want an Omega reaper, define its ability with the new 0.34.2 format, like Zombify.Zombie.Omega.

Link to comment
Share on other sites

2 minutes ago, Solver said:

The vanilla Zombify ability produces a Reaper.Zombie, the ZombifyAlpha ability produces a Reaper.ZombieAlpha. It's a miracle that it works - there's a bug that means Alpha zombies shouldn't ever be produced, but it combined with another bug so it actually works as originally intended. Anyway, if the zombified unit is wearing armour, the name just gets appended to the zombie name, resulting in Reaper.Zombie.Wolf or such.

Omegas won't work for sure. If you want an Omega reaper, define its ability with the new 0.34.2 format, like Zombify.Zombie.Omega.

Right, i missed the ZombifyAlpha ability.

3 minutes ago, Solver said:

Anyway, if the zombified unit is wearing armour, the name just gets appended to the zombie name, resulting in Reaper.Zombie.Wolf or such.

    <Rank  type="Zombie.buzzard"> is the example.

Thats really interesting ... ... ... lots of possibilities. Basically it means we have 2 different abilities available which take armor into account, as well as civilians ( generic ) and maybe locals ( basic ) and ofcourse xenos ( basic, jackal, etc ... ). Still needs testing though.

So to come back to the "Zombie.***", you said they dont differentiate between them, but it looks clear to me that the original idea was to let     <Rank  type="Zombie.buzzard"> have buzzard armor values, maybe a bit lower, no ? At least that was the intend of X-Div but i actually dont have data if it works. I will wait for the Draku report.

Link to comment
Share on other sites

23:45 - Solver: Because there's actually just two smoke types in the game, smoke and fire
23:45 - Solver: And different smokes have different gas types
23:46 - Solver: Each of which can only do damage once per turn, that's why you have that situation
23:46 - Charon: exactly, any way to softocde that into a per tile
23:46 - Charon: ?
23:48 - Solver: Probably could be softcoded
23:48 - Charon: just if its not a hassle, and just an interesting idea
23:49 - Charon: it would make a lot of interesting environments possible
23:49 - Charon: especially for the hive
23:49 - Solver: Maybe if you write it on the forums
23:49 - Solver: Or else I will forget for sure
 

Link to comment
Share on other sites

But still I need something to ask. 

As Chris said, the engine does not allow you put a movie to start so we got only the first picture before mani scene. Can you make it modable so I can put something more logical to there.. more cool stuff.

You can change it directly from xce files for now.

Link to comment
Share on other sites

Can you tell us how exactly the storage categorisation functions so we can properly implement it. Right now we have a lot of inteference of the vanilla/XCE manufacture file as this gets taken into account before the X-Division manufacture file.

Also can we simply make a new aircraft/vehicle category and use the "FillSlot" without any errors ?

Link to comment
Share on other sites

I do not understand what you are asking. Your new manufactures work the same way as the manufactures in the vanilla files, as always.

New categories for airplanes and vehicles should work as long as they have FillsSlot with "airplane"  and "vehicle" respectively in those strings.

Link to comment
Share on other sites

1 hour ago, Solver said:

I do not understand what you are asking. Your new manufactures work the same way as the manufactures in the vanilla files, as always.

I apologise, i thought the way i formualted my question might be confusing. Sometimes i forget not everybody is balls deep into the code and tries to survive there :).

In the storage view every item is assigned a category if we use Drakus UI. You said this category gets assigned by the game as it looks step by step what the first manufactures categories is that produces said item.

Right now we get a lot of inteferences from the vanilla/XCE manufacture file as this gets checked before the X-Division manufacture file.

I would like to ask that you tell us as much as you can about how this system works before is start to work because making a custom ID for 1300 is not small feat and i wouldnt want to start over.

 

Our current approach is to make a Dummy manufacture on top of the file for every category we want to have in the game. For example ( continuation in the next post )

ManTech.DummyRessourcesCategory

ManTech.DummyAircraftPartsCategory

Ressources

Aircraft Parts

5

5

5000

5000

1xItems.Dummy

1xItems.Dummy

   

StockItem( "Items.Alienalloys" ); StockItem( "Items.Alenium" ); StockItem( "Items.energycore" );

StockItem( "Items.Alienlightengine" ); StockItem( "Items.Aliencomputers" );

 

Edited by Charon
Link to comment
Share on other sites

9 minutes ago, Charon said:

I apologise, i thought the way i formualted my question might be confusing. Sometimes i forget not everybody is balls deep into the code and tries to survive there :).

In the storage view every item is assigned a category if we use Drakus UI. You said this category gets assigned by the game as it looks step by step what the first manufactures categories is that produces said item.

Right now we get a lot of inteferences from the vanilla/XCE manufacture file as this gets checked before the X-Division manufacture file.

I would like to ask that you tell us as much as you can about how this system works before is start to work because making a custom ID for 1300 is not small feat and i wouldnt want to start over.

 

Our current approach is to make a Dummy manufacture on top of the file for every category we want to have in the game. For example ( continuation in the next post )

ManTech.DummyRessourcesCategory

ManTech.DummyAircraftPartsCategory

Ressources

Aircraft Parts

5

5

5000

5000

1xItems.Dummy

1xItems.Dummy

   

StockItem( "Items.Alienalloys" ); StockItem( "Items.Alenium" ); StockItem( "Items.energycore" );

StockItem( "Items.Alienlightengine" ); StockItem( "Items.Aliencomputers" );

 

This makes Alenium, Alloy and the Energy Core have the category "Ressources" in the storage view and Alien Lightengine and Alien Computers have the category "Aircraft Parts".

 

But it would be good to know every detail before we start to implement 1300 items into Dummy Manufactures.

 

Remember me that we need to make Drakus new storage UI available for other modders somewhere too.

Edited by Charon
Link to comment
Share on other sites

If you don't want some of the default XCE/vanilla manufactures, you can of course also remove them through modmerging.

I think you're doing things correctly. If you are unhappy with the category a particular items gets thrown in, create a ManTech for it. I do not have any more details about how this works. The UI will look for what technology produces the item. If there are multiple, then I guess it will be the first technology that gets used, and I don't know what "first" is. This is how coding stuff for the game usually goes, I code it, then you figure out how it actually works :)

Link to comment
Share on other sites

5 minutes ago, Solver said:

If you don't want some of the default XCE/vanilla manufactures, you can of course also remove them through modmerging.

I think you're doing things correctly. If you are unhappy with the category a particular items gets thrown in, create a ManTech for it. I do not have any more details about how this works. The UI will look for what technology produces the item. If there are multiple, then I guess it will be the first technology that gets used, and I don't know what "first" is. This is how coding stuff for the game usually goes, I code it, then you figure out how it actually works :)

OK, sounds good to me. We will test how it works.

We wont only make overwriting categories for vanilla/XCE ones but every single category of an item will be defined by the top Dummy Manufactures we put on top of the file. For every single item of those 1300.

This lets us control every category we want to implement ( as this categories are purely Dummy versions and never actually get unlocked ), which category every item falls into 100% and adds a nice visual representaion of that on top with an easy to sort and easy to look for categories.

Sounds like pure genius to me and you made all of that possible Solver :).

Link to comment
Share on other sites

On 22.10.2016 at 8:54 PM, Charon said:

Hi,

one of the things which is important is map randomisation. We as the X-Division developer team have collectively the feeling that certain maps have a higher priority and thuse get picked more often than other maps.

This could be because of

  1. The different map pack bundles are not equaly taken, regarding their coding
  2. UFOs get shot down over certain areas more frequently. But this is not taken into account into the feeling that certain maps occur more often, we always calculate the maps as per "tileset". So map X has a higher chance to be taken for its tileset.

Could you explain all tools available to modders considering how the game picks a map ?

Could you explain how the game picks a map ?

Could you explain if maps gets marked as done once they get taken in a playthrough ?

 

Best Regards and thank you in advance
Charon

 

10 minutes ago, Charon said:

Thank you for your answer but i already noticed that the game uses code for the randomisation in the mapinfo.xml. Eg:


<?xml version="1.0" ?>
<MapInfo MODMERGEATTRIBUTE="Maps" MODMERGE="update">
    <Maps>
        <Map name="RMP_Farm_Huge_03_a_1" random="1"/>
        <Map name="RMP_Farm_Huge_03_b_1" random="1"/>
        <Map name="RMP_Farm_Huge_03_c_1" random="1"/>
        <Map name="RMP_Farm_Huge_03_d_1" random="1"/>
        <Map name="RMP_Farm_Huge_03_e_1" random="1"/>
        <Map name="RMP_Farm_Huge_04_a_1" random="1"/>
        <Map name="RMP_Farm_Huge_04_b_1" random="1"/>
        <Map name="RMP_Farm_Huge_04_c_1" random="1"/>
        <Map name="RMP_Farm_Huge_04_e_1" random="1"/>
        <Map name="RMP_Farm_Huge_05_a_1" random="1"/>
        <Map name="RMP_Farm_Huge_05_b_1" random="1"/>
        <Map name="RMP_Farm_Huge_05_c_1" random="1"/>

and the config.xml has this line:


<RandomMapsSelectCount>-1</RandomMapsSelectCount> <!-- When randomly choosing a map, all random maps together will count as this many maps, -1 for them to have normal chance. -->

 

So my questions were rather directed at how this system functions and if there was more to know, or other variables which influences the selection.

Nevertheless, thank you for your time.

 

1 minute ago, Solver said:

Since I do not have the time right now and will forget it otherwise, you should repost that question in the forum, then I'll see it again.

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...