Jump to content

  2. i30817's Content

i30817's Content

There have been 71 items by i30817 (Search limited from 12-May 23)


By content type

See this member's


Sort by                Order  

#540720 [WIP] Expanded Triggers

Posted by i30817 on 02 May 2012 - 04:15 AM in ToBEx

If you're doing all that for strings you are implementing a (probably buggy, no offense), parser and interperter on top of the other.

I think that if you're going to use muParserSSE for the maths (and it seems the right choice) should add a EvalString trigger for your string variables so there is "single responsability" for the functions.

You can setup this trigger based on printf ⁻ without the variable number of arguments, so you'd need to use assign as a replacement for those.
EvalString("@1, @1 and @2")
All the variables used in those would be assumed to be strings so could even be referenced by another symbol (and have a different "variable array") - unsure if it needs position since it there is only one string allowed in triggers?
If you want to use a number here from something that is naturally parsed as a int (say a e[3+5] on a assign), using the STR mode on the assign will try to convert to string and put it the string pool.

0x411A Assign(S:Statement*,I:Type*ArgType,I:Local*)
0x411B Eval(S:Expression*, /*maybe I:Type*ArgType */,I;Loc*)
0x411C EvalString(S:String* /*maybe I;Loc* */)

Leave the Eval only for int and math expressions. You can use them with strings anyway with e[] on the assignment, if STR Mode on Assign will try to convert to string.
Isn't it better?

If you want Eval("something", y), where y is the argument number from the trigger to replace, and "something" is a string type:
-First, the library must parse the "something"

No longer needed with the other scheme above, just straightforward string expansion. For the int expressions, sure, but that would happen anyway.

-Second, I have to search ahead
-Third, I need to check if the argument exists
...
-Finally, if type is valid, I will modify the value

Yes

-Fourth, I need to parse the trigger construction to check type

Table of TRIGGER.IDS names and arguments types built at startup?


#540714 [WIP] Expanded Triggers

Posted by i30817 on 02 May 2012 - 02:42 AM in ToBEx

4) What's the reason you put in Types in the Eval function?

I am forcing the modder to give explicit types for everything. If a type mismatch occurs, TobEx will bail out and not assign anything. If bDebugVerbose is active, you will swamp your TobEx console with warnings/errors.

For the arguments, just consider TRIGGERS.IDS and ACTION.IDS, the information of the type of argument expected is already there, given the 3rd position parameter.

No, the argument is given by the Trigger construction. Assign will always expect an int in the 3rd position. That doesn't tell you whether I should put a int into the position or a string into it.


I don't understand this: if i understand correctly; the 3rd argument of Assign is the variable 'slot'. The 3rd argument of Eval is the actual argument position to replace in the next trigger.
I was refering to the eval 3rd argument. Given that position and the values on TRIGGERS.IDS, why not build a table with the expected argument types and compare the result of eval (from the evaluation library) with
the actual type expected, if you're wanting debug validation?
Of three results of Eval: typeerror, int, "boolean" or string (if the library supports strings), they can all be typechecked with such a table
Of course, maybe i'm expecting too much of the library...

More; i think making it obligatory to add a type to "Eval" will make the proposed WEIDU compiler trick harder to implement (since the_bigg has to care about the "expected" type), he would probably read it from trigger.ids to get a sane value to put there, you can do the same algorithm at runtime if debug mode is on (and will be able to actually typecheck since you'd then have the type of the expression to compare).

ie: the expected type is the type the function expects, not what the scripter thinks the Eval'd expression will output as a result (since who decides that is the library). And that value can be derived by the position and the trigger (which you can recognize when you get to it later right?)

5) it seems that assignments got a whole lot more complicated, when you start allowing the use of variables inside them.

Not really, variables are replaced first. As stated above, I will parse them myself rather than rely on the math expression library.

I'm mainly worried about strings: if you allow strings arguments to be passed to Eval (which you need to for them to be used) and the library doesn't support string, you need to do a pass over the string to see if it there is a single "#string_variable" (or similar) and do the substitutions and skip passing it to the library, since it will choke one it.
Note that this means that you can't use number arithmetic and concatenate strings and kinda turns into a hack. Maybe it's best for performance though.


#540690 [WIP] Expanded Triggers

Posted by i30817 on 01 May 2012 - 10:00 AM in ToBEx

Is there any script action that saves points in globals/locals?
If there is, a Assign for points X_INT and Y_INT would be nice, to do some geometry.

I'm specifically thinking that if it can get a holdoff the location of the center of the "cloud" spells, can save that in a global somewhere and get my character location and do some simple geometry with those variables, i can avoid/flee the clouds ratio. Maybe something for spell revisions.


#540687 [WIP] Expanded Triggers

Posted by i30817 on 01 May 2012 - 09:23 AM in ToBEx

Hmmm. With re-assignment there is no reason not to keep them forever - there's only going to be 25 max anyway.
It's with the Eval that you've got to be careful (so if it fails, it doesn't affect a trigger in the next block for instance).

though to be honest i kinda think that for the script engine to really fly would need to cache the compiled code, and that would require some funky Assign/Eval trick (wouldn't need to recompile... or eval again, if the Eval arguments didn't change, as there is no source of side efffects on the language). How do you know the arguments didn't change? :whistling:


#540678 [WIP] Expanded Triggers

Posted by i30817 on 01 May 2012 - 05:14 AM in ToBEx

yeah, it's just so they "look the same", if you implement the
E(<#1 + 7>, 0) ->  Eval("#1 + 7", INT, 1) E(-33, 0)
transformation (or another like it)

The 2nd argument (the type) of both functions is bugging me.
As far as i can tell, if the evaluator library support strings it only needs one thing for it's string arguments: to wrap the string in the argument in two \" before replacing the occurrences of it in a expression. Since when you assign the arguments, you know where they come from (if they are supposed to be a string or not), why not mark that automatically?
Even if you want to allow "type conversion" by using that in the "Assign", surely it is not needed in the "Eval", since you already know that #1, #2 etc is a string or a int from the "Assign"

BTW, a isTrue(I:boolean) trigger would be useful to be "variable substitued" with a boolean Eval().


#540676 [WIP] Expanded Triggers

Posted by i30817 on 01 May 2012 - 05:07 AM in ToBEx

May i suggest another scheme for finding the data to assign? Tell me i'm dumb if it won't work.

[HPCLASS.0.1] for table (starts with [ )
G.data for a global named data (starts with G.)
L.data for a local named data (starts with L.)
C.LEVEL (for stats; character level, character strength etc).
Expression can use the string delimiter that weidu ends up choosing for the transformation, imagine it's < and >:
<#5+5>

(all of these strings)

I'd like this stuff to be easy to read and easy to distinguish. If someone has better suggestions, please post them!


#540673 [WIP] Expanded Triggers

Posted by i30817 on 01 May 2012 - 03:55 AM in ToBEx

Comments and questions (hope you're not sick of me by now):
1) muParserSSE doesn't have support for string vars. Are you planning to use another?
2) what's the "tn" and "id" prefixes? "e" should be expression right?
3) I like allowing using the evaluator in assignments. I'd forgotten that it might be useful to use a expression to access parts of tables for other assignments etc.
4) What's the reason you put in Types in the Eval function? Is it the expected return value of the expression in the first argument? The expected type of the arguments used in the expression? If it's only that... is it really needed? For the return value; I expect trying to put in a string - 10 would return a error in the evaluator library (maybe not for operator +, which may be string overloaded). For the arguments, just consider TRIGGERS.IDS and ACTION.IDS, the information of the type of argument expected is already there, given the 3rd position parameter.
5) it seems that assignments got a whole lot more complicated, when you start allowing the use of variables inside them. And the Type  2nd argument, it's like a cast right? Try to treat a 2da value as a int, or a global as a string? That stuff only seems useful if your evaluator library will alllow typechecking - which is unlikely to say the least. What's the type going to be used for; since in the eval library all the types need to go as strings arguments?


edit: edited stupid error in last paragraph, reread if it seemed stupid before.
edit2: more edits, now the whole post.
edit3: one more question
edit4: deleted a dumb suggestion
edit5: deleted another dumb suggestion (it would be slower)


#540671 [WIP] Expanded Triggers

Posted by i30817 on 01 May 2012 - 02:48 AM in ToBEx

What are the prefixes which are free in weidu?

I didn't put it in a string because i know that bgscript doesn't have multipart expressions in the arguments (or indeed, anything other than a number, point, object specifier or a string), so i was hoping that weidu could recognize a
multi-part expression | single variable expression | function
in a argument of a trigger inside eval (even better would be generally, so the Eval() pseudo-opcode isn't needed).
If it was a string, i don't see how that transformation would figure out which arguments to replace and which not. Unless you define another string-like construct for the expressions, something which doesn't clash with the lexer/parser - it's the simpler solution and maybe the best one, because it's grammar agnostic in relation to the evaluator library used.

As for the innefficiency with unneeded Evals.... uh, i don't suppose your parser has 2-phases? But i still think it's worth it even if slower than ideal.
Actually, i think that the implementation Ascension64 presented requires the evals of the replaced arguments be right before the affected trigger - to do otherwise would need a cache. At least that's what appeared to me in the examples he showed. Can you confirm Ascension64?
I finally figured out you were talking about Assigns.
The assignments are separate from the Eval triggers, another opcode, and wouldn't need to be part of the transformation. I also doubt they'd need to be repeated for multiple expressions. Do you have a better suggestion that separating them?


#540658 [WIP] Expanded Triggers

Posted by i30817 on 30 April 2012 - 08:38 PM in ToBEx

Also, is there really a need of the position argument (the last int) in the Assign functions?

Couldn't it be handled internally? Unless you want reassignment.

edit: Never mind, i can see how 10+ assignments might get confusing.

edit2: just one assignment opcode attempt:

Assign("STAT.LEVEL", 1)
Assign("GLOBAL.xyz", 1)
Assign("LOCAL.xyz", 1)
Assign("HPLEVEL.0.1", 1)//int from 2da - actually, i can't tell if they're supposed to be strings normally instead - they sometimes have strange "default" or marker values. Instead of -1 - this is a problem if you want to use them in expressions. Are you going to error if you read something which is not a int? Ignore the assignment?
Assign("EXPR.#2 + 3 + #1", 1)//not quite sure now if expr assigment is a good idea - recursion is a problem.

And strings?
AssignString("HPLEVEL.0.1", 1)//different opcode, assign var as string for the replacement/script engine
or
Assign("String_HPLEVEL.0.1", 1)//same opcode, parsing inside to distinguish?

edit3: muParserSSE doesn't allow strings in it's expressions. Neither MathPresso i suspect (it's homepage is spare). Since muParserSSE seems to have embedded math functions, i'd prefer it.

edit4: i suspect you might want to setup a limited (and simple) inmemory cache for 2da values that are "assigned". They can't change, and you don't need to parse the 2da again. Unless that data is already inmemory from the engine?
It would be nice if you could compile the expression separately from the variables (so you could cache the compiled code), but this link seems to indicate that you'd need to check that the variables didn't change too - you can't change the variables value after compilation- otherwise, you'd need to recompile. Seems hard to cache - but maybe the jit does it internally.
But if muParserSSE is faster because the benchmark was actually separating the compile function time from the execution - i can't find the benchmark code - then maybe you won't get the "full" performance without caching. But feel free to ignore this stuff, you know the saying about premature optimization.


#540653 [WIP] Expanded Triggers

Posted by i30817 on 30 April 2012 - 07:08 PM in ToBEx

Oh i just noticed in your reply that you have overloaded assignments strings too.
That throws a wrench on the "weidu transformation" stuff.
I think i'm going to ask the_bigg for his input on this stuff if you don't mind.

edit: then again, maybe not - if he can use TRIGGER.IDS to see what the type of the argument should be, there should be no problems with the substitution. Just add "" instead of 0 for the string arguments replaced.


#540652 [WIP] Expanded Triggers

Posted by i30817 on 30 April 2012 - 06:42 PM in ToBEx

I really like that preprocessor trick if the compiler itself will not change... it looks like it will prevent errors (besides being shorter)

Other thing: are you planning to "clear"/reset variables on block end? Or after use in Trigger? Because "AssignExpr" would be fairly useless if it could only be used in one trigger.
I think block is much better.

They have to be reset, so as not to corrupt the next block triggers right? (On success and block failure - if Eval2 of a block with Eval1 previously fails for ex).


#540531 [WIP] Expanded Triggers

Posted by i30817 on 29 April 2012 - 06:25 AM in ToBEx

I'm not clear yet if E, LT and GT are the only triggers whose arguments can get replaced?

I'm  satisfied your mode approach - i'm conditioned to avoid parameter "specialization" arguments, by some years of pedantic professors nagging, don't mind the bite.

I like the "AssignEval" idea, but suggest it to be named "AssignExpr" or something so as not to confuse.
The reason it's not a mode is that it would require two strings right?
Could the mode be a INT argument of "Assign" and thus "AssignExpr" be folded into it
NVM i see why you used a string: so GLOBALS and LOCALS can be assigned with only one string.


#540529 [WIP] Expanded Triggers

Posted by i30817 on 29 April 2012 - 05:27 AM in ToBEx

If I am in a trigger block of 3 triggers, of which trigger 1 and 2 substitute some of the variables in trigger 3, I cannot program so that when the engine is looking at trigger 1, it searches ahead for trigger 3 and replaces some values in it. That would destroy trigger 3 and breaks the GemRB static caching system.


Search ahead is "wait for execution of the script engine to get to it"? I was assuming you could collect the arguments from those new assignment triggers and just wait ("search ahead") for the next trigger that isn't a assigment or triggeroverride or or. Then replace the number of arguments that aren't "DEFAULT" on the trigger struct.
Though i see the problem, you'd wouldn't be able to know which assignment to give to which non-DEFAULT, and would need to use a default order, like "last assignment first" or something like that.
I see now why you're using Eval1 and Eval2.

Hmmm... nasty.

I suppose a compiler trick like WEIDU does for triggeroverride is out of the question?

3 opcode variants (need better names):
EvalBoth(E(0,0),"#1", "#2+5") //E(#1, #2+5)
EvalFirst(E(0,0),"#1")		   //E(#1,0)
EvalSecond(E(0,0),"#1")	 //E(0, #1)

and if possible, to use any trigger... though i don't know how it would work with triggeroverride in the mix
... though it occurs to me that if WEIDU would do a transformation, why not:
Eval(E(#1,0)) => Eval1("#1"), E(-33, 0)
Eval(E(0, #1 + 4)) => Eval2("#1 + 4"), E(0, -33)
Eval(E(#2, #1)) => Eval1("#2"), Eval2("#1"), E(-33,-33)

so there would only be two "real" Eval triggers and one that would appear in the scripts, joined to the trigger it would affect. Not using a string so WEIDU doesn't get confused on a trigger which does have a string argument. Not sure what's best for that - a expression special case that allows #number (math evaluator lib functions would not parse in weidu - but if it passes the lexer it's enough i think - as long as it doesn't get confused by nested "/)/(/," and can distinguish the exp from the ""normal" arguments.)


#540524 [WIP] Expanded Triggers

Posted by i30817 on 29 April 2012 - 03:35 AM in ToBEx

BTW,

It seems that you want to use Eval as returning conditional expressions specially?
Because then you'd can't distinguish between failure due to syntax/runtime/divby0 error in the expression and due to the expression returning false (since it's going to be jit-ed or interpreted at runtime).

I'm also wary of how you'd use a int expression later on, unless you want to treat eval like another Assignment? Eg:
IF
  Assign("STATS.LEVEL", Myself) //saves #1
  Eval("1 < 2")//returns true saves #2 (1)
  Eval("6+ #1")//not boolean only returns false if the expression failed (it won't), saves #3
  E(#3, 4)
THEN...

My examples above were using nominal variables and positional Eval expression results. And i was not counting on Eval returning anything except if the expression was parsed and computed successfully or not (and the have the possibility of using the result in a later trigger).

I don't think it's a good idea to make Eval return anything except expression parsing/compilation success or failure (don't overload the return). And that it's needed to save the result of eval expressions, not just variables, if they are going to be used in triggers.
I'm not sure what is more confusing, to use the same indexed positions ordering for expressions or to use another indexation
(like #1,#2 for variables and €1, €2 for expressions or something).


#540522 [WIP] Expanded Triggers

Posted by i30817 on 29 April 2012 - 03:10 AM in ToBEx

Could explain with small words why would it destroy the next trigger? Is it because you're piggybacking on that trigger hidden arguments or something? I know from checking the source of TobEx that there's only one large trigger function.

Edit: oh only one string argument per trigger. So they have to be positional, not nominal to allow reading from maps. Bummer.

But why doesn't this work?
IF
  Assign("STATS.LEVEL", Myself) //deleted the number... unless it's critical to reassign?
  Assign("STATS.LEVEL", NearestEnemyOf())  
  Eval("%1 + 6 <= %2")
THEN...
If you indeed replace the variables (as you'd have to if you used nominal ones anyway).
Please don't use the % symbol (it's a math operator).

#1, #2 etc should work ok ( i don't think the cardinal set symbol will be used).
or even 'at'
@1, @2
either is a good metaphor


#540520 [WIP] Expanded Triggers

Posted by i30817 on 29 April 2012 - 02:24 AM in ToBEx 

IF
		ReadStat(Myself, STATS.LEVEL, "MyLevel")
		ReadStat(NearestEnemyOf(), STATS.LEVEL, "EnemyLevel")
		Eval("MyLevel + 6")
		Eval("EnemyLevel")
  OR(2)
		LT(%1, %2)
		E(%1, %2)
THEN
  RESPONSE #75
		RunAwayFrom(NearestEnemyOf(),90)
  RESPONSE #25
		AttackReevaluate(NearestEnemyOf(),90)
END

The crazy expressions should be handled for you by the mathematical evaluator library you choose (if you can bind variables). I suggested you separate the assignment and evaluation and use (unlike your example above), because
1: you might want to use the same variable more than once in 2 expressions (or even the calculated expression)
2: it's easier to read if you do want a expression (granted, it's harder if you don't)

Do you think you can do something that "intercepts any" next trigger (except or or trigger override of course), and replace the first int, the second int etc? It would probably be ideal (not sure if strings arguments would be useful in this context), so people could use E() or CheckStat or whatever.
It also would remove (most) need of write functions, if you can just SetGlobal and derived value (but not sure about stats).

It would probably be useful to make warnings for more Evals than there are arguments in the next one (and to clear the variables binded at the end of the block, so no funny business happens in the next one).

If you can hack the compiler, i suggest making it accept either a placeholder (such as _) or a positional argument like in your example; so that you can match the Eval(s) completely to a trigger and warn if there are less or more than the placeholders.
I never took a compiler class, so i better shut up now.

edit: i mentioned the point because they'd be another kind of "next argument" that would have to be handled specifically if you wanted to allow the triggers and actions that use that argument with a calculated value.

edit 2: you might want to add a trigger that evaluates a boolean expression so you can write this instead of OR, E, LT and GT
Bool would be something that just returns bgscript true for 1 and false for 0 (or whatever the evaluator returns for booleans).
IF
		ReadStat(Myself, STATS.LEVEL, "MyLevel")
		ReadStat(NearestEnemyOf(), STATS.LEVEL, "EnemyLevel")
		Eval("MyLevel + 6 <= EnemyLevel")
		Bool(%1)
THEN
  RESPONSE #75
		RunAwayFrom(NearestEnemyOf(),90)
  RESPONSE #25
		AttackReevaluate(NearestEnemyOf(),90)
END


#540516 [WIP] Expanded Triggers

Posted by i30817 on 29 April 2012 - 12:04 AM in ToBEx

Oh, btw, weren't there some strange datatypes stored in LOCALS or GLOBALS in BGScript? Like radians or floats? It's not all ints right?

Edit: P:Point

[x.y].

edit: I'm still not clear if it's going to be possible to use arguments from LOCALS or GLOBALS in functions that don't expect it.
You're only doing it for E() LT() and GT() for now (or ever)?

For instance,
CheckStat(O:Object*,I:Value*,I:StatNum*Stats)
will be able to check a stat against a value in that map (as it can't now, without WEIDU unrolling all possible values?)

If it could be made general - though i suppose this would interfere with GemRB caching Avenger warned about above?


#540514 [WIP] Expanded Triggers

Posted by i30817 on 28 April 2012 - 11:45 PM in ToBEx

Just to reiterate if my last post was confusing, i'd much prefer new ReadXXXX/WriteXXXX functions than arguments.

If i've read the arguments right:

ReadGlobal("blah", "X", VAR)
ReadLocal("bleh", "Y")
ReadStat("STR", "Z")
Read2DA("HPCLASS", 0, 1, "N") etc.

And write forms.

Calculation engines... there is this .NET thing: http://ncalc.codeplex.com/
but i'm not sure if it's pure c++ (or if it's too much... dates?).
edit: nope, it's C#

As for wine, there is no reason not to try (unless it's just a wrapper over a javascript script engine - that would be bad).


#540511 [WIP] Expanded Triggers

Posted by i30817 on 28 April 2012 - 09:54 PM in ToBEx

I don't really like the modes idea, and i'd prefer overloaded versions for each... I'm used to that kind of programming, not argument modifiers.

Unless there is a reason you can't (or would prefer to keep) have many more triggers or actions.

A person that should give his input is certainly the_bigg. He's already helped a lot with the TriggerOverride syntax translation (and if that idea is applicable here, one less argument would help a lot).

As for arithmetic, can't you do a "simple" infix to postfix string evaluator?
http://scriptasylum....stfix/index.htm

I guess the problem is variables right? Unless you find a way to bind them to a number or representing the number assignment itself on the expression, it wouldn't be very useful.

Ordering doesn't seem to be enough for more complex expressions.

Can't you hack the second string argument to bind to a variable name instead of a scope? Let the scope be expressed in the function name or as a suffix to the first string?

ReadGlobal("blah", "X", VAR)
ReadLocal("bleh", "Y", VAR)
Eval("X*2 + 3")
Eval("X^3 + Y")
E(_,_)

?

I confess i'm confused about your last example though, and might have lost the plot.
(in the example above, it would be nice to reset the assignments at the end of the block - or if not possible, after the E(), GT() or LT() ).

Keeping the arithmetic functions hidden behind the string form should give you more latitude to add more simple functions like max(), log, % etc, and should allow you to use one of the hundreds of math expression evaluator libraries - so you don't even have to do that.

What about the write operation back to the globals or locals - or stats -? The equality operators won't allow that (but that would be actions i forgot)
Comparing stats/globals/locals is already very good though.


#540404 [WIP] Expanded Triggers

Posted by i30817 on 26 April 2012 - 05:33 PM in ToBEx

It's impossible to do OR without a additional block?
As in:


IF
		OR(2)
		Eval1Str("test","GLOBAL",VAR)
		Eval2Str("test2","GLOBAL",VAR)
		EQ(_,_)
		Eval1Str("test","GLOBAL",VAR)
		Eval2Str("test3","GLOBAL",VAR)
		EQ(_,_)

if not, if we do instead:
IF
		Eval1Str("test","GLOBAL",VAR)
		Eval2Str("test2","GLOBAL",VAR)
		EQ(_,_)
....

IF
	    !EQ(_,_)
		Eval1Str("test","GLOBAL",VAR)
		Eval2Str("test3","GLOBAL",VAR)
		EQ(_,_)
would this work? Or would it need to replicate the EvalStr before using !EQ in the second block?

Lol, the horrible contortions that BGScript original design is going through.


#540349 Request: New classes for TNO

Posted by i30817 on 26 April 2012 - 03:26 AM in PS:T Tweaks

That would only make sense on the narrative with extensive dialog and script changes - think about dialogs that have alternatives for thieves and mages for instance - (and Cleric is supposed to be right out, except maybe sensate - and that would be plenty weird without dialog).

But it WOULD be kinda cool to go f/t/m. As a artless tweak, you can just change the ofsets scient gave right?


#540336 [WIP] Expanded Triggers

Posted by i30817 on 25 April 2012 - 08:57 PM in ToBEx

What's the difficulty with actions? Just that you don't know the right offsets yet? (i assume you could do it for triggers due to your work for TriggerOverride)

Or is it the "cycle" delay (not knowing which actions will get triggered on each frame, potentially misordering the assigments)? Can't you just add a action with the same name that does the same thing as the trigger (but to the action function offsets of course, so you don't misorder?


#539830 [SOLVED]Time to deal with the stuttering

Posted by i30817 on 17 April 2012 - 11:52 AM in Mega Mod Help

If you can't take the criticism, don't display the code.

It's also just a piece of code, not your master work ffs. Don't be so sensitive.


#539828 [SOLVED]Time to deal with the stuttering

Posted by i30817 on 17 April 2012 - 11:34 AM in Mega Mod Help

Even if it's null terminated, comparing for null before doing the string equality test will save on a constant string equality test on early return (and doesn't make a difference for the normal case).

Unless you want to be able to "add" empty string mappings - is this even possible now on the original game?


#539821 [SOLVED]Time to deal with the stuttering

Posted by i30817 on 17 April 2012 - 10:34 AM in Mega Mod Help

Also couldn't you optimize the find method a little more?

for(unsigned int i = 0; i < nArraySize; i++)

there could maybe be limited to
for(unsigned int i = 0; i < nArraySize / 10;  i++)

like the add method?

Unless the unmarshall and marshall savegame serialization can mess that up?
Also, i'd put the
if(IsEmpty(pArray[index])) break;

before the string equality test (aren't you comparing random memory potentially?)



  1. Spellhold Studios
  2. → i30817's Content
  3. Guidelines