Search / View

[Tequila]

Hola conpadres !

for anyone interested, don't miss the news on Smokin'Guns Return I pushed on the site regarding future possible developments.

Anyone interested could join the discussion on Discord looking at the #dev channel or feel free to put your 2 cents here.

[illwieckz]

Yay!

[Barto]

I'm speechless, that's a lot of work you are attempting! Also, wow, Tequila is alive!

Still, I wonder what are the plans about unknown/unclear-licensed assets, or maybe randomly obtained stuffs/textures from the web.

I'll try to come on discord and get my goddamn IRC client to play nice with it. We'll see how I can do things...

--EDIT--
On freenode:

• #smokinguns bridges to #general
• #smokinguns-dev bridges to #dev

Thanks everybody for this!

[illwieckz]

Some early screenshots of maps ported to Dæmon the quick&dirty way:








No the game does not work yet, it's just some screenshots of the renderer, nothing is done on the code part yet, which is the biggest part of the job.

[TheDoctor]

Does the Daemon game engine use the same tools such as GTKRadiant?

In my opinion, the weak spot of games like SG are the aging tools for content creation. Creating a map is more difficult and much more time-consuming than it should be, not too mention the task of creating models with animations.

What needs to be done to compile a given .map to Daemon?

You probably are aware of Wild West, which attempted to port br_elpaso to the ET engine. Were you able to re-use some of their work?

[Tequila]

I'm speechless, that's a lot of work you are attempting! Also, wow, Tequila is alive!

Still, I wonder what are the plans about unknown/unclear-licensed assets, or maybe randomly obtained stuffs/textures from the web.

I'll try to come on discord and get my goddamn IRC client to play nice with it. We'll see how I can do things...

Yes, always alive !

The plan about unknown/unclear-licensed assets will be just to remove or recreate assets. This would be a shame if this means few maps have to be removed, but we will have no other choice.

@illwieckz You did a nice job. Let's work on the code now !

[illwieckz]

Does the Daemon game engine use the same tools such as GTKRadiant?

We use NetRadiant, the one by Xonotic, wich is a weak spot too!

Well, NetRadiant code is ugly but GtkRadiant code is worst, and NetRadiant usage looks better to me (GtkRadiant 1.6 is based on an older branch than NetRadiant).

We added to NetRadiant the DPK format support, a PK3 derivative that supports dependencies, this way both the engine and the editor only loads what is required (not the map compiler yet thoug), it means in NetRadiant you only see the texture packs you rely on.

I also patched q3map2 to support out-of-tree build. So it's now possible to follow both “out-of-tree build” and “eating-your-own-dog-food” best practices while mapping.

Also, PK3DIR/DPKDIR support was added to NetRadiant (using a directory with .dpkdir ext instead of .dpk file) in both engine and editor ensures you don't forget any files while packaging: your map is in map-name_version.dpdir and everything you need are in (or are shipped in packages you declared) and you won't seen other things in radiant (they will be displayed as missing even if they exists). See how UnvanquishedAssets repository is made to have an idea of how it works.

I also added a (very basic) pakpath support to NetRadiant, so mappers would not have to store their work in progress in ~/.smokinguns/smokinguns, but in a clean repository of their own at the place they want, even multiple of them, like one directory for official SmokinGuns dpkdir to build against, and one directory with their own custom dpkdir.

(Unlike GtkRadiant until I implemented something similar too), NetRadiant is able to load multiple shaderlist.txt : the one from the dpkdir your map live in and the ones from the dpkdir it depends on. It means you only have to edit it when you create texture sets for your own map, not when you reuse some other maps. And it means you can work on too map at the same time without having to rewriting it by hand while switching between them.

So, it's still radiant, but with improved usability in both the tool and the way to work with.

In my opinion, the weak spot of games like SG are the aging tools for content creation. Creating a map is more difficult and much more time-consuming than it should be, not too mention the task of creating models with animations.

NetRadiant is still radiant (I work on trying to make it more usable), for models Dæmon supports IQM models which are bone-based models with various tools and plugins out there. So people can use their beloved Blender or something else and export them. MD5models are supported too but IQM is recommended and after all MD5model to IQM conversion is straightforward: if your tool has MD5model support or a plugin to (which is likely to be possible since it was Doom3's format), you know you can make a model for Dæmon, either in MD5model format directly or in IQM after conversion.

What needs to be done to compile a given .map to Daemon?

The good, bad, and specially ugly q3map2, the one from NetRadiant's tree. The q3map2 from GtkRadiant is lacking too much feature, don't use it to target Dæmon. I added a very basic Dæmon support to GtkRadiant (dpkdir without deps support, for example) people have a fallback tool, but q3map2 must be the one from NetRadiant tree in any case.

Note that Viech from Unvanquished wrote a graphical tool named Chameleon to retexture maps (source required) with high-resolution alternatives without breaking the scaling.

You probably are aware of Wild West, which attempted to port br_elpaso to the ET engine. Were you able to re-use some of their work?

Yes, someone told me on that forum before, perhaps you.

And I'm also aware of the Wolfenstein: Enemy Territory's Western contrib map by Sage.

Since Dæmon has lineage from both ioquake3 and ET:XreaL those maps loads without recompilation. The only work to do is to somewhat reorganize the files the dpk way, and add the required entities into the entity lump to make it playable with Smokin’ Guns gameplay. The entity lump still being a text format inside and there is tools to extract and remerge it, including my Esquirel tool which I used to successfully port some UrbanTerror contrib maps to Unvanquished, and for that I had to edit the entities, rewrite some surfaceparms, and do a very basic texture fix. See my InterstellarOasis project.

Note that I got Western map source by Sage and already got permission to rebuild it for Smokin Guns (it can be good to ask for an explicit CC By SA 4.0 though) but the big issue in it is that it relies on some Wolf:ET textures and prefabs (so, a rebuild would lack some geometry).

So the Dæmon engine would make the port of those foreign things easier, especially when source is missing. Oups! I just written a wall of text.

[Barto]

Looking good illwieckz, I guess you repackaged the maps into unvanquished, right? I can observe that some entities are not understood, like the breakable windows in your shots, or the moving train (or landscape to be more exact).

That'd be a shame if you have to heavily remove contents. Assets under some unclear license weight about 75% of this game maybe. But, hey, that's the right way to do it as you well mentioned. Just don't lose those for the moment!

So far, I was pretty happy about the state of the general code. So, except for the sake of modernizing the code base, I would be already amazed to see a new sync to ioq3's code base with QVM cleanups, bug fixes and a merge of TheDoctor server's code. The game is known to have many quirks, which were often game breaking or being abused. It is likely to be one of the reasons that players left. But hey, with a $0 budget, you can't do much.

[TheDoctor]

NetRadiant is still radiant (I work on trying to make it more usable)

Regarding map making, I wished we had

• a map editor / a map format, which supports subtraction of objects without loosing information about the original objects. Example: door frames (let the map compiler break a door frame into surfaces, but let it remain one box of wood texture minus another box of void for the sake of better editability)
• a way to hierarchically group elements of a map so one can easily reselect, move, resize and retexture them. Example: door frame, door+door frame, house
• a way to share (grouped) elements between maps
• a way to clone/re-use a group of surfaces, such that editing the master will change all copies. Example: windows, doors with door frames
• a map compiler, which automatically detect unseen surfaces and caulk them
• a map compiler, which doesn't exit when compiling .AAS files for complex maps, e.g. Pyramid of the Magician
• (a map compiler, which can replace a texture by a repetitious structures, such as ladders, walls, fence, planks; probably with a combination of hiding/showing either those structures or the texture, depending on how far the viewer is)
• (a map compiler, that adds dirt/shade depending, how close textures are from the ground and whether they could reached by rain/visible from open sky)

What do you think is feasible/viable?

I would be willing to help out a few hours a week, but I would need ‎instructions what to do and where to begin. I can program, but I'm not good enough at it to implement any of the above (or I would have attempted it by now).

Also, I think, it was a bad idea for every Q3 mod to become standalone. If there would be a chance for a number of games to share a single engine again, this would help to share a player base and assemble forces.

[illwieckz]

Looking good illwieckz, I guess you repackaged the maps into unvanquished, right?

Right, just to show how close the engine are since they share the same lineage.

I can observe that some entities are not understood, like the breakable windows in your shots, or the moving train (or landscape to be more exact).

I think you can also see the hole in the bank, even from that angle. Yes, the breakable things are not rendered, probably because of entity yes, I thought the same. The train is moving (well, the landscape).

That'd be a shame if you have to heavily remove contents. Assets under some unclear license weight about 75% of this game maybe. But, hey, that's the right way to do it as you well mentioned. Just don't lose those for the moment!

Oh, Smokin' Guns already have the right to redistribute assets and there is no reason this right will be lost. It's better to ship a game with those than without alternatives. But if people contributes new things, please use a CC By SA 4.0 license to solve the problem today for future generations.

First priority is to have an updated and maintained game (and playable, of course).

[illwieckz]

Regarding map making, I wished we had […]

Oh yes some of these ideas would be cool to have. Note that other radiant forks has cool features, uforadiant has a cool prefab library, darkradiant seems to have a layer functionality (never tried, don't know if it's what I think it is).

What do you think is archievable?

Do you mean achievable ?

Well, most are far above my own knowledge. It's already interesting to have a look to others radiant, sometime they have interesting things. The most advanced one today is darkradiant which only lack one thing to open q3 maps correctly (the q3 brush texture scaling is currently a stub). And it lacks q3 entity file support to be usable to map for the q3 derivated games, but that's all. I would be very OK to make the jump to darkradiant, I'm focusing on netradiant because it us currently the most ready mapping tool for us, but this netradiant can become a backup editor stable and featureful enough to experiment on darkradiant later. See this thread on Unvanquished forum about darkradiant. See also that quick graph about alive projects we can move to or cherry-pick from.

I would be willing to help out a few hours a week, but I would need ‎instructions what to do and where to begin. I can program, but I'm not good enough at it to implement any of the above (or I would have attempted it by now).

I feel the same, but I know that by walking small steps after small steps things are getting done (and some not ).

Also, I think, it was a bad idea for every Q3 mod to become standalone. If there would be a chance for a number of games to share a single engine again, this would help to share a player base and assemble forces.

Yeah, that was both a bad idea and a big mistake. That happened because of two things:

1. the engine had be hardcoded for some things, hence requiring the rebuilt and if rebuilt is required, you already have a standalone before wanting it
2. mindset: people felt their project were not complete by using a ready-to-use engine, with a kind of hierarchy between a mod running on own engine and those running on upstream engine are a mod (or worst, like UrbanTerror did, buying a Q3 proprietary license to feel to be a real game and not to be a mod any more)

[edit: there is a third thing, the 0 one: id tech 3 is designed to be sold on that purpose, it also affects the mindset a lot but in a different way: it makes people think “that's the way to do it” not because of self-esteem and feeling like that, but because of cargo cult]

For the first issue things are done step after step to make the engine entirely agnostic, I hope it will become a thing soon. Even if not complete yet, I think things are already better than original id Tech 3 on that part.

For the second issue, well, time passes and solves things by itself. Also, with all those free-to-use or free-to-start-with out there, the only remaining people having inferiority complex to not have to patch the engine would be some old quake3 moders, and even for those, time passed.

[Megaman_90]

I made an account just to post this. I played this game countless hours years ago, I would love to see the best free shooter in the world get updated.

Heck I would still play the old game now; if people still played it. It would be great if you could get the new SG on steam.

[illwieckz]

I made an account just to post this.

Great!

the best free shooter in the world

I agree!

It would be great if you could get the new SG on steam.

Steam requires all the assets origin and permission being verified on a per-file basis, that's probably the most common reason some very old community games got greenlit but failed to release. That's why it must be a requirement to ask for clear licensing (like CC By SA 4.0 or similar) from the start when starting a new project, because no one knows what will happens in 20 years, and perhaps one day the “but who cares ?” or “no one will sue”, or even the “I don't put a licence in order to not bore you” from year 2000 will not be ok. ¯\_(ツ)_/¯

[-Murdoc-]

Hello there ! I'm glad to see SG revival ! I did't play the game since 3 or 4 years but i still keep on eye here
I hope it will be a good new start for the game and his community. Enjoy !

On compte sur vous les gars !

[-Murdoc-]

It's an adaptation of SG ioquake to daemon or you'll rewrite the game code ?
The new game will be a SG 1.2 or a 2.0 ? I mean a new game or an evolution of 1.1 ?