Print

[paragon]

cr.ParamBase[index] set parameter is stored in gamesave, although
<cirn13379> just a tip if you change params in the DLL directly, it will not trigger the onChangeParams callbacks

[greenthumb]

so you are announcing some sort of exploit or what is it

[John Porno]

dont get your hopes up

[paragon]

cr.isDead() != !cr.isLife() (Negative HP make critter !cr.isLife())
KnockedOut(cr) && !cr.isDead() != cr.isLife()

uuh, simplifying:
cr.isLife() checks for HP > 0 and not knocked out and good knows what else.
cr.isDead() checks for life/dead

thus cr.isLife() is often not what AoP developer wanted to use

[paragon]

This one is personal

Spoiler for "Utube: Code monkey AMV":

[VanCarnY]

Suffer omfg, Code Monkey belongs in the music post. this is seriously one of the best songs i've ever heard.

[paragon]

cr.AddItem( PID, 0 ); will add 1 item with such pid. Sic

[paragon]

In some cases SetChosenActions(null) makes chosen look north-west direction alongside with stopping the action. That's unwanted behaviour but it's the only way to make chosen watch some predefined direction unconditionally that I know.
uint[] a = {0,0,0,0,0,0,0};
SetChosenAction(a); is overwise preffered

[paragon]

Some MSVS+Angel Script manuals
https://xp-dev.com/svn/fonline_sdk/Tools/ASCompiler/MSVS%20Integration/msvs%20integration.doc?p=412
https://xp-dev.com/svn/fonline_sdk/Tools/ASCompiler/MSVS%20Integration/Solution/Readme.txt?p=412

[paragon]

Angel Script lesson
if 2.fos included into 1.fos and a var defined on the root scope of 2.fos then 1.fos can access this var.
That looks like an antipattern to me though.

[paragon]

How do we test our code?



More detailed example:
https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commit/a047be85247755cdbe0acce6f1dafc8beb84f2ac

[paragon]

UPD: damn, I failed it. What I actually meant in previous post is:
We test it absolutely, when we're done with it.

[paragon]

Request sequence during custom-script / engine-hardcoded server calls.

In my case custom-script client to server request (function call) was always faster than following in execution flow engine request. Doesn't mean it will never cause race condition though.

It might or not be what you wanted (probably not). If it's not and you want to have perfect control over situation, then you could try to send all needed data to the server, and simulate situation or it parts from there.

[paragon]

<Tenova> lol what means
<Tenova> *you are no longer fat*
<Tenova> in messbox

Different kind of conditions are applied and pass,
Information messages warning players about it are nice,
But only if they are actual.

Condition drop / clear up functions should check if they actually change the value before notifying about it.

[paragon]

holy. fucking. shit.

class Item
{
const uint8 Mode;
int Val0;
...
}

For weapons Mode consist of
Older 4 bits are aim location.
Younger 4 bits are use type.

Mode has no public setter but being changed in the engine, e.g. during reloads. It's set to default value "primary fire mode".
If your gun is not in primary fire mode before you reloaded, it will change it after. Uncomfortable and confusing.

Val0 used for storing custom data. AoP stores use type in there. Use_Type in Mode is always 0 at AoP.

Many binds/functions required use type, e.g. _WeaponSkill(proto, use).
In AoP _WeaponSkill(weapon.Proto, _WeaponModeUse(weapon.Mode)) will be incorrect,
_WeaponSkill(weapon.Proto, weapon.Val0) should be used instead.

All code uses .Val0 instead where _WeaponModeUse(weapon.Mode) expected.
.Val0 is set explicitly during item manipulations.