-= Gametoast.com =-

Posted: **Thu Feb 01, 2018 11:45 pm**

Hello all! I was wondering if it would be possible to remove the HUD bullseye completely, on all levels, not just the levels I create.

I came accross this guide http://www.gametoast.com/viewtopic.php?f=27&t=29836, which is fantastic and just happens to target the exact HUD mesh that I want to remove, but I haven't managed to get it to work yet due to a few different issues with my installation of battlefront and the visual munge installation.

I think I could get it to work eventually if I spent some more time on it but before I do that I was wondering if someone could tell me whether it would be simple to apply this to the entire game? I was thinking perhaps I could replace the base game "ingame.lvl" with my munged one? (I have very little understanding of how the munger works and the limits of what it can do so I realize that this might be a ridiculous suggestion)

So my question really is, would it be relatively simple to get rid of the bullseye for the whole game (with only a few extra steps compared for a single level) or is it something that would take significant time and expertise to do?

Any guidance would be much appreciated!

pacelek.

Posted: **Fri Feb 02, 2018 5:59 am**

hey there and welcome to GT.

Well replacing the ingame.lvl is one option. BUT:
1) that way your "mod" won't be compatible with other things
2) you need to find everything from the original ingame.lvl
3) you won't target custom mods/maps

So if you are not familiar with programming you should learn any language. It doesn't really matter what it is c, c++, java, Delphi, lua,... but you should understand the basics. Then you take a look at the user scripts. You can write a wrapper for the ReadData() function where you check if the loaded file is called ingame.lvl. If it is, you load your custom lvl with the invisible bullseye and continue with the original function. It isn't really complicated, but in order to make your script not hurt any other wrappers for the ReadData function you may wanna post your results for others (Zerted is a SWBF scripting god) to have a look at it.

btw i updated the tutorial to point to a tool that creates custom lvls in an easier way then the shell solution

Posted: **Fri Feb 02, 2018 10:01 pm**

Wow! Guidance from the tutorial writer himself!

Thanks for the advice. I know enough c++ to write simple code so I'll have a look at the example user scripts and see if I can work out how to make a wrapper to load a custom lvl. I'll definitely use your custom LVL maker tool as it looks much easier.

I'll see how I get along and I may have to ask a few more questions to the experts if I get stuck. ;}

Cheers!!

EDIT
Hmm.. Ok so just by looking at the debug log it seems as though the user scripts are loaded after a ReadDataFile("ingame.lvl") call. When I run my custom lvl through my user_script, I get

Model "hud_main_reticule_bullseye" already loaded in ather level file

If I edit my lua file on my custom map to print to the console when it calls ReadDataFile(ingame.lvl), it prints before the user_scripts are printed, which indicates that the call is happening before my script is even read.

I'm assuming the reason why we add

ReadDataFile("dc:ingame.lvl")

above

ReadDataFile("ingame.lvl")

is because the game just skips loading a model if one with the same name has already been loaded.

I'm wondering how I could work around this..

I know there have been a few different HUD mods that have been made already, I wonder if I could contact someone who's done one, or get hold of some source code to see how they've gone about it..

Does anyone know of anybody that I could get in touch with? Or if you have an idea yourself?
I'm a complete beginner when it comes to modding so it's very possible I'm not seeing something obvious.

Any help would be wonderful!

Double posting is against the RULES; please EDIT your post instead -Staff

Posted: **Sat Feb 03, 2018 6:17 am**

well i know someone, who made a fully custom HUD

In my mod i've made a custom ingame lvl and loaded it before the stock ingame. Just the way i wrote in the tutorial. But you want this to affect ALL mods/maps and you don't want to recompile the whole mission script.
So your way is the scripting.
There are two different scripts. The user_script_x.lvl and the custom_gc_x.lvl Well the custom gc script is more then just a script that can add custom galactic conquest. In fact it is nothing else then the user script but loaded earlier.
The custom_gc script is loaded once when you start the game (so you can still affect the legal pictures and the gui) and the user_script is loaded each time when you start a map. I cannot tell you about the exact time when it is loaded, but you can figure it out on your own by using some print functions if you are interested in that.

So the user_script does not work, fine, let's take the custom_gc.

Here is a part of my fontmanager mod

Code: Select all

if ScriptPostLoad then
	print("font_killer: Taking control of ScriptPostLoad()...")

	-- backup variable is in use??
	if fm_ScriptPostLoad then
		print("font_killer: Warning: Someone else is using our fm_ScriptPostLoad variable!")
		print("font_killer: exited")
		return
	end

	-- backup old function
	fm_ScriptPostLoad = ScriptPostLoad

	-- define new function
	ScriptPostLoad = function(...)

		-- let the original function happen
		local fm_return = fm_ScriptPostLoad(unpack(arg))
		
		ReadDataFile("..\\..\\addon\\FM\\invisible_font.lvl")
	
		return fm_return
	end

else
	print("font_killer: Warning: No ScriptPostLoad() to take over")
	print("font_killer: exited")
	return
end

Let's go in detail. First i check whether my target exists. If the function isn't already defined, we needn't continue because the original definition will overwrite our wrapper. In this case i want to wrap ScriptPostLoad from the lua mission. (it is a user_script)
Next check whether the backup variable is in use. If it is, i cannot continue, but i don't think there is someone using exact the same variable. It's just for safety. So backup the old function and redefine it. Important is the (...) because we don't know how many arguments the function has. And if we know, we don't know if there may be another wrapper that has more. You remember the Leia don't spawn bug? Well this was the reason.
Now in the new defined function we can do what ever we want. You can do some more If/else things, load some other files,.... In my case i let the original function happen (don't forget to rescue the return value) and after that i want to load a lvl file. Finally i return the return value from the original function (but you can manipulate it if you like). Don't forget the unpack(arg) when you call the function, it does the opposite thing from (...) it just passes all arguments catched from (...) to the function.

If there is a argument you need you can access it that way

Code: Select all

myTargetFunction(coolParameter,...)
    if(coolParameter ==...)

    return backup_myTargetFunction(coolParameter, unpack(arg))
end

or this way

Code: Select all

myTargetFunction(...)
    local coolParameter = arg[1]
    if(coolParameter ==...)

    return backup_myTargetFunction(unpack(arg))
end

in your case you want to wrap ReadDataFile and if the name of the file (first argument) is ingame.lvl you want to load your customLvl.lvl and after that you want to continue the old function. If the file name is not ingame.lvl you simply continue the original function.

-= Gametoast.com =-

Removing the reticule bullseye from the whole game

Removing the reticule bullseye from the whole game

Re: Removing the reticule bullseye from the whole game

Re: Removing the reticule bullseye from the whole game

Re: Removing the reticule bullseye from the whole game