wowgetoffyourcellphone

I had the idea of extending the Tab key. Right now, depress the Tab and you see the health bars of all your units. What if the Tab is more of a toggle and it toggle on other things too, like the floaty icons you propose and various range graphics. Likely too busy to play that way for the whole match, but would be useful, 10 seconds at a time for the player to plan better or get snapshot of what's going on.

Yes, it's funny because if you take static screenshot of his game you don't know what the hell you're looking at either. lol What makes one mech and obvious econ unit and another an obvious military unit? The economic "pod" mechs could be kamikaze units or something for all I would know from a dense, static screenshot.

Here's the weird thing too. I have 2 CCs. I upgrade them to Fortified CCs separately, 5 mins apart, and I still lose. I swear the FCCs have the CivilCentre class.

Hi. So, I made a new Victory Condition for DE, called Conquest Civic Centers. Basically, win by destroy or capture the enemy Civic Centers. Here is the code of the script: var cmpTrigger = Engine.QueryInterface(SYSTEM_ENTITY, IID_Trigger); cmpTrigger.conquestClassFilter = "CivilCentre"; var data = {"enabled": true}; cmpTrigger.RegisterTrigger("OnOwnershipChanged", "ConquestHandlerOwnerShipChanged", data); cmpTrigger.RegisterTrigger("OnStructureBuilt", "ConquestAddStructure", data); cmpTrigger.DoAfterDelay(0, "ConquestStartGameCount", null); This works fine... until I use an Upgrade feature to upgrade my Civic Center. I made it so I can upgrade my Civic Center to a Fortified Civic Center. The Fortified Civic Center inherits from the Civic Center template, so has all the same classes, etc. There may be a brief moment where the game think I don't have a Civic Center, so it makes me lose. Even though the enemy didn't destroy or capture it. Can I edit something in the script to prevent this? Perhaps that last line that mentions Delay?

The flag indicates a waypoint, actually. Ask @Itms or @elexis, it might be a separate, though related, task.

When a force of enemy troop try to capture my Civic Center, they couldn't capture it because of the number of garrisoned defenders. So, the attackers switched from capture to attack instead. Very nice. @mimo May have been in the logic for a long time, but it really showed this time. They would capture it by about 5% but my defenders capture it back to 100% every 5 seconds or so. The attackers were all like, "Screw this!" and switch to destroy instead. Very nice, something a human player would do.

The red and gold looks really nice. Maybe a subtle spec texture too, especially on the gold trim? And I think the animation should be somewhat faster. This is exciting though.

Post the whole xml file or copypasta the code from the xml file for us.

Pretty much how it's done.

My god, what is holding this one up? https://trac.wildfiregames.com/ticket/3987 @Sandarac @s0600204

This is a standard feature that should have been implemented years ago

shield_arm for hoplite shields, shield for most other shields.

The combat seems kind of odd, all the moving around and whatnot, since it looks like every single shot is a hit.

Open some existing actros, breh. Specifically, ones of the same type that you are trying to create. They should tell you the prop points you need. Else, you can open the unit mesh collada -- .dae -- files in a text editor and ctrl-F "prop-" <group> <variant file="biped/base_archer_ready.xml"> <mesh>skeletal/new/m_pants_tunic_long.dae</mesh> <props> <prop actor="props/units/heads/new/head_pers_a.xml" attachpoint="head"/> <prop actor="props/units/heads/pers_conical.xml" attachpoint="helmet"/> <prop actor="props/units/heads/pers_hair.xml" attachpoint="helmet"/> <prop actor="props/units/weapons/arrow_back.xml" attachpoint="weapon_R"/> <prop actor="props/units/weapons/bow_recurve.xml" attachpoint="weapon_L"/> <prop actor="props/units/quiver_hip.xml" attachpoint="sheath_L"/> <prop actor="props/units/shields/pers_pelta_a_b_reverse.xml" attachpoint="back"/> </props> </variant> </group> <group> <variant file="biped/base_hoplite.xml"> <mesh>skeletal/new/m_armor_tunic_short.dae</mesh> <props> <prop actor="props/units/shields/hele_round_e.xml" attachpoint="shield_arm"/> <prop actor="props/units/weapons/spear_hoplite.xml" attachpoint="weapon_R"/> </props> </variant> </group>

Ugh, solitary trees really need to be able to be built over -- disappear -- not block building placement. See his frustration building a wall.

Very nice. Makes me want to revamp the Ptolemaic unit rost, especially the Military Center.

This kind of thing get you in trouble later when the file is changed by the public mod. I should know...

It's very possible a fix I request was added to the public mod and then I was not aware the fix was committed or I forgot. I'll delete my amended file and hope that doesn't screw with something I once thought was important. EDIT: No can do. Deleting my DE Templates.js gives an error in structree about the production queue and structree does not render at all when my file is deleted. DE has 2 units which research techs. The Worker Elephant and Chanakya.These may be the trigger to the error, or it may be because I have not gone through every single tech and added Glory costs to them. If the ultimate fix is to fix the tech costs, then I'll do it, but that means every other mod that adds a new resource will have to edit all existing techs in the game. ERROR: JavaScript error: gui/structree/structree.js line 273 TypeError: g_ParsedData.units[unitCode].production is undefined selectCiv@gui/structree/structree.js:273:1 __eventhandler38 (selectionchange)@civSelection selectionchange:0:1 init@gui/structree/structree.js:40:3 __eventhandler8 (press)@menuStrucTreeButton press:2:8 ERROR: GUI page 'page_structree.xml': Failed to call init() function

Those don't sound like reasons "Good players" would "agree" to not use walls. Sounds like they are overpowered or hard to counter or drag the game out "too long" for some people.

My suggestion @Andrettin is to make everything 3D, and then adjust the camera settings to give you the isometric view you desire. See:

If this is the case, then walls need to be rebalanced in some creative way.

Okay, I believe I did this to allow the Glory costs to show up or something like that. Someone said, "hey, to fix it just add this line to the code, lol!" and I did and it worked. Fixing Template.js fixed the errors though.

I will have to go back through my commits and see what was changed.