Tx606

I guess it's because the  script is read from top to bottom, right?

Also if this is for MP purposes remember print needs an exclaimation point (!) before the message for it to appear. (Although that appears to everyone)

If it may help you, here's something I used in MP for my map mods. A player gets their parm2 set to 1 at spawn and a scaler adds +0.1 every "use" until the limit is reached.

The "2big" and "defaultsize uses are just target_prints I use to tell the user they're at the biggest size or the default size. Obviously you can use something similar for other map features like scaling objects/models/whatever, it's just to give you an alternative method.

if ( $get( FLOAT, "SET_PARM2" ) > 2.900$ )
{
	use ( "2big" );
	set ( "SET_PARM2", "3" );
	set ( "SET_SCALE", $get( FLOAT, "SET_PARM2" )$ );
}


else (  )
{

	if ( $get( FLOAT, "SET_PARM2" ) < 0.100$ )
	{
		set ( "SET_PARM2", "0.1" );
		set ( "SET_SCALE", $get( FLOAT, "SET_PARM2" )$ );
	}


	else (  )
	{
		set ( "SET_PARM2", "+0.1" );
		set ( "SET_SCALE", $get( FLOAT, "SET_PARM2" )$ );
	}


	if ( $get( FLOAT, "SET_PARM2" ) = 1.000$ )
	{
		use ( "defaultsize" );
	}

}

Try a trigger_multiple targetting a target_push (which targets a target_position). I've been using this (inactive and active) without issues.

In fact, it sets the rescale key to "parm1" and if you look at my .bsp file, there is a line in my switch-looking model entry: "parm1" "1.75", which sets it's size to 175% of the original. The script is badly written though. Should have been either ( "SET_SCALE", $get( STRING, "SET_PARM1" )$ );  or ( "SET_PARM1", $get( STRING, "SET_SCALE" )$ ); not sure atm.

Yeah, I know of the method and use it myself. However it should look like:

set ( /*@SET_TYPES*/ "SET_SCALE", $get( FLOAT, "SET_PARM1")$ );

edit: ignore the set types part obviously, its just a BehavEd thing, but you should use float and get the value from parm1, is what I'm trying to point out.

If you're trying to spawn a vehicle like a swoop, use NPC_Vehicle. I believe all you need is classname, origin, targetname, and NPC_type for this to work. 

EDIT: took a quick look at your file, whats the purpose of set ( "SET_PARM1", $get( STRING, "SET_PARM1" )$ ); and the parm1 you're using on your button model?

For me the changes seem to work ingame on Lugormod, by the way. Your button model is just a bit in the wrong place and not angled the right way, but the trigger+spawning ent worked there.

Try clearing out your base folder of other .pk3s to ensure that whatever issue you have isn't caused by extra vehicles and such.

EDIT2:

Your BSP is called t2_mod.bsp - why is this?

EDIT3:

Okay, took another look. Try renaming NPC_vehicle to NPC_Vehicle. I believe it's case sensitive. Lugormod may have fixed this with their mod, but base/JA+/JA++ might still have problems with it.

What I meant with the rotating part was, that if you have a func_ entity that you end up rotating to another angle, you'll need different coordinates from the usual !brushmoveorigin, which is where !brushmrorigin comes in. However you're still using a trigger so again, ignore all of that. Triggers don't get rotated obviously, and the angle key is used for the facing flag that is part of the entity itself. Again, never mind, this should be all good then.

Based on what I can see from your entity, it looks good. Note that the multiple spawnflag has always been broken from what I believe, but it shouldn't matter.

I'm also assuming you've tried to press the actual button in a 360 radius, right? Perhaps you were facing the wrong direction.

I took a quick look ingame and this is where your entity ends up ingame for me: https://jkhub.org/images/yvOWmgF.jpg

This is right outside of the large arena in the center of the map, so I'm kind of guessing this is where you intend it to be.

Are you absolutely sure your PK3 is set up correctly? Is your server set up correctly and the PK3 included in the base (or mod) folder? Perhaps you should post your file so I can have a look.

When I mod maps, I usually host a local lugormod server. I don't use any of the lugormod entities/features at all, except for the commands to reload the entities. In other words, I can conveniently edit the entity file, and reload all of them (/mapents load default) to see 'live' changes without needing to re-compile or restart maps. This can usually speed things up. It's just something I recommend to most people. Just keep in mind that some features are present on LMD that aren't on other mods, and some things may work there that can be absolutely broken on Base/JA+/JA++. It's just a tip, so use whatever method you prefer obviously. 

As for you not seeing the change you made, that could be harder to narrow down. Can you show the entity that you added?

Without seeing anything from your end, all I can do is guess. A few quick thoughts:

- Compiling went wrong or didn't include the (updated) .ent file. Check your .bsp and search if your added entities are there.

- Did you include the model of the bmodel in your entity?

- If you rotate a bmodel, you need a different origin (!brushmrorigin in UU) but that doesn't apply for triggers, only func_* entities.

- You didn't pack the PK3 correctly or didn't set the folder structure correctly. .bsp should be located in the maps folder.

- Doesn't overwrite the assets (or other PK3s). Has to at least be alphabetically after assets0.pk3 (z_YourPK3Name.pk3 should be fine). This is very unlikely.

About entity modding and GTKRadiant:

Generally you don't want to do this. There's a way to add solid objects (brushes) or resize them with GTK for entity modding. But it often doesn't work ideally. You can even remove collision, but it will give you a somewhat laggy effect when moving through said brushes because the client thinks it's still solid, prediction yada yada. There is a way to add or stretch brushes, but I only have found it to be good for walls and ceilings, not for floors/things to stand on. Your client will think it is still falling. Generally I suggest you forget all about GTK if you wish to do entity modding, as it generally is a somewhat messy method.

To me it seems like you're new to this thing. Did you read any tutorials? There should be a few on JKHub. So anyway, you need to know how to:

- Extract the entities

- Modify the entities

- Compile and put .bsp in a PK3

- Or if you're using an OpenJK server just upload the .ent file

There are plenty of guides which explain how to do the above.

https://jkhub.org/tutorials/article/81-another-entity-modding-tutorial/

https://jkhub.org/tutorials/article/50-adding-entities-to-maps-after-compiling-editing-base-maps/

To your questions, OP:

1. This should be very easy. In the t2_trip entities, find the existing info_player_start and simply move it to whatever origin you want. Yes, you can use /viewpos to get your origin, but it uses the camera, I believe. In JA+ you could use /amorigin or in Lugormod you could use /where as a command to see your clients origin. These commands should also show you the angle which you're looking at.

So you could also add an angle key to whatever direction you want people to be facing such as "angle" "180"

I recommend adding multiple spawnpoints to avoid people telefragging each other all the time.

NOTE: I believe in MP, info_player_start is exactly the same as info_player_deathmatch.

2. Depends on what exactly you want. The NPC_spawner entity can have an option that automatically respawns said vehicle when it gets destroyed.

You could also add something like a trigger with a use-flag targetting an NPC_spawner to spawn the vehicle.

About the video you linked: they're using health power converters. This is generally used for models because we don't have a convenient misc_model_breakable entity like lugormod does. Note how their crosshair turns yellow with the dead tauntaun on the floor at 1:26 or so. It's likely the same deal at other moments. They could also be using func_statics with model2 to show the models, and then put other bmodels (func_statics) inside the model to make it appear as solid. Or they could be using the blockwall feature from JA+.

So, on how to make a button and make it solid: you need to use the misc_model_health_power_converter entity. This is used for most if not all of the models people add in entity modding. It's normally used for those healing consoles that you press USE on and it gives you back health. Obviously you don't want this, so you make a very simple icarus script that sets set_player_usable to false. Save and compile that script, and include it on that entity as the spawnscript. It'd end up looking something like this:

{

"classname" "misc_model_health_power_converter"

"model" "models/map_objects/factory/f_con2.md3"

"spawnscript" "no-use"

"origin" "123 123 123"

}

The hitbox for that is generally not perfect however. Place it flat on the floor and you might be able to step on the button and it'd look somewhat odd. Generally I make it float a bit over the ground so noone notices it, or use a button on a wall or something. Alternatively you could move some bmodels inside the model so it would appears as solid, but that all depends on having a small bmodel available in the map you're using. 

[EDIT] To clarify - that only gives you a button (model) obviously. You will need to get a trigger that spawns an npc/vehicle. Most guides out there explain how to move bmodels, which is what you'll need to do to get a trigger to whatever place you want to get it.[/EDIT]

More complex designs are also possible, but would require icarus scripting and can be very complex if you're new to it. For example on my vjun map here's something I came up with: video.

However I'd refrain from attempting something so complex for the moment

3. Unsure what you mean. There is no magic command to magically texture something which has no texture.

Yes, you could technically cover things up with models (health converters or func_statics with model2 key), but the process would be difficult and use up many entities. Not saying it can't be done, but T2_Trip is too large to cover all of those areas up.

4. This should be easy enough. Simply dig through the entities and remove what you need to remove.

I can't access the JAWA page you linked, by the way. My explainations might be a little vague, but I feel like you should try and inform yourself a bit more OP, you could probably get most of the things you want to do easily. Let me know if you need more help.

Just so you know, it showing up in local for you is usually normal. I would put my money on a firewall issue if he cannot connect directly with the IP:port.

I can merely tell you what I know. If you want to dismiss what I'm telling you, that is your choice but it doesn't make what I'm saying invalid.

My Internet speed is ADSL2, and I was getting 0.1 MBps speed from the MBII server. Either the actual speed/traffic on the server, or the distance of that server from my location is throttling the download.

Possible. All I'm saying is that not everyone is having this problem. I for one was downloading at around 18 MB/s just fine the other day.

I have no MBII folder in "Documents/My Games/openjk/". I've been using the MBII client (OpenJK) from the start. If what you're saying is true, then MBII is not compatible with other versions/releases of regular OpenJK.

I'm not saying this. The way it current goes is that if you're using OpenJK without the launcher, it will write to those folders. Our launcher overrides this behaviour and forces it to the MBII folder, but again if you do not use the launcher to launch the game, then this override is not in place and it'll use my games instead. Anyway, if you're using the launcher and such then this is of no concern to you and you can ignore this, as it's not the case in your situation.

I don't see how it is related to me moving DLLs if the DLLs in GameData are not taken into account. Currently my base folder contains the assets1-3 pk3s and ui.x86.dll only -- absolutely nothing else. I'm launching the game using the official launcher with the MBII client setting. My JKA install is up-to-date (patched to 1.01). Yet the client mismatch persists.

Can you explain why you think those DLLs need to be in GameData? Serious question, as I do not understand why they need to be there. I'm aware of files like OpenAL, and OpenJKs renderer .dll and whatnot, I just don't see why any of the mod DLL files need to be in gamedata whatsoever.

The reason I was asking about you moving DLLs is because (in addition to the above):

MBII really needs a clean install of JKA for it to work properly. If you have a custom/later version of OpenJK, or have moved things around between base and GameData, chances are MBII will have trouble running.

For the devs (if they read this):



The installer/launcher needs to check for missing DLLs before running the game! If the requirements are not met, it should notify the user about the files it can't find.

the mod has no control over whether or not it gets created.

Correct, but he is using the launcher, and that does have control over it IIRC.

I haven't heard of this being the case, but it can't hurt to try in this case. However, if they're using OpenJK, they would have to delete openjk.cfg as that'd be the equivalent of jampconfig.cfg in that case.

I would like to remind people again - I am a retired MB2 dev, not a programmer, and that you'd likely have more help with this kinda deal on the MBII forums if this turns out to be a MBII specific issue.

1: Aware of this. All we can do is force the launcher to check if all files transferred properly and do another file check when the update finishes. Right now it doesn't do that automaticly so a repair installation in the settings in the launcher would be recommended. Beyond that, all I can tell you is download speed depends on your internet connection.

2: This doesn't seem right to me. You shouldn't have to put any mod (cgame jampgame uix) DLLs in base for MBII to run. Let alone in GameData where as far as I am aware nothing will read/use it. I am however aware that if you don't use the launcher from MBII it will put certain DLLs in my documents/openjk/mbii. The folder may contain the extracted .dlls from the previous version, and prioritize those over the newly updated (1.3 DLLs) ones in our updated PK3s in the GameData->MBII folder.

3. Possibly caused by you moving DLLs, or not launching the game correctly. However, my point above may also apply.

For the devs (if they read this):

The installer/launcher needs to check for missing DLLs before running the game! If the requirements are not met, it should notify the user about the files it can't find.

What files exactly are you talking about? MBII does not need anything in base other than assets0-3.pk3. Beyond that nothing should be an issue in there.

We distribute the DLLs for the mod in the MBII folder, which assuming your download goes well, should all be there.

You really need to explain your issue better OP, aswell as your solution if you fixed it. Details are important if you actually want us to be able to help other people in the future and solve these kind of issues.

"Create new game" and the whole thing just poops on you and throws you to the desktop, without any explanation as to what's happening...

So from what I can get from this, your normal game works? As in, multiplayer, joining a server and playing etc?

On the subject of create game, starting that from a custom resolution will make it crash.

I don't understand. Isn't the OP mentioning /Create Game/ is what is broken for him?

Seriously, all these  explanations are beyond vague.

And yes as others pointed out, you really really should be asking this  kinda stuff on the MBII forums. We have devs there who know better about these issues than I do, and not to mention it'll be a hell of a lot more convenient for us to keep track of issues and on how they were fixed. Not to mention, others who run into the same problem could search our forums and fine a solution there!

Unfortunately I have no such option in BIOS or at least I didn't notice it. Also as if I get this right, I can't play MB2 on a newer version of OpenJK until the devs release their modified version aka the MB2 Client?

You should be able to play it just fine on regular OpenJK. Just know that we didn't test it so issues may occur.

Well you could've answered my non-offtopic question already, considering you're one of the MB2 devs and clearly have more information on the mb2 openjk implementation.

Yeah, I have the answer, I just decided not to give it to you for fun reasons. I'm also a retired dev, am not a coder, and know little to nothing about OpenJK. I decided to bring in what info I did know, since someone was asking about that specific thing.

By the way, why aren't you asking this on the MB2 forums, if you actually want help from MB2 devs?

EDIT: I fixed it by renaming the newest rd-vanilla_x86.dll file to rd-vanilla-mbii_x86.dll. I have no idea why guys over at MBII did this but whatever. Gonna check if my issues are now gone.

We have our own fork of openjk for MBII, and because we don't want it to conflict or overwrite the normal version of OpenJK (say, if you use it in BaseJKA/JA+/something else), these files have different names.

As for the IGP crashing after some time, this is a complete guess: don't motherboards have their own settings as to how much ram they assign to the IGP? In the motherboard (BIOS/UEFI) settings I believe its either set to auto or a static limit of VRAM that the IGP can use for itself? This may differ per system (and is most likely complete different on a laptop, perhaps you can't even alter this there). All I can say is MB2 obviously uses more vram than BaseJKA does and perhaps the longer you play, the more models get loaded (due to people switching models etc) and more data is used by maps etc. Again, a complete guess.

Why does it say 

sv_master1 is read only.

 Something must be trying to change the sv_master1 outside of code.  Not related to issue though.

Probably the launcher for MBII setting it to MBII's one

Although this is most likely not the case, I had a similar issue on win10 and found out my nvidia control panel tried to force SLI, put it back in single GPU and worked fine.

Went to shit for the past few years, yeah. A shame they didn't give people a chance to download some of the old files up there though.

It's a lot of effort. Larger projects like JKG have failed simply due to lack of proper leadership. 

It also depends on what you'd like to do with it - remaking SP/MP content would be silly, if you ask me.

The real problem would be animating, models and sound, I'd argue. Models would have to be re-made from scratch, and many third party-made models out there are not really that optimized.

Level design wouldn't be much of an issue.

I remember that in the past, hosting multiple servers on the same IP would not work too well with raven's master server. Some would occasionally not show.

If you have a extra IPs, I'd recommend trying that out.

You could try setting your fs_homepath (startup parameter) to your server folders location again so it'd end up in the mod folders instead of the local folder that OpenJK sets them to, I think.

Just a wild guess.

Triple posting won't make it go any faster. Merged.

It looks like Raven's master server is up again right now.

Looks like it worked! 

Jokes aside, good to know it's back up. Probably related to the Bundle, yeah. Lets hope it lasts a bit longer this time.

Latest beta drivers (347.25) with GTX 970 here. All working just fine on jamp.exe. 

Pretty sure it went down again.

So if you hosted a game and told said player the IP, would it still work? or would you still need to rely on the master server?

You can connect to any server with just the IP. The master server is purely for displaying servers in the list.

Letting them know that on MB2 forums got me banned for a week, lol.

I'm sure your trolling has nothing to do with this.

MBIII development has stopped quite a while ago. hleV is right that something else is in the works by some of the MBII/MBIII devs, but the MBII team has nothing to do with it. 

Personally, I don't know any of the details whatsoever. I hope it works out for them, though.

There are quite a few devs still working on MBII, is all I can say.

Note: Fix your shitty ass site so that it doesn't get blocked by NOD32.

Appears to be some kind of false positive and I've mailed them about this weeks ago.