[StratComm]

Like SEXP evaluation or beam damage, this should only be done in fixed intervals.  That's pretty obvious, as you want the effect to be framerate dependent.

[Bobboau]

for flickreing you don't need to know anything, you just need to make a simple probablistic formula sign(ipart(rand*(1.0/probability))) will give an out put of 1.0 at the specified probability., it would be constant flickering, so you would do something like sign(ipart(rand*(1.0/(probability*sin(time/10)*sin(time /11)))))

sExp values can be rereived, as well as any global.

[WMCoolmon]

Bobb, can you (please) make this OO? I have nothing against a probability variable, but something like "math.probability" would make things clearer, and easier to document.

If that seems too long, we could follow with a shorthand system that would allow "m.p", by basically aliasing the command names. sexps could be

Code: [Select]

sexp."variable name" or sx."variable name"
with ships

Code: [Select]

ships."ship".variable or s."ship".variable

I think the OO/shorthand system would let us add mass amounts of variables without running out of names (as often) or having things get disorganized. Whether or not it's true OO or just a string with a dot in it won't matter in the shortterm.

Kasperl: The way that things are handled, if you want to have something flicker half a second, it'll work. FS2 basically increments the mission timer by frametime. If you wanted something to flicker once every two seconds:

Code: [Select]

$Brightness: 255*(mission.time%2)
Freespace would increment the mission.time properly to account for any frame lag, then /2, find the result was either an odd or even number. On an even second, the gauge/texture would be off. On an odd second, the gauge would be on.

[Bobboau]

when I said probability in that statement I meant what ever the probability of the light being on was, like if you wanted it to be on half the time then you  would put 0.5 in.

[Setekh]

Originally posted by redmenace

I think this is a school project that involve trees IIRC back to the days of Data Structures.

Hey, that's exactly what I'm learning right now. Abstract data types and stuff - stacks, queues, binary search trees, 2-3 and 2-3-4 trees, heaps... it's fun.

[WMCoolmon]

Originally posted by Bobboau
when I said probability in that statement I meant what ever the probability of the light being on was, like if you wanted it to be on half the time then you  would put 0.5 in.

Ohh, alright.

[Bobboau]

though if there is going to be a lot of demand it might be a good idea to make a flicker(x) function, just a thought.

ok, new build I'm prety sure this just about sums everything up, the only thing it lacks is a rand function, because I'm going to use the one in FS already so I need to wait untill I reintegrate, and I've decided on how I'm going to implement it, it will be passed a variable, it will return a number between 0 and the number passed, this will make it simple to implement and generaly flexable.

I haven't done this yet, but it won't matter because it's currently just a stub feature anyway, rather than being passed a ship pointer, I'm going to have it pass an object pointer, and the evaluating functions for each of the ship variables will be able to handle weapons and shock waves and fireballs and any other object type the only place were it won't get a pointer is in the tech room, and in the sky box code.

[Bobboau]

ok, once again, I can only assume that the 12 hours of deffoning silence implies that everything is working perfictly, and it's almost tme for me to reintegrate it into the game so I hope there aren't any bugs left.

[kasperl]

I couldn't find anything while testing, no. That doesn't mean it's infallible. Especially in the outer bits of the float range the thing will behave oddly.

[Bobboau]

ok, I've worked out the object variable syntax, it's sort of an odd OO style setup, but toaly diferent than any exsisting language (because I already have the '.' defined as part of a number)

all game variables will start off with the ':' charicter, then there will be which groupe of variables you want, currently all I have defined is object (meaning the currently rendered object) but I will likely also have :global, and maybe :player_object and :targeted_object (though this could probly be done via :object{targeted object{whatever}}). after this is a set of {}s with the name of the variable in it so to get the currently rendered object's engine output, you'd type
:object{engine_output}, currently this is being tested with a bunch of stubb data, so it realy isn't anything to test, just look to see if there are any further glareing errors in the last build.

[WMCoolmon]

Hmm, I dislike that way for a few reasons.
1):object doesn't seam as intuitive as object:
2):object{member objectvar} seems similar enough to functions to be confusing when reading code, and you have to keep track of the number of closing braces...unlike parentheses, they aren't really denoting a section per-se.
3)both the : and the {} characters all require you to hold down shift, which is a little annoying (for me anyway)
4)No other coding language has used that system, as far as I know, unless it's from some shader language...meaning you have to learn + get used to an all new syntax. If we ever implement a full scripting system, it'd add needless confusion as well

Wouldn't it be possible for the parser to do something like this? (this is pseudo-code, as I didn't fully understand how the parser actually parsed the various operators and have to be somewhere in 10 min)

Code: [Select]


if(isletter(currentchar))
{
     while(isletter(currentchar))
     {
           currentchar++;
     }
     if(currentchar=='(')
          return THIS_IS_A_FUNCTION;
     else if(currentchar=='.')
     {
          return THIS_IS_AN_OBJECT_ITEM;
          //Next function does this
          if(currentobject)
               add_object_child(currentparseitem);
     }
     else
     {
          parse_error("Somebody used an invalid thingamabob!");
     }
}

Unless you've got another reason for using the :{} syntax or that'd be really hard to do with the current parser

I still need to test the last build.

Edit: SYNTAX ERROR

[kasperl]

Disabling smilies might be a good idea BTW....

[Bobboau]

yeah

and the reason I have a thing to start and end members is because the string gets read backwards so I need something to denote the end of a member as well as the begining of a game variable, when the string is getting converted to postfix notation it is reversed, ans what if by sone twist of fate the end of a mamber variable hapens to end in "log" or "sin" or something that I already have a check for, it's just simpler to go if you fiind '}' copy everything untill you find ':'. '}' isn't currently used by anything so the only posability is that we have a member of an object.
I doubt anyone useing this is going to be a coder, so it doesn't matter if it looks like function syntax.

I supose I could change it to :object.member: everything between two colens gets coppied as a single operand. but I've already started integrateing it into the game again, so I'll just have to wait untill I get the game working with it again, it should be a simple change.

[WMCoolmon]

Yeah, I sort of like that better.

Couldn't you check if 'log' actually is the end of a word or a variable? Since all variables would have '.' in 'em, any contiguous string with a '.' should automatically be processed as a variable.

I can try and do that once you've got it into CVS.

[MatthewPapa]

20*.3 = 6
??? Since when.
And since when does 9999*.3 = 2999.7

[Bobboau]

ummm... sence decimal numbers were invented I supose, so... I don't know... 2500 B.C. maybe?

those are corect. at least acording to my $150 calculator, and MScalculator, and google... am I missing something?

[Taristin]

Originally posted by MatthewPapa
20*.3 = 6
??? Since when.
And since when does 9999*.3 = 2999.7

You're thinking division.

.3, 20 times, is 6

[WMCoolmon]

.3 is 3/10.

[Bobboau]

well it's good that my code is starting to out think some peaople... probly...

[Scuddie]

We don't know that...  Yet .