Then again, your original post had dividing the base damage by 4, but in that second post, you don't...ut yes, I did :)

"Let's say, base attack is 40"

"dmg = 10 * 1^1 + 10 * 0.5^1 + 10 * 2^1 + 10 * 0^1"

Attack hit box:

Base damage = 10

Lightning = 1

Fire = 0

Earth = 0

Water = 0

Enemy defense:

Lightning = 1

Fire = 1

Earth = 1

Water = 1

Now, I assume this would mean that the damage given to the enemy would be 10, but after trying it out, turned out to be 2.5. I... think I might've missed something. Did I? Or should it happen like that?It depends on how you put in the values to the formula. Remember, 0^1 equals 0, but 0^0 equals 1, so if you raise 'attack' to the power of 'defense', you get 1^1, 0^1, 0^1, 0^1

That's three times 0, and one time 1. Every element influences 25% of the result, so the result is 2.5

The one variable that is set to 0 if that element doesn't exist, should be the power. In that case you'd get

1^1, 1^0, 1^0, 1^0

That's four times 1, which would result to 10

Well, I did have exactly that in mind (the multiple elements influencing each other), but maybe I didn't understand the use of the two variables correctly?

I thought one variable would have a value somewhere between 0 and 2 (the one I called 'lightning', 'fire', etc. And the second one would have a value of either 0 or 1 (according to your explanation: "If an attack didn't have one of the elements, that element would be set at 0."), the one I called "...existance"

If both assumptions are given, then that formula works quite good. Let's just look at the four damage examples you made in the first post and pretend they are an "omni-elemental" attack. Let's say, base attack is 40. Then

dmg = 10 * 1^1 + 10 * 0.5^1 + 10 * 2^1 + 10 * 0^1 = 10 + 5 + 20 + 0 = 35

5 lower than the base attack, which makes absolutely sense, because while there is a double damage there is also a half damage, a normal damage and last but not least no damage.

Each of the 4 elements will always influence the result by 25%. If there is only one element, you'd double only 25% of the result (which would lead to 50 in the example above, where base attack was 40). If that was not the intention, that formula won't work for you, of course.

If you rather want something like "double the base damage, no matter what element is active", then I currently can't think of a reliable solution in only one formula, as you seem to aim for. (But maybe others can :) )

What I don't understand:

I sent a game to a friend, a simple .exe with no instructions whatsoever. The next day I asked if there were any problems. Answer: "No, started the application, it wanted me to install something, I agreed, and the game runs nice."

Could it be that often people just ignore the window that tells to install that needed files?

First problem:

Instead of multiplying element by elementexistence, use e to the power of ee. If an element exists, ee equals 1, else it equals 0

x^1 = x

x^0 = 1

(This works even if x = 0. 0^0 = 1, 0^1 = 0)

So, if e is 2 and ee is 1, the result is

2^1 = 2

If it doesn't exist, it's

2^0 = 1

Second problem:

Instead of multiplying all, split base damage into 4 parts (l = lightning, le = lightningexistance, f = fire, fe = fireexistance, etc.):

dmg = (b / 4) * l^le + (b / 4) * f^fe + (b / 4) * e^ee + (b / 4) * w^we

First part of your questions: No, C2 is still a bit behind CC.

Second part: Not easy to answer. It depends on your goals. For example, if you want to create an executable, there is no other way than CC, but if you want to make a browser game, you need to use C2.

That color suits you <img src="smileys/smiley4.gif" border="0" align="middle" />

Congrats Kya <img src="smileys/smiley32.gif" border="0" align="middle" />

Please don't apologize. There is no need to! This is the help forum - where if not here could one ask for help? <img src="smileys/smiley1.gif" border="0" align="middle" />

Hey 00Rez,

I like your work so far. Just keep on going, I think it is the right way.

For the rendering "issue": You might want to try deleting every object that is not lit.

I made the tests and I think there is something wrong either in the fps calculation or the code itself. But first the results:

pretty example: 8-9

rad 1: 56-60 (22-25)

rad 3: 56-61

rad 5: 58-62

rad 7: 60-64

rad 8: 47-51

rad 9: 36-40

rad 10: 29-31

rad 11: 24-27

rad 12: 21-22

Now the thing is, to me it makes no sense that the framerate decreases if I decrease the radius from the starting 7 down to 1. But more obviously there is another issue. If I decrease the radius from the starting point down to 1 the resulting framerate is 56-60. But if I get to radius 1 by increasing from the starting point all the way up to radius 12 and still increasing, where it automatically switches back to 1, then the resulting framerate is 22-25. So there is something wrong, although I don't know what :)

This is a very good project. It shows the hesitating people, like me, how far you can already go with C2. I will use this project (if you will post further updates, that is) to see the progress of C2 and my browser's speed :)

Set text doesn't change anything. It just does what you tell it to. You order the text box to set the text to the word "Lives".

A global variable is adressed with the keyword global.

Here is a cap showing how you have to do it.

Also, please have a look at the wiki. It really helps with issues like this one :)

<img src="smileys/smiley5.gif" border="0" align="middle" />

Previewing isn't working anymore.

Have a look at the image:

Object A is the one that moves, Object B is the one that moves around Object A. The green rectangle defines the region in which Object B moves around Object A.

You have to do two steps: Create a movement within a region with origin (0, 0) and set the boundaries relative to Object A's hotspot.

Let's say, the green rectangle represents a region of 200x300 pixel. The points P1 to P4 then are (0, 0), (199, 0), (0, 299), (199, 299). Object B has 7 private variables: nx, ny, ox, oy, cx, cy, t

cx and cy represent the current position within the region, nx and ny represent the new position that Object B has to reach, ox and oy the last position that was reached and t is the t-value for the lerp expression.

Some random starting position (you could as well just set the initial values of the PVs):

+ Start of layout

-> Object B: Set 'cx' to 80

-> Object B: Set 'cy' to 90

-> Object B: Set 'nx' to 80

-> Object B: Set 'ny' to 90

-> Object B: Set 'ox' to 80

-> Object B: Set 'oy' to 90

-> Object B: Set 'tx' to 1

If Object B reaches nx/ny set a new position (use 'Pick by evaluate'):

+ ObjectB: Pick by Round('cx') = 'nx' and Round('cy') = 'ny'

-> ObjectB: Set 't' to 0

-> ObjectB: Set 'ox' to 'nx'

-> ObjectB: Set 'oy' to 'ny'

-> ObjectB: Set 'nx' to Random(200)

-> ObjectB: Set 'ny' to Random(300)

While valid calculate the current position within the virtual region and make the region relative to Object A's position:

+ System: Always (every tick)

-> ObjectB: Add 0.5 * TimeDelta to 't'

-> ObjectB: Set 'cx' to Lerp('ox', 'nx', 't')

-> ObjectB: Set 'cy' to Lerp('oy', 'ny', 't')

-> ObjectB: Set position to ObjectA.X - 100 + 'cx', ObjectA.Y - 150 + 'cy'

This is just one movement style for Object B. You would have to adapt your own to this scheme. For example, the region is set centered around Object A's hotspot. You might want to have it not centered. Then calculate the "hotspot" of the region accordingly in the last action of the "always"-event. But the basics stay the same: "Move" the object within a virtual region. Then set the region relative to the first object's position.

Here is the .cap: http://www.mediafire.com/file/tkk496k08okk65q/relative.cap

The "pause" happens, because "alt" is a system hotkey that sets the focus to the window's system menu (restore, minimize, maximize, exit, etc.) This menu exists if the window has a caption bar (it is the one you get if you left click on the icon in the title bar, or rightclick the title bar). So the quickest way to prevent this behavior without python or some plugin is to disable "caption" in Application Properties/Window Properties, or to go fullscreen.

To be honest, this is the first time that I see this behavior. It is an issue that should be avoided by Construct if possible.