Last-minute wishes for the next map format

[stef]

I'm just finishing up changing the map format to version 10. So far, I've added a few things:

* free-form extensions for future additions which won't break the map format anymore - current extensions include embedded map config, undo-redo history, vantage points and various attribtes like author and description.

* three new attributes for map entities (so far only used for map models)

* attributes to change pitch and roll of map models

* changed waterlevel to allow 0.1 cube increments

Right now, I'm changing several entity attributes to use higher resolution (at the cost of reduced maximum values).

I did try adding a mechanism to control map model animation offsets to improve the looks of several identical map models near each other... however, it appears, that there is no way to fix that...

Should I look into anything else while I'm at it? Last call...

[RKTnoob]

can you explain more about vantage points and the three new attributes for mapmodels?
As for wishes, I'd like more control, less restrictions like always, but if it doesn't happen, at least the fix for the akimbo not downloading relevant mapmodels, even if it's not directly tied to the map format verison.

[Pi_Halo]

I've always wondered what the work load would be on redoing the lights to something more useful that cylinders would be. I am curious to know the effort it would take to do such. Maybe I can be enlighten on this matter? Maybe not?

[stef]

Vantage points are just camera positions to provide a preview before first spawn. Not yet used, though.

Two of the three new attributes provide pitch and roll for mapmodels. Third one is unused.

The lighting of the map geometry is fully 2D. Each cube has 3 values for R, G and B. All lighting data is required to fit into that: one light per cube. More complex lighting would require a more detailed database to store the map geometry - which is basically what cube 2 does. Trying to implement that in cube 1 would be reinventing the wheel.

[Ronald_Reagan]

It is important to note that I believe the scatter of the lights isn't fully static anymore (iirc), because of this you map will look the same every time you load it. Which makes it loads easier to map correctly.

[Robtics]

are textured clips a possibility?

[Mr.Floppy]

Maybe this does exist already, but I always wanted to have a time stamp (local system time) baked into the mapfile on /savemap, which then can be called and displayed by some simple command.

[stef]

You don't want textured clips. You want to map for cube 2.

It's weird - I thought, there were at least timestamps on xmaps, but apparently, there are none. We do have timestamps on backup files, though. Of ac_desert_1429805894.BAK, the number is the time, the backup was created. A timestamp inside the cgz would be for informational purposes only - the "newer version" (for example on a server) would still be determined by the revision counter.

I'm bringing this over from the other thread...

I understand why some mappers ask for more control over client graphic settings and such, since it might open opportunities to circumvent some of the given limits. Though, as I have said already, it is not acceptable to allow mappers to change the users' personal settings in first place. Those methods are most likely going to make things less stable, because no mapper will be able to foresee the actual outcome on all those various clients. After all it's the mappers' job to deal with this boundaries, at least that's my opinion.

Would map options to disable certain features be of use? For example, setting a maximum value for waveheight could help maps like ac_desert, where the only water is in a well, and waves look a bit weird. Some map environments may call to disable water reflection and refraction as well. It would be ugly to implement, so I'd like to know, if it would be of actual practical use...

The only feature I can think of which could be implemented rather easily and would bring great benefit are negative light entities, which then will be effectively shadow entities. There has been a mod around quite some time ago.

Is that mod available somewhere? The question is mostly, how should the shadow entity behave. Regular light entities throw shadows at map geometry - I'd guess, a shadow entity would not need to do that ;)

Would a circular shadow area, with a core radius of constant darkness and an outer area of decreasing darkness be sufficient? Uninflicted by map geometry and rendered after all regular lights? (That would mean, a shadow would reach through walls.) Would a shadow need coloring, or should it be "white"? Should the shadow decrease the light by absolute numbers or as a percentage?

You are right: the implementation of shadow entities is fairly simple. But to design them to be easy to use is a bit harder :)

Currently, light calculation starts with the ambient light value as a start value and then all lights add to those values (up to a max value of 255). If we add shadow entities to subtract from that value, we also need to clarify, if a shadow should be able to cause a cube to be darker than ambient light - or if ambient level should stay the lowest possible value.

[Mr.Floppy]

OK, I've got little time so here's a rather quick response. Hope it will be of help. :)

I only would need that timestamp to find a particular mapversion through the mapping process. Maybe xmaps will make things easier, but I still haven't tested this feature... Sorry.

The wave hight parameter surely makes sense to be configurable by mappers. However, it obviously would take a little more time to cover all possible settings appropriately. Is anyone (RTKnoob?) up to compile a list of settings he likes to configure as a mapper and put them up for discussion. That would speed up the process and we wouldn't have to take care of stuff nobody ever was interested in anyway.

...and yes, it would be useful to disable such setting changes, if it is decided to add this feature.

I can't find that mod anymore, maybe someone else could at least remember the guys name who put it online.

However, the shadow entity could be working exactly like a light entity, expect it does subtract instead of add to the light value. Of course zero will be the lowest value and leave the particular scene unlit = black. It should also subtract ambient lights (in fact ambient lighting would be way more useful than it is now!) and it should not reach through walls, at least as long as we stick to a cylinder shaped shadow-impact-zone.

Remains the question how to deal with models and their shadows I guess...

[stef]

BTW: during the loading of a map, all light entities are reduced to a max radius of 32 cubes - but during editing, larger values can be used (which will be capped after next load).

Would it be better, to limit the editing also to a max of 32? Or is it useful to have lights that will be capped during next save-load cycle?

Also: until now, light entities with negative radius are possible but are ignored completely. Would that be a nice enough way to encode shadow entities?

[Pi_Halo]

What about negative height mapmodels? You know, mapmodels that are technically starting underground? Felix-the-ghost made a mapping client with such if I do recall correctly. Also, what about better coop settings. A lot of stuff can't be done quickly in coop, like using the slopes and arches command. To do heightfields in coop you have to literally do them, no quick way.

[stef]

You don't need a special client to get mapmodels underground. You just have to know how to edit your map config. The mapmodel command also has a "elevation" attribute - which unlike the mapmodel entity allows negative numbers. I've written a script to decrease the elevation in the map config and simultaneously increase the elevation of all mapmodels using that slot - which in effect changes nothing visible on the map, but gives the entities "leg room" to lower the model. https://github.com/ac-stef/AC/commit/358335c1

Only basic commands are set up for coop edit. The other commands are supposed to be used while disconnected and then distributed with sendmap/getmap.

Some basic slopes could easily be scripted with only using multiplayer-capable commands. Apparently, so far, no one saw the need for that.

[Mr.Floppy]

Would it be better, to limit the editing also to a max of 32? Or is it useful to have lights that will be capped during next save-load cycle?

I usually just put some huge lights arround randomly when starting a new map, so I won't have to make use of fullbright. Those lights of course will be removed later. I believe others do this as well.

On the other hand, one could put quite some information into the rest of that byte. Maybe it's only me, but wouldn't it be nice to have some advanced light effects, like blinking regularly or randomly, or something like 'pulsing' in order to have some glowing effects? You could store that information in that remaining 223 bits (well, technically it's 3 bits I think) rather than leave them 'unused'. However, I sense using one byte for multiple purposes like that is beyond bad style, isn't it? :P

Also: until now, light entities with negative radius are possible but are ignored completely. Would that be a nice enough way to encode shadow entities?

Yes, probably that never-to-be-found-again mod just made use of that.

[stef]

Those lights of course will be removed later.

In fact, they will be reduced automatically during next map load.

Maybe it's only me, but wouldn't it be nice to have some advanced light effects, like blinking regularly or randomly, or something like 'pulsing' in order to have some glowing effects?

There are now three unused attributes on all entities, so storing more values is not a problem.
However - adding dynamic effects doesn't integrate with the light management of the engine: everything is calculated exactly once, during map load.
Blinking can be done with animated map models - but without affecting the lighting.

The problem with blinking is, that even three parameters wouldn't get much use out of it: you need at least one for the speed - which leaves just two to describe the blinking itself... should it be regular sine blinking or flashing like an alarm, should it be regular or random. And in the end, it will probably the same problem as with animated map models: you can't use more than one, or it will look like shit because it's weirdly synced. As I mentioned in the first post - I did try to find a solution for the map models - but nothing looks good...

About the shadow entities: should shadow subtract absolute light from it's area - or reduce the light by a percentage? Subtracting constant values would, for example, reduce 120 to 80 and a neighboring 60 to 20 but removing a percentage would change 120 to 80 and 60 to 40.

Absolute reduction makes it easier to get already quite dark areas even darker but a reduction by a percentage would keep the original light profile and just make it darker altogether.

PS: the current state can be tested under https://github.com/ac-stef/AC/commits/mapformat10 - it also includes automapcfg
(don't use this to edit maps that you want to keep - it's not finished)

[stef]

I just committed a test version for particle emitting map entities. Check out and compile the latest "mapformat10", goto edit mode and try "/newent particle 5 1 1" :)
It's quite rudimentary and we'd have to add other particles, for example, to look like steam coming out of a vent. If used carefully, it's a pretty cheap effect, regarding graphics performance.

[ExodusS]

You don't want textured clips. You want to map for cube 2.

Why are you always so sure even if you are wrong? I guess you only see mappers using textured clips to create stages and level while it's not that at all... I would really see you creating a high quality map with only actual mapper's stuff, so that you will be able to understand the struggle and what textured clips would bring to us.

[Mr.Floppy]

Hell yeah! Particles! I'm going to check out that branch tomorrow. :)

[Luc@s]

What i would like to see : proper hit detection (taking into account mapmodels shape), bullet penetration, and bullet/bouncing penetration properties texture/mapmodel dependant. Might not require map format change (the attributes can be set into the map config file)

[Alien]

Preventing saving map with map restriction error. Doesn't matter if in coop or in single mode. Next it would be nice to load old map and save it new format.

[XFA]

Map mode restrictions, ie. map can't be played on teammodes

[stef]

Preventing saving map with map restriction error.

Map restrictions will be handled differently in the future - but that's not an issue for the file format.

Next it would be nice to load old map and save it new format.

All maps are converted during load (as it has always been). This is map format 10. The format versions 0..9 can all still be loaded (at least in theory - I don't have any older than format 6).

One question would be, if it would be helpful, if newer versions could still save to format 9.

Map mode restrictions, ie. map can't be played on teammodes

Has been partially in place since AC 1.0 (if a map has no team spawns, the server won't allow votes for team modes).
Format 10 has one of those free-form extensions in planning for more detailed mode descriptions - with info for player numbers and preferred modes. It will contain information similar to that what is currently written into good maprots - like minimum player numbers for certain modes.

PS: it's too early to expect great particle emitters: I just enabled what was already implemented. But I'll try to add at least a usable steam emitter. But that's not a file format change, so it'll have to wait.

[Thrawn]

PS: it's too early to expect great particle emitters: I just enabled what was already implemented. But I'll try to add at least a usable steam emitter. But that's not a file format change, so it'll have to wait.

Particle emitters might be easier to use if you can rotate them like mapmodels. Presumably that would be a file format change, which is why I'm bringing it up.

[stef]

Map format changes need to happen at a version bump, if they change existing stuff. Adding a new entity type can be done without changing the format itself. Older clients just ignore entities that they don't know.

[Thrawn]

Stef asked me to post this here.
Here is the compiled binary of the latest (as of the time of writing) version of the experimental mapformat10 branch, for windows: ac_client.zip. It was built on Win 7 64-bit, but it should work on other versions of windows as well (Including 32-bit). If anyone could test that, it would be helpful, since I don't have any other versions of windows to test on.  If you don't know what to do with this, unzip the binary, reinstall AC somewhere else, and drop in this ac_client.exe replacing the old one.
For the security conscious: [Virus Total link]

Edit: Update: Newer version here: ac_client.zip
[Virus Total]

Edit2: Apparently, the mapformat10 branch is not based off the master branch as had thought, which means it's not as simple as I thought to test the binary. Do not drop the binary into an existing 1.2.0.2 installation, as it will most likely corrupt your saved.cfg (Sorry Nightmare! >_<). Instead, you'll need to check out the mapformat10 files and drop the binary in there. (If you don't want to deal with git, use this link, for convenience: https://github.com/ac-stef/AC/archive/mapformat10.zip )

[ExodusS]

Is that possible for the client to recognize the map format and so read the map as it's from 1.2 or if it's older? I mean by this, is that possible to have both map formats compatibles because there are thousands of old maps that have not been converted yet and converting all of them often cause issues so it would requires too much time to just make them playable. Since we changed the .cfg of all maps and we moved some files, there are too much maps that became unplayable. Also I don't know if it's offtopic but the autopackager does not work well at all, 100% of the time there are textures/models/sounds missing, /getmap won't fix anything.

[Luc@s]

Is that possible for the client to recognize the map format and so read the map as it's from 1.2 or if it's older? I mean by this, is that possible to have both map formats compatibles because there are thousands of old maps that have not been converted yet and converting all of them often cause issues so it would requires too much time to just make them playable. Since we changed the .cfg of all maps and we moved some files, there are too much maps that became unplayable. Also I don't know if it's offtopic but the autopackager does not work well at all, 100% of the time there are textures/models/sounds missing, /getmap won't fix anything.

thats how it always worked

map format != cfg format

[stef]

As I've said, AC can read all map formats since the first cube 1 map existed. The map config format never really changed - the paths for the media files did. And for those: I'm really pissed, that there are so many server owners who don't give a shit and still have unconverted map configs on their servers.
FYI, there won't be polls for those servers. They will simply be removed from the list.

[SELECT ALL] Code:

grep \"bench *.cfg

will find most of the unconverted configs, if you can't be bothered to load every map on your server at least once. Fix your damn servers! It's been over a year!
PS: If your server is taken off the list for delivering broken map configs... who knows... maybe, it'll also take over a year to get it back on the list?

EDIT: This is offtopic here - continue this in http://forum.cubers.net/thread-8249.html

[stef]

Last call...

[Mr.Floppy]

Are high-res textures considered with format 10? I have no idea whether there's even anything additional needed, but I guess nobody minds a reminder.

Will there be an accessible and 'readable' documentation about the new format? That would be highly appreciated.

[Luc@s]

Are high-res textures considered with format 10? I have no idea whether there's even anything additional needed, but I guess nobody minds a reminder.

Will there be an accessible and 'readable' documentation about the new format? That would be highly appreciated.

not map format specific