| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
variables to their initializer values, rather then zeroing them.
Also handles lists properly now.
|
| |
|
|
|
|
|
|
| |
new method for testing
|
|
|
|
|
|
|
|
|
| |
Thank you, ralphos, for a patch the adapts llSetColor and friends to
a change in the underlying types.
Also, thank you for a much cleaner way of casting types out of
lists, which I will adopt throughout.
|
|
|
|
|
|
|
| |
* This is a HUGE OMG update and will definitely have unknown side effects.. so this is really only for the strong hearted at this point. Regular people should let the dust settle.
* This has been tested to work with most basic functions. However.. make sure you back up 'everything' before using this. It's that big!
* Essentially we're back at square 1 in the testing phase.. so lets identify things that broke.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Types extracted from a LSL_Types.list have to be down-cast initially
to the exact type of value type object that the Object actually is.
This would make for very cumbersome, ugly code when extracting list
parameter items in ll functions where a few implicit conversions
should be applied such as key -> LSLString and LSLInteger -> LSLFloat
(but not LSLFloat -> LSLInteger). This patch adds a set of GetXXXItem
member functions to the LLS_Type.list class, where XXX is the name
of the LSL_Type to be extracted: LSLFLoat, LSLInteger etc. All take
a single, int parameter that is the item number to be extracted.
|
|
|
|
|
|
|
| |
Thannk you, ralphos, for a patch to clean up list item type handling
and add a missing explicit cast in Shared/
|
| |
|
|
|
|
|
|
|
|
| |
1000 chars to avoid the exception thrown by libomv at 1100 chars.
Change string->int conversion so it copes with non-numeric chars
after the number and no longer uses a float to parse the value.
|
|
|
|
|
|
|
|
|
|
| |
It wraps constants in new LSLType(x), so that lists with
constant values are processed correctly. Contains changes to
the lsl.parser.cs that are not (yet) reflected in opensim-libs,
since this experimental patch affects XEngine only. Also contains
nuts.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
XEngine missing string constructor for LSLInteger and LSLFloat
|
|
|
|
|
|
|
|
|
| |
used in scripts
-cast from bool to LSL{Integer,Float,String} so functions such as `integer
isZero(integer x) { return (x == 0); }` work
-progress on issue 1863
|
| |
|
|
|
|
|
|
| |
this commit, issue 1822 should be fixed.
|
|
|
|
|
|
|
| |
-sync Shared/LSL_Types.cs with Common/LSL_Types.cs
-get the test script in issue 1822 to compile
|
|
|
|
|
|
| |
-fix some whitespace/formatting
|
|
|
|
|
|
| |
more complete.
|
| |
|
|
|
|
|
|
| |
1832.
|
| |
|
|
|
|
|
|
|
| |
-fix formatting
-remove CompilerTest test since it seems to fail randomly
|
| |
|
|
|
|
|
|
|
|
|
| |
r5487.
Also put the unit tests back for Bamboo to execute them, let's see how this
goes.
|
| |
|
|
|
|
|
|
|
|
| |
When using math operators +,-,*,/ in an LSL script with an LSLFloat
and an integer literal the wrong result is returned. This patch
adds operators to the LSLFloat type to handle this case.
|
|
|
|
|
|
|
| |
LSLInteger + literal integer is not an LSLInteger.
The included patch fixes the issue: LSLInteger + literal
integer is not an LSLInteger (also fixed for -,*,/)
|
| |
|
| |
|
|
api and compiler out of XEngine"
"First stage in a major Script Engine refactor, that will result in the LSL implementaions ebing reconverged. Not there yet, but one major part is done."
Thank you, Melanie!
|