Miscellaneous section => Off-topic Discussions => Topic started by: paragon on May 13, 2015, 02:56:05 PM
Title: Random tips about fonline developing
Post by: paragon on May 13, 2015, 02:56:05 PM
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
Title: Re: Random tips about fonline developing
Post by: greenthumb on May 13, 2015, 03:16:28 PM
so you are announcing some sort of exploit or what is it
Title: Re: Random tips about fonline developing
Post by: John Porno on May 13, 2015, 04:58:17 PM
dont get your hopes up
Title: Re: Random tips about fonline developing
Post by: paragon on July 11, 2015, 09:15:32 AM
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
Title: Re: Random tips about fonline developing
Post by: paragon on July 30, 2015, 02:53:39 AM
This one is personal
https://youtu.be/5W_wd9Qf0IE
Title: Re: Random tips about fonline developing
Post by: VanCarnY on August 08, 2015, 05:24:36 AM
Suffer omfg, Code Monkey belongs in the music post. this is seriously one of the best songs i've ever heard.
Title: Re: Random tips about fonline developing
Post by: paragon on August 22, 2015, 06:13:22 PM
cr.AddItem( PID, 0 ); will add 1 item with such pid. Sic
Title: Re: Random tips about fonline developing
Post by: paragon on September 14, 2015, 01:29:05 PM
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
Title: Re: Random tips about fonline developing
Post by: paragon on September 17, 2015, 12:28:56 PM
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
Title: Re: Random tips about fonline developing
Post by: paragon on September 17, 2015, 03:37:36 PM
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.
Title: Re: Random tips about fonline developing
Post by: paragon on November 03, 2015, 09:35:03 AM
More detailed example: https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commit/a047be85247755cdbe0acce6f1dafc8beb84f2ac
Title: Re: Random tips about fonline developing
Post by: paragon on November 03, 2015, 11:11:52 AM
UPD: damn, I failed it. What I actually meant in previous post is: We test it absolutely, when we're done with it.
Title: Re: Random tips about fonline developing
Post by: paragon on November 04, 2015, 05:08:06 AM
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.
Title: Re: Random tips about fonline developing
Post by: paragon on February 10, 2016, 07:50:37 AM
<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.
Title: Re: Random tips about fonline developing
Post by: paragon on February 12, 2016, 03:39:48 PM
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.