OpenBOR v3.0 Build 4082 for Windows/Linux/Wii

Status
Not open for further replies.
DCurrent

DCurrent

Site Owner, OpenBOR Project Leader
Staff member
Latest attempt at randomization.

Upon further review, I found elapsed time won't work for us either. That's because it's not really a timer at all per say, and so always gives the same seed. In light of that I've completely scrapped the old random system written by Roel.

As is usually recommended for random generation OpenBOR now uses the C <time.h> library in order to gain access to system time. In turn, system time is used as a random seed, ensuring a strong random generation.

The catch: As I said before, we can't always be sure there is a system clock available. That's why I didn't do this in the first place. PCs all have system time of course and so does the Dreamcast. I'm just not sure about the other platforms, so they'll need testing.

DOWNLOAD
 
I'm sorry, but there will never be a Playstaion 2 port of OpenBOR - you might as well ask for an Atari port. I have explained at length several times why and am not inclined to do so again.

DC
 
Atari port would be cool :) . Can you imagine a Beat em Up in Atari? (well, in fact, there is a Double Dragon for Atari).
ah, if Linux is discontinued, I think you should edit the topic title. For what I see, its for DC, GP2X, PSP, WII, WINDOWS and WIZ.
 
That's the sort of thing I was afraid of. AI is powered by the random generator across the board and obviously I broke some compatibility somewhere.

*sigh* Back to the drawing board.

DC
 
maybe leave it how it was and use new random method only when you want to create random numbers with script.Cause it is actually only reason why this conversation about random method was brought up, scripting and rand function.
 
bWWd said:
maybe leave it how it was and use new random method only when you want to create random numbers with script.Cause it is actually only reason why this conversation about random method was brought up, scripting and rand function.
Click to expand...

I agree with that. Maybe we could have srand() for those type of things (the newer method) and let the old rand() as it was on the older versions. Its possible?
 
Certainly, but I'm specifically trying NOT to do that. Why have two random number generators that do the exact same thing? That's the epitome of bloatware.

DC
 
But one method - rand() - uses the normal pattern-based seed, while srand() would use your new method.
Would this be that bloat?
 
For one thing, they're both random generators. For another one of them is so deep rooted on the code that it breaks compatibility when it's disturbed. Right now at the r4083 build, DC removed stdlib to the random generator since it now uses the time library for C instead, which really cements the new random generator altogether. (I think that's what I understood about the recent code change)
 
well, if this really breaks the compability, I think we should stick to the old version. Because weapons have many bugs already, and If we force another one...it will be a disaster.
 
There might need a lot of work for the new random generators, but I think they'll worth in the end anyway. The weapons, as they say here, need to be finetuned to the new random gen.
 
DC, seams that the "stealth" setting doesn't works on this version.

I have a NPC with this setting:

stealth 10 0
Click to expand...

And my enemy has this setting and its hostile to NPC too:

stealth 0 15
Click to expand...

But he never attacks the NPC, even if its close. When I spawn a NPC with no steath, the enemy chases him to attack. But if I put the stealth (notice that his perception is greater than NPC stealth value), the NPC is just ignored.

I will make some tests with other releases to try to check where this issue began.
 
Thanks, that will be a big help. I've already decided to roll back and make sure I didn't accidentally mess some other code up. Some of the new bugs just can't happen from the edits I made. I must have fat fingered a character somewhere else into code I wasn't actually working on while browsing around.

DC
 
Maybe this will help you:

3979 - NO
3921 - YES
3XXX (Compile Date: Dec 31 2013) - YES
4055 - YES
(the log says OpenBOR v3.0 Build , Compile Date: Aug 25 2014) - YES

So something had broken it between 3979 and 3921.
 
Guys, I've found a problem:

In the version 4082, for Andoid, the random simply doesn't works. I am using a random sound script in some chars, but the engine always get the same value

This is my code:

Code: 
void randSound0(char s1,char s2)
{
   int r = rand()%100;
   char sound;
   if (r<=0)
   {
      sound=s1;
   }else{
      sound=s2;
   }
   playSound("data/"+sound);
}

Usage:
@cmd randSound0 "chars/namor/attack3.wav" "chars/namor/weakling.wav"

But everytime he does the move, the sample "weakling" is played. I've tried it 24 times in a row, and I always get the same sample. This doesn't happens in Windows version.
 
@Illusionista, I'll try to download the 4083 build and compile it and see if it works for you. I saw DC's code and apparenly he has a double check (DC, I don't know if that's the right term):

From the random code

Code: 
unsigned int rand32(void)
{
    unsigned int result = 0;

    // If we haven't seeded for random numbers yet, use time.
    if(!random_s.seed)
    {
        srand32(time(NULL));
    }

    result = random_s.seed;
    result *= 1103515245ull;
    result += 12345ull;

    random_s.seed = result;

    result = (result >> 16) & 0xFFFFFFFF;

    return result;
}

It passes over various modifications before it spits the result, I think that's how I interpret it. @DC, what does the first multiply and adds do for?
 
Is there a new setting for velocities between enemies and other entities ?
i have an entity type trap that use @cmd dasher 0.7 0 0
once i set this entitie to enemy the dasher speed gets slower like it took -1
 
Status
Not open for further replies.
Back
Top Bottom