All Activity

Unfortunately that didn't work. It can't find the inventory item, no matter what name I use for it. I think the engine does some special processing when you pick up melee weapons. I also tried code to delete the blackjack weapon: $player1.selectWeapon("blackjack") entity weap = $player1.getWeaponEntity(); weap.remove(); but that crashed the game. Is there any way to temporarily override the key bindings, so that '1' and '2' are inactive?

Well done, once again i am soo sorry to give so much grief

Is it rare that I find these topics entertainingly funny? Visualizing the faces of those programmers coding graphics in RAM, while those of OpenGL talking about "well, how are we going to prevent this?" I guess I'm a sophisticated guy.

Entities can be changed with no need to recompile the map. DR is quite a good entity editor.

Yes, there was some bureaucratic mess related to deprecation during GL 3.0 and 3.1, which was finally resolved in GL 3.2. Like "deprecated but not removed yet" which later turned into "removed in core". It can easily explain it worked before version bump, but stopped working after it.

Coming back to the issue in the tutorial mission where you can unlock both the base and the lid of a chest, until somebody makes a remaster of this, is there an entity editor for TDM to fix this quickly without the need to recompile the whole map?

Probably since OpenGL <=3.1 allowed to use Client-Side Vertex Arrays, instead of Vertex Buffer Objects, drivers just followed the same capability. Even if it didn't make sense programmatically. For instance they removed that possibility in OpenGL 3.2, likely just to make it explicit that you should not program that shitty, 80s graphics style.

There hasn't been a halloween contest for many years. Sometimes authors will release a halloween themed mission on their own (like this one two years ago), but I don't know if there are any in the works this year. There is a contest announced for Christmas but it's not necessarily Christmas themed...

I don't know about approval, but it would definitely give me a good chuckle! Exciting that there is a new contest out, haven't had one of these in a long time! I like the theme of connecting storylines too. We'll see if I have time to participate, been rather quiet from me lately unfortunately, but I am well on my way creating a prequel to the CoS trilogy. If all goes smoothly with that perhaps I will have time to flesh out an unreleased 3-mini mission campaign I've put on the shelf for this contest, but I would definitely have to put my nose to the proverbial grindstone to make the deadline.

Better use your browsers inspect function. But there indeed are paragraphs consisting of only a non-breaking space between the lines. I too wonder, why nbohr1more did the extra work leading to a longer and less readable post.

Agree about fixing the error I just can’t imagine a game requiring a core profile and then doing client arrays. Oh, wait…

Live the idea of the contest!! Very good! Nbohr's posts always look like this these days and I always wonder how he does it. @nbohr1more do you write your posts in some other editor and perform manual linebreaks (and maybe even have different lineendings than what the forum expects)? Edit: I just copy pasted the post to notepad++ and enabled showing of whitespace characters. What are you doing there mate?

@demagogue Quite a few of the methods for calling a script in fact pass the name of the calling entity. For example, any entity that has a "frob_action_script" passes its own name. This makes it quite straightforward to getKey custom spawnargs that were set on that entity in DR. The callscriptfunction entity is the most versatile method because it's uniquely able to pass 3 different entities: itself, the entity that triggered it and one of its targets. In the wiki example, the buttons target such entities. @Geep Yeah, I suppose at least some of those examples could use visualisation

Now I can finally decipher the correct stack trace. Here is the list of commands which was necessary to achieve that: # note: all the .so files obtained from user machine must be put into local directory. # # most importantly, the following files are necessary: # 1. libthread_db.so.1 and libpthread.so.0: required for thread debugging. # 2. other .so files are required if they occur in call stack. # # these files must also be renamed exactly as the symlinks # i.e. libpthread-2.28.so should be renamed to libpthread.so.0 # load executable file file ./thedarkmod.x64 # force gdb to forget about local system! # load all .so files using local directory as root set sysroot . # drop dump-recorded paths to .so files # i.e. load ./libpthread.so.0 instead of ./lib/x86_64-linux-gnu/libpthread.so.0 set solib-search-path . # disable damn security protection set auto-load safe-path / # load core dump file core core.6487 # print stacktrace bt

Because they are more permissive. Maybe some popular game used CPU pointers in core profile, so drivers decided to support it. Anyway, it is a big error for core profile, and it must be fixed.

This is an old issue. It's not straightforward to pass the calling entity to a script, because it's technically the "player" that's being passed to the script (the thing frobbing the button, not the button itself, or whatever it is). You can't get the button's spwanargs because the script has no idea what button called it, since the player was the calling entity. (You can get the player's spawnargs, but what good is that?!) So when you want conditional calls to the same script becomes a big mess, since the same player is always passed; how do you get the conditional value in? Tels actually fixed it, or made a version of a call that would pass the button directly instead, which was great. But IIRC it broke a puzzle in one FM so the idea was torched. I proposed we could just make a new kind of button that passes itself directly under that new system as a parallel thing (i.e., "pass the frobbee not the frobber" as a parallel call type to "pass the frobber", and a different type of button for each one) so it doesn't break that FM, but I guess by that time the momentum for it was dead, or maybe that idea wouldn't work. Too bad as it'd be a really nice thing for mappers to have. I think there's a way around it, but I can never remember what it is, so it can't be that intuitive by comparison. Edit: Oh that's right. Yes, you just put the value in as a spawnarg to some dummy object and then getKey it into the script, although then you still need two steps (one to setKey it into the object and one to getKey it into a script; remember the script doesn't know which button to getKey either, so you can't just tell it to getKey "the button you want"), so it's still annoying. Be better if the script could just take it directly from the arbitrary calling button! But alas! Edit2: Note though I had issues with this years and years ago, so I don't know if any functionality or methods were developed after I looked into it back then. Edit3: I guess I should have read the wiki entry. So I gather with a "call" "scriptname" set on a button you can use "ent_button.<function>" in the script (instead of the old "$player1.<function>"), so the script get the spawnargs directly off the calling button / ent_button. If you can do that, then this is what me & Tels were talking about. I believe the catch is you're making your own buttons with this functionality instead of the vanilla functionality of buttons, which is fine under the circumstances, but this is the part that needs to be communicated, I guess. Thanks for that wiki entry by the way, Dragofer. We'd be even more confused without it!

Yes, that wiki example was pretty opaque to me. Now I can see how getting a button's spawnargs works.

@Dragofer Perhaps that advanced example is a bit hard to grasp, a little too abstract in presentation. Maybe it needs an illustration with 2 buttons, "Jump East" and "Jump West", and two rabbits (func_static model instances) that "jump" in unison. And the salient Entity Views of each button and the target_callscriptfunction.

Yep, that seems like the way to go. The "advanced example" uses spawnargs like this on various entities to make a teleportation buttons setup. Once you have an entity you can also get all its spawnargs.

I will test too when I have a moment.

What is it supposed to fix? Core profile on pre-GCN Radeons? Why did all other drivers work if it's about the removed legacy stuff? I can test tomorrow, but I'm skeptical.

Ah got it.

I think I fixed all calls in svn rev 9595. Here are executables from the latest SVN, most likely compatible with the latest dev build. It would be great if someone can verify that everything works properly now even with "r_glCoreProfile 2" (default).

Yes. One has to be logged into Github to see the download links, but there's a portable package for each pushed set of changes. E.g. https://github.com/codereader/DarkRadiant/actions/runs/1218642341

This is one of two stand-alone WIPs Grayman could not complete anymore. He asked his son to donate both WIPs to our Abandoned WIPs thread. Bikerdude is working on the other one called "Seeking Lady Leicester".