Dragofer
-
Posts
2631 -
Joined
-
Last visited
-
Days Won
157
Posts posted by Dragofer
-
-
I've had an Intel HD 3000 in the past and was able to run TDM 2.04 (most recent version at the time) with around 10-20fps and without graphical errors. For more recent versions I had the same experience as you: unplayable because of performance and bugs. I think part of the problem may be that that laptop is just so old that the system-wide performance has become abysmal.
-
Well it looks like you can buy a plugin that unlocks the option for users of this forum to ignore topics for $15. Maybe it'd be worth it to make a collect so taaaki can buy this feature?
More options:
Plugin: Hide ignored users' posts from activity stream and search results: $6.50
This one looks like a combination of the above 2 for $11.50, but there's 1 negative review saying it disrupted long threads.
-
Steam probably just wouldn't accept a submission from a legal entity that's in a country without copyright enforcement. If the copyright claimants can't get at the "owner" of the game, then they'd just go for Steam itself?
An alternative would be to designate someone in a Western country who lives a life secluded from society and with no valuable possessions, i.e. in a makeshift hut in the forest. But then courts might see through that and instead look for people who have demonstrable ties to the project, i.e. members of the development team living within their jurisdiction. Or Steam just rejects the submission for the same reason as above.
Online stores aren't exactly a hospitable environment for a free open source project with 15 years worth of contributions.
-
1
-
1
-
-
On 8/18/2021 at 2:43 AM, Kurshok said:
I'm not a goddamn troll. But then again, isn't it easy for people to try and discredit others as "trolling" on a digital platform? No, I mean every fucking word I say when it comes to the topics. And yeah, reality can be brutal and unfair. Doesn't mean we have to accept it and get beaten down until the world is entirely a hellhole with a pussywhipped "such is life" attitude about it.
If your special interest is politics and controversies, then your discussions would be much better received on a dedicated forum for discussing such things.
This is a fan community whose focus is on enjoying and developing TDM. Trying to confront "brutal and unfair reality" primarily results in filling up ignore lists, rather than the result it's fair to assume you're looking for, which is to get an in-depth discussion of the topics that interest you by a large variety of people who are as interested in them as you are.
-
2
-
-
From my perspective there's one bad sheep among our FM download mirrors that's abysmally slow even for the smallest mission. Could be the main TDM server that's supposed to see almost no traffic?
-
The West spends trillions and loses thousands of lives for the futile installation of democracy in foreign countries on the other side of the world, while China invests trillions in infrastructure and is now poised to dominate this century.
After ca. 20 years in Vietnam and another 20 years in Afghanistan, how much more do we need to learn from our mistakes?
-
2
-
-
32 minutes ago, Geep said:
Scripting question. For script variables that are at file level (not within a function and not part of a script object), are their values automatically handled correctly during game Save/Load? Or does the script author need to do something explicit?
Yes to question 1, I've used such variables for the new secret tracking system and encountered no problems when testing loading and saving.
-
1
-
-
I've added support for "set x on head" spawnargs for AI heads, adding a simplifed version of the general method from idEntity::ParseAttachmentSpawnargs() to idActor::SetupHead(). Rev 9557
-
2
-
-
@OrbWeaver
A lot of chests contain objects that can only be frobbed from certain angles/distances, especially if the chest body is frobable and it's not possible to climb on top. You know the items are in there, but you can't see them at the time of frobbing. Chests are one of the clunkier aspects of gameplay. -
I'm wondering if there's a way to set spawnargs on heads of AIs:
Normally for anything that's def_attached, you can use "set x on y", where x is the name of the spawnarg and y is the name of the attachment (name_attach). So i.e.
"set light_radius on flame" "120 120 120"on candle holders changes the radius of the def_attached light entity ("name_attach" "flame"). This is important because in DR it's not possible to select or apply spawnargs to def_attached entities directly.
Problem is, it seems heads are attached differently. You use def_head instead of def_attach, and there seems to be no name_attach given to the head (only "head_bodyname" "head" and "head_jointname" "head"). This doesn't work:
"set model on head" "head_skeleton_skull"These "set x on y" spawnargs seem to be parsed in Entity.cpp from line 12886. Maybe we should add separate handling for "set x on head"?
Spoiler// tels: parse all "set .." spawnargs const idKeyValue *kv_set = from->MatchPrefix( "set ", NULL ); while ( kv_set ) { // "set FOO on BAR" "0.5 0.5 0" // means set "_color" "0.5 0.5 0" on the entity attached to the attachment point // named "BAR" (defined with "name_attach" "BAR" on the original entity) // Get the value // example: "0.5 0.5 0" idStr SpawnargValue(kv_set->GetValue()); // "set FOO on BAR" idStr SetAttName(kv_set->GetKey()); // "set FOO on BAR" => "FOO on BAR" SetAttName = SetAttName.Right( kv_set->GetKey().Length() - 4 ); // "FOO on BAR" idStr SpawnargName(SetAttName); // find position of first ' ' int PosSpace = SetAttName.Find( ' ', 0, -1); if (PosSpace == -1) { gameLocal.Warning( "%s of class %s: Spawnarg '%s' (value '%s') w/o attachment name. Applying to to all attachments.", from->GetString("name", "[unknown]"), from->GetString("classname", "[unknown]"), kv_set->GetKey().c_str(), kv_set->GetValue().c_str() ); //kv_set = from->MatchPrefix( "set ", kv_set ); //continue; // pretend "set _color" "0.1 0.2 0.3" means "set _color on BAR" where BAR is the // current attachement. So it applies to all of them. // SpawnargName is already right SetAttName = AttNameValue; } else { // "FOO on BAR" => "FOO" SpawnargName = SpawnargName.Left( PosSpace ); // "FOO on BAR" => "BAR" SetAttName = SetAttName.Right( SetAttName.Length() - (PosSpace + 4) ); } // gameLocal.Printf("SetAttName '%s'\n", SetAttName.c_str()); // gameLocal.Printf("AttNameValue '%s'\n", AttNameValue.c_str()); // gameLocal.Printf("SpawnargName '%s'\n", SpawnargName.c_str()); // does this spawnarg apply to the newly spawned entity? if (SetAttName == AttNameValue) { // it matches, so this spawnarg must be applied directly to this entity //gameLocal.Printf("Match: Setting '%s' to '%s'\n", SpawnargName.c_str(), SpawnargValue.c_str() ); args.Set( SpawnargName, SpawnargValue ); } else { // pass along the original "set ..." spawnarg, it might apply to an // def_attached entity of the newly spawned one //gameLocal.Printf("No match: Passing along '%s' ('%s')\n", kv_set->GetKey().c_str(), SpawnargValue.c_str() ); args.Set( kv_set->GetKey(), SpawnargValue ); } kv_set = from->MatchPrefix( "set ", kv_set ); // end while ( kv_set ) }What I want to use this for is to set "model_xray" on heads so that they get replaced with a skull when seen through an xray screen. This would be much more convenient than having to create a new head entity just to change a couple spawnargs.
Edit: might be better to modify idActor::SetupHead() in Actor.cpp since that's where def_head is handled, while the code I pasted from Entity.cpp only handles spawnargs for def_attach entities before spawning them.
Spoilervoid idActor::SetupHead() { idStr headModelDefName = spawnArgs.GetString( "def_head", "" ); if (!headModelDefName.IsEmpty()) { // We look if the head model is defined as a key to have a specific offset. // If that is not the case, then we use the default value, if it exists, // otherwise there is no offset at all. mHeadModelOffset = spawnArgs.GetVector(headModelDefName, "0 0 0"); // greebo: Regardless what happens, the offsetHeadModel vector always gets added to the offset mHeadModelOffset += spawnArgs.GetVector("offsetHeadModel", "0 0 0"); idStr jointName = spawnArgs.GetString( "head_joint" ); jointHandle_t joint = animator.GetJointHandle( jointName ); if ( joint == INVALID_JOINT ) { gameLocal.Error( "Joint '%s' not found for 'head_joint' on '%s'", jointName.c_str(), name.c_str() ); } // set the damage joint to be part of the head damage group (if possible) jointHandle_t damageJoint = joint; for (int i = 0; i < damageGroups.Num(); i++ ) { if ( damageGroups[ i ] == "head" ) { damageJoint = static_cast<jointHandle_t>( i ); break; } } // Setup the default spawnargs for all heads idDict args; const idDeclEntityDef* def = gameLocal.FindEntityDef(headModelDefName, false); if (def == NULL) { gameLocal.Warning("Could not find head entityDef %s!", headModelDefName.c_str()); // Try to fallback on the default head entityDef def = gameLocal.FindEntityDef(TDM_HEAD_ENTITYDEF, false); } if (def != NULL) { // Make a copy of the default spawnargs args = def->dict; } else { gameLocal.Warning("Could not find head entityDef %s or %s!", headModelDefName.c_str(), TDM_HEAD_ENTITYDEF); } // Copy any sounds in case we have frame commands on the head for (const idKeyValue* kv = spawnArgs.MatchPrefix("snd_", NULL); kv != NULL; kv = spawnArgs.MatchPrefix("snd_", kv)) { args.Set(kv->GetKey(), kv->GetValue()); } // Spawn the head entity idEntity* ent = gameLocal.SpawnEntityType(idAFAttachment::Type, &args); idAFAttachment* headEnt = static_cast<idAFAttachment*>(ent); headEnt->SetName( name + "_head" ); // Retrieve the actual model from the head entityDef idStr headModel = args.GetString("model"); if (headModel.IsEmpty()) { gameLocal.Warning("No 'model' spawnarg on head entityDef: %s", headModelDefName.c_str()); } headEnt->SetBody( this, headModel, damageJoint ); headEnt->SetCombatModel(); // Store the head locally head = headEnt; DM_LOG(LC_AI, LT_DEBUG)LOGSTRING("SETBODY: Actor %s : damage joint %d for attached head is part of damage group %s\r", name.c_str(), (int) damageJoint, GetDamageGroup( damageJoint ) ); // Add the head as attachment idVec3 origin; idMat3 axis; CAttachInfo& attach = m_Attachments.Alloc(); attach.channel = animator.GetChannelForJoint( joint ); animator.GetJointTransform( joint, gameLocal.time, origin, axis ); origin = renderEntity.origin + ( origin + modelOffset + mHeadModelOffset ) * renderEntity.axis; attach.ent = headEnt; attach.posName = jointName; // grayman #2603 headEnt->SetOrigin( origin ); headEnt->SetAxis( renderEntity.axis ); headEnt->BindToJoint( this, joint, true ); // greebo: Setup the frob-peer relationship between head and body m_FrobPeers.AddUnique(headEnt->name); } }
-
It may be too late to change how frob detection works, since it's entirely possible that there are missions with frobable items arranged in such a way that they can no longer be frobbed if a clear line of sight is needed.
A frob outline with depth detection wouldn't break anything except possibly performance. Maybe this could be remedied by introducing overall graphics settings - Low, Medium, High, Ultra High - in which the frob outline is disabled on lower settings.
-
Yeah, a kind of "point-and-click" align feature via the Camera sounds quite useful. Maybe there could be a new button next to "Floor selection" that, once clicked, does the alignment as soon as you click somewhere in the Camera. Though that could get screwed up if you click somewhere else. Alternatives like a left-click menu or a hotkey wouldn't be discoverable enough.
That said, I'd already be well served just by a simple horizontal alignment button that asks me whether I want to align my selection north/west/south/east. It also seems much simpler to implement.
-
2
-
-
1 hour ago, MirceaKitsune said:
Once you insert that item, it's automatically positioned so its back rests against that wall (total bounding box), the item also rotated to face toward the camera (in 90 or 45 degree increments).
This sounds quite prone to error, considering that you can't really expect a program to figure out which way is forward on a model. Also, a lot of the time you'd want to snap something to something more complex than a wall, i.e. filling up a shelf. I think such tasks will work better if they're supported, but not automated by DR, since programming an automated system that covers the majority of situations sounds like a nightmare.
What could be nice is having a horizontal version of the "Floor selection" button. Since there are 4 possible options (X+, X-, Y+ and Y+) it could help if it were a single button that took the current view direction of the camera (N-S-W-E) into account. A possible downside is that it can be a pain if the mapper constantly has to turn the camera (and reposition it if he still wants to see what he's working on) in order to get things to move into the right direction.
1 hour ago, MirceaKitsune said:Some shortcuts like "floor selection" offer limited help afterward, but even then you usually need to select the wall so you can see the red outline and be sure on how much you need to move that item so it correctly rests against the surface.
By the way, it gets much easier to align 2 things if you hide the entire rest of the map, i.e. by selecting what you want to work with and then pressing I (invert selection) then H (hide selection). Alternatively, Ctrl + Shift + H.
-
1
-
-
1 hour ago, SeriousToni said:
OK thank you! And when do I use the various options for under the connection tab? I was changing the ambient light and wanted to see how it looks ingame instantly, so I tried reload map file command from the menu but it didn't do anything.
The ambient light is usually controlled by the location script system. Script-controlled entities including anything with def_attached lights usually aren't supported that well by hot reloading. You might get it to work by selecting your info_locationsettings entity and respawning it from the connection tab.
-
1 hour ago, thebigh said:
When I make a room it just looks like a big empty horrible-looking room and I immediately lose motivation to put things in it and make it look nice
There's copious amounts of inspiration to be had for medieval/renaissance rooms from projects made at the Feng Zhu Design school, like this one:
Definitely don't have to have that much stuff especially in a first mission (quite a few of their scenes are heavy on the clutter imo), but it gives plenty of primers for what could be done.
-
2
-
-
1 hour ago, NeonsStyle said:
@STiFU It was an email I got from Google telling me this.
Hm, it might be worth looking closely at the URL of the sender - it might not be Google, but a phishing attempt.
-
1
-
-
The other thing on my "texturing diagonal brushes wishlist" is that I wish it were easier to align textures on slanted faces with each other. The screenshot below shows the result when using the MMB and Ctrl + MMB to paste the texture from the left face to the right face:
The vertical alignment of the pasted texture is just way off, even though both faces have the same slope gradient. It's possible to work around this by cloning the brush and rotating it 90° before pasting so that source & destination faces are on the same plane. But it'd be nice if DR could, say, detect that both faces have the same slope and thus treat them as if they're on the same plane for texturing purposes.
-
I've moved what was shaping up to be a longer discussion of the frob highlight feature and menu settings to its own thread here. The public dev builds thread is in my understanding a good place to post specific feedback on a new dev build, but anything more substantial deserves its own thread.
-
I can see that it'd be difficult to rotate the texture during a shear operation, but I actually want the UV coordinates of the texture to change as little as possible in this case. This is roughly the Texture Tool equivalent of the above screenshot:
The reason why patches work well in such a scenario is that their patch vertices can be moved without shifting the UV vertices, allowing both to be controlled precisely without conflicts. That matters when making long, intersecting beams, where a few units of error can lead to z-fighting, gaps or clipping through each other.
For technical reasons that exact behaviour won't be possible for brushes - i.e. the UV island can only have right angles if the brush face has right angles. And there'll probably still be a need to adjust the scale afterwards (though less finicky than adjusting the rotation). But maybe it could be approximated with a form of texture lock that minimises changes to the UV islands? Maybe by only allowing UV transformations in one axis at a time: the one with the smaller change?
-
We could probably at least swap out the menu option for the frob helper with one for the frob outline, since the outline is a much more substantial effect. Or have neither if we don't believe such options should be accessible in the main menu.
There are probably quite a few cvar-only settings that'd be interesting to some people, such as texture resolution, that could go in a submenu as suggested by Mircea.
-
1
-
-
I was wondering how feasible it would be to tweak the way brush texture alignments are handled for diagonal brushes.
In the screen below I'm trying to make a diagonal brush by shifting the top 4 vertices horizontally. The top half shows the current behaviour, where the texture basically stays vertical. The bottom half shows what would be preferrable.
Currently, as far as I'm aware, the desired look in the bottom half can be achieved by:
- Using brush-shaped patches, which is probably the most time-efficient method that's also precise.
- Rotating the brush. If the vertices must be snapped to grid without changing the dimensions of the brush, one can copy the brush, rotate it and use the MMB to paste the texture over to the original brush.
- Open the surface inspector, select 1 face at a time and rotate the texture until it looks right (i.e. by setting the rotation increment to 1 and then holding down one of the arrow keys), then adjust the vertical alignment.
Definitely a wishlist kind of thing and can be disregarded if it requires drastic changes to the brush texturing algorithm. But some kind of "texture lock" that lets the texture follow the angle of the brush face would be nice.
-
1
-
Our forum rules state that personal attacks and harrassment are off-limits. Coming from a specific country or culture doesn't give license to blatantly flout them, i.e. by alleging mental illness.
I believe everything that needs to be said has been said for now, so this thread can be locked.
-
1
-
-
59 minutes ago, duzenko said:
You kinda assume that @MirceaKitsune gets deeply offended and psychologically traumatized but in fact in his culture he may get that a lot every day and he simply chooses to not respond like this because he's a nice guy
It's fortunate that MirceaKitsune seems to take this easy, but it can't be excluded that others in his situation would respond - and have responded - by withdrawing from the forums. This is an important reason why our historically hands off moderation policy is being discussed again.
-
A fine update with an impressive changelog!
How does the "ignore user" function work?
in Off-Topic
Posted
If I'm reading the description correctly, that's what the last one of those plugins promises to do. Quite shameful that we have to pay for what should be basic functionality, but at least it exists and doesn't seem insurmountable... Would have to make sure it does what we want.