Author Topic: Annikk's Mechanics  (Read 10536 times)

0 Members and 1 Guest are viewing this topic.

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 1,794
Re: Annikk's Mechanics
« Reply #15 on: January 27, 2011, 09:33:45 AM »
I was examining the parallax engine today and noticed that colours are currently done per-layer, rather than per-star.  I'll need to modify the guide to make note of that at some point.

Actually I'm thinking of modifying the whole engine.  I want to introduce sizes per star, rather than 1 size for all stars.  That will enable twinkling.  :>  Also I think I might make some slightly more n00b-friendly default values....
I'm working on a new level right now which will use the parallax engine (hopefully).

AWS

  • Achiever
  • Arboreal Being
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 274
Re: Annikk's Mechanics
« Reply #16 on: February 01, 2011, 07:05:29 PM »
I was examining the parallax engine today and noticed that colours are currently done per-layer, rather than per-star.  I'll need to modify the guide to make note of that at some point.

Actually I'm thinking of modifying the whole engine.  I want to introduce sizes per star, rather than 1 size for all stars.  That will enable twinkling. ...

hows this improving going?
got it twinkling yet?
im most interested as i want to use this for my next effort...
:D


annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 1,794
Re: Annikk's Mechanics
« Reply #17 on: February 01, 2011, 07:15:10 PM »
If all goes well, the Parallax engine will be rendered totally obsolete within a few weeks.


See this thread for details.

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 17
  • Posts: 899
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #18 on: February 01, 2011, 07:17:58 PM »
C'mon, at least let us get used to the old stuff before releasing new ones!

You don't work for Apple really do you?

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 1,794
Re: Annikk's Mechanics
« Reply #19 on: February 01, 2011, 07:25:36 PM »
Crappy parallax engine.  It's so complicated to configure!
Trust me, you guys are not going to want to go back.  The new one will be simpler to understand, and it looks sooo much better.  It's only the engine that got more complicated; the Init section is easier.


Also, the concept of "parallax layers" specifically has been deprecated entirely.  That concept doesn't exist in the new engine.  Instead, depth is derived literally from a Z-coordinate.  So when you make a star in the StarfieldInit() function, you set it's X position, its Y position, and its Z position.  Everything you need to specify in setup is now either a global value (eg numberofstars = 200) or it's specific to individual stars (eg SetStarX[0] = -2000)
I think that is much more intuitive than layers.

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 1,794
Re: Annikk's Mechanics
« Reply #20 on: February 15, 2011, 07:28:57 PM »
RIP Parallax Engine.


EDIT - This is a demo only, NOT A TEMPLATE.
« Last Edit: February 27, 2011, 10:59:35 AM by annikk.exe »

AWS

  • Achiever
  • Arboreal Being
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 274
Re: Annikk's Mechanics
« Reply #21 on: February 16, 2011, 08:25:54 PM »

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 1,794
Re: Annikk's Mechanics
« Reply #22 on: February 16, 2011, 10:23:41 PM »
That's a playable level file, by the way.
Just some fireworks I threw together with the new engine.  Go ahead and load it up - it's freaking awesome!  And then you'll understand why this signifies the end of Parallax and the start of 2.5D.  :>


Expect a 2.5D Engine Template to appear shortly..... or eventually...

AWS

  • Achiever
  • Arboreal Being
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 274
Re: Annikk's Mechanics
« Reply #23 on: February 17, 2011, 11:36:45 PM »
hey annikk, are you adding the 3D engine to this thread and keeping the parallax stuff? deprecating it?
whats the deal, yo?

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 1,794
Re: Annikk's Mechanics
« Reply #24 on: February 17, 2011, 11:41:36 PM »
Still trying to decide.  I am temped to just keep Parallax for the time being due to the better performance, and hold off releasing 2.5D until I hear if A&R might be able to add the DrawSpriteBehind command I requested the "I want to but I can't" thread.. :>

threephi

  • Sapling
  • **
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 63
Bug workaround for Infected AI
« Reply #25 on: June 01, 2011, 05:58:54 AM »
Hey Annikk, I've been playing the EXTREME PWN LAZ0RZ!!12 level (I love that name btw ;)) quite a bit lately, and thus running into that mixed tree bug that I posted about several times in that thread.  It was bothering me so I decided to do something about it.

Today I took a long look at the Infected AI code, and did a lot of testing, and I fixed it ;D

The bug actually stems from a flaw in the PlantDysonTree(faction) function in the game engine. This function will plant a tree of the designated faction on any asteroid so long as that asteroid has an available planting slot and the requisite number of that faction's seedlings, even if the asteroid already belongs to another faction and has existing trees growing there (which should make it unplantable by anyone else).  The result is trees belonging to different factions growing on the same asteroid.  This bug probably also exists in PlantDefenseTree but I didn't test it.

The formulas in the Infected AI that determine the asteroid metric values do allow for conditions where this bug is possible (for those reading along, in a nutshell it has to do with not having enough seedlings on an enemy asteroid to count as an attack, yet enough to plant a tree, and there is an open tree slot).  I didn't want to mess with how you have the metrics balanced, and figured it would be best to fix it at the planting stage, not the filtering stage.  This makes a sort of secondary metric 100 condition where an enemy asteroid has open tree slots but can't be planted yet; maybe it's a good thing since the low metric will encourage that AI faction to send seedlings towards it anyway, and soon enough tip the balance towards metric 0 and full attack... blood in the water if you will ;)

Without further ado, here is the relevant section from the Infected AI code, with the workaround included.  Essentially it performs the check that the function is supposed to, but doesn't.  The altered code is enclosed with the comment "bug workaround".

Code: [Select]
-- Actions

-- There are 3 different action types.  We must make sure not to use any actions for players 0 and 1!
-- 1.  Plant trees

-- trap for player 0, exclude player 1
if checkedroid.owner == 0 or checkedroid.owner > 1 then
-- so plant one :>
for i = 2,10 do

if metric[checkedroid.id] == 100 and (checkedroid:GetNumSeedlings() - checkedroid:GetNumSeedlings(i)) < 5 and checkedroid:GetNumSeedlings(i) > 9 then
-- this asteroid isn't owned by greys or player, the enemy only has a bit of seedlings here
-- its metric is 100
-- and it has enough seedlings belonging to the asteroid's empire to plant a tree
-- bug workaround: and there are zero growing trees on the asteroid, or the faction with enough seeds to plant actually owns the asteroid
-- this is necessary as PlantDysonTree() will plant a foreign tree on another faction's asteroid even if trees are already present
if checkedroid:IsBarren() or checkedroid.owner == i then
a = checkedroid:PlantDysonTree(i)
end
-- bug workaround end
end
end
end

-- 2.  Send seedlings to the next lowest metric

After spending about three hours today poring over the Infected AI code, I want to once again tip my hat to you for how smart that code is, and thank you especially for the copious comments that made figuring it out a LOT easier!

I made several attempts before settling on the above fix (which happily is quite small!).  The secret sauce is the IsBarren() function, which does two magical things at once: it traps for an asteroid with zero trees no matter who owns it, and it also, unlike any other function I could find, distinguishes between a fully planted root and one that hasn't finished planting yet.

I hope you will consider adding this fix into the main code and updating it since IMO the impact of this bug can be rather serious, and make a level unwinnable.

If anyone wants to see the bug in action, I made a test level (attached to this post) based on the the example Infected AI where I tried to set the preconditions that would automatically trigger the bug, but found that a bit daunting.  There seems to be an additional required element I haven't figured out yet.  But you can use this test level to very easily and clearly show the bug in the PlantDysonTree function:

N.B. the Infected AI in this test level does not include the workaround for this bug.

1) Load the level.
2) Immediately upon loading, hit esc and ` to pause the game and open the lua console.
3) Enter the following in the console:
Code: [Select]
GetAsteroid(0):PlantDysonTree(3)4) Unpause, and you will have an asteroid with trees belonging to two different factions.
« Last Edit: June 01, 2011, 06:29:40 AM by threephi »

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 1,794
Re: Annikk's Mechanics
« Reply #26 on: June 01, 2011, 10:05:38 AM »
I followed your instructions and was able to recreate (in your test level) an asteroid belonging to 2 different factions.  :>

Going to theorycraft my way through the engine now to see if I can visualise how it might occur "in the wild" so to speak.

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 1,794
Re: Annikk's Mechanics
« Reply #27 on: June 01, 2011, 10:37:10 AM »
Well, I've thought about it, and I think your assertions about the engine and analysis of the bug are spot on.  I can visualise certain situations where a multi-owner asteroid might occur.

I tried to think of a good test to see if checking IsBarren() would prevent the bug from occuring.  I settled on trying the following line in the console immediately after entering your test level:

if checkedroid:IsBarren() or checkedroid.owner == i then a = checkedroid:PlantDysonTree(i) end

As I'd hoped, a tree did not plant.  The asteroid was only owned by one empire.


I am satisfied that you have proved the existence of the problem and developed a good fix for it.  Congratulations and thankyou very much.  :>  I will now edit EXTREME PWN LAZ0RZ!!12 and the AI engine template to include your bug fix, and will credit you with finding and fixing the bug.

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 1,794
Re: Annikk's Mechanics
« Reply #28 on: June 01, 2011, 11:39:03 AM »
EXTREME PWN LAZ0RZ!!12 and the AI engine template and "after" file have all been updated with the fix.

threephi

  • Sapling
  • **
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 63
Re: Annikk's Mechanics
« Reply #29 on: June 03, 2011, 06:30:37 PM »
I posted about the bug in the support forum, and in formulating that post I realized there's a shortcoming to using IsBarren() since it will return true for an asteroid with TreeCap = 0 :-[  It doesn't affect the infected code, since you won't get to the planting code unless you have metric 100, which in turn means there is an open tree slot on the asteroid, but it's not the most elegant or transparent solution.

After thinking it over a little more, a more complete test for plantability is as follows:

(assuming the correct number of seedlings is present)
checkedroid:AvailableStructureSpace() and (checkedroid.IsBarren() or checkedroid.owner == i)