[BETA] Addon Overtime Last Chance
- Thread starter _Lynx
- Start date
-
Two Factor Authentication is now available on BeyondUnreal Forums. To configure it, visit your Profile and look for the "Two Step Verification" option on the left side. We can send codes via email (may be slower) or you can set up any TOTP Authenticator app on your phone (Authy, Google Authenticator, etc) to deliver codes. It is highly recommended that you configure this to keep your account safe.
Heh, I probably should have noticed that you'd already suggested it if I'd bothered to read further up the thread 
tarquin said:
I take it that there's a way to modify the function and prevent it from sending the local message. Dont have the ability to look into the code atm though. Will check that out asap
Ah well, great minds think alike (but they just suck at reading).Sexmachine said:Thanks go to CD and Zed, I am glad you agree with that suggestion.
Has anyone tried compiling this?
I get this messsage:
I get this messsage:
Code:
Failed loading package: Can't find file XGame_rc.usx.
Code:
// clearing messages, so they won't appear
class'JBLocalMessage'.default.TextTeamReleasedNobody = " ";
class'JBLocalMessage'.default.TextLastMan = " ";every JBLocalMessage that shows up is spawned newly. Clearing default properties of one will not affect the next message that is spawned. To prevent the message from showing up, it needs to be stopped before it's spawned, in JBInterfaceHud. Extend it, then insert the following:
Code:
simulated function CheckLastMan()
{
bIsLastMan = False;
}
Last edited:
Changing the default properties of a class will affect any future instances of that class.Jrubzjeknf said:
Mychaeel said:
Not in my experience. I have tried to make my TeamSpecificActors work that way.
What I tried: I made a custom Volume, which could send a localized message to the player on touch, with adjustable properties. I subclassed LocalMessage, just like _Lynx did. Then, when one touched the volume, the defaultproperties of the message subclass were overwritten with the properties set by the mapper. Then the localized message was sent to the player. This didn't work. It kept sending the localized message using the original defaultproperties of the message subclass.
This finally worked: I created a function within the message subclass to overwrite it's own defaultproperties. Like this:
Code:
function GetRequiredInfo(string myDisplayMessage, color myMessageColor, int myMessageLifeTime, bool mybFlash)
{
default.DisplayMessage = myDisplayMessage;
default.DrawColor = myMessageColor;
default.LifeTime = myMessageLifeTime;
default.bFlash = mybFlash;
}To execute this function, I had to call it from the volume, so I inserted the following in the Touch() function:
Code:
local LocalMessageSubclass myLocalMessage;
myLocalMessage = Spawn(class'LocalMessageSubclass'); //Needed to access function
myLocalMessage.GetRequiredInfo(var1, var2, var3, var4); //Modify properties. Using class'LocalMessageSubclass'.default.bFlash = True/False didnt work
Player.ReceiveLocalizedMessage(class'LocalMessageSubclass',,,,); //Send messageAnd it works like an absolute charm.
To get back on topic: I think preventing the message from showing up is a better way to not send the message to the player than by sending a blank string. That would just be unnecessairy imo.
Sexmachine said:
I would suggest a regular Overtime and then a No Chance Double Overtime. I like that idea.
Sexmachine said:
_Lynx, if you are still around it'd be great if you get these things done someday as I have removed the mutator from the MotherShip mostly because of the first suggestion (see above) and I would love to put an enhanced version back on.
add a fix: when a game is won by reaching the cap limit, the mutator is initialized. Dont think that should be there...
I played about a bit with the layout of the options widgets, to make it match the bundled add-ons. I'll attach the class script later.
Hm... it seems I missed 2 or so pages of feedback and I recieved the update e-mail only tdoay, weirdo....
Flexx, can you attch the UT2004.log so I can look through it.
Flexx, can you attch the UT2004.log so I can look through it.
Here's my tweaked version of the options panel.
The controls are nicely lined up now
Lynx, can we get this into CVS? Do you have an account?
The controls are nicely lined up now
Lynx, can we get this into CVS? Do you have an account?
error message_Lynx said:
History: UObject::execClassContext <- (JBAddonOvertimeLastChance JB-Arlon.JBAddonOvertimeLastChance @ Function JBAddonOvertimeLastChance.JBAddonOvertimeLastChance.MakeLocalChanges : 0014) <- UObject:
rocessEvent <- (JBAddonOvertimeLastChance JB-Arlon.JBAddonOvertimeLastChance, Function JBAddonOvertimeLastChance.JBAddonOvertimeLastChance.Timer) <- AActor::Tick <- TickAllActors <- ULevel::Tick <- (NetMode=0) <- TickLevel <- UGameEngine::Tick <- Level JB-Arlon <- UpdateWorld <- MainLoop <- FMallocWindows::Free <- FMallocWindows::Realloc <- 10910191 0 FArray <- FArray::Realloc <- 0*2 <- FMallocWindows::Freelog
View attachment UT2004.txt
I can't reproduce this issue with the same addon and bots on Arlon and don't see anything suspictious in the log either. UT's being 3369 and JB is 2004b. strange. :?
In the code that Timer runs MakeLocalChanges(), when it is said to. MakeLocalChanges seem to fail to do something - it removes (erm... tries to) the default values for JBLocalMessage, then disables emitters on Locks, except if it is on dedicated server, where are no emitters and there's nothing to remove. The only (oh, crap - my UDE completely f.... up) idea is that something with JBLocalMessage is causing the problem. But that code doesn't do anything that much critical. Also that bit: FMallocWindows::Free <- FMallocWindows::Realloc <- 10910191 0 FArray <- FArray::Realloc <- 0*2 <- FMallocWindows::Free displays some problem with memory - what may cause it just can' understand. an attempt to write into locked memory?
In the code that Timer runs MakeLocalChanges(), when it is said to. MakeLocalChanges seem to fail to do something - it removes (erm... tries to) the default values for JBLocalMessage, then disables emitters on Locks, except if it is on dedicated server, where are no emitters and there's nothing to remove. The only (oh, crap - my UDE completely f.... up) idea is that something with JBLocalMessage is causing the problem. But that code doesn't do anything that much critical. Also that bit: FMallocWindows::Free <- FMallocWindows::Realloc <- 10910191 0 FArray <- FArray::Realloc <- 0*2 <- FMallocWindows::Free displays some problem with memory - what may cause it just can' understand. an attempt to write into locked memory?