• All, Gmail is currently rejecting messages from my host. I have a ticket in process, but it may take some time to resolve. Until further notice, do NOT use Gmail for your accounts. You will be unable to receive confirmations and two factor messages to login.
OpenBOR

OpenBOR 4.0 7556

No permission to download
So, I'm facing a weird behavior.

I've always used the function below to make my life easier in the previous versions:
C:
void ModProperty(char PropName, void Value)
{
    void Self         = getlocalvar("self");
    void PropValue     = getentityproperty(Self,PropName);

    PropValue += Value;

    changeentityproperty(Self, PropName, PropValue);
}

But for some reason, the function is not reading the entity's property as intended, and I received the following warning on the log:
Function getentityproperty must have a string property name.


PS.: I'm posting this here because this same script works in previous builds of OpenBoR.
 
Last edited:
So, I'm facing a weird behavior.

I've always used the function below to make my life easier in the previous versions:
C:
void ModProperty(char PropName, void Value)
{
    void Self         = getlocalvar("self");
    void PropValue     = getentityproperty(Self,PropName);

    PropValue += Value;

    changeentityproperty(Self, PropName, PropValue);
}

But for some reason, the function is not reading the entity's property as intended, and I received the following warning on the log:
@paulo.bender

What are you trying to perform exactly? I can try to replicate it in my game.
Maybe the mix of "PropValue += Value" is resulting in a non-string value, you need to add a "" in the formula. This way everything mixed after will result in a string.

C:
PropValue = ""+PropValue+Value;
 
I'm trying to make a "@cmd friendly" changeentityproperty that takes two parameters: "PropName" and "PropValue" and adds value the the property's current value.

example:
@cmd ModProperty "mp" 2
would add 2 to the character's MP, but instead it's setting the character's MP to 2.
 
@Ianyer The way the engine is assigned is different now, think of it as a much better and new way to create instead of an updated version, what you create with Unreal engine 4 is not going to be compatible with Unreal engine 5, so choose what version of the engine you want to use and stick with that.

I'm not going to look at OpenBor engine 4 until all my projects with OpenBor engine 3 are finished and if I do decide to create with OpenBor engine 4 I'll be starting from a bare bones new project.

Going forward try to consider that OpenBor engine 4 has nothing to do with OpenBor engine 3.
Actually... alot of Unreal Engine 4 stuff is drop-in compatible with Unreal Engine 5. :) but what *is* missing is the fancy "convert UE4 project to UE5" thing that unreal engine also has.
 
Actually... alot of Unreal Engine 4 stuff is drop-in compatible with Unreal Engine 5. :) but what *is* missing is the fancy "convert UE4 project to UE5" thing that unreal engine also has.

....and that's exactly how OpenBOR works. Which is why we used the Unreal/Unity example. Almost everything works the same in 4.0 as 3.0 and that's not changing.

The only difference is previously the community demanded absolute 100% backward compatibility across the board, and that's what we tried to do. Which frankly, is stupid. It's just not sustainable.

Now, the policy is we will try to maintain backward compatibility, but not as a dogma. If something has to changed to fix a bug or extend functionality, then so be it.

You know... just like every other engine.

DC
 
Can anybody help me out and test OpenBOR 4.0 - 7533 wii port is working: WII

I don't have a system I can test on right now.
 
  • Locking/Compiling - If OpenBOR has a flaw, it's that it is too open and too easy for its own good. I am working on a setup for creators to compile their game data into a closed form without resorting to third party tools. This should open the door for cretors interesed in professional work or projects with original content and cut back a bit (though never fully eliminate) the proilferation of "EXs", "XXXs", "super-ultimate-whatever" hacks from outside the community that have caused some of our best creators to depart.

Has there been any update on this?
 
Has there been any update on this?

Not a lot to be honest. My graduate work went insane this semester, so I'm kind of on halt for major coding until early May. However, recently, our previous lead coder (@SX) returned to work on some Mac ports, and has also been modernizing the compiling process. One of the obstacles to a locking system was that the compiling tools were very much a black box. So while I haven't directly coded a lock system yet, part of the foundation work is being done as we speak.

DC
 
Has there been any update on this?
@DCurrent This sounds a lot like SecurePAK. Back in the day we had this functionality baked into limited runs when a OpenBOR creator wanted to lock down their resources because they either had heavily modified artwork or created artwork from scratch and did not want others to manipulate the resources.

I had then created an encrypted version of the PAK format which required a unique key in order to be able to unlock it and provided a custom version of OpenBOR. I had called this new PAK structure "SecurePAK" and the extension was "spk". BonusJZ was the only one who ever requested this from me and we agreed to unlock the SecurePAK after 1 year because even though it was heavily modified it was still based on Capcom/SNK derivatives.

An only 2 people have access to SecurePAK... myself and @DCurrent. @DCurrent has anyone used this feature since then? I would have to dig up the source code and tool which encrypts an existing PAK file if you need it. That's a good way to fund OpenBOR..... for creators that want their PAK files secured, you can offer this as service.... which will provide them a SecurePAK file and a variant of OpenBOR which supports it.

This is where the new build tools will shine.... you can automatically regenerate all targets for them.... Then they can take those targets and do as they wish (Sell them on Steam, etc....).... just make sure to put a disclaimer to protect yourself if in the future if the SecurePAK did get compromised.... just like anything else in this world.... nothing is 100% guaranteed.
 
Last edited:
This sounds a lot like SecurePAK. Back in the day we had this functionality baked into limited runs when a OpenBOR creator wanted to lock down their resources because either 1 they heavily modified existing artwork or created artwork from scratch and did not want others to manipulate the resources.

Oh good lord why did you say the name SecurePAK. Dude, I've fought more battles over that @#*@() thing since you left than you could possibly imagine. Just ask @Kratus and @O Ilusionista. Believe me, I know what it is and what it did - the problem is that nobody else does, nor do they believe me when I explain I don't have it and never did. Technically you left me access, but I didn't actually have a copy at any point, and AFAIK it stopped getting updates long before even you left. I can almost guarantee the peanut gallery will arrive in force now that you brought it up...

Besides that, I don't want to bring it back as it was, because it requires our intervention, which in turns requires judgement over what does and doesn't deserve to be secured. The only 100% fair way to do that is require 100% original content and IP.

Instead I'm looking into a way creators can encode and secure games on their own. That way I can wash my hands of any involvement.

DC
 
Back
Top Bottom