[Deji]

I 'think' I'm having some sort of lite version installed.
It just crashes right after I pressed the keys for activating it.

CLEO error

CODE

Error during loading of custom script PMC_TUNING.cm occured.
Error message: ios_base::failbit set

I'm trying to redownload since I don't know for sure if I've edited anything else than the key combo. But it stops at 80%. Though, I doubt I have edited the .CM file.

---

About drawing text and textures, I have just cleaned the code of one script where I used 8119: car 0@ wrecked.. Is that even valid? o.O It did work on 4.1 though (well, it didn't crash).

I'm not sure if you would have that much fun installing all my buggy scripts related to the complete mod for trying it out yourself. Maybe you could post a simple test script which I would try to crash my game with.

You don't use 03F0... no wonder the draws don't dissapear

Here's a brief overview of why USE_TEXT_COMMANDS is essential whenever you're, well, using text commands...

CODE

    case 0x3F0:   // opcode handler
      CRunningScript__CollectParameters(this, 1u);
      CTheScripts__UseTextCommands = (CTheScripts__ScriptParams[0] != 0) + 1;

Now here script params is tested, then the result is incremented. Hence the error on the OpcodeDB page of having to pass 1 or 2. You actually just pass 0 or 1, but the cause for confusion here is slightly obvious.

This command is essential to let the game know it needs to bother handling text and texture stuff...

CODE

    if ( CTheScripts__UseTextCommands )
    {
      v1 = &CTheScripts__IntroTextLines[0].color.blue;
      v0 = 96;
      do
      {
        *(_DWORD *)(v1 - 10) = 0x3EF5C28Fu;
        *(_DWORD *)(v1 - 6) = 0x3F8F5C29u;
        v2 = CRGBA__CRGBA((CRGBA *)&v15, 0xE1u, 0xE1u, 0xE1u, 0xFFu);
        // whole load more text draw resetty stuff...
        v1 += 68;
        --v0;
      } while ( v0 );
      CTheScripts__NumberOfIntroTextLinesThisFrame = 0;   // reset the number of texts to draw at once!
      // remove all current texture draws
      v5 = &CTheScripts__IntroRectangles[0].drawBeforeFade;
      v6 = 128;
      do
      {
        *((_DWORD *)v5 - 1) = 0;
        *v5 = 0;
        v5 += 60;
        --v6;
      }
      while ( v6 );

      }
      CTheScripts__NumberOfIntroRectanglesThisFrame = 0;  // reset index of texture draw array
    
      // this is where 03F0's param also makes a difference
      if ( CTheScripts__UseTextCommands == 1 )
         CTheScripts__UseTextCommands = 0;
    } // fin

So, you're not telling the game to reset the index of the text and sprite arrays, which will crash the game once you repeatedly draw those textures enough times to overflow the array and overwrite something important.

Use 03F0 in the loop, and it will work fine. This is standard drawing procedure, every script in the main.scm does it.

[uokka]

Oh bummer!
When I discoverd this 10 minutes ago, I thought "Deji will beat the shit out of me for reporting a bug while it's just yet another feature"..

There is a dedicated .cs file in my CLEO folder that does just that (for CLEO < 4.3).

while true
    wait 10
    03f0: enable_text_draw 0
end

Of course, this did work for 4.1 where drawing stuff is not script dependant.

I apologize. Sorry if you invested precious time in that voidness.

[uokka]

'Pimp My Car' working again! O_o
Maybe related? It does use 03f0 too. Both, in .CS and .CM file.

[Deji]

Oh bummer!
When I discoverd this 10 minutes ago, I thought "Deji will beat the shit out of me for reporting a bug while it's just yet another feature"..

There is a dedicated .cs file in my CLEO folder that does just that (for CLEO < 4.3).

while true
    wait 10
    03f0: enable_text_draw 0
end

Of course, this did work for 4.1 where drawing stuff is not script dependant.

I apologize. Sorry if you invested precious time in that voidness.

No problem, it's made me more aware of CLEO's vulnerabilities. One the one hand, CLEO 4.3 has caused an incompatibility by making this stuff script-dependant. However, it's clear these scripts in question would've still crashed if, like you've pointed out, there's not another script covering it's damage. I'm not sure if it will be necessary to add another CLEO 3 compatibility mode feature for this, however.

[uokka]

That wasn't a good solution anyway, I think. No unrelated script would have been able to set '03f0: enable_text_draw 1' without it being reset to "0".
Even though backwards compatibility is always a good thing, stuff that makes sense is way better. Presupposed we're aware of what makes sense.

[Junior_Djjr]

'Pimp My Car' working again! O_o
Maybe related? It does use 03f0 too. Both, in .CS and .CM file.

are you saying about failbit error?
i already said to you, this error appears almost random times and random scripts, appeared to me 11 times when i opened the game 30 times .-.
thats is not pimp my car or this opcode, is random scripts(i think)

btw: i don't have pmp

[uokka]

Yep:
For me, the "ios_base::failbit set" message occured not only randomly (how it seems), but also every single time I tryed to activate 'PMC'. That is, immediately 'after' pressing the respective key combo.
What I was pointing out is that it didn't even work partially fo me like it did for Deji, but starting the .CM made the game crash immediately.

I don't know either what was causing that crash exactly, but it dissappeared after I 'fixed' other scripts which have to use 03f0 opcode due to text/texture drawing. So my simple mind makes a connection there which Deji might be able to make use of (or not) by thinking about it.

[Junior_Djjr]

Yep:
For me, the "ios_base::failbit set" message occured not only randomly (how it seems), but also every single time I tryed to activate 'PMC'. That is, immediately 'after' pressing the respective key combo.
What I was pointing out is that it didn't even work partially fo me like it did for Deji, but starting the .CM made the game crash immediately.

I don't know either what was causing that crash exactly, but it dissappeared after I 'fixed' other scripts which have to use 03f0 opcode due to text/texture drawing. So my simple mind makes a connection there which Deji might be able to make use of (or not) by thinking about it.

hm, but i think of this is all about load of threads and not the problem with PMP
then: if you use other mod of load .CM too (or other custom thread too?) ...then the error appears @_@

test

[uokka]

Yes it seems to be related to the starting of threads / scripts. I have a mod that starts a couple of scripts without problems though. But when I rename a file which is usually started by this mod, so that CLEO can't find it anymore, it crashes with the 'failbit set' error message too.

Other than that I only got it when reloading a save game. Didn't happen anymore since the last update I think. It now crashes silently when reloading a save game. However, I'm not sure if I can blame CLEO for that. My modded game installation has never been super stable.

[Deji]

It's hard to test Pimp My Car and ignore the billion coding errors, such as all these which only seem to be causing weird output:

CODE

03A4: name_thread 'PMCSPMAIN' // over max length
03A4: name_thread 'PMCARSTORA' // over max length
03A4: name_thread 'PMCARSTORB' // --//--
03A4: name_thread 'PMCARSTORC' // --//--
03A4: name_thread 'PMCARSTORD' // --//--
03A4: name_thread 'PMCARSTORE' // --//--
03A4: name_thread 'PMCARSTORF' // --//--
03A4: name_thread 'PMCARSTORG' // ugh...
03A4: name_thread 'PMCARSTORH'
03A4: name_thread 'PMCARSTORI'
03A4: name_thread 'PMCARSTORJ'
03A4: name_thread 'PMCARSTORK'
03A4: name_thread 'PMCBLURED'
03A4: name_thread 'PMCSPXWL' // still over
03A4: name_thread 'PMCSPXSL'
03A4: name_thread 'PMCSPXTRIO'
03A4: name_thread 'PMCSPXMG'
03A4: name_thread 'PMCSPXCAN'
03A4: name_thread 'CARGRENADE'
03A4: name_thread 'PMCSPXCOLOR'
03A4: name_thread 'PMCSPXOSIG'
03A4: name_thread 'PMCSPXRED'
03A4: name_thread 'PMCSPXBLINK'
03A4: name_thread 'PMCSPXHSL'

(all in one script)

Now, the script engine reads up to 8 characters (which is one over the proper limit) to the struct. Causing a lack of termination of the script name, which causes CLEO (being the only thing actually using the script name regularly) to treat that part of the script struct + base pointer to be part of the script name. Baaaaddd!

Hence I'm getting logs like this:

CODE

23/01/2014 11:32:31.873 Unregistering custom script named pmcspxmgP#„æ„

In fact, if the base pointer is over a certain limit, it will include the current pointer as part of the script name, too.



However, all of that, amazingly, is irrelevant. And I have a CLEO update which may fix the final problem of mission loading. I didn't notice, but 4.2 didn't re-initialise the mission load state after a SCM mission ended, hence CLEO was refusing the launch the custom mission. I also changed some error stuff, to make the game more playable in spite of the seemingly random errors (which could mostly be down to the instability of the scripts). Errors and warnings will now simply be sent to the log, assuming they aren't critical. As well as some more cosmetic changes...

CODE

-- 4.3.9 --

* Will now be able to start a CLEO mission after recently finishing a standard mission

* Will no longer error & terminate when scripts fail to open and instead simply log the error

* Will no longer terminate on warnings

* No longer includes paths in automatically generated script names (e.g. cleo\dir\demo.cs is now named 'demo.cs' and not 'dir\dem')

* Improved handling of script load errors

[Junior_Djjr]

then, this errors (failbit) is cause of names?
i and link2012 don't uses thread name in scripts, and our scripts have this failbit error too... then out of curiosity, the not use of thread names is worng? (was wrong...)


btw: nice, now with this new cleo i opened the game 15 times and don't appeared this error! :3

[Deji]

then, this errors (failbit) is cause of names?
i and link2012 don't uses thread name in scripts, and our scripts have this failbit error too... then out of curiosity, the not use of thread names is worng? (was wrong...)


btw: nice, now with this new cleo i opened the game 15 times and don't appeared this error! :3

No, the thread names have caused no obvious errors so far, except for weird output, as I say.

And yeah, now there will be no forced termination on those small errors, which will make the game playable. If the error occurs it will only be written to cleo.log - and continue the game, where since the errors occuring seem random, hopefully it will succeed on the next attempt.

[Deji]

CLEO Update!

CODE

-- 4.3.10 --

* Improvements to opcodes 0AE1, 0AE2 and 0AE3 - now loops around the pool even when the 'find_next' flag isn't used correctly

* Fixed 0AD2 not returning peds targetted with the mouse, while targetting with a pad worked

[Junior_Djjr]

CRASH

script:

{$CLEO}
0000:

while true
    wait 0
    player.Defined($player_char)
    jf continue
    
    if test_cheat "p"
    then
        if 0A9A: 0@ = openfile "cleo\EnhFuncs\bonnet_dummy\Elegy.cfg" mode 0x72  // IF and SET
        then
            0ADA: 31@ = scan_file 0@ format "%f, %f" 0@ 1@ //IF and SET
            0AD1: show_formatted_text_highpriority "%f %f" time 2000 0@ 1@
        else
            0AD1: show_formatted_text_highpriority "dont loaded" time 2000
        end
    end
end

SCRLog:

CODE

********************************************
script test fi
Local variables dump:
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
53366679 6647
********************************************

00000006&0: [0256] IS_PLAYER_PLAYING 0    // TRUE
00000011&1: [004D] GOTO_IF_FALSE -158
00000018&1: [00D6] IF 0
00000022&0: [0ADC] TEST_CHEAT "p"    // TRUE
00000027&1: [004D] GOTO_IF_FALSE -158
00000034&1: [00D6] IF 0
00000038&0: [0A9A] OPEN_FILE "cleo\EnhFuncs\bonnet_dummy\Elegy.cfg" 114 -> 1562296881    // TRUE
00000083&1: [004D] GOTO_IF_FALSE -139
00000090&1: [0ADA] SCAN_FILE 1562296881 "%f, %f" l31(0)
00000107&1: [0000] NOP
00000109&1: [0103] LOCATE_STOPPED_CHAR_IN_CAR_3D [UNKNOWN] 2.38221e-044 -1866.31 4.4537 15.0 3.66426e-041 15.0 0

*********************************
> Logging finished: 01:28:20
  Powered by SCRLog (by LINK/2012)
*********************************

but i tested and works on cleo 4.1

This post has been edited by Junior_Djjr: Jan 28 2014, 03:41 AM

[Deji]

CRASH

script:

but i tested and works on cleo 4.1

0A9A: 0@ = openfile "cleo\EnhFuncs\bonnet_dummy\Elegy.cfg" mode 0x72

Don't use 0x72 to open the file. That's the weird CLEO 3 way. Just use "r" for read and "w" for write. However, you're also opening it in binary mode, and using it for text purposes. So use "rt"...

0A9A: 0@ = openfile "cleo\EnhFuncs\bonnet_dummy\Elegy.cfg" mode "rt"

And hopefully SB doesn't also now use backslash characters in any way (though it may one day, so be careful).

0ADA: 31@ = scan_file 0@ format "%f, %f" 0@ 1@ //IF and SET

Here you're trying to overwrite your file handle with a float. Bad. Once the variable 0@ is overwritten, your file handle is gone and you leave the file inaccessible for the duration of the game. You should use 0A9B to close the file once you've finished.

Also, just in case you tried... Don't name your script .cs3 as this is a script which requires CLEO 4 specific file functions.

[Junior_Djjr]

@Deji, thanks for tips in load, I did not know, and yes i used the 0A9B in other script of i was created and then make this crash, this other script is only for test .-.

but, in CLEO 4.1 this worked (i think of cleo 4.3.8 or oldest too cause I was using and don't have problem), then, if other mod was created so, will not work in cleo 4.3 (or newest) but will work in cleo 4.1 (or cleo 4.3.8 i think), thats not so good


EDIT: i changed and don't worked yet.....

This post has been edited by Junior_Djjr: Jan 29 2014, 01:37 AM

[Seemann]

As seen in the log output:

CODE

00000090&1: [0ADA] SCAN_FILE 1562296881 "%f, %f" l31(0)
00000107&1: [0000] NOP
00000109&1: [0103] LOCATE_STOPPED_CHAR_IN_CAR_3D [UNKNOWN] 2.38221e-044 -1866.31 4.4537 15.0 3.66426e-041 15.0 0

there might be an error in opcode 0ADA. Deji, does this opcode work well?

And from a quick test I see that SB does not correctly disassemble 0ABA with the given opcode description:

CODE

0ADA=-1,%3d% = scan_file %1d% format %2d%  //IF and SET

SB produces this:

CODE

0ADA: 31@ = scan_file 0@ format "%F, %F" //IF and SET 0@ 1@

note that the extra parameters are now commented out. However the cs file is compiled fine, so it's only a dissasembler bug. And while it's not fixed, the INI line must be so:

CODE

0ADA=-1,%3d% = scan_file %1d% format %2d%

This post has been edited by Seemann: Jan 29 2014, 08:02 AM

[Deji]

@Deji, thanks for tips in load, I did not know, and yes i used the 0A9B in other script of i was created and then make this crash, this other script is only for test .-.

but, in CLEO 4.1 this worked (i think of cleo 4.3.8 or oldest too cause I was using and don't have problem), then, if other mod was created so, will not work in cleo 4.3 (or newest) but will work in cleo 4.1 (or cleo 4.3.8 i think), thats not so good


EDIT: i changed and don't worked yet.....

Okay, I missed one very small detail. The opcode was reading the scripts base to test if there were any more params, instead of the current position, so when I tested with opcode 0001 very conveniently placed at the base, it worked fine. You've got 0000 which would have been telling it to stop reading, so if you'd had started the script with any other opcode, you wouldn't have noticed a crash either

Updated with fix.

[Deji]

CLEO 4.3.12 Released!

-- 4.3.12 --
* Fixed string parameter skipping in 'SkipOpcodeParams' used by CLEO plugins
* 0AC8 now returns a NULL value to the output var if allocation failed (as it did before 4.3a)
* 0AC9 now checks the memory was allocated by 0AC8 before attempting to free it
* FXT references are now case insensitive (as they were before 4.3a)
* File operations now check the input handle isn't null (as it seems was the way before 4.3a)
* 'Loaded mission' status now reset on new/loaded game (as it was before 4.3a)
* Scripts no longer load prematurely (like before 4.3a)
* Resolved conflicts with other menu hooks such as 'HUME'
* Other minor tweaks

Basically, CLEO 3 support is pretty much nailed. It's just scripts that were written in versions of CLEO 4 prior to 4.3a (for which Alien totally rewrote the source code) we seem to be battling with. Unfortunately I have no 4.1.1.30f source to go by, so attempts at stabilising CLEO are requiring me to decompile the old .asi, which isn't easy. However, I fixed a bunch of stuff today so hopefully there's not too many problems left.

[uokka]

Loading different save games like mad as much as possible in 15 minutes and seems to work - no crashes on attempting to load.

But starting a new game after loading a save, still almost always crashes the game.

CODE

Closing Soundsystem...
Freeing BASS library